>-----
> *** 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
>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. 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. Description=20
>
> When 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=20
> between the client and the server. Here is a view of this message
>flow:
>
> 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
>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.=20
>
> 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. Impact =20
>
> Systems 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.=20
>
>III. Solution
>
> There 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:=20
> 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.=20
>
> NOTE to customers of Internet service providers:=20
> We STRONGLY recommend that you contact your service provider to
>verify
> 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
>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 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.
>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 inet
>
> Too many connections in the state "SYN_RECEIVED" indicates that
>the
> system is being attacked.
>
>=0C
>........................................................................=
>...
>
>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
>restricts=20
>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 Information
>- ----------------------
>
>The 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 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
>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
>side
>-
>------------------------------------------------------------------------=
>----
>
>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 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=20
> network).
>
>* Your local network(s): These are your network addresses
>
>* Reserved private networks: 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:=20
> 10.0.0.0
> 127.0.0.0
> 172.16.0.0
> 192.168.0.0
>
>-
>------------------------------------------------------------------------=
>-----
>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
>Response=20
>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) /
>EDT(GMT-4)
> 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
> USA
>
>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
>information.=20
> 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
>newsgroup
> comp.security.announce=20
>
> To be added to our mailing list for advisories and bulletins, send
>your
> email address to=20
> cert-advisory-request@cert.org=20
>
>-
>------------------------------------------------------------------------=
>---
>Copyright 1996 Carnegie Mellon University
>This material may be reproduced and distributed without permission
>provided
>it is used for noncommercial purposes and the copyright statement is
>included.
>
>CERT is a service mark of Carnegie Mellon University.
>-
>------------------------------------------------------------------------=
>---
>
>This file:
>ftp://info.cert.org/pub/cert_advisories/CA-96.21.tcp_syn_flooding
> http://www.cert.org
> click on "CERT Advisories"
>
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=
>
>Revision history=20
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.2
>
>iQCVAwUBMkGmUnVP+x0t4w7BAQHPcgP9Fxarwmbfq9rQtj3+CktCU3HtYtX4wgSQ
>RW+hl6Z9lig61ha+bgEyEUqj/1ishwlJopgJ7LOMjgfzjGZt/25/+XmHCrOcUSNx
>+eoqAcg59eisXtWXFgOLgfcadcH/9dDRHn3WUcXYrAFFpXPREBS66P2Tbo8MlmzX
>l0LbKYde7uc=3D
>=3DiZ8P
>-----END PGP SIGNATURE-----
>