http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a00800f67d5.shtmlhttp://www.cert.org/advisories/CA-1996-21.htmlhttp://www.cert.org/advisories/CA-1995-01.html

ContentsAbstractPrerequisitesRequirementsComponents UsedConventionsProblem DescriptionThe TCP SYN AttackDefending Against Attacks on Network DevicesDevices Behind FirewallsDevices Offering Publicly Available Services (Mail Servers, Public Web Servers)Preventing A Network from Unwittingly Hosting an AttackPreventing Transmission of Invalid IP AddressesPreventing Reception of Invalid IP AddressesRelated InformationRelated Cisco Support Community DiscussionsAbstractThere is a potential denial of service attack at internet service providers (ISPs) that targets network devices. TCP SYN attack: A sender transmits a volume of connections that cannot be completed. This causes the connection queues to fill up, thereby denying service to legitimate TCP users.This paper contains a technical description of how the potential TCP SYN attack occurs and suggested methods for using Cisco IOS software to defend against it.Note:Cisco IOS 11.3 software has a feature to actively prevent TCP denial of service attacks. This feature is described in the documentConfiguring TCP Intercept (Prevent Denial-of-Service Attacks).PrerequisitesRequirementsThere are no specific prerequisites for this document.Components UsedThis document is not restricted to specific software and hardware versions.The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.ConventionsFor more information on document conventions, see theCisco Technical Tips Conventions.Problem DescriptionThe TCP SYN AttackWhen a normal TCP connection starts, a destination host receives a SYN (synchronize/start) packet from a source host and sends back a SYN ACK (synchronize acknowledge). The destination host must then hear an ACK (acknowledge) of the SYN ACK before the connection is established. This is referred to as the "TCP three-way handshake."While waiting for the ACK to the SYN ACK, a connection queue of finite size on the destination host keeps track of connections waiting to be completed. This queue typically empties quickly since the ACK is expected to arrive a few milliseconds after the SYN ACK.The TCP SYN attack exploits this design by having an attacking source host generate TCP SYN packets with random source addresses toward a victim host. The victim destination host sends a SYN ACK back to the random source address and adds an entry to the connection queue. Since the SYN ACK is destined for an incorrect or non-existent host, the last part of the "three-way handshake" is never completed and the entry remains in the connection queue until a timer expires, typically for about one minute. By generating phony TCP SYN packets from random IP addresses at a rapid rate, it is possible to fill up the connection queue and deny TCP services (such as e-mail, file transfer, or WWW) to legitimate users.There is no easy way to trace the originator of the attack because the IP address of the source is forged.The external manifestations of the problem include inability to get e-mail, inability to accept connections to WWW or FTP services, or a large number of TCP connections on your host in the state SYN_RCVD.Defending Against Attacks on Network DevicesDevices Behind FirewallsThe TCP SYN attack is characterized by an influx of SYN packets from random source IP addresses. Any device behind a firewall that stops inbound SYN packets is already protected from this mode of attack and no further action is needed. Examples of firewalls include a Cisco Private Internet Exchange (PIX) Firewall or a Cisco router configured with access lists. For examples of how to set up access lists on a Cisco router, please refer to the documentIncreasing Security On IP Networks.Devices Offering Publicly Available Services (Mail Servers, Public Web Servers)Preventing SYN attacks on devices behind firewalls from random IP addresses is relatively simple since you can use access lists to explicitly limit inbound access to a select few IP addresses. However, in the case of a public web server or mail server facing the Internet, there is no way to determine which incoming IP source addresses are friendly and which are unfriendly. Therefore, there is no clear cut defense against an attack from a random IP address. Several options are available to hosts: Increase the size of the connection queue (SYN ACK queue). Decrease the time-out waiting for the three-way handshake. Employ vendor software patches to detect and circumvent the problem (if available).You should contact your host vendor to see if they have created specific patches to address the TCP SYN ACK attack.Note:Filtering IP addresses at the server is ineffective since an attacker can vary his IP address, and the address may or may not be the same as that of a legitimate host.Preventing A Network from Unwittingly Hosting an AttackSince a primary mechanism of this denial of service attack is the generation of traffic sourced from random IP addresses, we recommend filtering traffic destined for the Internet. The basic concept is to throw away packets with invalid source IP addresses as they enter the Internet. This does not prevent a denial of service attack on your network, but will help attacked parties rule out your location as the source of the attacker. In addition, it makes your network less attractive as a base for this class of attack.Preventing Transmission of Invalid IP AddressesBy filtering packets on your routers that connect your network to the Internet, you can permit only packets with valid source IP addresses to leave your network and get into the Internet.For example, if your network consists of network 172.16.0.0, and your router connects to your ISP using a serial 0/1 interface, you can apply the access list as follows:access-list 111 permit ip 172.16.0.0 0.0.255.255 anyaccess-list 111 deny ip any any log

interface serial 0/1ip access-group 111 outNote:The last line of the access list determines if there is any traffic with an invalid source address entering the Internet. It is not crucial to have this line, but it will help locate the source of the possible attacks.Preventing Reception of Invalid IP AddressesFor ISPs who provide service to end networks, we highly recommend the validation of incoming packets from your clients. This can be accomplished by the use of inbound packet filters on your border routers.For example, if your clients have the following network numbers connected to your router via a serial interface named "serial 1/0", you can create the following access list:The network numbers are 192.168.0.0 to 192.168.15.0, and 172.18.0.0.

