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:
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.
has been used by attackers to seize control of existing
interactive sessions (e.g., telnet).
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
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.
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.
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
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.
Table 16.4: Eavesdropping Potential for Different Data Links
Potential for Eavesdropping
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.
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.
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
IP over cable TV
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
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:
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
. Special link encryptors are
available for modems and leased-line links.
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
was not designed to be a secure protocol. The protocol contains
no means by which the information returned by a
query can be verified as correct or incorrect. Thus, if
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
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
r commands (
and rlogin) use the hostname for authentication. Many programs examine
the IP address of an incoming
operation, and trust that
the resulting hostname is correct. More sophisticated programs perform
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
An attacker has more trouble spoofing a double reverse lookup,
but the possibility still exists. Some of these attacks are:
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
client performing a
lookup will most likely
accept the attacker's response, rather than the legitimate
response from the authentic nameserver.
nameserver cache loading
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.
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
can taint the responses to clients.
Firewalls (described in
) can provide
some (small) degree of protection against a few
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
(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
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.
From: email@example.com.EDU (Gene Spafford)
Subject: Warning: April Fools Time again (forged messages on loose)
Date: 1 Apr 88 00:00:00 GMT
Expires: 1 May 88 00:00:00 GMT
Organization: Dept. of Computer Sciences, Purdue Univ.
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
* 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
* 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!