FW: CERT Advisory CA-96.21 - TCP SYN Flooding and IP Spoofing Attacks

Dan Kohn (dan@teledesic.com)
Thu, 19 Sep 1996 16:56:11 -0700

>From: CERT Advisory[SMTP:cert-advisory@cert.org]
>Sent: Thursday, September 19, 1996 1:40 PM
>To: cert-advisory@cert.org
>Subject: CERT Advisory CA-96.21 - TCP SYN Flooding and IP Spoofing
>CERT(sm) Advisory CA-96.21
>Original issue date: September 19, 1996
>Last revised: --
> =20
>Topic: TCP SYN Flooding and IP Spoofing Attacks

> *** This advisory supersedes CA-95:01. ***
>Two "underground magazines" have recently published code to conduct
>denial-of-service attacks by creating TCP "half-open" connections. This
>is actively being used to attack sites connected to the Internet. There
>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
>being identified.
>Any system connected to the Internet and providing TCP-based network
>(such as a Web server, FTP server, or mail server) is potentially
>subject to
>this attack. The consequences of the attack may vary depending on the
>however, the attack itself is fundamental to the TCP protocol used by
>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
>service provider, please encourage your provider to take these steps.
>This advisory provides a brief outline of the problem and a partial
>We will update this advisory as we receive new information. If the
>change in
>information warrants, we may post an updated advisory on
>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

>I. Description=20
> When a system (called the client) attempts to establish a TCP
> to a system providing a service (the server), the client and
> exchange a set sequence of messages. This connection technique
> to all TCP connections--telnet, Web, email, etc.
> The client system begins by sending a SYN message to the server.
> server then acknowledges the SYN message by sending SYN-ACK
>message to
> the client. The client then finishes establishing the connection
> responding with an ACK message. The connection between the client
> the server is then open, and the service-specific data can be
> between the client and the server. Here is a view of this message
> Client Server
> ------ ------
> SYN-------------------->
> <--------------------SYN-ACK
> ACK-------------------->
> Client and server can now
> send service-specific data
> The potential for abuse arises at the point where the server
>system has
> sent an acknowledgment (SYN-ACK) back to client but has not yet
> the ACK message. This is what we mean by half-open connection. The
> server has built in its system memory a data structure describing
> pending connections. This data structure is of finite size, and it
>can be
> made to overflow by intentionally creating too many partially-open
> connections.=20
> Creating half-open connections is easily accomplished with IP
> spoofing. The attacking system sends SYN messages to the victim
> system; these appear to be legitimate but in fact reference a
> 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
> The half-open connections data structure on the victim server
> will eventually fill; then the system will be unable to accept any
> 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
> recover. However, the attacking system can simply continue sending
> IP-spoofed packets requesting new connections faster than the
> system can expire the pending connections.
> In most cases, the victim of such an attack will have difficulty
> 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
> rendered otherwise inoperative.
> The location of the attacking system is obscured because the
> addresses in the SYN packets are often implausible. When the
> arrives at the victim server system, there is no way to determine
> true source. Since the network forwards packets based on
> address, the only way to validate the source of a packet is to use
> source filtering (see Appendix A).
>II. Impact =20
> Systems providing TCP-based services to the Internet community may
> be unable to provide those services while under attack and for
> time after the attack ceases. The service itself is not harmed by
> attack; usually only the ability to provide the service is
> In some cases, the system may exhaust memory, crash, or be
> otherwise inoperative.=20
>III. Solution
> There is, as yet, no generally accepted solution to this problem
> the current IP protocol technology. However, proper router
> can reduce the likelihood that your site will be the source of one
> these attacks.
> Appendix A contains details about how to filter packets to reduce
> number of IP-spoofed packets entering and exiting your network. It
> contains a list of vendors that have reported support for this
>type of
> filtering.
> NOTE to Internet Service Providers:=20
> We STRONGLY urge you to install these filters in your routers
> protect your customers against this type of an attack. Although
> 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
> the appropriate organizations.=20
> NOTE to customers of Internet service providers:=20
> We STRONGLY recommend that you contact your service provider to
> that the necessary filters are in place to protect your
>network. =20
> Many networking experts are working together to devise
>improvements to
> existing IP implementations to "harden" kernels to this type of
> When these improvements become available, we suggest that you
> them on all your systems as soon as possible. This advisory will
> updated to reflect changes made by the vendor community.=20
>IV. Detecting an Attack
> Users of the attacked server system may notice nothing unusual
>since the
> IP-spoofed connection requests may not load the system noticeably.
> 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
> system's network traffic. For example, on SunOS this may be done
>by the
> command:
> netstat -a -f inet
> Too many connections in the state "SYN_RECEIVED" indicates that
> system is being attacked.