access-list 111 permit ip 192.168.0.0 0.0.15.255 anyaccess-list 111 permit ip 172.18.0.0 0.0.255.255 anyaccess-list 111 deny ip any any log

interface serial 1/0ip access-group 111 inNote:The last line of the access list determines if there is any traffic with invalid source addresses entering the Internet. It is not crucial to have this line, but it will help locate the source of the possible attack.This topic has been discussed in some detail on the NANOG [North American Network Operator1s Group] mailing list. The list archives are located at:http://www.merit.edu/mail.archives/nanog/index.htmlFor a detailed description of the TCP SYN denial of service attack and IP spoofing, see:http://www.cert.org/advisories/CA-1996-21.htmlhttp://www.cert.org/advisories/CA-1995-01.htmlCERTAdvisory CA-1996-21 TCP SYN Flooding and IP Spoofing AttacksOriginal issue date: September 19, 1996Last revised: November 29, 2000Updated vendor information for the Linux kernel.A complete revision history is at the end of this file.This advisory supersedes the IP spoofing portion ofCA-95.01.Two "underground magazines" have recently published code to conduct denial-of-service attacks by creating TCP "half-open" connections. This code is actively being used to attack sites connected to the Internet. There is, as yet, no complete solution for this problem, but there are steps that can be taken to lessen its impact. Although discovering the origin of the attack is difficult, it is possible to do; we have received reports of attack origins being identified.Any system connected to the Internet and providing TCP-based network services (such as a Web server, FTP server, or mail server) is potentially subject to this attack. Note that in addition to attacks launched at specific hosts, these attacks could also be launched against your routers or other network server systems if these hosts enable (or turn on) other TCP services (e.g., echo). The consequences of the attack may vary depending on the system; however, the attack itself is fundamental to the TCP protocol used by all systems.If you are an Internet service provider, please pay particular attention to Section III and Appendix A, which describes step we urge you to take to lessen the effects of these attacks. If you are the customer of an Internet service provider, please encourage your provider to take these steps.This advisory provides a brief outline of the problem and a partial solution. We will update this advisory as we receive new information. If the change in information warrants, we may post an updated advisory on comp.security.announce and redistribute an update to our cert-advisory mailing list. As always, the latest information is available at the URLs listed at the end of this advisory.

I. DescriptionWhen a system (called the client) attempts to establish a TCP connection to a system providing a service (the server), the client and server exchange a set sequence of messages. This connection technique applies to all TCP connections--telnet, Web, email, etc.The client system begins by sending a SYN message to the server. The server then acknowledges the SYN message by sending SYN-ACK message to the client. The client then finishes establishing the connection by responding with an ACK message. The connection between the client and the server is then open, and the service-specific data can be exchanged between the client and the server. Here is a view of this message flow: Client Server ------ ------ SYN-------------------->

Client and server can now send service-specific dataThe potential for abuse arises at the point where the server system has sent an acknowledgment (SYN-ACK) back to client but has not yet received the ACK message. This is what we mean by half-open connection. The server has built in its system memory a data structure describing all pending connections. This data structure is of finite size, and it can be made to overflow by intentionally creating too many partially-open connections.Creating half-open connections is easily accomplished with IP spoofing. The attacking system sends SYN messages to the victim server system; these appear to be legitimate but in fact reference a client system that is unable to respond to the SYN-ACK messages. This means that the final ACK message will never be sent to the victim server system.The half-open connections data structure on the victim server system will eventually fill; then the system will be unable to accept any new incoming connections until the table is emptied out. Normally there is a timeout associated with a pending connection, so the half-open connections will eventually expire and the victim server system will recover. However, the attacking system can simply continue sending IP-spoofed packets requesting new connections faster than the victim system can expire the pending connections.In most cases, the victim of such an attack will have difficulty in accepting any new incoming network connection. In these cases, the attack does not affect existing incoming connections nor the ability to originate outgoing network connections.However, in some cases, the system may exhaust memory, crash, or be rendered otherwise inoperative.The location of the attacking system is obscured because the source addresses in the SYN packets are often implausible. When the packet arrives at the victim server system, there is no way to determine its true source. Since the network forwards packets based on destination address, the only way to validate the source of a packet is to use input source filtering (see Appendix A).II. ImpactSystems providing TCP-based services to the Internet community may be unable to provide those services while under attack and for some time after the attack ceases. The service itself is not harmed by the attack; usually only the ability to provide the service is impaired. In some cases, the system may exhaust memory, crash, or be rendered otherwise inoperative.III. SolutionThere is, as yet, no generally accepted solution to this problem with the current IP protocol technology. However, proper router configuration can reduce the likelihood that your site will be the source of one of these attacks.Appendix A contains details about how to filter packets to reduce the number of IP-spoofed packets entering and exiting your network. It also contains a list of vendors that have reported support for this type of filtering.NOTE to Internet Service Providers:We STRONGLY urge you to install these filters in your routers to protect your customers against this type of an attack. Although these filters do not directly protect your customers from attack, the filters do prevent attacks from originating at the sites of any of your customers. We are aware of the ramifications of these filters on some current Mobile IP schemes and are seeking a position statement from the appropriate organizations.NOTE to customers of Internet service providers:We STRONGLY recommend that you contact your service provider to verify that the necessary filters are in place to protect your network.Many networking experts are working together to devise improvements to existing IP implementations to "harden" kernels to this type of attack. When these improvements become available, we suggest that you install them on all your systems as soon as possible. This advisory will be updated to reflect changes made by the vendorIV. Detecting an AttackUsers of the attacked server system may notice nothing unusual since the IP-spoofed connection requests may not load the system noticeably. The system is still able to establish outgoing connections. The problem will most likely be noticed by client systems attempting to access one of the services on the victim system.To verify that this attack is occurring, check the state of the server system's network traffic. For example, on SunOS this may be done by the command: netstat -a -f inetNote that use of the above command depends on the OS version, for example for a FreeBSD system use netstat -s |grep "listenqueue overflows"Too many connections in the state "SYN_RECEIVED" could indicate that the system is being attacked.

