home *** CD-ROM | disk | FTP | other *** search
/ Chaos Computer Club 1997 February / cccd_beta_feb_97.iso / contrib / cert / ca9621 < prev    next >
PGP Signed Message  |  1997-02-28  |  21KB  |  496 lines
  1. -----BEGIN PGP SIGNED MESSAGE-----
  2.  
  3. =============================================================================
  4. CERT(sm) Advisory CA-96.21
  5. Original issue date: September 19, 1996
  6. Last revised: January 2, 1997 - Updates - added or modified vendor information
  7.               for SGI, Livingston, HP, 3COM.
  8.  
  9.               A complete revision history is at the end of this file.
  10.  
  11. Topic: TCP SYN Flooding and IP Spoofing Attacks
  12. - -----------------------------------------------------------------------------
  13.            *** This advisory supersedes the IP spoofing
  14.                portion of CA-95:01. ***
  15.  
  16. Two "underground magazines" have recently published code to conduct
  17. denial-of-service attacks by creating TCP "half-open" connections. This code
  18. is actively being used to attack sites connected to the Internet. There is,
  19. as yet, no complete solution for this problem, but there are steps that can be
  20. taken to lessen its impact. Although discovering the origin of the attack is
  21. difficult, it is possible to do; we have received reports of attack origins
  22. being identified.
  23.  
  24. Any system connected to the Internet and providing TCP-based network services
  25. (such as a Web server, FTP server, or mail server) is potentially subject to
  26. this attack. Note that in addition to attacks launched at specific hosts,
  27. these attacks could also be launched against your routers or other network
  28. server systems if these hosts enable (or turn on) other TCP services (e.g.,
  29. echo). The consequences of the attack may vary depending on the system;
  30. however, the attack itself is fundamental to the TCP protocol used by all
  31. systems.
  32.  
  33. If you are an Internet service provider, please pay particular attention to
  34. Section III and Appendix A, which describes step we urge you to take to
  35. lessen the effects of these attacks. If you are the customer of an Internet
  36. service provider, please encourage your provider to take these steps.
  37.  
  38. This advisory provides a brief outline of the problem and a partial solution.
  39. We will update this advisory as we receive new information. If the change in
  40. information warrants, we may post an updated advisory on comp.security.announce
  41. and redistribute an update to our cert-advisory mailing list. As always, the
  42. latest information is available at the URLs listed at the end of this advisory.
  43.  
  44. - -----------------------------------------------------------------------------
  45.  
  46. I.  Description
  47.  
  48.      When a system (called the client) attempts to establish a TCP connection
  49.      to a system providing a service (the server), the client and server
  50.      exchange a set sequence of messages. This connection technique applies
  51.      to all TCP connections--telnet, Web, email, etc.
  52.  
  53.      The client system begins by sending a SYN message to the server. The
  54.      server then acknowledges the SYN message by sending SYN-ACK message to
  55.      the client. The client then finishes establishing the connection by
  56.      responding with an ACK message. The connection between the client and
  57.      the server is then open, and the service-specific data can be exchanged
  58.      between the client and the server. Here is a view of this message flow:
  59.  
  60.                 Client                  Server
  61.                 ------                  ------
  62.                 SYN-------------------->
  63.  
  64.                    <--------------------SYN-ACK
  65.  
  66.                 ACK-------------------->
  67.  
  68.                      Client and server can now
  69.                      send service-specific data
  70.  
  71.      The potential for abuse arises at the point where the server system has
  72.      sent an acknowledgment (SYN-ACK) back to client but has not yet received
  73.      the ACK message. This is what we mean by half-open connection. The
  74.      server has built in its system memory a data structure describing all
  75.      pending connections. This data structure is of finite size, and it can be
  76.      made to overflow by intentionally creating too many partially-open
  77.      connections.
  78.  
  79.      Creating half-open connections is easily accomplished with IP
  80.      spoofing. The attacking system sends SYN messages to the victim server
  81.      system; these appear to be legitimate but in fact reference a client
  82.      system that is unable to respond to the SYN-ACK messages. This means that
  83.      the final ACK message will never be sent to the victim server system.
  84.  
  85.      The half-open connections data structure on the victim server system
  86.      will eventually fill; then the system will be unable to accept any new
  87.      incoming connections until the table is emptied out. Normally there is a
  88.      timeout associated with a pending connection, so the half-open
  89.      connections will eventually expire and the victim server system will
  90.      recover. However, the attacking system can simply continue sending
  91.      IP-spoofed packets requesting new connections faster than the victim
  92.      system can expire the pending connections.
  93.  
  94.      In most cases, the victim of such an attack will have difficulty in
  95.      accepting any new incoming network connection. In these cases, the
  96.      attack does not affect existing incoming connections nor the ability to
  97.      originate outgoing network connections.
  98.  
  99.      However, in some cases, the system may exhaust memory, crash, or be
  100.      rendered otherwise inoperative.
  101.  
  102.      The location of the attacking system is obscured because the source
  103.      addresses in the SYN packets are often implausible. When the packet
  104.      arrives at the victim server system, there is no way to determine its
  105.      true source. Since the network forwards packets based on destination
  106.      address, the only way to validate the source of a packet is to use input
  107.      source filtering (see Appendix A).
  108.  
  109. II.  Impact
  110.  
  111.      Systems providing TCP-based services to the Internet community may
  112.      be unable to provide those services while under attack and for some
  113.      time after the attack ceases. The service itself is not harmed by the
  114.      attack; usually only the ability to provide the service is impaired.
  115.      In some cases, the system may exhaust memory, crash, or be rendered
  116.      otherwise inoperative.
  117.  
  118. III. Solution
  119.  
  120.      There is, as yet, no generally accepted solution to this problem with
  121.      the current IP protocol technology. However, proper router configuration
  122.      can reduce the likelihood that your site will be the source of one of
  123.      these attacks.
  124.  
  125.      Appendix A contains details about how to filter packets to reduce the
  126.      number of IP-spoofed packets entering and exiting your network. It also
  127.      contains a list of vendors that have reported support for this type of
  128.      filtering.
  129.  
  130.      NOTE to Internet Service Providers:
  131.         We STRONGLY urge you to install these filters in your routers to
  132.         protect your customers against this type of an attack. Although these
  133.         filters do not directly protect your customers from attack, the
  134.         filters do prevent attacks from originating at the sites of any of your
  135.         customers. We are aware of the ramifications of these filters on some
  136.         current Mobile IP schemes and are seeking a position statement from
  137.         the appropriate organizations.
  138.  
  139.      NOTE to customers of Internet service providers:
  140.         We STRONGLY recommend that you contact your service provider to verify
  141.         that the necessary filters are in place to protect your network.
  142.  
  143.      Many networking experts are working together to devise improvements to
  144.      existing IP implementations to "harden" kernels to this type of attack.
  145.      When these improvements become available, we suggest that you install
  146.      them on all your systems as soon as possible. This advisory will be
  147.      updated to reflect changes made by the vendor community.
  148.  
  149. IV.  Detecting an Attack
  150.  
  151.      Users of the attacked server system may notice nothing unusual since the
  152.      IP-spoofed connection requests may not load the system noticeably. The
  153.      system is still able to establish outgoing connections. The problem will
  154.      most likely be noticed by client systems attempting to access one of the
  155.      services on the victim system.
  156.  
  157.      To verify that this attack is occurring, check the state of the server
  158.      system's network traffic. For example, on SunOS this may be done by the
  159.      command:
  160.  
  161.               netstat -a -f inet
  162.  
  163.     Note that use of the above command depends on the OS version, for
  164.     example for a FreeBSD system use
  165.  
  166.               netstat -s |grep "listenqueue overflows"
  167.  
  168.      Too many connections in the state "SYN_RECEIVED" could indicate that the
  169.      system is being attacked.
  170.  
  171.  
  172. ...........................................................................
  173.  
  174. Appendix A - Reducing IP Spoofed Packets
  175.  
  176.  
  177. 1. Filtering Information
  178. - ------------------------
  179.  
  180. With the current IP protocol technology, it is impossible to eliminate
  181. IP-spoofed packets. However, you can take steps to reduce the number of
  182. IP-spoofed packets entering and exiting your network.
  183.  
  184. Currently, the best method is to install a filtering router that restricts
  185. the input to your external interface (known as an input filter) by not
  186. allowing a packet through if it has a source address from your internal
  187. network. In addition, you should filter outgoing packets that have a source
  188. address different from your internal network to prevent a source IP spoofing
  189. attack from originating from your site.
  190.  
  191. The combination of these two filters would prevent outside attackers from
  192. sending you packets pretending to be from your internal network. It would also
  193. prevent packets originating within your network from pretending to be from
  194. outside your network. These filters will *not* stop all TCP SYN attacks, since
  195. outside attackers can spoof packets from *any* outside network, and internal
  196. attackers can still send attacks spoofing internal addresses.
  197.  
  198. We STRONGLY urge Internet service providers to install these filters in your
  199. routers.
  200.  
  201. In addition, we STRONGLY recommend customers of Internet service providers to
  202. contact your service provider to verify that the necessary filters are in
  203. place to protect your network.
  204.  
  205.  
  206. 2. Vendor Information
  207. - ---------------------
  208.  
  209. The following vendor(s) have reported support for the type of filtering we
  210. recommend and provided pointers to additional information that describes how
  211. to configure your router. If you need more information about your router or
  212. about firewalls, please contact your vendor directly.
  213.  
  214.    Cisco
  215.    -----
  216.         Refer to the section entitled "ISP Security Advisory"
  217.         on http://www.cisco.com for an up-to-date explanation of
  218.         how to address TCP SYN flooding on a Cisco router.
  219.  
  220.  
  221. NOTE to vendors:
  222. If you are a router vendor who has information on router capabilities and
  223. configuration examples and you are not represented in this list, please
  224. contact the CERT Coordination Center at the addresses given in the Contact
  225. Information section below. We will update the advisory after we hear from you.
  226.  
  227.  
  228. 3. Alternative for routers that do not support filtering on the inbound side
  229. - ----------------------------------------------------------------------------
  230.  
  231. If your vendor's router does not support filtering on the inbound side of the
  232. interface or if there will be a delay in incorporating the feature into your
  233. system, you may filter the spoofed IP packets by using a second router
  234. between your external interface and your outside connection. Configure this
  235. router to block, on the outgoing interface connected to your original router,
  236. all packets that have a source address in your internal network. For this
  237. purpose, you can use a filtering router or a UNIX system with two interfaces
  238. that supports packet filtering.
  239.  
  240. Note: Disabling source routing at the router does not protect you from this
  241. attack, but it is still good security practice to follow.
  242.  
  243. On the input to your external interface, that is coming from the Internet to
  244. your network, you should block packets with the following addresses:
  245.  
  246. * Broadcast Networks: The addresses to block here are network 0 (the all zeros
  247.   broadcast address) and network 255.255.255.255 (the all ones broadcast
  248.   network).
  249.  
  250. * Your local network(s): These are your network addresses
  251.  
  252. * Reserved private network numbers: The following networks are defined
  253.   as reserved private networks, and no traffic should ever be received
  254.   from or transmitted to these networks through a router:
  255.  
  256.         10.0.0.0    - 10.255.255.255    10/8            (reserved)
  257.         127.0.0.0   - 127.255.255.255   127/8           (loopback)
  258.         172.16.0.0  - 172.31.255.255    172.16/12       (reserved)
  259.         192.168.0.0 - 192.168.255.255   192.168/16      (reserved)
  260.  
  261. - -----------------------------------------------------------------------------
  262. The CERT Coordination Center staff thanks the team members of NASIRC
  263. for contributing much of the text for this advisory and thanks the many
  264. experts who are devoting time to addressing the problem and who provided input
  265. to this advisory.
  266. - -----------------------------------------------------------------------------
  267.  
  268. If you believe that your system has been compromised, contact the CERT
  269. Coordination Center or your representative in the Forum of Incident Response
  270. and Security Teams (see ftp://info.cert.org/pub/FIRST/first-contacts).
  271.  
  272.  
  273. CERT/CC Contact Information
  274. - ---------------------------
  275. Email    cert@cert.org
  276.  
  277. Phone    +1 412-268-7090 (24-hour hotline)
  278.                 CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4)
  279.                 and are on call for emergencies during other hours.
  280.  
  281. Fax      +1 412-268-6989
  282.  
  283. Postal address
  284.          CERT Coordination Center
  285.          Software Engineering Institute
  286.          Carnegie Mellon University
  287.          Pittsburgh PA 15213-3890
  288.          USA
  289.  
  290. Using encryption
  291.    We strongly urge you to encrypt sensitive information sent by email. We can
  292.    support a shared DES key or PGP. Contact the CERT/CC for more information.
  293.    Location of CERT PGP key
  294.          ftp://info.cert.org/pub/CERT_PGP.key
  295.  
  296. Getting security information
  297.    CERT publications and other security information are available from
  298.         http://www.cert.org/
  299.         ftp://info.cert.org/pub/
  300.  
  301.    CERT advisories and bulletins are also posted on the USENET newsgroup
  302.         comp.security.announce
  303.  
  304.    To be added to our mailing list for advisories and bulletins, send your
  305.    email address to
  306.         cert-advisory-request@cert.org
  307.  
  308. - ---------------------------------------------------------------------------
  309. Copyright 1996 Carnegie Mellon University
  310. This material may be reproduced and distributed without permission provided
  311. it is used for noncommercial purposes and the copyright statement is
  312. included.
  313.  
  314. CERT is a service mark of Carnegie Mellon University.
  315. - ---------------------------------------------------------------------------
  316.  
  317. This file: ftp://info.cert.org/pub/cert_advisories/CA-96.21.tcp_syn_flooding
  318.            http://www.cert.org
  319.                click on "CERT Advisories"
  320.  
  321. ==============================================================================
  322. UPDATES
  323.  
  324. 3COM
  325. ====
  326.  
  327.   Please refer to the "Network Security Advisory" link on
  328.   http://www.3com.com/ for a thorough discussion of
  329.   how to address TCP SYN flooding attacks on a 3Com router.
  330.  
  331.  
  332. Berkeley Software Design, Inc.
  333. =============================
  334. BSDI has patches available.
  335.  
  336. PATCH:
  337.     K210-021 (ftp://ftp.bsdi.com/bsdi/patches/patches-2.1/K210-021)
  338.     md5 checksum: c386e72f41d0e409d91b493631e364dd K210-021
  339.  
  340.         This patch adds two networking features that can help defeat
  341.         and detect some types of denial of service attacks.
  342.         This patch requires U210-025 which provides new copies of
  343.         sysctl(8) and netstat(1) for configuration and monitoring of
  344.         these new features.
  345.  
  346. PATCH:
  347.     K210-022 (ftp://ftp.bsdi.com/bsdi/patches/patches-2.1/K210-22)
  348.     md5 checksum: 9ec62b5e9cc424b9b42089504256d926 K210-022
  349.  
  350.         This patch adds a TCP SYN cache which reduces and/or
  351.         eliminates the effects of SYN-type denial of service attacks
  352.         such as those discussed in CERT advisory CA 96.21.
  353.  
  354. PATCH:
  355.     U210-025 (ftp://ftp.bsdi.com/bsdi/patches/patches-2.1/U210-025)
  356.     md5 checksum: d2ee01238ab6040e9b7a1bd2c3bf1016 U210-025
  357.  
  358.         This patch should be installed in conjunction with IP source
  359.         address check and IP fragmentation queue limit patch
  360.         (K210-021) and SYN flooding patch (K210-022).
  361.  
  362. Additional details about these patches are available from
  363.         http://www.bsdi.com
  364.         ftp://ftp.bsdi.com
  365.  
  366. Hewlett-Packard Company
  367. =======================
  368.  
  369. Hewlett-Packard         Vulnerable      Patch in progress
  370.  
  371.  
  372. IBM Corporation
  373. ===============
  374.  
  375. Any system that is connected to a TCP/IP-based network (Internet or
  376. intranet) and offers TCP-based services is vulnerable to the SYN flood
  377. attack.  The attack does not distinguish between operating systems,
  378. software version levels, or hardware platforms; all systems are
  379. vulnerable. IBM has released AIX operating system fixes for the SYN
  380. flood vulnerability.
  381.  
  382. NOTE: If you are using the IBM Internet Connection Secured Network Gateway
  383.       (SNG) firewall software, you must also apply the fixes listed in
  384.       the next section.
  385.  
  386. The following Automated Program Analysis Reports (APARs) for IBM AIX
  387. are now available to address the SYN flood attack:
  388.  
  389.           AIX 3.2.5
  390.           ---------
  391.               No APAR available; upgrade to AIX 4.x recommended
  392.  
  393.           AIX 4.1.x
  394.           ---------
  395.               APAR - IX62476
  396.  
  397.           AIX 4.2.x
  398.           ---------
  399.               APAR - IX62428
  400.  
  401.  
  402. Fixes for IBM SNG Firewall
  403. - -------------------------
  404.  
  405. The following Automated Program Analysis Reports (APARs) for the IBM
  406. Internet Connection Secured Network Gateway firewall product are now
  407. available to address the SYN flood and "Ping o' Death" attacks:
  408.  
  409. NOTE: The fixes in this section should ONLY be applied to systems running
  410.           the IBM Internet Connection Secured Network Gateway (SNG)
  411.           firewall software.  They should be applied IN ADDITION TO the
  412.           IBM AIX fixes listed in the previous section.
  413.  
  414.           IBM SNG V2.1
  415.           ------------
  416.               APAR - IR33376 PTF UR46673
  417.  
  418.           IBM SNG V2.2
  419.           ------------
  420.  
  421.               APAR - IR33484 PTF UR46641
  422.  
  423. Obtaining Fixes
  424. - ---------------
  425.  
  426. IBM AIX APARs may be ordered using Electronic Fix Distribution (via the
  427. FixDist program), or from the IBM Support Center.  For more information on
  428. FixDist, and to obtain fixes via the Internet, please reference
  429.  
  430.         http://service.software.ibm.com/aixsupport/
  431.  
  432. or send electronic mail to "aixserv@austin.ibm.com" with the word "FixDist"
  433. in the "Subject:" line.
  434.  
  435. Livingston Enterprises, Inc.
  436. ============================
  437.  
  438. Refer to the following Applications Note for more information on
  439. configuring a Livingston IRX or PortMaster to help block outgoing SYN
  440. attacks from an ISP's users:
  441.  
  442.         ftp://ftp.livingston.com/pub/le/doc/notes/filters.syn-attack
  443.  
  444.  
  445. Silicon Graphics, Inc.
  446. =====================
  447.  
  448. Updated Silicon Graphics information concerning SYN attacks
  449. can be found in SGI advisory number 19961202-01-PX.
  450.  
  451. SGI advisories are available from
  452.  
  453.          ftp://sgigate.sgi.com/security/
  454.  
  455. Sun Microsystems, Inc.
  456. ======================
  457. Sun published a bulletin on October 9, 1996--Sun security bulletin number
  458. 00136. Sun Security Bulletins are available via the security-alert@sun.com
  459. alias and on SunSolve.
  460.  
  461.  
  462.  
  463.  
  464. Note: Advisories from vendors listed in this section can also be found at
  465.          ftp://info.cert.org/pub/vendors/
  466.  
  467. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  468. Revision history
  469.  
  470. Jan. 2, 1997 - Updates - added or modified vendor information for SGI,
  471.                Livingston, HP, 3COM.
  472. Dec. 19, 1996  Updates - corrected Sun Microsystems security-alert email
  473.                address.
  474. Dec. 10, 1996  Appendix A, #3 - corrected next to last reserved private
  475.                network number entry.
  476. Dec. 09, 1996  Updates - added IBM patch information.
  477. Nov. 12, 1996  Introduction, paragraph 2 - added some clarification.
  478. Oct. 10, 1996  Updates - added a pointer to Sun Microsystems advisory.
  479.                          added a pointer to the CERT /pub/vendors directory.
  480. Oct. 08, 1996  Appendix A, #3 - revised the last item, reserved private
  481.                  network numbers
  482.                Updates - added BSDI patch information.
  483. Oct. 07, 1996  Updates - added a pointer to Silicon Graphics advisory.
  484. Sep. 24, 1996  Modified the supersession statement.
  485.  
  486.  
  487. -----BEGIN PGP SIGNATURE-----
  488. Version: 2.6.2
  489.  
  490. iQCVAwUBMswS6HVP+x0t4w7BAQHSCwQAybtrLI/dNK/C9G6XMZZ0GTQqq0uMEBK5
  491. jpPcF9JNHXyiLFspnwoFPF4j1+KgxlHtZOoM6AgPHQjsPgPYuysTeaPCRRgNdJ1J
  492. 6M3mqlr45ea5G5ifpymALNcWID7NEWQW44jtUG4TvG+ZhNtmCTytNCKmIzcxnSqf
  493. QVldZHoUDrc=
  494. =wtFm
  495. -----END PGP SIGNATURE-----
  496.