>Appendix A - Reducing IP Spoofed Packets
>1. Filtering Information
>- -------------------------
>With 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
>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
>address different from your internal network to prevent a source IP
>attack from originating from your site.
>The combination of these two filters would prevent outside attackers
>sending you packets pretending to be from your internal network. It
>would also
>prevent packets originating within your network from pretending to be
>outside your network. These filters will *not* stop all TCP SYN
>attacks, since
>outside attackers can spoof packets from *any* outside network, and
>attackers can still send attacks spoofing internal addresses.
>We STRONGLY urge Internet service providers to install these filters in
>In addition, we STRONGLY recommend customers of Internet service
>providers to
>contact your service provider to verify that the necessary filters are
>place to protect your network.
>2. Vendor Information
>- ----------------------
>The following vendor(s) have reported support for the type of filtering
>recommend and provided pointers to additional information that
>describes how
>to configure your router. If you need more information about your
>router or
>about firewalls, please contact your vendor directly.
> Cisco
> -----
> Refer to the section entitiled "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
>configuration examples and you are not represented in this list, please
>the CERT Coordination Center at the addresses given in the Contact
>section below. We will update the advisory after we hear from you.
>3. Alternative for routers that do not support filtering on the inbound

>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
>system, you may filter the spoofed IP packets by using a second router
>between your external interface and your outside connection. Configure
>router to block, on the outgoing interface connected to your original
>all packets that have a source address in your internal network. For
>purpose, you can use a filtering router or a UNIX system with two
>that supports packet filtering.
>Note: Disabling source routing at the router does not protect you from
>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 (the all ones
> network).
>* Your local network(s): These are your network addresses
>* Reserved private networks: The following networks are defined as
> private networks and no traffic should ever be received from or
> to these networks through a router:=20

>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.

>If you believe that your system has been compromised, contact the CERT
>Coordination Center or your representative in the Forum of Incident
>and Security Teams (see ftp://info.cert.org/pub/FIRST/first-contacts).=20
>CERT/CC Contact Information=20
>- ----------------------------=20
>Email cert@cert.org
>Phone +1 412-268-7090 (24-hour hotline)
> CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) /
> and are on call for emergencies during other hours.
>Fax +1 412-268-6989
>Postal address
> CERT Coordination Center
> Software Engineering Institute
> Carnegie Mellon University
> Pittsburgh PA 15213-3890
>Using encryption
> We strongly urge you to encrypt sensitive information sent by email.
>We can
> support a shared DES key or PGP. Contact the CERT/CC for more
> Location of CERT PGP key
> ftp://info.cert.org/pub/CERT_PGP.key
>Getting security information
> CERT publications and other security information are available from
> http://www.cert.org/
> ftp://info.cert.org/pub/
> CERT advisories and bulletins are also posted on the USENET
> comp.security.announce=20
> To be added to our mailing list for advisories and bulletins, send
> email address to=20
> cert-advisory-request@cert.org=20

>Copyright 1996 Carnegie Mellon University
>This material may be reproduced and distributed without permission
>it is used for noncommercial purposes and the copyright statement is
>CERT is a service mark of Carnegie Mellon University.

>This file:
> http://www.cert.org
> click on "CERT Advisories"

>Revision history=20
>Version: 2.6.2