Appendix A - Reducing IP Spoofed Packets1. Filtering InformationWith the current IP protocol technology, it is impossible to eliminate IP-spoofed packets. However, you can take steps to reduce the number of IP-spoofed packets entering and exiting your network.Currently, the best method is to install a filtering router that restricts the input to your external interface (known as an input filter) by not allowing a packet through if it has a source address from your internal network. In addition, you should filter outgoing packets that have a source address different from your internal network to prevent a source IP spoofing attack from originating from your site.The combination of these two filters would prevent outside attackers from sending you packets pretending to be from your internal network. It would also prevent packets originating within your network from pretending to be from outside your network. These filters will *not* stop all TCP SYN attacks, since outside attackers can spoof packets from *any* outside network, and internal attackers can still send attacks spoofing internal addresses.We STRONGLY urge Internet service providers to install these filters in your routers.In addition, we STRONGLY recommend customers of Internet service providers to contact your service provider to verify that the necessary filters are in place to protect your network.2. Vendor InformationThe following vendor(s) have reported support for the type of filtering we recommend and provided pointers to additional information that describes how to configure your router. If we hear from other vendors, we will add their information to the "Updates" section at the end of this advisory.If you need more information about your router or about firewalls, please contact your vendor directly.CiscoRefer to the section entitled "ISP Security Advisory" on http://www.cisco.com for an up-to-date explanation of how to address TCP SYN flooding on a Cisco router.NOTE to vendors:If you are a router vendor who has information on router capabilities and configuration examples and you are not represented in this list, please contact the CERT Coordination Center at the addresses given in the Contact Information section below. We will update the advisory after we hear from you.3. Alternative for routers that do not support filtering on the inbound sideIf your vendor's router does not support filtering on the inbound side of the interface or if there will be a delay in incorporating the feature into your system, you may filter the spoofed IP packets by using a second router between your external interface and your outside connection. Configure this router to block, on the outgoing interface connected to your original router, all packets that have a source address in your internal network. For this purpose, you can use a filtering router or a UNIX system with two interfaces that supports packet filtering.Note: Disabling source routing at the router does not protect you from this attack, but it is still good security practice to follow.On the input to your external interface, that is coming from the Internet to your network, you should block packets with the following addresses: Broadcast Networks: The addresses to block here are network 0 (the all zeros broadcast address) and network 255.255.255.255 (the all ones broadcast network). Your local network(s): These are your network addresses Reserved private network numbers: The following networks are defined as reserved private networks, and no traffic should ever be received from or transmitted to these networks through a router: 10.0.0.0 - 10.255.255.255 10/8 (reserved) 127.0.0.0 - 127.255.255.255 127/8 (loopback) 172.16.0.0 - 172.31.255.255 172.16/12 (reserved) 192.168.0.0 - 192.168.255.255 192.168/16 (reserved)

The CERT Coordination Center staff thanks the team members of NASIRC for contributing much of the text for this advisory and thanks the many experts who are devoting time to addressing the problem and who provided input to this advisory.

