Security Warning: TCP SYN Flooding and IP Spoofing Attacks On September 19, 1996, the Computer Emergency Response Team (CERT) issued a security advisory [CERT Advisory CA-96.21)] concerning TCP SYN Flooding and IP Spoofing attacks. Any organization that is connected to the Internet and provides TCP/IP-based services such as a WWW server or an electronic mail server is a possible target for these types of attacks. The Attack When a client attempts to establish a TCP connection with a server, the client and server exchange an initial set of messages that are used to create the internal data structures that manage the connection. This connection setup procedure, known as the 3-way handshake, applies to all TCP connections - WWW, FTP, SMTP, telnet, etc. Figure 1: TCP Connection Establishment (3-Way Handshake) The 3-way handshake begins when the client initiates a connection request by transmitting a SYN message to the server. Upon receipt of the SYN message, the server creates an entry in its pending TCP connection data structure and sends a SYN-ACK message back to the client. The client completes the 3-Way handshake by responding to the server's SYN-ACK message with an ACK message of its own. When the server receives the client's ACK, the connection is established, and the server removes the associated entry from its pending TCP connection data structure. A possibility for abuse exists if the connection remains "half-open." A half-open connection occurs when the client system does not respond to the server's SYN-ACK with the final ACK to complete the 3-way handshake. Note that the client initiating the connection determines whether the 3-Way handshake is completed, not the server! Figure 2: Half-Open TCP Connection A client can launch a denial of service attack against a server by creating too many half-open connections causing the server's pending TCP connection data structure to overflow. This means that the victim server will not be able to accept legitimate connections from other clients until the pending TCP connection data structure is emptied. Depending on the server's TCP/IP implementation, a worst case scenario could result in the exhaustion of the server's memory and a potential system crash. It is important to note that in a TCP SYN Flooding attack the actual service is not damaged, only the ability to provide the service to legitimate clients is impeded. Creating half-open connections is facilitated by combining the attack with IP Spoofing. The client initiating the attack spoofs, or changes, the source IP address in its SYN messages to that of a currently unreachable host. The source IP address must be changed to an unreachable address since the attacker does not want any host that receives the server's SYN-ACK to respond with a RST (Reset) message. A RST is transmitted when a host receives a packet that does not appear to be correct for the referenced connection. This would defeat the attack since a RST message from an active host owning the spoofed IP address would cause the backlogged connection to be removed from the server's pending TCP connection data structure. Finally, it is very difficult to discover the origin of this type of assault since the source IP address in the attacking client's SYN message is counterfeit. A thorough discussion of TCP SYN Flooding attacks is published on the WWW in Phrack Magazine. An account of IP Spoofing attacks is also available from Phrack Magazine. Preventing the Attack Unfortunately, there is no generally accepted solution for this type of attack since it exploits a fundamental weakness in the standards that define the TCP/IP protocol suite. One of the most disturbing features of this attack is that it can be launched with a very limited amount of network traffic when compared to other types of denial of service attacks such as ping flooding, mass mailings, etc. Due to the global nature of this problem, a wordwide solution needs to be developed to ensure its effectiveness and interoperability. It is important to note that servers placed behind Internet firewalls that block all incoming TCP connection requests are currently protected from externally launched TCP SYN Flooding attacks. If an organization wishes to provide remote offices, nomadic workers, and business partners with access to corporate servers via the Internet, packet filters can be configured on the organization's firewall system that restrict access to a limited set of external network numbers. While this is a prudent policy, there is still an exposure if the attacker spoofs one of the small set of addresses that is permitted through the firewall system. Finally, there is no guaranteed way to protect servers that provide information to the general public via the Internet since public servers accept connection requests originating from any subnetwork on the Internet. CERT recommends that you configure your firewall to prevent packets that contain spoofed IP addresses from exiting your network. This can reduce the likelihood that your site will be the source of one of these attacks. Unlike the situation in which you are protecting yourself from IP spoofing attacks against your IP addresses, in this case you are acting as a good Internet citizen by preventing systems on your network from launching a TCP SYN Flooding attack. CERT urges all Internet Service Providers (ISPs) to implement policies that prohibit packets containing spoofed IP addresses from exiting their infrastructure. Please see the following section for information concerning the configuration of 3Com's NETBuilder Bridge/Router to prevent IP Spoofing Attacks. As of this writing, a number of UNIX system vendors are modifying their TCP/IP kernels to be more resilient against TCP SYN Flooding attacks. Also, vendors of host-based firewall systems are beginning to develop their own proprietary solutions: Silicon Graphics, Inc. CheckPoint's FireWall-1 Raptor's Eagle 3Com Solutions to Limit IP Spoofing Attacks Please refer to the following 3Com technical papers for information concerning the configuration of 3Com's NETBuilder Bridge/Router to prevent IP Spoofing Attacks. "Internet FireWalls and Security" This paper discusses how an Internet firewall fits into an organization's overall security policy and describes several types of firewall systems and their advantages and disadvantages. The major topics include: the benefits and limitations of Internet firewalls, the hackers toolbox, basic firewall design decisions, a discussion of the basic firewall building blocks (packet-filtering routers, application-level gateways, and circuit-level gateways), and three sample firewall system topologies (a packet-filtering router, a screened-host firewall, and a screened-subnet firewall). "Securing Your Network Against Source IP Spoofing Attacks" This paper provides a detailed introduction to IP Spoofing Attacks as described in the January 1995 CERT Advisory. It offers a series of examples that show how NETBuilder software can be configured to prevent these types of attack. Note that this paper focuses on software solutions prior to the 9.1 Release. S/W Release 9.1 introduces the new FireWall Service which is discussed in "NETBuilder FireWall Service." "NETBuilder FireWall Service" This paper provides a detailed technical introduction to the comprehensive, easy-to-use NETBuilder FireWall service that was first introduced in S/W Release 9.1. For information concerning the prevention of IP Spoofing Attacks, review the section that discusses Service-Independent Filters (i.e., the IgnoreSrcSpoofing | DenySrcSpoofing option). The NETBuilder FireWall service has recently been certified by the National Computer Security Association (NCSA). It combines simplicity of configuration with powerful features that permit the construction of robust and secure firewall systems. This paper includes discussion of service-independent filters, service-dependent filters, and generic filters. It describes how to test the FireWall service and how to use the service's powerful application-specific routing feature. It also describes how to use the NETBuilder FireWall service as a simple IP traffic analyzer.