Document ID: 13602
Clarification of CERT Advisory Article
With regard to the Computer Emergency Response Team (CERT) advisory CA-95:01 published Jan, 23, 1995, the defense simply is to set up your Internet firewall router to deny packets from outside your network that claim to have a source address from inside your network.
Here is an example configuration:
access-list 101 deny ip 126.96.36.199 0.0.255.255 0.0.0.0 255.255.255.255 access-list 101 deny ip 188.8.131.52 0.0.0.255 0.0.0.0 255.255.255.255 [..rest of your firewall goes here..]
In this example, 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 below to the end of the earlier example:
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
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 Cisco Connection Online (CCO) information service and various USENET mailing lists. You can telnet to cco.cisco.com or point your WWW browser at http://www.cisco.com.
Once you have defined an appropriate access list you can apply them to the vulnerable interfaces.
Assuming your Interface serial 0 faces the Internet for a router running System Software Release 9.21 or later:
interface serial 0 description interface facing the big, bad Internet ip access-group 101 in
If you do not have System Software Release 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.
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
This helps prevent other forms of spoofing attack from outside.
The following article appeared on comp.security.misc and sums up the references cited in the CERT advisory concerning the cited vulnerabilities.
There are no specific requirements for this document.
This document is not restricted to specific software and hardware versions.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
There is a great deal of confusion about what kind of attack the recent CERT advisory is referring to. Let me try to clear things up.
The specific attack is a sequence number guessing attack, originally described by R.T. Morris in Bell Labs Computer Science Technical Report #117, Feb. 25, 1985. I generalized (and publicized) the attack in my 1989 paper "Security Problems in the TCP/IP Protocol Suite," Computer Communications Review 19:2, April 1989, pp. 32-48. Both his attack and my generalizations are special cases of a more general attack, IP source address spoofing, in which the attacker illegitimately uses a trusted machine's IP address in conjunction with some protocol (such as the remote shell protocol (rsh)) that does address-based authentication.
In order to understand the particular case of sequence number guessing, you have to look at the three-way handshake used in the TCP open sequence. Suppose client machine A wants to talk to rsh server B. It sends the following message:
A->B: SYN, ISSa
That is, it sends a packet with the synchronize sequence number (SYN) bit set and an initial sequence number ISSb.
B replies with:
B->A: SYN, ISSb, ACK(ISSa)
In addition to sending its own initial sequence number, it acknowledges A's.
Note: The actual numeric value ISSa must appear in the message.
A concludes the handshake by sending
The initial sequence numbers are intended to be more or less random. More precisely, RFC 793 specifies that the 32-bit counter be incremented by 1 in the low-order position about every 4 microseconds. Instead, Berkeley-derived kernels increment it by 128 every second, and 64 for each new connection. Thus, if you open a connection to a machine, you know to a very high degree of confidence what sequence number it will use for its next connection. And therein lies the attack.
X first opens a real connection to its target B -- say, to the mail port or the TCP echo port. This gives ISSb. It then impersonates A and sends
A->B: SYN, ISSx
B's response to X's original SYN
B->A: SYN, ISSb', ACK(ISSx)
goes to the legitimate A, about which more anon. X never sees that message but can still send
using the predicted value for ISSb. If the guess is right -- and usually it will be -- B's rsh server thinks it has a legitimate connection with A, when in fact X is sending the packets. X cannot see the output from this session, but it can execute commands as more or less any user -- and in that case, the game is over and X has won.
There is a minor difficulty here. If A sees B's message, it will realize that B is acknowledging something it never sent, and will send a reset (RST) packet in response to tear down the connection. There are a variety of ways to prevent this; the easiest is to wait until the real A is down (possibly as a result of enemy action, of course).
There are several possible defenses. Most obvious is to take advantage of topological knowledge: Do not let packets purporting to be from a local machine arrive on an outside interface. That works very well if you only trust local machines. If trust is granted to outside machines (say, via .rhosts files) and if the attacker can identify the patterns of trust (which is not that difficult), the topological solution does not work. In that case, you have to block all protocols that use TCP and address-based authentication. (UDP is a separate can of worms.)
Best of all, do not use address-based authentication; it is a disaster waiting to happen. The only real solution is cryptographic authentication.
For further information, see the two papers cited below:
|Updated: Apr 07, 2004||Document ID: 13602|