UPDATES3COMPlease refer to the "Network Security Advisory" for a thorough discussion of how to address TCP SYN flooding attacks on a 3Com router:http://www.3com.com/Berkeley Software Design, Inc.BSDI has patches available.PATCHK210-021 (ftp://ftp.bsdi.com/bsdi/patches/patches-2.1/K210-021)md5 checksum: c386e72f41d0e409d91b493631e364dd K210-021This patch adds two networking features that can help defeat and detect some types of denial of service attacks.This patch requires U210-025 which provides new copies ofsysctl(8)andnetstat(1)for configuration and monitoring of these new features.PATCHK210-022 (ftp://ftp.bsdi.com/bsdi/patches/patches-2.1/K210-22)md5 checksum: 9ec62b5e9cc424b9b42089504256d926 K210-022This patch adds a TCP SYN cache which reduces and/or eliminates the effects of SYN-type denial of service attacks such as those discussed in CERT advisory CA 96.21.PATCHU210-025 (ftp://ftp.bsdi.com/bsdi/patches/patches-2.1/U210-025)md5 checksum: d2ee01238ab6040e9b7a1bd2c3bf1016 U210-025This patch should be installed in conjunction with IP source address check and IP fragmentation queue limit patch (K210-021) and SYN flooding patch (K210-022).Additional details about these patches are available fromhttp://www.bsdi.comftp://ftp.bsdi.comHewlett-Packard CompanyHPSBUX9704-060Description: SYN Flooding Security Vulnerability in HP-UXHEWLETT-PACKARD SECURITY BULLETIN: #00060Security Bulletins are available from the HP ElectronicSupport Center via electronic mail.User your browser to get to the HP Electronic SupportCenter page at:http://us-support.external.hp.com(for US, Canada, Asia-Pacific, & Latin-America)http://europe-support.external.hp.com(for Europe)IBM CorporationAny system that is connected to a TCP/IP-based network (Internet or intranet) and offers TCP-based services is vulnerable to the SYN flood attack. The attack does not distinguish between operating systems, software version levels, or hardware platforms; all systems are vulnerable. IBM has released AIX operating system fixes for the SYN flood vulnerability.NOTE: If you are using the IBM Internet Connection Secured Network Gateway (SNG) firewall software, you must also apply the fixes listed in the next section.The following Automated Program Analysis Reports (APARs) for IBM AIX are now available to address the SYN flood attack:AIX 3.2.5No APAR available; upgrade to AIX 4.x recommendedAIX 4.1.xAPAR - IX62476AIX 4.2.xAPAR - IX62428Fixes for IBM SNG FirewallThe following Automated Program Analysis Reports (APARs) for the IBM Internet Connection Secured Network Gateway firewall product are now available to address the SYN flood and "Ping o' Death" attacks:NOTE: The fixes in this section should ONLY be applied to systems running the IBM Internet Connection Secured Network Gateway (SNG) firewall software. They should be applied IN ADDITION TO the IBM AIX fixes listed in the previous section.IBM SNG V2.1APAR - IR33376 PTF UR46673IBM SNG V2.2APAR - IR33484 PTF UR46641Obtaining FixesIBM AIX APARs may be ordered using Electronic Fix Distribution (via the FixDist program), or from the IBM Support Center. For more information on FixDist, and to obtain fixes via the Internet, please referencehttp://service.software.ibm.com/aixsupport/or send electronic mail to"aixserv@austin.ibm.com" with the word "FixDist" in the "Subject:" line.LinuxA patch for version 2.0.29 of the linux kernel source is available from:http://www.kernel.org/pub/linux/kernel/v2.0/patch-2.0.30.gzThe patch allows tcp/ip processing to continue as normal, until the queue gets close to full. Then, instead of just sending the synack back, it sends a syn cookie back, and waits for a response to IT before sending the synack. When it sends the cookie, it clears the syn from the queue, so while under attack, the queue will never fill up. Cookies expire shortly after they are sent. Basically this prevents people from filling up the queue completely. No one flooding from a spoof will be able to reply to the cookie, so nothing can be overloaded. And if they aren't flooding from a spoof, they would be getting a cookie they would have to respond to, and would have a hard time responding to all the cookies and continuing the flood.Livingston Enterprises, Inc.Refer to the following Applications Note for more information on configuring a Livingston IRX or PortMaster to help block outgoing SYN attacks from an ISP's users:ftp://ftp.livingston.com/pub/le/doc/notes/filters.syn-attackSilicon Graphics, Inc.Updated Silicon Graphics information concerning SYN attacks can be found in SGI Security Advisory, "IRIX IP Spoofing/TCP Sequence Attack Update," 19961202-01-PX, issued on August 6, 1998.Patches are available via anonymous FTP and your service/support provider.The SGI anonymous FTP site is sgigate.sgi.com (204.94.209.1) or its mirror, ftp.sgi.com. Security information and patches can be found in the ~ftp/security and ~ftp/patches directories, respectfully.For subscribing to the wiretap mailing list and other SGI security related information, please refer to the Silicon Graphics Security Headquarters website located at:http://www.sgi.com/Support/securitySun Microsystems, Inc.Sun published a bulletin on October 9, 1996--Sun security bulletin number 00136. Sun Security Bulletins are available via thesecurity-alert@sun.comalias and on SunSolve.Note: Advisories from vendors listed in this section can also be found atftp://ftp.cert.org/pub/vendors/

This document is available from:http://www.cert.org/advisories/CA-1996-21.html

CERT/CC Contact InformationEmail:cert@cert.orgPhone:+1 412-268-7090 (24-hour hotline)Fax:+1 412-268-6989Postal address:CERT Coordination CenterSoftware Engineering InstituteCarnegie Mellon UniversityPittsburgh PA 15213-3890U.S.A.CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5) / EDT(GMT-4) Monday through Friday; they are on call for emergencies during other hours, on U.S. holidays, and on weekends.Using encryptionWe strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available fromhttp://www.cert.org/CERT_PGP.keyIf you prefer to use DES, please call the CERT hotline for more information.Getting security informationCERT publications and other security information are available from our web sitehttp://www.cert.org/* "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office.

NO WARRANTYAny material furnished by Carnegie Mellon University and the Software Engineering Institute is furnished on an "as is" basis. Carnegie Mellon University makes no warranties of any kind, either expressed or implied as to any matter including, but not limited to, warranty of fitness for a particular purpose or merchantability, exclusivity or results obtained from use of the material. Carnegie Mellon University does not make any warranty of any kind with respect to freedom from patent, trademark, or copyright infringement.

