home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / hacking / general / cert0089.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  27.4 KB  |  660 lines

  1.  
  2. -----BEGIN PGP SIGNED MESSAGE-----
  3.  
  4. =============================================================================
  5. CERT(sm) Advisory CA-95:01
  6. Original issue date: January 23, 1995
  7. Last revised: September 24, 1996
  8.               Supersession statement modified -
  9.               IP spoofing portion is superseded by CA-96.21.
  10.  
  11.               A complete revision history is at the end of this file.
  12.  
  13. Topic: IP Spoofing Attacks and Hijacked Terminal Connections
  14. - -----------------------------------------------------------------------------
  15.                *** The IP Spoofing portion of this advisory
  16.                    has been superseded by  CA-96.21 ***
  17.  
  18. The CERT Coordination Center has received reports of attacks in which
  19. intruders create packets with spoofed source IP addresses. These attacks
  20. exploit applications that use authentication based on IP addresses. This
  21. exploitation leads to user and possibly root access on the targeted system.
  22. Note that this attack does not involve source routing. Recommended solutions
  23. are described in Section III below.
  24.  
  25. In the current attack pattern, intruders may dynamically modify the kernel of
  26. a Sun 4.1.X system once root access is attained.  In this attack, which is
  27. separate from the IP spoofing attack, intruders use a tool to take control of
  28. any open terminal or login session from users on the system. Note that
  29. although the tool is currently being used primarily on SunOS 4.1.x systems,
  30. the system features that make this attack possible are not unique to SunOS.
  31.  
  32. We will update this advisory as we receive additional information.
  33. Please check advisory files regularly for updates that relate to your site.
  34.  
  35. - -----------------------------------------------------------------------------
  36.  
  37. I.   Description
  38.  
  39.      This description summarizes both the IP spoofing technique that can
  40.      lead to root access on a system and the tool that intruders are using to
  41.      take over open terminal and login connections after they get root access.
  42.      We are currently seeing attacks in which intruders combine IP spoofing
  43.      with use of the tool. However, these are two separate actions. Intruders
  44.      can use IP spoofing to gain root access for any purpose; similarly, they
  45.      can highjack terminal connections regardless of their method of gaining
  46.      root access.
  47.  
  48.      IP spoofing
  49.         To gain access, intruders create packets with spoofed source IP
  50.         addresses. This exploits applications that use authentication based on
  51.         IP addresses and leads to unauthorized user and possibly root access
  52.         on the targeted system. It is possible to route packets through
  53.         filtering-router firewalls if they are not configured to filter
  54.         incoming packets whose source address is in the local domain. It
  55.         is important to note that the described attack is possible even if
  56.         no reply packets can reach the attacker.
  57.  
  58.         Examples of configurations that are potentially vulnerable include
  59.         - routers to external networks that support multiple internal
  60.           interfaces
  61.         - routers with two interfaces that support subnetting on the
  62.           internal network
  63.         - proxy firewalls where the proxy applications use the source
  64.           IP address for authentication
  65.  
  66.         The IP spoofing attacks we are currently seeing are similar to those
  67.         described in two papers: 1) "Security Problems in the TCP/IP Protocol
  68.         Suite" by Steve Bellovin, published in _Computer Communication Review_
  69.         vol. 19, no. 2 (April 1989) pages 32-48; 2) "A Weakness in the 4.2BSD
  70.         Unix TCP/IP Software" by Robert T. Morris. Both papers are available
  71.         by anonymous FTP from
  72.  
  73.            ftp.research.att.com:/dist/internet_security
  74.  
  75.            Bellovin paper: ipext.ps.Z
  76.            Morris paper:   117.ps.Z
  77.  
  78.         Services that are vulnerable to the IP spoofing attack include
  79.            SunRPC & NFS
  80.            BSD UNIX "r" commands
  81.            anything wrapped by the tcp daemon wrappers - site dependent; check
  82.                your configuration
  83.            X windows
  84.            other applications that use source IP addresses for authentication
  85.  
  86.      Hijacking tool
  87.         Once the intruders have root access on a system, they can use a tool
  88.         to dynamically modify the UNIX kernel. This modification allows them
  89.         to hijack existing terminal and login connections from any user on the
  90.         system.
  91.  
  92.         In taking over the existing connections, intruders can bypass one-time
  93.         passwords and other strong authentication schemes by tapping the
  94.         connection after the authentication is complete. For example, a
  95.         legitimate user connects to a remote site through a login or terminal
  96.         session; the intruder hijacks the connection after the user has
  97.         completed the authentication to the remote location; the remote site
  98.         is now compromised. (See Section I for examples of vulnerable
  99.         configurations.)
  100.  
  101.         Currently, the tool is used primarily on SunOS 4.1.x systems. However,
  102.         the system features that make this attack possible are not unique to
  103.         SunOS.
  104.  
  105.         The CERT Coordination Center has been informed that any services
  106.         that use Kerberos for authentication should not be vulnerable
  107.         to an IP spoofing attack.  For more information about Kerberos, see
  108.  
  109.                 ftp://rtfm.mit.edu/pub/usenet/news.answers/kerberos-faq
  110.  
  111.         Also note that the information and solution described in this advisory
  112.         does not address the issue of mobile IP spoofing.
  113.  
  114. II. Impact
  115.  
  116.      Current intruder activity in spoofing source IP addresses can lead to
  117.      unauthorized remote root access to systems behind a filtering-router
  118.      firewall.
  119.  
  120.      After gaining root access and taking over existing terminal and login
  121.      connections, intruders can gain access to remote hosts.
  122.  
  123.  
  124. III. Solutions
  125.  
  126.      A. Detection
  127.  
  128.         IP spoofing
  129.            If you monitor packets using network-monitoring software such as
  130.            netlog, look for a packet on your external interface that has
  131.            both its source and destination IP addresses in your local domain.
  132.            If you find one, you are currently under attack. Netlog is
  133.            available by anonymous FTP from
  134.               net.tamu.edu:/pub/security/TAMU/netlog-1.2.tar.gz
  135.               MD5 checksum: 1dd62e7e96192456e8c75047c38e994b
  136.  
  137.            Another way to detect IP spoofing is to compare the process
  138.            accounting logs between systems on your internal network. If
  139.            the IP spoofing attack has succeeded on one of your systems,
  140.            you may get a log entry on the victim machine showing a remote
  141.            access; on the apparent source machine, there will be no
  142.            corresponding entry for initiating that remote access.
  143.  
  144.         Hijacking tool
  145.            When the intruder attaches to an existing terminal or login
  146.            connection, users may detect unusual activity, such as commands
  147.            appearing on their terminal that they did not type or a blank window
  148.            that will no longer respond to their commands. Encourage your users
  149.            to inform you of any such activity. In addition, pay particular
  150.            attention to connections that have been idle for a long time.
  151.  
  152.            Once the attack is completed, it is difficult to detect. However,
  153.            the intruders may leave remnants of their tools. For example, you
  154.            may find a kernel streams module designed to tap into existing TCP
  155.            connections.
  156.  
  157.      B. Prevention
  158.  
  159.         IP spoofing
  160.            The best method of preventing the IP spoofing problem is to install
  161.            a filtering router that restricts the input to your external
  162.            interface (known as an input filter) by not allowing a packet
  163.            through if it has a source address from your internal network. In
  164.            addition, you should filter outgoing packets that have a source
  165.            address different from your internal network in order to prevent
  166.            a source IP spoofing attack originating from your site.
  167.  
  168.            The following vendors have reported support for this feature:
  169.              Bay Networks/Wellfleet routers, version 5 and later
  170.              Cabletron - LAN Secure
  171.              Cisco - RIS software all releases of version 9.21 and later
  172.              Livingston - all versions
  173.  
  174.            3COM, Cisco Systems, and Morning Star Technologies have provided
  175.            detailed information, which you can find in Appendix A of this
  176.            advisory.
  177.  
  178.            If you need more information about your router or about firewalls,
  179.            please contact your vendor directly.
  180.  
  181.            If your vendor's router does not support filtering on the inbound
  182.            side of the interface or if there will be a delay in incorporating
  183.            the feature into your system, you may filter the spoofed IP packets
  184.            by using a second router between your external interface and your
  185.            outside connection. Configure this router to block, on the outgoing
  186.            interface connected to your original router, all packets that have a
  187.            source address in your internal network. For this purpose, you can
  188.            use a filtering router or a UNIX system with two interfaces that
  189.            supports packet filtering.
  190.  
  191.            NOTE: Disabling source routing at the router does not protect you
  192.                  from this attack, but it is still good security practice to
  193.                  do so.
  194.  
  195.            Additional information about protecting yourself from IP spoofing
  196.            attacks is in Updates section at the end of this file; these
  197.            updates were added after the initial release of the advisory.
  198.  
  199.          Hijacking tool
  200.            There is no specific way to prevent use of the tool other than
  201.            preventing intruders from gaining root access in the first place.
  202.            If you have experienced a root compromise, see Section C for general
  203.            instructions on how to recover.
  204.  
  205.  
  206.      C. Recovery from a UNIX root compromise
  207.  
  208.         1. Disconnect from the network or operate the system in
  209.            single-user mode during the recovery.  This will keep users
  210.            and intruders from accessing the system.
  211.  
  212.         2. Verify system binaries and configuration files against the
  213.            vendor's media (do not rely on timestamp information to
  214.            provide an indication of modification).  Do not trust any
  215.            verification tool such as cmp(1) located on the compromised
  216.            system as it, too, may have been modified by the intruder.
  217.            In addition, do not trust the results of the standard UNIX
  218.            sum(1) program as we have seen intruders modify system
  219.            files in such a way that the checksums remain the same.
  220.            Replace any modified files from the vendor's media, not
  221.            from backups.
  222.                                 -- or --
  223.  
  224.            Reload your system from the vendor's media.
  225.  
  226.         3. Search the system for new or modified setuid root files.
  227.  
  228.                 find / -user root -perm -4000 -print
  229.  
  230.            If you are using NFS or AFS file systems, use ncheck to
  231.            search the local file systems.
  232.  
  233.                 ncheck -s /dev/sd0a
  234.  
  235.         4. Change the password on all accounts.
  236.  
  237.         5. Don't trust your backups for reloading any file used by
  238.            root.  You do not want to re-introduce files altered by an
  239.            intruder.
  240.  
  241. ............................................................................
  242.  
  243. Appendix A: Vendor Information
  244.  
  245. 3COM
  246. ====
  247.  
  248. The following information has been provided by 3COM for their customers.
  249. - ------------------------------------------------------------------------------
  250.                      Begin Text Provided by 3COM
  251.  
  252. The following examples illustrate how NETBuilder software can be
  253. configured to support the CERT Advisory recommendations.  Each of
  254. these examples assumes that the value of the -IP FilterDefAction
  255. parameter is configured to Forward.
  256.  
  257. Example 1:
  258.  
  259. This example illustrates a two-router solution where the internal
  260. network is configured with non-contiguous IP network numbers.  The
  261. filters are installed on the border router which can only have two
  262. interfaces.  In a two-port router, an output filter on one port is
  263. equivalent to an input filter on the other port.  Please refer to
  264. Figure 1:
  265.  
  266. Figure 1: Non-Contiguous IP Networks
  267.  
  268.  
  269.                         |
  270.            | Border |   |   |Internal|--- 10.0.0.0
  271. Outside  --| Router |---|---| Router |
  272.                         |   |        |--- 20.0.0.0
  273.                         |
  274.                      30.0.0.0
  275.  
  276.  
  277. The border router is configured with the following filters:
  278.  
  279. ADD -IP FilterAddrs 10.0.0.0/0.255.255.255 >
  280.           10.0.0.0/0.255.255.255 Discard
  281.  
  282. ADD -IP FilterAddrs 20.0.0.0/0.255.255.255 >
  283.           20.0.0.0/0.255.255.255 Discard
  284.  
  285. ADD -IP FilterAddrs 30.0.0.0/0.255.255.255 >
  286.           30.0.0.0/0.255.255.255 Discard
  287.  
  288. ADD -IP FilterAddrs 10.0.0.0/0.255.255.255 <>
  289.           20.0.0.0/0.255.255.255 Discard
  290.  
  291. ADD -IP FilterAddrs 10.0.0.0/0.255.255.255 <>
  292.           30.0.0.0/0.255.255.255 Discard
  293.  
  294. ADD -IP FilterAddrs 20.0.0.0/0.255.255.255 <>
  295.           30.0.0.0/0.255.255.255 Discard
  296.  
  297. This configuration prevents the external attack and allows the
  298. internal router to route traffic between networks 10.0.0.0, 20.0.0.0,
  299. and 30.0.0.0.  This configuration also works for the cascade topology
  300. shown in Figure 2.
  301.  
  302.  
  303. Figure 2: Non-Contiguous IP Networks (alternate topology)
  304.  
  305.  
  306.                         |                |
  307.            | Border |   |   |Internal|   |   |Internal|
  308. Outside ---| Router |---|---| Router |---|---| Router |--- 10.0.0.0
  309.                         |                |
  310.                         |                |
  311.                     30.0.0.0          20.0.0.0
  312.  
  313.  
  314. Example 2:
  315.  
  316. The second example illustrates a two-router solution when the internal
  317. network is configured with multiple subnets of the Class B network
  318. address - 130.5.0.0.  The subnet mask is 255.255.255.0.  Please refer
  319. to Figure 3.
  320.  
  321.  
  322. Figure 3: Subnets on the Internal Network
  323.  
  324.  
  325.                         |
  326.            | Border |   |   |Internal|--- 130.5.2.0
  327. Outside  --| Router |---|---| Router |
  328.                         |   |        |--- 130.5.3.0
  329.                         |
  330.                     130.5.1.0    Subnet Mask = 255.255.255.0
  331.  
  332.  
  333. The border router is configured with the following filter:
  334.  
  335. ADD -IP FilterAddrs 130.5.0.0/0.0.255.255 >
  336.          130.5.0.0/0.0.255.255 Discard
  337.  
  338. This configuration prevents the external attack and allows the internal route
  339. to route traffic between all subnetworks of 130.5.0.0.  In this example, a
  340. single filter can protect multiple subnets.
  341.  
  342. Example 3:
  343.  
  344. The final example illustrates a two-router solution when the internal
  345. network is configured with contiguous IP network numbers.  Assume the
  346. service provider has provided the subscriber with the CIDR block
  347. 200.5.0.0/255.255.0.0.  Please refer to Figure 4:
  348.  
  349.  
  350. Figure 4: Multiple Contiguous IP Networks
  351.  
  352.  
  353.                         |
  354.            | Border |   |   |Internal|---  200.5.2.0
  355. Outside  --| Router |---|---| Router |
  356.                         |   |        |---  200.5.3.0
  357.                         |
  358.                      200.5.1.0    CIDR Mask = 255.255.0.0
  359.  
  360. The border router is configured with the following filter:
  361.  
  362. ADD -IP FilterAddrs 200.5.0.0/0.0.255.255 >
  363.           200.5.0.0/0.0.255.255 Discard
  364.  
  365. This configuration prevents the external attack and allows the
  366. internal router to route traffic between supernets of
  367. 200.5.0.0/255.255.0.0.  In this example, a single filter can protect
  368. multiple contiguous IP networks numbers assigned as a CIDR block.
  369.  
  370.                       End Text Provided by 3COM
  371. - ------------------------------------------------------------------------------
  372.  
  373. Cisco Systems
  374. =============
  375.  
  376. The following information has been provided by Cisco Systems for
  377. their customers.
  378. - -------------------------------------------------------------------------------
  379.                      Begin Text Provided by Cisco
  380.  
  381. The defense is to set up your internet firewall router to deny packets
  382. from OUTSIDE your network that claim to have a source address INSIDE
  383. your network.
  384.  
  385. example configuration:
  386.  
  387. access-list 101 deny ip 131.108.0.0 0.0.255.255 0.0.0.0 255.255.255.255
  388. access-list 101 deny ip 198.92.93.0 0.0.0.255 0.0.0.0 255.255.255.255
  389. [..rest of your firewall goes here..]
  390.  
  391. and so on, where access list 101 describes all possible source
  392. addresses on YOUR network.  The example above describes a network with
  393. internal source addresses of 131.108.x.x and 198.92.93.x
  394.  
  395. Note: If you use only the two line example described above without any
  396. other access-list commands, ALL TRAFFIC will be stopped on your interface
  397. since the implicit action of an unmatched access-list is to deny packets.
  398.  
  399. If you only want source address spoofing protection and nothing else, add
  400. the line
  401.  
  402. access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
  403.  
  404. to the end of the earlier example.  This is NOT an optimal solution since
  405. there are many other possible attacks barring the IP spoofing fixed here.
  406.  
  407. There are articles on this topic on the CIO information service and various
  408. USENET mailing lists.  You can telnet to cio.cisco.com or point your WWW
  409. browser at http://www.cisco.com.
  410.  
  411. Anyway!  Once you have defined an appropriate access list you can apply them
  412. to the vulnerable interfaces.
  413.  
  414. Assuming your interface serial 0 faces the Internet:
  415.  
  416. interface serial 0
  417. description interface facing the big, bad Internet
  418. ip access-group 101 in
  419.  
  420. for a router running 9.21 or later.
  421.  
  422. If you DO NOT have 9.21, an upgrade is NOT required if your internet
  423. firewall is a two port router (which it should be).  Simply
  424. apply access-list 101 as described above to the LAN interface and not
  425. the serial interface.
  426.  
  427. example:
  428.  
  429. interface ethernet 0
  430. description LAN port on my internet router
  431. ip access-group 101
  432.  
  433. The essence of this defense is that any packets coming from the internet that
  434. claim to be from your network are tossed, thereby preventing the style of
  435. attack described below.
  436.  
  437. Also, for good measure, ALL INTERNET FIREWALLS should have the global
  438. command
  439.  
  440. no ip source-route
  441.  
  442. Which helps prevent other forms of spoofing attack from outside.
  443.  
  444.  
  445. For further discussion of sequence number guessing attacks, see papers
  446. by Morris and also Bellovin in
  447.  
  448.  ftp://ftp.research.att.com/dist/internet_security/117.ps.Z
  449.  ftp://ftp.research.att.com/dist/internet_security/ipext.ps.Z
  450.  
  451.                       End Text Provided by Cisco
  452. - -------------------------------------------------------------------------------
  453.  
  454.  
  455. Morning Star Technologies, Inc.
  456. ===============================
  457.  
  458. The following information has been provided by Morning Star
  459. Technologies for their customers.
  460. - -------------------------------------------------------------------------------
  461.                  Begin Text Provided by Morning Star
  462.  
  463. TO ALL USERS OF MORNING STAR PRODUCTS:
  464.  
  465. Here is how to configure your Internet interface to prevent such
  466. attacks:
  467.  
  468.     1) Locate the packet filter file controlling your interface to the
  469.        Internet.  For users of Morning Star PPP, this will usually be
  470.        /etc/ppp/Filter, /usr/etc/ppp/Filter, or /usr/lib/ppp/Filter.
  471.        Users of Express routers should look in the file called Filter.
  472.        Check your pppd (or frd for frame relay users) command line for
  473.        a possibly different filter filename, or look for `ifconfig
  474.        [interface] filter [filename]' commands in your Express
  475.        router's rc.boot file.
  476.  
  477.     2) Within the packet filter file, locate the individual filter
  478.        specification used by your Internet connection.  It will begin
  479.        with either the hostname or IP address of the remote side of a
  480.        PPP connection, the local hostname or IP address of a frame
  481.        relay, Ethernet, or RF modem connection, or the special keyword
  482.        `default' for any type of connection.
  483.  
  484.     3) Within the appropriate filter specification, locate the `pass'
  485.        filter.
  486.  
  487.     4) Add the following line to the beginning of the pass filter:
  488.  
  489.           !ip_opt=srcrt
  490.  
  491.        This will cause all transmitted or received IP packets with
  492.        Source Routing options to be discarded.
  493.  
  494.     5) Determine the IP network number or numbers of your internal
  495.        network or networks.  Insert a set of lines similar to the
  496.        following pair following the source route rule described in
  497.        step 4) above for each internal network number.
  498.  
  499.           !recv/src/[network-number]
  500.           !send/dst/[network-number]
  501.  
  502.        This will block all received packets containing a source IP
  503.        address in your internal network, and will block the
  504.        transmission of all packets containing a destination IP address
  505.        in your internal network.  For example, we have Class B network
  506.        137.175, so our Filter file contains
  507.  
  508.           !ip_opt=srcrt
  509.           !recv/src/137.175.0.0
  510.           !send/dst/137.175.0.0
  511.  
  512.        If you don't have a whole IP network, you'll also need to
  513.        specify a netmask.  For example, an organization that has both
  514.        the Class C network 192.1.1.0 and the Class-C-sized 10.1.220.0
  515.        segment of the Class A net 10 would add these lines
  516.  
  517.           !ip_opt=srcrt
  518.           !recv/src/192.1.1.0
  519.           !send/dst/192.1.1.0
  520.           !recv/src/10.1.220.0/255.255.255.0
  521.           !send/dst/10.1.220.0/255.255.255.0
  522.  
  523. FURTHER NOTE:
  524.  
  525. Do not configure any of your systems to trust any of the Unix `r'
  526. commands (rlogin, rsh, etc.) from any machine outside your firewall.
  527. Such systems can be spoofed as easily as internal machines, but
  528. spoofed packets cannot be detected at your firewall.
  529.  
  530. GETTING MORE HELP:
  531.  
  532. If you need any help with these modifications, call our customer
  533. support hotline at +1 800 558 7827 or send us e-mail at
  534. support@MorningStar.Com.  When sending e-mail, please include the
  535. phrase CERT SECURITY PROBLEM in your Subject: header.  We will provide
  536. assistance with this to all Morning Star customers, even for those
  537. without current customer support agreements.  If you do not have a
  538. current support agreement, use the phrase `CERT SECURITY PROBLEM' when
  539. asked for your customer support number.
  540.  
  541.                   End Text Provided by Morning Star
  542. - ------------------------------------------------------------------------------
  543.  
  544.  
  545. - ---------------------------------------------------------------------------
  546. The CERT Coordination Center thanks Eric Allman, Steve Bellovin, Keith Bostic,
  547. Bill Cheswick, Mike Karels, and Tsutomu Shimomura for contributing to our
  548. understanding of these problems and their solutions.
  549. - ---------------------------------------------------------------------------
  550.  
  551. If you believe that your system has been compromised, contact the CERT
  552. Coordination Center or your representative in Forum of Incident
  553. Response and Security Teams (FIRST).
  554.  
  555. If you wish to send sensitive incident or vulnerability information to
  556. CERT staff by electronic mail, we strongly advise that the e-mail be
  557. encrypted.  The CERT Coordination Center can support a shared DES key, PGP
  558. (public key available via anonymous FTP on info.cert.org), or PEM (contact
  559. CERT staff for details).
  560.  
  561. Internet E-mail: cert@cert.org
  562. Telephone: +1 412-268-7090 (24-hour hotline)
  563.            CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4),
  564.            and are on call for emergencies during other hours.
  565. Fax: +1 412-268-6989
  566.  
  567. CERT Coordination Center
  568. Software Engineering Institute
  569. Carnegie Mellon University
  570. Pittsburgh, PA 15213-3890
  571. USA
  572.  
  573. Past advisories, CERT bulletins, information about FIRST representatives,
  574. and other information related to computer security are available for anonymous
  575. FTP from info.cert.org.
  576.  
  577.  
  578. Copyright 1995, 1996 Carnegie Mellon University
  579. This material may be reproduced and distributed without permission provided
  580. it is used for noncommercial purposes and the copyright statement is
  581. included.
  582.  
  583. CERT is a service mark of Carnegie Mellon University.
  584.  
  585. ===========================================================================
  586. UPDATES
  587.  
  588. Additional steps you can take to address IP spoofing:
  589.  
  590. For IP spoofing to be successful, intruders rely on two machines to
  591. trust each other through the use of the .rhosts file or the
  592. /etc/hosts.equiv file.  By exploiting applications that use
  593. authentication based on IP addresses (e.g., rsh and rlogin), intruders
  594. can gain user or root access on targeted hosts.
  595.  
  596. We suggest that you use TCP wrappers to allow access from only a
  597. select few machines.  Although this is not a complete solution, it
  598. does reduce your susceptibility to attack.  Alternatively, change the
  599. configuration of your Internet gateway so that rlogin and rsh from the
  600. Internet to hosts in your domain are blocked.  If that is not
  601. possible, disable the rlogin and rsh services on all of your hosts.
  602.  
  603. Some sites have turned off source routing thinking that this would
  604. prevent IP spoofing attacks. This is NOT the case. Although we
  605. encourage sites to turn off source routing this does not prevent IP
  606. spoofing attacks. To prevent such attacks it is necessary to undertake
  607. packet filtering as described in the advisory.
  608.  
  609. In addition to the attacks described in this advisory, we are now
  610. seeing attacks in which intruders gain access to a site using loopback
  611. IP addresses rather than IP addresses particular to that site.
  612.  
  613. We recommend that in addition to the packet filtering suggestions
  614. described in Section III B of the advisory, you configure the
  615. filtering router to filter inbound packets in the following IP ranges:
  616.  
  617.         127.0.0.0       -       127.255.255.255         (loopback)
  618.         10.0.0.0        -       10.255.255.255          (reserved)
  619.         172.16.0.0      -       172.31.255.255          (reserved)
  620.         192.168.0.0     -       192.168.255.255         (reserved)
  621.  
  622.  
  623.  
  624. Finally, we encourage you to consider using network monitoring tools to check
  625. for signs of IP spoofing attacks. Argus is a network monitoring tool that
  626. uses a client-server model to capture data and associate it into
  627. "transactions." The tool provides network-level auditing; it can verify
  628. compliance to a router configuration file, and information is easily adapted
  629. to protocol analysis, intrusion detections, and other security needs. Argus is
  630. available from
  631.  
  632.                 ftp://ftp.net.cmu.edu/pub/argus-1.5
  633.  
  634.  
  635. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  636. Revision history
  637.  
  638. Sep. 24, 1996  Supersession statement modified
  639. Sep. 19, 1996  Superseded by CA-96.21 [IP spoofing portion only]
  640. Aug. 30, 1996  Information previously in the README was inserted
  641.                         into the advisory.
  642.     --         Appendix A - added vendor information as it was received: Cisco
  643.                         Systems, Morning Star Technologies, and 3COM.
  644. May 10, 1996   Updates section - added pointer to the Argus tool.
  645. Aug. 04, 1995  Updates section - added more information on IP spoofing
  646.                         and recommendations for detecting such activity.
  647. Aug. 04, 1995  Sec. I - added notes about Kerberos and mobile IP spoofing.
  648.  
  649.  
  650. -----BEGIN PGP SIGNATURE-----
  651. Version: 2.6.2
  652.  
  653. iQCVAwUBMkf23nVP+x0t4w7BAQEphwP+MQFO67ra5i1f1RXvu2AhQH50wBHcvyVo
  654. 89ASbYa4f1OrTCp8TQa7YUGmWF4eA7T2Ha7YBvK78ne5mR/VGYlmfR2FtD9Ncca8
  655. nBlkDTegm1zkF7CaOdH7jVb4T7zpVaqurZk+FW5eVusWFo2cMHCToYK/8Wt8DVf2
  656. zK35FrZ0B9c=
  657. =tOul
  658. -----END PGP SIGNATURE-----
  659.  
  660.