 | Chapter 16 TCP/IP Networks |  |
| Chapter 16 TCP/IP Networks | |
Throughout the 1980s, computers on the Internet were subject to many individual attacks. The solution to these attacks was relatively simple: encourage users to choose good passwords, prevent users from sharing accounts with each other, and eliminate security holes in programs such as sendmail and login as holes were discovered.
In the 1990s, the actual infrastructure of the Internet has come under attack:
Network sniffers have captured passwords and other sensitive pieces of information passing through the network as they are transmitted.
IP spoofing attacks have been used by attackers to break into hosts on the Internet.
Connection hijacking has been used by attackers to seize control of existing interactive sessions (e.g., telnet).
Data spoofing has been used by attackers of a rogue computer on a network to insert data into an ongoing communication between two other hosts. Data spoofing has been demonstrated as an effective means of compromising the integrity of programs executed over the network from NFS servers.
Many of these attacks were anticipated more than ten years ago. Yet the IP protocols and the Internet itself are not well protected against them. There are several reasons for this apparent failure:
IP was designed for use in a hostile environment, but its designers did not thoroughly appreciate how hostile the network itself might one day become.
IP was designed to allow computers to continue communicating after some communications lines had been cut. The concept is the genesis of packet communications: by using packets, you can route communications around points of failure. But the IP designers appear to have not anticipated wide-scale covert attacks from legitimate users. As a result, while IP is quite resilient when subjected to hardware failure, it is less resistant to purposeful attack.
IP was not designed to provide security.
IP was designed to transmit packets from one computer to another. It was not designed to provide a system for authenticating hosts, or for allowing users to send communications on the network in absolute secrecy. For these purposes, IP's creators assumed that other techniques would be used.
IP is an evolving protocol.
IP is always improving. Future versions of IP may provide greater degrees of network security. However, IP is still, in many senses, an experimental protocol. It is being employed for uses for which it was never designed.
IP is designed to get packets from one computer to another computer; the protocol makes no promise as to whether or not other computers on the same network will be able to intercept and read those packets in real time. Such interception is called eavesdropping or packet sniffing.
Different ways of transmitting packets have different susceptibility to eavesdropping. The following table lists several different ways of sending packets and notes the eavesdropping potential.
Data link | Potential for Eavesdropping | Comments |
|---|---|---|
Ethernet | High | Ethernet is a broadcast network. Most incidents of packet sniffing that have plagued the Internet have been the result of packet-sniffing programs running on a computer that shares an Ethernet with a gateway or router. |
FDDI Token-ring | High | Although ring networks are not inherently broadcast, in practice all packets that are transmitted on the ring pass through, on average, one-half of the interfaces that are on the network. High data rates make sniffing somewhat challenging. |
Telephone lines | Medium | Telephones can be wiretapped by someone who has the cooperation of the telephone company or who has physical access to telephone lines. Calls that traverse microwave links can also be intercepted. In practice, high-speed modems are more difficult to wiretap than low-speed modems because of the many frequencies involved. |
IP over cable TV | High | Most systems that have been developed for sending IP over cable TV rely on RF modems which use one TV channel as an uplink and another TV channel for a downlink. Both packet streams are unencrypted and can be intercepted by anyone who has physical access to the TV cable. |
Microwave and radio | High | Radio is inherently a broadcast medium. Anyone with a radio receiver can intercept your transmissions. |
The only way to protect against eavesdropping in these networks is by using encryption. There are several methods:
With link-level encryption, packets are automatically encrypted when they are transmitted over an unsecure data link and decrypted when they are received. Eavesdropping is defeated because an eavesdropper does not know how to decrypt packets that are intercepted. Link-level encryption is available on many radio networking products, but is harder to find for other broadcast network technologies such as Ethernet or FDDI. Special link encryptors are available for modems and leased-line links.
With end-to-end encryption, the host transmitting the packet encrypts the packet's data; the packet's contents are automatically decrypted when they are received at the other end. Some organizations that have more than one physical location use encrypting routers for connecting to the Internet. These routers automatically encrypt packets that are being sent from one corporate location to the other, to prevent eavesdropping by attackers on the Internet; however, the routers do not encrypt packets that are being sent from the organization to third-party sites on the network.
Instead of relying on hardware to encrypt data, encryption can be done at the application layer. For example, the Kerberos version of the telnet command can automatically encrypt the contents of the telnet data stream in both directions.
These three encryption techniques are shown in Figure 16.8.
DNS was not designed to be a secure protocol. The protocol contains no means by which the information returned by a DNS query can be verified as correct or incorrect. Thus, if DNS tells you that a particular host has a particular IP address, there is no way that you can be certain if the information returned is correct.
DNS was designed as an unsecure protocol because IP addresses and hostnames were designed as a system for moving data, and not as a system for providing authentication.
Unfortunately, hostnames and IP addresses are commonly used for authentication on the Internet. The Berkeley UNIX r commands ( rsh and rlogin) use the hostname for authentication. Many programs examine the IP address of an incoming TCP connection, perform a reverse lookup DNS operation, and trust that the resulting hostname is correct. More sophisticated programs perform a double reverse lookup, in which the network client performs an IP address lookup with the resulting hostname, to see if the looked-up IP address matches the IP address of the incoming TCP connection.[12]
[12] A double reverse lookup involves looking up the hostname that corresponds to an incoming IP connection, then doing a lookup on that hostname to verify that it has the same IP address. This process is non-trivial, as Internet computers can have more than one IP address, and IP addresses can resolve to more than one Internet hostname. Although the double reverse lookup is designed to detect primitive nameserver attacks, all that it usually detects is sites that have not properly configured their nameserver files.
An attacker has more trouble spoofing a double reverse lookup, but the possibility still exists. Some of these attacks are:
As DNS uses UDP, an attacker can easily flood the host, making a nameserver request with thousands of invalid responses. These can be constructed so as to appear to come from the DNS server. The client performing a DNS lookup will most likely accept the attacker's response, rather than the legitimate response from the authentic nameserver.
Some nameservers will cache any response that they receive, whether it was requested or not. You can load these nameservers with incorrect IP address translations as part of a response to some other request.
The fact that someone runs a nameserver on his or her machine doesn't mean you can trust the results. By appropriately modifying the responses of a nameserver for one domain to respond to requests with inappropriate information, the maintainer of a real DNS server can taint the responses to clients.
Firewalls (described in Chapter 21) can provide some (small) degree of protection against a few DNS attacks. Nevertheless, the real safety relies on not using IP addresses or hostnames for authentication.
Most IP services do not provide a strong system for positive authentication. As a result, an attacker (or a prankster) can transmit information and claim that it comes from another source.
The lack of positive authentication presents problems especially for services such as DNS (see above), electronic mail, and Usenet. In all of these services, the recipient of a message, be it a machine or a person, is likely to take positive action based on the content of a message, whether or not the message sender is properly authenticated.
One of the best-known cases of a fraudulently published Usenet message appears below. It was not written by Gene Spafford; instead, it was created and posted to the Usenet by Chuq von Rospach.
Path: purdue!umd5!ames!mailrus!umix!uunet!seismo!sundc!pitstop!sun!moscvax!perdue!spaf From: [email protected] (Gene Spafford) Newsgroups: news.announce.important Subject: Warning: April Fools Time again (forged messages on loose) Message-ID: <[email protected]> Date: 1 Apr 88 00:00:00 GMT Expires: 1 May 88 00:00:00 GMT Followup-To: news.admin Organization: Dept. of Computer Sciences, Purdue Univ. Lines: 25 Approved: [email protected] Warning: April 1 is rapidly approaching, and with it comes a USENET tradition. On April Fools day comes a series of forged, tongue-in-cheek messages, either from non-existent sites or using the name of a Well Known USENET person. In general, these messages are harmless and meant as a joke,and people who respond to these messages without thinking, either by flaming or otherwise responding, generally end up looking rather silly when the forgery is exposed. So, for the next couple of weeks, if you see a message that seems completely out of line or is otherwise unusual, think twice before posting a followup or responding to it; it's very likely a forgery. There are a few ways of checking to see if a message is a forgery. These aren't foolproof, but since most forgery posters want people to figure it out, they will allow you to track down the vast majority of forgeries: * Russian computers. For historic reasons most forged messages have as part of their Path: a non-existent (we think!) russian computer, either kremvax or moscvax. Other possibilities are nsacyber or wobegon. Please note, however, that walldrug is a real site and isn't a forgery. * Posted dates. Almost invariably, the date of the posting is forged to be April 1. * Funky Message-ID. Subtle hints are often lodged into the Message-Id, as that field is more or less an unparsed text string and can contain random information. Common values include pi, the phone number of the red phone in the white house, and the name of the forger's parrot. * Subtle mispellings. Look for subtle misspellings of the host names in the Path: field when a message is forged in the name of a Big Name USENET person. This is done so that the person being forged actually gets a chance to see the message and wonder when he actually posted it. Forged messages, of course, are not to be condoned. But they happen, and it's important for people on the net not to over-react. They happen at this time every year, and the forger generally gets their kick from watching the novice users take the posting seriously and try to flame their tails off. If we can keep a level head and not react to these postings, they'll taper off rather quickly and we can return to the normal state of affairs: chaos. Thanks for your support. Gene Spafford, Spokeman, The Backbone Cabal.
The April 1 post is funny, because it contains all of the signs of a forged message that it claims to warn the reader about. But other forged messages are not quite so friendly. Beware!
|  | |
| 16.2 IPv4: The Internet Protocol Version 4 |  | 16.4 Other Network Protocols |