Conditions for use, disclaimers, and sponsorship informationCopyright 1996, 1997, 1998, 1999, 2000 Carnegie Mellon University.

Revision HistoryNov. 29, 2000 Updated vendor information for the Linux kernel.Aug. 24, 1998 Updated vendor information for Silicon Graphics, Inc.Sep, 24, 1997 Updated copyright statementJuly 18, 1997 Updates - added informationMay 08, 1997 Updates - updated vendor information for Hewlett-Packard.Jan. 02, 1997 Updates - added or modified vendor information for SGI, Livingston, HP, 3COM.Dec. 19, 1996 Updates - corrected Sun Microsystems security-alert email address.Dec. 10, 1996 Appendix A, #3 - corrected next to last reserved private network number entry.Dec. 09, 1996 Updates - added IBM patch information.Nov. 12, 1996 Introduction, paragraph 2 - added some clarification.Oct. 10, 1996 Updates - added a pointer to Sun Microsystems advisory. added a pointer to the CERT /pub/vendors directory.Oct. 08, 1996 Appendix A, #3 - revised the last item, reserved private network numbers Updates - added BSDI patch information.Oct. 07, 1996 Updates - added a pointer to Silicon Graphics advisory.Sep. 24, 1996 Modified the supersession statement.

CERTAdvisory CA-1995-01 IP Spoofing Attacks and Hijacked Terminal ConnectionsOriginal issue date: January 23, 1995Last revised: September 23, 1997Updated Copyright StatementA complete revision history is at the end of this file.The IP Spoofing portion of this advisory has been superseded byCA-96.21The CERT Coordination Center has received reports of attacks in which intruders create packets with spoofed source IP addresses. These attacks exploit applications that use authentication based on IP addresses. This exploitation leads to user and possibly root access on the targeted system. Note that this attack does not involve source routing. Recommended solutions are described in Section III below.In the current attack pattern, intruders may dynamically modify the kernel of a Sun 4.1.X system once root access is attained. In this attack, which is separate from the IP spoofing attack, intruders use a tool to take control of any open terminal or login session from users on the system. Note that although the tool is currently being used primarily on SunOS 4.1.x systems, the system features that make this attack possible are not unique to SunOS.We will update this advisory as we receive additional information. Please check advisory files regularly for updates that relate to your site.

