|
|
| Previous | Table of Contents | Next |
Reducing the Risks of TCP/IP Spoofing
One way to reduce the threat of this sort of attack is to simply log out of all terminal sessions before they become inactive and only start up terminal sessions when you need them. Inactive terminal sessions are the easiest to hijack.
A second way to reduce the threat is to use an implementation of the terminal session protocol (Telnet or rlogin) that inserts extra terminal protocol data transmitted to the timesharing machine. Doing so will not fool a sniffer, but it will make it harder for the attacker who is guessing that the terminal protocol sends only a small, relatively fixed amount of data before the user begins typing commands.
A third way to reduce the threat is to avoid the use of terminal session protocols between the user’s desktop and the timesharing machine. For example, with the X Window system, you have the option of running the windowing program (for example, xterm) on the desktop and then starting a remote terminal session with the windowing program.
You can also run the windowing program on the timesharing machine and use the X protocol to have the window displayed on your desktop. Using X may introduce its own set of security problems, but convincing the timesharing system to accept forged data as keystrokes requires a somewhat messier process and it is much harder to make a good guess at a current sequence number without a sniffer.
A fourth way to reduce the threat of TCP/IP spoofing is to use an encryption-based terminal protocol. The use of encryption does not help prevent an attacker from making a good guess at the current sequence number. If the attacker is using a sniffer, the sniffer knows the exact current sequence number. Encrypted protocols, however, can limit the consequences of introducing forged data on the connection. Unless the encryption is broken, the receiver will accept the data as valid but the command interpreter will not be able to make sense of it. When the legitimate sender gets acknowledgments for the forged data it will become confused and may reset the TCP/IP connection, causing the terminal session to be shut down.
The only way to deal with this threat completely with current standardized technology is to use a combination approach. Initial sequence numbers must be unpredictable and fall throughout the full range of four billion. TCP/IP data must be encrypted so that unencrypted or mis-encrypted data will not be confused with valid commands. You also must simply live with the possibility that an attacker may cause a TCP/IP connection to reset because of garbage injected into a connection by an attacker with a sniffer.
Using Next-Generation Standard IP Encryption Technology
To stop IP address spoofing, you must use encryption on the entire data portion of an IP datagram, including the TCP header. By doing so, you prevent a sniffer from determining the sequence numbers of the TCP connection. See RFCs 1825-1830.
One IP encryption technique currently in use is SwIPe. It encrypts the TCP header and the TCP data, preventing sniffers from finding sequence numbers. This program is considerably more sophisticated than that, and goes well beyond the scope of the kind of coverage provided in this chapter. Because it requires kernel modification the source code is not of general interest; if you are interested, however, it is at ftp://ftp.csua.berkeley.edu/pub/cypherpunks/swIPe/.
An emerging standardized IP encryption technique is specified in “RFC 1825: Security Architecture for the Internet Protocol.” It is a standards-track specification for an option to the current version of IP (IPv4) and a required part of the next generation of IP (Ipv6). RFC 1825 specifies two parts: an authentication header (AH) and an encapsulating security payload. These two parts may be used separately or in combination. The use of the authentication header prevents the forging of IP datagrams. The encapsulated security payload encrypts the content of the IP datagram, including the TCP header.
The following RFCs detail a proposed standard authored by R. Atkinson of the Naval Research Laboratory and published in August 1995:
The following RFCs detail the mechanisms behind RFC 1826 and RFC 1827, respectively, and are part of the proposed standard. They were authored by Metzger, Karn, and Simpson and published in August 1995. RFC 1851 and RFC 1852, published in September 1995, are follow-ups to these papers. The newer RFCs listed below, are, as of this writing, still “experimental” rather than part of a “proposed standard.”
| Previous | Table of Contents | Next |