660 lines
27 KiB
Plaintext
660 lines
27 KiB
Plaintext
|
|
-----BEGIN PGP SIGNED MESSAGE-----
|
|
|
|
=============================================================================
|
|
CERT(sm) Advisory CA-95:01
|
|
Original issue date: January 23, 1995
|
|
Last revised: September 24, 1996
|
|
Supersession statement modified -
|
|
IP spoofing portion is superseded by CA-96.21.
|
|
|
|
A complete revision history is at the end of this file.
|
|
|
|
Topic: IP Spoofing Attacks and Hijacked Terminal Connections
|
|
- -----------------------------------------------------------------------------
|
|
*** The IP Spoofing portion of this advisory
|
|
has been superseded by CA-96.21 ***
|
|
|
|
The CERT Coordination Center has received reports of attacks in which
|
|
intruders create packets with spoofed source IP addresses. These attacks
|
|
exploit applications that use authentication based on IP addresses. This
|
|
exploitation leads to user and possibly root access on the targeted system.
|
|
Note that this attack does not involve source routing. Recommended solutions
|
|
are described in Section III below.
|
|
|
|
In the current attack pattern, intruders may dynamically modify the kernel of
|
|
a Sun 4.1.X system once root access is attained. In this attack, which is
|
|
separate from the IP spoofing attack, intruders use a tool to take control of
|
|
any open terminal or login session from users on the system. Note that
|
|
although the tool is currently being used primarily on SunOS 4.1.x systems,
|
|
the system features that make this attack possible are not unique to SunOS.
|
|
|
|
We will update this advisory as we receive additional information.
|
|
Please check advisory files regularly for updates that relate to your site.
|
|
|
|
- -----------------------------------------------------------------------------
|
|
|
|
I. Description
|
|
|
|
This description summarizes both the IP spoofing technique that can
|
|
lead to root access on a system and the tool that intruders are using to
|
|
take over open terminal and login connections after they get root access.
|
|
We are currently seeing attacks in which intruders combine IP spoofing
|
|
with use of the tool. However, these are two separate actions. Intruders
|
|
can use IP spoofing to gain root access for any purpose; similarly, they
|
|
can highjack terminal connections regardless of their method of gaining
|
|
root access.
|
|
|
|
IP spoofing
|
|
To gain access, intruders create packets with spoofed source IP
|
|
addresses. This exploits applications that use authentication based on
|
|
IP addresses and leads to unauthorized user and possibly root access
|
|
on the targeted system. It is possible to route packets through
|
|
filtering-router firewalls if they are not configured to filter
|
|
incoming packets whose source address is in the local domain. It
|
|
is important to note that the described attack is possible even if
|
|
no reply packets can reach the attacker.
|
|
|
|
Examples of configurations that are potentially vulnerable include
|
|
- routers to external networks that support multiple internal
|
|
interfaces
|
|
- routers with two interfaces that support subnetting on the
|
|
internal network
|
|
- proxy firewalls where the proxy applications use the source
|
|
IP address for authentication
|
|
|
|
The IP spoofing attacks we are currently seeing are similar to those
|
|
described in two papers: 1) "Security Problems in the TCP/IP Protocol
|
|
Suite" by Steve Bellovin, published in _Computer Communication Review_
|
|
vol. 19, no. 2 (April 1989) pages 32-48; 2) "A Weakness in the 4.2BSD
|
|
Unix TCP/IP Software" by Robert T. Morris. Both papers are available
|
|
by anonymous FTP from
|
|
|
|
ftp.research.att.com:/dist/internet_security
|
|
|
|
Bellovin paper: ipext.ps.Z
|
|
Morris paper: 117.ps.Z
|
|
|
|
Services that are vulnerable to the IP spoofing attack include
|
|
SunRPC & NFS
|
|
BSD UNIX "r" commands
|
|
anything wrapped by the tcp daemon wrappers - site dependent; check
|
|
your configuration
|
|
X windows
|
|
other applications that use source IP addresses for authentication
|
|
|
|
Hijacking tool
|
|
Once the intruders have root access on a system, they can use a tool
|
|
to dynamically modify the UNIX kernel. This modification allows them
|
|
to hijack existing terminal and login connections from any user on the
|
|
system.
|
|
|
|
In taking over the existing connections, intruders can bypass one-time
|
|
passwords and other strong authentication schemes by tapping the
|
|
connection after the authentication is complete. For example, a
|
|
legitimate user connects to a remote site through a login or terminal
|
|
session; the intruder hijacks the connection after the user has
|
|
completed the authentication to the remote location; the remote site
|
|
is now compromised. (See Section I for examples of vulnerable
|
|
configurations.)
|
|
|
|
Currently, the tool is used primarily on SunOS 4.1.x systems. However,
|
|
the system features that make this attack possible are not unique to
|
|
SunOS.
|
|
|
|
The CERT Coordination Center has been informed that any services
|
|
that use Kerberos for authentication should not be vulnerable
|
|
to an IP spoofing attack. For more information about Kerberos, see
|
|
|
|
ftp://rtfm.mit.edu/pub/usenet/news.answers/kerberos-faq
|
|
|
|
Also note that the information and solution described in this advisory
|
|
does not address the issue of mobile IP spoofing.
|
|
|
|
II. Impact
|
|
|
|
Current intruder activity in spoofing source IP addresses can lead to
|
|
unauthorized remote root access to systems behind a filtering-router
|
|
firewall.
|
|
|
|
After gaining root access and taking over existing terminal and login
|
|
connections, intruders can gain access to remote hosts.
|
|
|
|
|
|
III. Solutions
|
|
|
|
A. Detection
|
|
|
|
IP spoofing
|
|
If you monitor packets using network-monitoring software such as
|
|
netlog, look for a packet on your external interface that has
|
|
both its source and destination IP addresses in your local domain.
|
|
If you find one, you are currently under attack. Netlog is
|
|
available by anonymous FTP from
|
|
net.tamu.edu:/pub/security/TAMU/netlog-1.2.tar.gz
|
|
MD5 checksum: 1dd62e7e96192456e8c75047c38e994b
|
|
|
|
Another way to detect IP spoofing is to compare the process
|
|
accounting logs between systems on your internal network. If
|
|
the IP spoofing attack has succeeded on one of your systems,
|
|
you may get a log entry on the victim machine showing a remote
|
|
access; on the apparent source machine, there will be no
|
|
corresponding entry for initiating that remote access.
|
|
|
|
Hijacking tool
|
|
When the intruder attaches to an existing terminal or login
|
|
connection, users may detect unusual activity, such as commands
|
|
appearing on their terminal that they did not type or a blank window
|
|
that will no longer respond to their commands. Encourage your users
|
|
to inform you of any such activity. In addition, pay particular
|
|
attention to connections that have been idle for a long time.
|
|
|
|
Once the attack is completed, it is difficult to detect. However,
|
|
the intruders may leave remnants of their tools. For example, you
|
|
may find a kernel streams module designed to tap into existing TCP
|
|
connections.
|
|
|
|
B. Prevention
|
|
|
|
IP spoofing
|
|
The best method of preventing the IP spoofing problem is to install
|
|
a filtering router that restricts 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 in order to prevent
|
|
a source IP spoofing attack originating from your site.
|
|
|
|
The following vendors have reported support for this feature:
|
|
Bay Networks/Wellfleet routers, version 5 and later
|
|
Cabletron - LAN Secure
|
|
Cisco - RIS software all releases of version 9.21 and later
|
|
Livingston - all versions
|
|
|
|
3COM, Cisco Systems, and Morning Star Technologies have provided
|
|
detailed information, which you can find in Appendix A of this
|
|
advisory.
|
|
|
|
If you need more information about your router or about firewalls,
|
|
please contact your vendor directly.
|
|
|
|
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
|
|
do so.
|
|
|
|
Additional information about protecting yourself from IP spoofing
|
|
attacks is in Updates section at the end of this file; these
|
|
updates were added after the initial release of the advisory.
|
|
|
|
Hijacking tool
|
|
There is no specific way to prevent use of the tool other than
|
|
preventing intruders from gaining root access in the first place.
|
|
If you have experienced a root compromise, see Section C for general
|
|
instructions on how to recover.
|
|
|
|
|
|
C. Recovery from a UNIX root compromise
|
|
|
|
1. Disconnect from the network or operate the system in
|
|
single-user mode during the recovery. This will keep users
|
|
and intruders from accessing the system.
|
|
|
|
2. Verify system binaries and configuration files against the
|
|
vendor's media (do not rely on timestamp information to
|
|
provide an indication of modification). Do not trust any
|
|
verification tool such as cmp(1) located on the compromised
|
|
system as it, too, may have been modified by the intruder.
|
|
In addition, do not trust the results of the standard UNIX
|
|
sum(1) program as we have seen intruders modify system
|
|
files in such a way that the checksums remain the same.
|
|
Replace any modified files from the vendor's media, not
|
|
from backups.
|
|
-- or --
|
|
|
|
Reload your system from the vendor's media.
|
|
|
|
3. Search the system for new or modified setuid root files.
|
|
|
|
find / -user root -perm -4000 -print
|
|
|
|
If you are using NFS or AFS file systems, use ncheck to
|
|
search the local file systems.
|
|
|
|
ncheck -s /dev/sd0a
|
|
|
|
4. Change the password on all accounts.
|
|
|
|
5. Don't trust your backups for reloading any file used by
|
|
root. You do not want to re-introduce files altered by an
|
|
intruder.
|
|
|
|
............................................................................
|
|
|
|
Appendix A: Vendor Information
|
|
|
|
3COM
|
|
====
|
|
|
|
The following information has been provided by 3COM for their customers.
|
|
- ------------------------------------------------------------------------------
|
|
Begin Text Provided by 3COM
|
|
|
|
The following examples illustrate how NETBuilder software can be
|
|
configured to support the CERT Advisory recommendations. Each of
|
|
these examples assumes that the value of the -IP FilterDefAction
|
|
parameter is configured to Forward.
|
|
|
|
Example 1:
|
|
|
|
This example illustrates a two-router solution where the internal
|
|
network is configured with non-contiguous IP network numbers. The
|
|
filters are installed on the border router which can only have two
|
|
interfaces. In a two-port router, an output filter on one port is
|
|
equivalent to an input filter on the other port. Please refer to
|
|
Figure 1:
|
|
|
|
Figure 1: Non-Contiguous IP Networks
|
|
|
|
|
|
|
|
|
| Border | | |Internal|--- 10.0.0.0
|
|
Outside --| Router |---|---| Router |
|
|
| | |--- 20.0.0.0
|
|
|
|
|
30.0.0.0
|
|
|
|
|
|
The border router is configured with the following filters:
|
|
|
|
ADD -IP FilterAddrs 10.0.0.0/0.255.255.255 >
|
|
10.0.0.0/0.255.255.255 Discard
|
|
|
|
ADD -IP FilterAddrs 20.0.0.0/0.255.255.255 >
|
|
20.0.0.0/0.255.255.255 Discard
|
|
|
|
ADD -IP FilterAddrs 30.0.0.0/0.255.255.255 >
|
|
30.0.0.0/0.255.255.255 Discard
|
|
|
|
ADD -IP FilterAddrs 10.0.0.0/0.255.255.255 <>
|
|
20.0.0.0/0.255.255.255 Discard
|
|
|
|
ADD -IP FilterAddrs 10.0.0.0/0.255.255.255 <>
|
|
30.0.0.0/0.255.255.255 Discard
|
|
|
|
ADD -IP FilterAddrs 20.0.0.0/0.255.255.255 <>
|
|
30.0.0.0/0.255.255.255 Discard
|
|
|
|
This configuration prevents the external attack and allows the
|
|
internal router to route traffic between networks 10.0.0.0, 20.0.0.0,
|
|
and 30.0.0.0. This configuration also works for the cascade topology
|
|
shown in Figure 2.
|
|
|
|
|
|
Figure 2: Non-Contiguous IP Networks (alternate topology)
|
|
|
|
|
|
| |
|
|
| Border | | |Internal| | |Internal|
|
|
Outside ---| Router |---|---| Router |---|---| Router |--- 10.0.0.0
|
|
| |
|
|
| |
|
|
30.0.0.0 20.0.0.0
|
|
|
|
|
|
Example 2:
|
|
|
|
The second example illustrates a two-router solution when the internal
|
|
network is configured with multiple subnets of the Class B network
|
|
address - 130.5.0.0. The subnet mask is 255.255.255.0. Please refer
|
|
to Figure 3.
|
|
|
|
|
|
Figure 3: Subnets on the Internal Network
|
|
|
|
|
|
|
|
|
| Border | | |Internal|--- 130.5.2.0
|
|
Outside --| Router |---|---| Router |
|
|
| | |--- 130.5.3.0
|
|
|
|
|
130.5.1.0 Subnet Mask = 255.255.255.0
|
|
|
|
|
|
The border router is configured with the following filter:
|
|
|
|
ADD -IP FilterAddrs 130.5.0.0/0.0.255.255 >
|
|
130.5.0.0/0.0.255.255 Discard
|
|
|
|
This configuration prevents the external attack and allows the internal route
|
|
to route traffic between all subnetworks of 130.5.0.0. In this example, a
|
|
single filter can protect multiple subnets.
|
|
|
|
Example 3:
|
|
|
|
The final example illustrates a two-router solution when the internal
|
|
network is configured with contiguous IP network numbers. Assume the
|
|
service provider has provided the subscriber with the CIDR block
|
|
200.5.0.0/255.255.0.0. Please refer to Figure 4:
|
|
|
|
|
|
Figure 4: Multiple Contiguous IP Networks
|
|
|
|
|
|
|
|
|
| Border | | |Internal|--- 200.5.2.0
|
|
Outside --| Router |---|---| Router |
|
|
| | |--- 200.5.3.0
|
|
|
|
|
200.5.1.0 CIDR Mask = 255.255.0.0
|
|
|
|
The border router is configured with the following filter:
|
|
|
|
ADD -IP FilterAddrs 200.5.0.0/0.0.255.255 >
|
|
200.5.0.0/0.0.255.255 Discard
|
|
|
|
This configuration prevents the external attack and allows the
|
|
internal router to route traffic between supernets of
|
|
200.5.0.0/255.255.0.0. In this example, a single filter can protect
|
|
multiple contiguous IP networks numbers assigned as a CIDR block.
|
|
|
|
End Text Provided by 3COM
|
|
- ------------------------------------------------------------------------------
|
|
|
|
Cisco Systems
|
|
=============
|
|
|
|
The following information has been provided by Cisco Systems for
|
|
their customers.
|
|
- -------------------------------------------------------------------------------
|
|
Begin Text Provided by Cisco
|
|
|
|
The defense is to set up your internet firewall router to deny packets
|
|
from OUTSIDE your network that claim to have a source address INSIDE
|
|
your network.
|
|
|
|
example configuration:
|
|
|
|
access-list 101 deny ip 131.108.0.0 0.0.255.255 0.0.0.0 255.255.255.255
|
|
access-list 101 deny ip 198.92.93.0 0.0.0.255 0.0.0.0 255.255.255.255
|
|
[..rest of your firewall goes here..]
|
|
|
|
and so on, where access list 101 describes all possible source
|
|
addresses on YOUR network. The example above describes a network with
|
|
internal source addresses of 131.108.x.x and 198.92.93.x
|
|
|
|
Note: If you use only the two line example described above without any
|
|
other access-list commands, ALL TRAFFIC will be stopped on your interface
|
|
since the implicit action of an unmatched access-list is to deny packets.
|
|
|
|
If you only want source address spoofing protection and nothing else, add
|
|
the line
|
|
|
|
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
|
|
|
|
to the end of the earlier example. This is NOT an optimal solution since
|
|
there are many other possible attacks barring the IP spoofing fixed here.
|
|
|
|
There are articles on this topic on the CIO information service and various
|
|
USENET mailing lists. You can telnet to cio.cisco.com or point your WWW
|
|
browser at http://www.cisco.com.
|
|
|
|
Anyway! Once you have defined an appropriate access list you can apply them
|
|
to the vulnerable interfaces.
|
|
|
|
Assuming your interface serial 0 faces the Internet:
|
|
|
|
interface serial 0
|
|
description interface facing the big, bad Internet
|
|
ip access-group 101 in
|
|
|
|
for a router running 9.21 or later.
|
|
|
|
If you DO NOT have 9.21, an upgrade is NOT required if your internet
|
|
firewall is a two port router (which it should be). Simply
|
|
apply access-list 101 as described above to the LAN interface and not
|
|
the serial interface.
|
|
|
|
example:
|
|
|
|
interface ethernet 0
|
|
description LAN port on my internet router
|
|
ip access-group 101
|
|
|
|
The essence of this defense is that any packets coming from the internet that
|
|
claim to be from your network are tossed, thereby preventing the style of
|
|
attack described below.
|
|
|
|
Also, for good measure, ALL INTERNET FIREWALLS should have the global
|
|
command
|
|
|
|
no ip source-route
|
|
|
|
Which helps prevent other forms of spoofing attack from outside.
|
|
|
|
|
|
For further discussion of sequence number guessing attacks, see papers
|
|
by Morris and also Bellovin in
|
|
|
|
ftp://ftp.research.att.com/dist/internet_security/117.ps.Z
|
|
ftp://ftp.research.att.com/dist/internet_security/ipext.ps.Z
|
|
|
|
End Text Provided by Cisco
|
|
- -------------------------------------------------------------------------------
|
|
|
|
|
|
Morning Star Technologies, Inc.
|
|
===============================
|
|
|
|
The following information has been provided by Morning Star
|
|
Technologies for their customers.
|
|
- -------------------------------------------------------------------------------
|
|
Begin Text Provided by Morning Star
|
|
|
|
TO ALL USERS OF MORNING STAR PRODUCTS:
|
|
|
|
Here is how to configure your Internet interface to prevent such
|
|
attacks:
|
|
|
|
1) Locate the packet filter file controlling your interface to the
|
|
Internet. For users of Morning Star PPP, this will usually be
|
|
/etc/ppp/Filter, /usr/etc/ppp/Filter, or /usr/lib/ppp/Filter.
|
|
Users of Express routers should look in the file called Filter.
|
|
Check your pppd (or frd for frame relay users) command line for
|
|
a possibly different filter filename, or look for `ifconfig
|
|
[interface] filter [filename]' commands in your Express
|
|
router's rc.boot file.
|
|
|
|
2) Within the packet filter file, locate the individual filter
|
|
specification used by your Internet connection. It will begin
|
|
with either the hostname or IP address of the remote side of a
|
|
PPP connection, the local hostname or IP address of a frame
|
|
relay, Ethernet, or RF modem connection, or the special keyword
|
|
`default' for any type of connection.
|
|
|
|
3) Within the appropriate filter specification, locate the `pass'
|
|
filter.
|
|
|
|
4) Add the following line to the beginning of the pass filter:
|
|
|
|
!ip_opt=srcrt
|
|
|
|
This will cause all transmitted or received IP packets with
|
|
Source Routing options to be discarded.
|
|
|
|
5) Determine the IP network number or numbers of your internal
|
|
network or networks. Insert a set of lines similar to the
|
|
following pair following the source route rule described in
|
|
step 4) above for each internal network number.
|
|
|
|
!recv/src/[network-number]
|
|
!send/dst/[network-number]
|
|
|
|
This will block all received packets containing a source IP
|
|
address in your internal network, and will block the
|
|
transmission of all packets containing a destination IP address
|
|
in your internal network. For example, we have Class B network
|
|
137.175, so our Filter file contains
|
|
|
|
!ip_opt=srcrt
|
|
!recv/src/137.175.0.0
|
|
!send/dst/137.175.0.0
|
|
|
|
If you don't have a whole IP network, you'll also need to
|
|
specify a netmask. For example, an organization that has both
|
|
the Class C network 192.1.1.0 and the Class-C-sized 10.1.220.0
|
|
segment of the Class A net 10 would add these lines
|
|
|
|
!ip_opt=srcrt
|
|
!recv/src/192.1.1.0
|
|
!send/dst/192.1.1.0
|
|
!recv/src/10.1.220.0/255.255.255.0
|
|
!send/dst/10.1.220.0/255.255.255.0
|
|
|
|
FURTHER NOTE:
|
|
|
|
Do not configure any of your systems to trust any of the Unix `r'
|
|
commands (rlogin, rsh, etc.) from any machine outside your firewall.
|
|
Such systems can be spoofed as easily as internal machines, but
|
|
spoofed packets cannot be detected at your firewall.
|
|
|
|
GETTING MORE HELP:
|
|
|
|
If you need any help with these modifications, call our customer
|
|
support hotline at +1 800 558 7827 or send us e-mail at
|
|
support@MorningStar.Com. When sending e-mail, please include the
|
|
phrase CERT SECURITY PROBLEM in your Subject: header. We will provide
|
|
assistance with this to all Morning Star customers, even for those
|
|
without current customer support agreements. If you do not have a
|
|
current support agreement, use the phrase `CERT SECURITY PROBLEM' when
|
|
asked for your customer support number.
|
|
|
|
End Text Provided by Morning Star
|
|
- ------------------------------------------------------------------------------
|
|
|
|
|
|
- ---------------------------------------------------------------------------
|
|
The CERT Coordination Center thanks Eric Allman, Steve Bellovin, Keith Bostic,
|
|
Bill Cheswick, Mike Karels, and Tsutomu Shimomura for contributing to our
|
|
understanding of these problems and their solutions.
|
|
- ---------------------------------------------------------------------------
|
|
|
|
If you believe that your system has been compromised, contact the CERT
|
|
Coordination Center or your representative in Forum of Incident
|
|
Response and Security Teams (FIRST).
|
|
|
|
If you wish to send sensitive incident or vulnerability information to
|
|
CERT staff by electronic mail, we strongly advise that the e-mail be
|
|
encrypted. The CERT Coordination Center can support a shared DES key, PGP
|
|
(public key available via anonymous FTP on info.cert.org), or PEM (contact
|
|
CERT staff for details).
|
|
|
|
Internet E-mail: cert@cert.org
|
|
Telephone: +1 412-268-7090 (24-hour hotline)
|
|
CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4),
|
|
and are on call for emergencies during other hours.
|
|
Fax: +1 412-268-6989
|
|
|
|
CERT Coordination Center
|
|
Software Engineering Institute
|
|
Carnegie Mellon University
|
|
Pittsburgh, PA 15213-3890
|
|
USA
|
|
|
|
Past advisories, CERT bulletins, information about FIRST representatives,
|
|
and other information related to computer security are available for anonymous
|
|
FTP from info.cert.org.
|
|
|
|
|
|
Copyright 1995, 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.
|
|
|
|
===========================================================================
|
|
UPDATES
|
|
|
|
Additional steps you can take to address IP spoofing:
|
|
|
|
For IP spoofing to be successful, intruders rely on two machines to
|
|
trust each other through the use of the .rhosts file or the
|
|
/etc/hosts.equiv file. By exploiting applications that use
|
|
authentication based on IP addresses (e.g., rsh and rlogin), intruders
|
|
can gain user or root access on targeted hosts.
|
|
|
|
We suggest that you use TCP wrappers to allow access from only a
|
|
select few machines. Although this is not a complete solution, it
|
|
does reduce your susceptibility to attack. Alternatively, change the
|
|
configuration of your Internet gateway so that rlogin and rsh from the
|
|
Internet to hosts in your domain are blocked. If that is not
|
|
possible, disable the rlogin and rsh services on all of your hosts.
|
|
|
|
Some sites have turned off source routing thinking that this would
|
|
prevent IP spoofing attacks. This is NOT the case. Although we
|
|
encourage sites to turn off source routing this does not prevent IP
|
|
spoofing attacks. To prevent such attacks it is necessary to undertake
|
|
packet filtering as described in the advisory.
|
|
|
|
In addition to the attacks described in this advisory, we are now
|
|
seeing attacks in which intruders gain access to a site using loopback
|
|
IP addresses rather than IP addresses particular to that site.
|
|
|
|
We recommend that in addition to the packet filtering suggestions
|
|
described in Section III B of the advisory, you configure the
|
|
filtering router to filter inbound packets in the following IP ranges:
|
|
|
|
127.0.0.0 - 127.255.255.255 (loopback)
|
|
10.0.0.0 - 10.255.255.255 (reserved)
|
|
172.16.0.0 - 172.31.255.255 (reserved)
|
|
192.168.0.0 - 192.168.255.255 (reserved)
|
|
|
|
|
|
|
|
Finally, we encourage you to consider using network monitoring tools to check
|
|
for signs of IP spoofing attacks. Argus is a network monitoring tool that
|
|
uses a client-server model to capture data and associate it into
|
|
"transactions." The tool provides network-level auditing; it can verify
|
|
compliance to a router configuration file, and information is easily adapted
|
|
to protocol analysis, intrusion detections, and other security needs. Argus is
|
|
available from
|
|
|
|
ftp://ftp.net.cmu.edu/pub/argus-1.5
|
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
Revision history
|
|
|
|
Sep. 24, 1996 Supersession statement modified
|
|
Sep. 19, 1996 Superseded by CA-96.21 [IP spoofing portion only]
|
|
Aug. 30, 1996 Information previously in the README was inserted
|
|
into the advisory.
|
|
-- Appendix A - added vendor information as it was received: Cisco
|
|
Systems, Morning Star Technologies, and 3COM.
|
|
May 10, 1996 Updates section - added pointer to the Argus tool.
|
|
Aug. 04, 1995 Updates section - added more information on IP spoofing
|
|
and recommendations for detecting such activity.
|
|
Aug. 04, 1995 Sec. I - added notes about Kerberos and mobile IP spoofing.
|
|
|
|
|
|
-----BEGIN PGP SIGNATURE-----
|
|
Version: 2.6.2
|
|
|
|
iQCVAwUBMkf23nVP+x0t4w7BAQEphwP+MQFO67ra5i1f1RXvu2AhQH50wBHcvyVo
|
|
89ASbYa4f1OrTCp8TQa7YUGmWF4eA7T2Ha7YBvK78ne5mR/VGYlmfR2FtD9Ncca8
|
|
nBlkDTegm1zkF7CaOdH7jVb4T7zpVaqurZk+FW5eVusWFo2cMHCToYK/8Wt8DVf2
|
|
zK35FrZ0B9c=
|
|
=tOul
|
|
-----END PGP SIGNATURE-----
|
|
|