I. DescriptionThis description summarizes both the IP spoofing technique that can lead to root access on a system and the tool that intruders are using to take over open terminal and login connections after they get root access. We are currently seeing attacks in which intruders combine IP spoofing with use of the tool. However, these are two separate actions. Intruders can use IP spoofing to gain root access for any purpose; similarly, they can highjack terminal connections regardless of their method of gaining root access.IP spoofingTo gain access, intruders create packets with spoofed source IP addresses. This exploits applications that use authentication based on IP addresses and leads to unauthorized user and possibly root access on the targeted system. It is possible to route packets through filtering-router firewalls if they are not configured to filter incoming packets whose source address is in the local domain. It is important to note that the described attack is possible even if no reply packets can reach the attacker.Examples of configurations that are potentially vulnerable include routers to external networks that support multiple internal interfaces routers with two interfaces that support subnetting on the internal network proxy firewalls where the proxy applications use the source IP address for authenticationThe IP spoofing attacks we are currently seeing are similar to those described in two papers: 1) "Security Problems in the TCP/IP Protocol Suite" by Steve Bellovin, published in _Computer Communication Review_ vol. 19, no. 2 (April 1989) pages 32-48; 2) "A Weakness in the 4.2BSD Unix TCP/IP Software" by Robert T. Morris. Both papers are available by anonymous FTP fromftp://ftp.research.att.com/dist/internet_securityBellovin paper:ipext.ps.ZMorris paper:117.ps.ZServices that are vulnerable to the IP spoofing attack includeSunRPC & NFSBSD UNIX "r" commandsanything wrapped by the tcp daemon wrappers - site dependent; check your configurationX windowsother applications that use source IP addresses for authenticationHijacking toolOnce the intruders have root access on a system, they can use a tool to dynamically modify the UNIX kernel. This modification allows them to hijack existing terminal and login connections from any user on the system.In taking over the existing connections, intruders can bypass one-time passwords and other strong authentication schemes by tapping the connection after the authentication is complete. For example, a legitimate user connects to a remote site through a login or terminal session; the intruder hijacks the connection after the user has completed the authentication to the remote location; the remote site is now compromised. (See Section I for examples of vulnerable configurations.)Currently, the tool is used primarily on SunOS 4.1.x systems. However, the system features that make this attack possible are not unique to SunOS.The CERT Coordination Center has been informed that any services that use Kerberos for authentication should not be vulnerable to an IP spoofing attack. For more information about Kerberos, seeftp://rtfm.mit.edu/pub/usenet/news.answers/kerberos-faqAlso note that the information and solution described in this advisory does not address the issue of mobile IP spoofing.II. ImpactCurrent intruder activity in spoofing source IP addresses can lead to unauthorized remote root access to systems behind a filtering-router firewall.After gaining root access and taking over existing terminal and login connections, intruders can gain access to remote hosts.III. SolutionsA. DetectionIP spoofingIf you monitor packets using network-monitoring software such as netlog, look for a packet on your external interface that has both its source and destination IP addresses in your local domain. If you find one, you are currently under attack. Netlog is available by anonymous FTP fromftp://net.tamu.edu/pub/security/TAMU/netlog-1.2.tar.gzMD5 checksum: 1dd62e7e96192456e8c75047c38e994bAnother way to detect IP spoofing is to compare the process accounting logs between systems on your internal network. If the IP spoofing attack has succeeded on one of your systems, you may get a log entry on the victim machine showing a remote access; on the apparent source machine, there will be no corresponding entry for initiating that remote access.Hijacking toolWhen the intruder attaches to an existing terminal or login connection, users may detect unusual activity, such as commands appearing on their terminal that they did not type or a blank window that will no longer respond to their commands. Encourage your users to inform you of any such activity. In addition, pay particular attention to connections that have been idle for a long time.Once the attack is completed, it is difficult to detect. However, the intruders may leave remnants of their tools. For example, you may find a kernel streams module designed to tap into existing TCP connections.B. PreventionIP spoofingThe best method of preventing the IP spoofing problem is to install a filtering router that restricts the input to your external interface (known as an input filter) by not allowing a packet through if it has a source address from your internal network. In addition, you should filter outgoing packets that have a source address different from your internal network in order to prevent a source IP spoofing attack originating from your site.The following vendors have reported support for this feature:Bay Networks/Wellfleet routers, version 5 and laterCabletron - LAN SecureCisco - RIS software all releases of version 9.21 and laterLivingston - all versions3COM, Cisco Systems, and Morning Star Technologies have provided detailed information, which you can find in Appendix A of this advisory.If you need more information about your router or about firewalls, please contact your vendor directly.If your vendor's router does not support filtering on the inbound side of the interface or if there will be a delay in incorporating the feature into your system, you may filter the spoofed IP packets by using a second router between your external interface and your outside connection. Configure this router to block, on the outgoing interface connected to your original router, all packets that have a source address in your internal network. For this purpose, you can use a filtering router or a UNIX system with two interfaces that supports packet filtering.NOTE:Disabling source routing at the router does not protect you from this attack, but it is still good security practice to do so.Additional information about protecting yourself from IP spoofing attacks is in Updates section at the end of this file; these updates were added after the initial release of the advisory.Hijacking toolThere is no specific way to prevent use of the tool other than preventing intruders from gaining root access in the first place. If you have experienced a root compromise, see Section C for general instructions on how to recover.C. Recovery from a UNIX root compromise1. Disconnect from the network or operate the system in single-user mode during the recovery. This will keep users and intruders from accessing the system.2. Verify system binaries and configuration files against the vendor's media (do not rely on timestamp information to provide an indication of modification). Do not trust any verification tool such ascmp(1)located on the compromised system as it, too, may have been modified by the intruder. In addition, do not trust the results of the standard UNIXsum(1)program as we have seen intruders modify system files in such a way that the checksums remain the same. Replace any modified files from the vendor's media, not from backups.-- or --Reload your system from the vendor's media.3. Search the system for new or modified setuid root files.4. find / -user root -perm -4000 -printIf you are using NFS or AFS file systems, use ncheck to search the local file systems.ncheck -s /dev/sd0a5. Change the password on all accounts.6. Don't trust your backups for reloading any file used by root. You do not want to re-introduce files altered by an intruder.

Appendix A: Vendor Information3COMThe following information has been provided by 3COM for their customers.

Begin Text Provided by 3COMThe following examples illustrate how NETBuilder software can beconfigured to support the CERT Advisory recommendations. Each ofthese examples assumes that the value of the -IP FilterDefActionparameter is configured to Forward.

Example 1:

This example illustrates a two-router solution where the internalnetwork is configured with non-contiguous IP network numbers. Thefilters are installed on the border router which can only have twointerfaces. In a two-port router, an output filter on one port isequivalent to an input filter on the other port. Please refer toFigure 1:

Figure 1: Non-Contiguous IP Networks

| | Border | | |Internal|--- 10.0.0.0 Outside --| Router |---|---| Router | | | |--- 20.0.0.0 | 30.0.0.0

The border router is configured with the following filters:

ADD -IP FilterAddrs 10.0.0.0/0.255.255.255 > 10.0.0.0/0.255.255.255 Discard

ADD -IP FilterAddrs 20.0.0.0/0.255.255.255 > 20.0.0.0/0.255.255.255 Discard

ADD -IP FilterAddrs 30.0.0.0/0.255.255.255 > 30.0.0.0/0.255.255.255 Discard

ADD -IP FilterAddrs 10.0.0.0/0.255.255.255 20.0.0.0/0.255.255.255 Discard

ADD -IP FilterAddrs 10.0.0.0/0.255.255.255 30.0.0.0/0.255.255.255 Discard

ADD -IP FilterAddrs 20.0.0.0/0.255.255.255 30.0.0.0/0.255.255.255 Discard

This configuration prevents the external attack and allows theinternal router to route traffic between networks 10.0.0.0, 20.0.0.0,and 30.0.0.0. This configuration also works for the cascade topologyshown in Figure 2.

Figure 2: Non-Contiguous IP Networks (alternate topology)

| | | Border | | |Internal| | |Internal| Outside ---| Router |---|---| Router |---|---| Router |--- 10.0.0.0 | | | | 30.0.0.0 20.0.0.0

Example 2:

The second example illustrates a two-router solution when the internalnetwork is configured with multiple subnets of the Class B networkaddress - 130.5.0.0. The subnet mask is 255.255.255.0. Please referto Figure 3.

Figure 3: Subnets on the Internal Network

| | Border | | |Internal|--- 130.5.2.0 Outside --| Router |---|---| Router | | | |--- 130.5.3.0 | 130.5.1.0 Subnet Mask = 255.255.255.0

The border router is configured with the following filter:

ADD -IP FilterAddrs 130.5.0.0/0.0.255.255 > 130.5.0.0/0.0.255.255 Discard

This configuration prevents the external attack and allows the internal routeto route traffic between all subnetworks of 130.5.0.0. In this example, asingle filter can protect multiple subnets.

Example 3:

The final example illustrates a two-router solution when the internalnetwork is configured with contiguous IP network numbers. Assume theservice provider has provided the subscriber with the CIDR block200.5.0.0/255.255.0.0. Please refer to Figure 4:

Figure 4: Multiple Contiguous IP Networks

| | Border | | |Internal|--- 200.5.2.0 Outside --| Router |---|---| Router | | | |--- 200.5.3.0 | 200.5.1.0 CIDR Mask = 255.255.0.0

The border router is configured with the following filter:

ADD -IP FilterAddrs 200.5.0.0/0.0.255.255 > 200.5.0.0/0.0.255.255 Discard

This configuration prevents the external attack and allows theinternal router to route traffic between supernets of200.5.0.0/255.255.0.0. In this example, a single filter can protectmultiple contiguous IP networks numbers assigned as a CIDR block.End Text Provided by 3COM

Cisco SystemsThe following information has been provided by Cisco Systems for their customers.

Begin Text Provided by Cisco

The defense is to set up your internet firewall router to deny packetsfrom OUTSIDE your network that claim to have a source address INSIDEyour network.

example configuration:

access-list 101 deny ip 131.108.0.0 0.0.255.255 0.0.0.0 255.255.255.255access-list 101 deny ip 198.92.93.0 0.0.0.255 0.0.0.0 255.255.255.255[..rest of your firewall goes here..]

and so on, where access list 101 describes all possible sourceaddresses on YOUR network. The example above describes a network withinternal source addresses of 131.108.x.x and 198.92.93.x

Note: If you use only the two line example described above without anyother access-list commands, ALL TRAFFIC will be stopped on your interfacesince the implicit action of an unmatched access-list is to deny packets.

If you only want source address spoofing protection and nothing else, addthe line

access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

to the end of the earlier example. This is NOT an optimal solution sincethere are many other possible attacks barring the IP spoofing fixed here.

There are articles on this topic on the CIO information service and variousUSENET mailing lists. You can telnet to cio.cisco.com or point your WWWbrowser at http://www.cisco.com.

Anyway! Once you have defined an appropriate access list you can apply themto the vulnerable interfaces.

Assuming your interface serial 0 faces the Internet:

interface serial 0 description interface facing the big, bad Internet ip access-group 101 in

for a router running 9.21 or later.

If you DO NOT have 9.21, an upgrade is NOT required if your internetfirewall is a two port router (which it should be). Simplyapply access-list 101 as described above to the LAN interface and notthe serial interface.

example:

interface ethernet 0 description LAN port on my internet router ip access-group 101

The essence of this defense is that any packets coming from the internet thatclaim to be from your network are tossed, thereby preventing the style ofattack described below.

Also, for good measure, ALL INTERNET FIREWALLS should have the globalcommand

no ip source-route

Which helps prevent other forms of spoofing attack from outside.

For further discussion of sequence number guessing attacks, see papersby Morris and also Bellovin in

ftp://ftp.research.att.com/dist/internet_security/117.ps.Zftp://ftp.research.att.com/dist/internet_security/ipext.ps.ZEnd Text Provided by Cisco

Morning Star Technologies, Inc.The following information has been provided by Morning Star Technologies for their customers.

Begin Text Provided by Morning StarTO ALL USERS OF MORNING STAR PRODUCTS:

Here is how to configure your Internet interface to prevent suchattacks:

1) Locate the packet filter file controlling your interface to the Internet. For users of Morning Star PPP, this will usually be /etc/ppp/Filter, /usr/etc/ppp/Filter, or /usr/lib/ppp/Filter. Users of Express routers should look in the file called Filter. Check your pppd (or frd for frame relay users) command line for a possibly different filter filename, or look for `ifconfig [interface] filter [filename]' commands in your Express router's rc.boot file.

2) Within the packet filter file, locate the individual filter specification used by your Internet connection. It will begin with either the hostname or IP address of the remote side of a PPP connection, the local hostname or IP address of a frame relay, Ethernet, or RF modem connection, or the special keyword `default' for any type of connection.

3) Within the appropriate filter specification, locate the `pass' filter.

4) Add the following line to the beginning of the pass filter:

!ip_opt=srcrt

This will cause all transmitted or received IP packets with Source Routing options to be discarded.

5) Determine the IP network number or numbers of your internal network or networks. Insert a set of lines similar to the following pair following the source route rule described in step 4) above for each internal network number.

!recv/src/[network-number] !send/dst/[network-number]

This will block all received packets containing a source IP address in your internal network, and will block the transmission of all packets containing a destination IP address in your internal network. For example, we have Class B network 137.175, so our Filter file contains

!ip_opt=srcrt !recv/src/137.175.0.0 !send/dst/137.175.0.0

If you don't have a whole IP network, you'll also need to specify a netmask. For example, an organization that has both the Class C network 192.1.1.0 and the Class-C-sized 10.1.220.0 segment of the Class A net 10 would add these lines

!ip_opt=srcrt !recv/src/192.1.1.0 !send/dst/192.1.1.0 !recv/src/10.1.220.0/255.255.255.0 !send/dst/10.1.220.0/255.255.255.0

FURTHER NOTE:

Do not configure any of your systems to trust any of the Unix `r' commands (rlogin, rsh, etc.) from any machine outside your firewall. Such systems can be spoofed as easily as internal machines, but spoofed packets cannot be detected at your firewall.

GETTING MORE HELP:

If you need any help with these modifications, call our customer support hotline at +1 800 558 7827 or send us e-mail at support@MorningStar.Com. When sending e-mail, please include the phrase CERT SECURITY PROBLEM in your Subject: header. We will provide assistance with this to all Morning Star customers, even for those without current customer support agreements. If you do not have a current support agreement, use the phrase `CERT SECURITY PROBLEM' when asked for your customer support number.End Text Provided by Morning Star

The CERT Coordination Center thanks Eric Allman, Steve Bellovin, Keith Bostic, Bill Cheswick, Mike Karels, and Tsutomu Shimomura for contributing to our understanding of these problems and their solutions.

UPDATESAdditional steps you can take to address IP spoofing:For IP spoofing to be successful, intruders rely on two machines to trust each other through the use of the .rhosts file or the /etc/hosts.equiv file. By exploiting applications that use authentication based on IP addresses (e.g., rsh and rlogin), intruders can gain user or root access on targeted hosts.We suggest that you use TCP wrappers to allow access from only a select few machines. Although this is not a complete solution, it does reduce your susceptibility to attack. Alternatively, change the configuration of your Internet gateway so that rlogin and rsh from the Internet to hosts in your domain are blocked. If that is not possible, disable the rlogin and rsh services on all of your hosts.Some sites have turned off source routing thinking that this would prevent IP spoofing attacks. This is NOT the case. Although we encourage sites to turn off source routing this does not prevent IP spoofing attacks. To prevent such attacks it is necessary to undertake packet filtering as described in the advisory.In addition to the attacks described in this advisory, we are now seeing attacks in which intruders gain access to a site using loopback IP addresses rather than IP addresses particular to that site.We recommend that in addition to the packet filtering suggestions described in Section III B of the advisory, you configure the filtering router to filter inbound packets in the following IP ranges:127.0.0.0 - 127.255.255.255 (loopback)10.0.0.0 - 10.255.255.255 (reserved)172.16.0.0 - 172.31.255.255 (reserved)192.168.0.0 - 192.168.255.255 (reserved)Finally, we encourage you to consider using network monitoring tools to check for signs of IP spoofing attacks. Argus is a network monitoring tool that uses a client-server model to capture data and associate it into "transactions." The tool provides network-level auditing; it can verify compliance to a router configuration file, and information is easily adapted to protocol analysis, intrusion detections, and other security needs. Argus is available fromftp://ftp.net.cmu.edu/pub/argus-1.5.

This document is available from:http://www.cert.org/advisories/CA-1995-01.html

CERT/CC Contact InformationEmail:cert@cert.orgPhone:+1 412-268-7090 (24-hour hotline)Fax:+1 412-268-6989Postal address:CERT Coordination CenterSoftware Engineering InstituteCarnegie Mellon UniversityPittsburgh PA 15213-3890U.S.A.CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5) / EDT(GMT-4) Monday through Friday; they are on call for emergencies during other hours, on U.S. holidays, and on weekends.Using encryptionWe strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available fromhttp://www.cert.org/CERT_PGP.keyIf you prefer to use DES, please call the CERT hotline for more information.Getting security informationCERT publications and other security information are available from our web sitehttp://www.cert.org/* "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office.

NO WARRANTYAny material furnished by Carnegie Mellon University and the Software Engineering Institute is furnished on an "as is" basis. Carnegie Mellon University makes no warranties of any kind, either expressed or implied as to any matter including, but not limited to, warranty of fitness for a particular purpose or merchantability, exclusivity or results obtained from use of the material. Carnegie Mellon University does not make any warranty of any kind with respect to freedom from patent, trademark, or copyright infringement.

Conditions for use, disclaimers, and sponsorship informationCopyright 1995, 1996 Carnegie Mellon University.

Revision HistorySep. 23, 1997 Update Copyright statementDec. 19, 1996 Updates section - reminderSep. 24, 1996 Supersession statement modifiedSep. 19, 1996 Superseded by CA-96.21 [IP spoofing portion only]Aug. 30, 1996 Information previously in the README was inserted into the advisory. Appendix A - added vendor information as it was received: Cisco Systems, Morning Star Technologies, and 3COM.May 10, 1996 Updates section - added pointer to the Argus tool.Aug. 04, 1995 Updates section - added more information on IP spoofing and recommendations for detecting such activity.Aug. 04, 1995 Sec. I - added notes about Kerberos and mobile IP spoofing.