Maximum Security:
A Hacker's Guide to Protecting Your Internet Site and Network
  
12
Sniffers
A sniffer is any device, whether software or hardware, that grabs information
traveling along a network. That network could be running any protocol: Ethernet,
TCP/IP, IPX, or others (or any combination of these). The purpose of the sniffer
to place the network interface--in this case, the Ethernet adapter--into promiscuous
mode and by doing so, to capture all network traffic.
NOTE: Promiscuous mode refers
to that mode where all workstations on a network listen to all traffic, not simply
their own. In other words, non-promiscuous mode is where a workstation only listens
to traffic route it its own address. In promiscuous mode, the workstation listens
to all traffic, no matter what address this traffic was intended for.
When one discusses sniffers, one is not discussing key capture utilities,
which grab keystrokes and nothing more. Essentially, a key capture utility is the
software equivalent of peering over someone's shoulder. This peering might or might
not reveal important information. True, it might capture passwords typed into the
console of the local terminal, but what about other terminals? In contrast, sniffers
capture network traffic. This network traffic (irrespective of what protocol is running)
is composed of packets (these might be IP datagrams or Ethernet packets).
These are exchanged between machines at a very low level of the operating-system
network interface. However, these also carry vital data, sometimes very sensitive
data. Sniffers are designed to capture and archive that data for later inspection.
About Ethernet
As I have discussed, Ethernet was created at Xerox's Palo Alto Research Center.
(Sometimes referred to as PARC Place.) You might remember an RFC document
that I presented earlier in this book: It was posted over a Christmas holiday and
discussed the issue of hackers gaining access to a network that would soon become
the Internet. The author of that RFC was Bob Metcalfe, who, along with David Boggs
(both at PARC), invented Ethernet.
In 1976, these two gentlemen presented to the computing communities a document
titled Ethernet: Distributed Packet Switching for Local Computer Networks.
The ideas set forth in that paper revolutionized business-based computing. Prior
to the birth of Ethernet, most large networks were strung to mainframe computers
(in even earlier years, most systems were based on computer time sharing).
Today, Ethernet is probably the most popular way to network machines. A group
of machines within an office that are linked via Ethernet might be referred to as
a local area network (LAN). These machines are strung together with high-speed
cable that transfers information as quickly (or sometimes much more quickly) than
most hard drives.
NOTE: You might remember that in Chapter
6, "A Brief Primer on TCP/IP," I noted that one element of TCP/IP networking
was the full-duplex transmission path, which allows information to travel in both
directions at one time, a common situation in TCP/IP that is especially vital to
the error-reporting process during a transmission (a typical example might be during
a FTP transfer). Ethernet does not truly support full-duplex transmission and therefore,
although Ethernet interfaces are advertised as being capable of extremely high-speed
transmission, you can expect only perhaps 50-75 percent of the actual advertised
speed when using Ethernet on a high-traffic network. If you were to employ a packet
sniffer, you would see that while a card is receiving a heavy transmission of data
from some card elsewhere on the network, it cannot also send data out with any great
reliability. That represents an interesting security issue of sorts. For example,
can an Ethernet card answer an ARP request while being bombarded with data? If not,
couldn't a cracker temporarily conduct an ARP spoofing session under such circumstances?
At any rate, there are switching products that can remedy this limitation.
The Composition of an Ethernet Network
The composition of a network is complex. First, in order for each machine to be
part of a network, it must have both software and hardware designed to traffic Ethernet
packets. The four minimal components necessary are illustrated in Figure 12.1.
Figure 12.1.
The minimum requirements for a single workstation.
The software can either come with the operating system (Novell NetWare, UNIX,
Windows NT, Windows 95), or it can be a third-party product added later (LANtastic).
At a minimum, the software needed is as follows:
- Ethernet packet driver
- Network adapter driver
The network adapter driver commonly comes with the network adapter or Ethernet
card. It is typically provided by the manufacturer of the card but might also be
included in a total package. This is not always true. It is primarily the IBM-compatible
architecture that requires an Ethernet card. Most workstations (and most Macintoshes)
have on-board Ethernet support. This means that the Ethernet card is already hard-wired
to the motherboard. I believe that IBM-based RS/6000 machines might be one of the
few real exceptions to this. A good example would be an IBM Powerstation 320H.
NOTE: Most operating systems now come
with boot drivers for various Ethernet cards. Linux certainly does, as does Windows
95 and Windows NT. Chances are, unless you have a very strange, off-beat Ethernet
card, you may never need the manufacturer's driver.
The packet driver negotiates packets back and forth. The network adapter driver
is used to bind the Ethernet protocol to the Ethernet card. The card transmits these
packets from the workstation and into wire. This wire may be one of several kinds.
Some Ethernet cable transmits packets at 10MB/sec, others at 100MB/sec.
NOTE: TCP/IP can be bound to most Ethernet
cards as quickly as IPX or other network protocols.
So you have a machine running Ethernet software (for both packet and card). The
machine is a classic workstation, equipped with an Ethernet card that connects to
a cable. But where does the data that travels down that cable lead? The answer depends
on the network needs of the organization.
In general, there will be a least several other workstations and a network hub
(see Figure 12.2). The workstations may be deposited throughout a building, with
the wire strung through the walls.
Figure 12.2.
Basic network setting.
Figure 12.2 shows a very simple network setting. Thousands of businesses nationwide
have such a setting, using any of a dozen different networked operating systems.
NOTE: In many network settings, you can
take the hub out of the picture altogether. There are plenty of Novell NetWare networks
that have simply a file server or a closed-circuit cabling scheme, precisely like
the setup in Figure 12.2. Hubs are used for many things, including enhancement of
security, as you will see later. But if you have no fear of allowing indiscriminate,
network-wide broadcasts, a hub might not be necessary.
Note the line in Figure 12.2 that represents information flow. On networks without
hubs, the data doesn't point in any particular direction. Instead, it travels in
all directions. A typical example of this is at the moment a message needs
to be sent. Each network node or workstation is an interface. When a message needs
to be sent, a request is forwarded to all interfaces, looking for the intended recipient.
This request is sent in the form of a general broadcast.
This broadcast issues a message to all interfaces, saying: "Hey! Which one
of you is this data destined for? Will the real recipient please stand up?"
All interfaces receive this message, but only one (the one for which the message
is intended) actually replies. In this respect, then, there is no established flow
of information until the recipient is known. As you might expect, because this broadcast
is global on the network, all machines hear it. Those that are not intended recipients
of the data hear the broadcast but ignore it. The request packet dies at such workstations
because there is no reply.
NOTE: This all broadcast scenario only
occurs in network blocks, or segments. In other words, bar hard-wiring by hub (where
all machines are strung to a hub), the information will be broadcast between all
machines within that network segment. As you will see, the topology of such segments
can greatly enhance or debilitate your network security, at least with respect to
sniffers. In general, however, all machines are sent this request.
The workstation that is the intended recipient responds, forwarding its
hardware address. The information is then sent down the wire (in packets) from the
issuing workstation to the recipient. You might imagine that in this scenario (and
from the instant that the recipient is known), all other workstations ignore the
data being sent between the bona-fide sender and recipient. This is true; they do.
However, they do not necessarily have to ignore this data, and if they
don't, they can still hear it. In other words, any information traveling through
the network is always "hear-able" by all interfaces within a segment (barring
installation of controls to prevent it).
A sniffer is nothing more than hardware or software that hears (and does not ignore)
all packets sent across the wire. In this respect, every machine and every router
is a sniffer (or at least, each of these devices could be a sniffer). This
information is then stored on some media and archived for later viewing.
NOTE: To use your machine as a sniffer,
you will need either special software (a promiscuous driver for the Ethernet card)
or a version of networking software that allows promiscuous mode.
NOTE: Think of the network as a dynamic
atmosphere, such as a river. In that river, packets flow freely along the path of
least resistance. A sniffer is an entity that sticks its hand into the river and
filters the water through its fingers.
A sniffer can be (and usually is) a combination of both hardware and software.
The software might be a general network analyzer enabled with heavy debugging options,
or it might be a real sniffer.
A sniffer must be located within the same network block (or net of trust) as the
network it is intended to sniff. With relatively few exceptions, that sniffer could
be placed anywhere within that block (see Figure 12.3).
Figure 12.3.
Possible placements for sniffers.
Notice that one of the positions I have marked as a sniffer is located in the
void (along the network wire instead of within a workstation). This is possible,
though unlikely. Certain tools designed for network-traffic analysis can be spliced
into the cable itself. These tools are quite expensive and not something that the
average cracker would employ (however, I thought I should mention them).
Cross Reference: There are also devices
that are referred to as cable sniffers, which are used to diagnose problems along
network cable. One such product is called the Cable Sniffer by Macally. It
can be used to sniff cable problems on AppleTalk networks. Their page is located
at http://www.macally.com/.
Sniffers are a significant threat because of the following:
- They can capture passwords.
- They can capture confidential or proprietary information.
- They can be used to breach security of neighboring networks.
Where Is One Likely to Find a Sniffer?
You are likely to find a sniffer almost anywhere. However, there are some strategic
points that a cracker might favor. One of those points is anywhere adjacent to a
machine or network that receives many passwords. This is especially so if the targeted
machine is the gateway of a network, or a path of data going to or coming from the
outside world. If your network goes out to the Internet (and that's really what I'm
getting at here), the cracker will want to capture authentication procedures between
your network and other networks. This could exponentially expand the cracker's sphere
of activity.
What Level of Risk Do Sniffers Represent?
Sniffers represent a high level of risk. In fact, the existence of a sniffer in
itself shows a high level of compromise. In fact, if a sniffer has been placed on
your network (by folks other than those authorized to undertake such an action),
your network is already compromised. That is, taking the case study out of the LAN
and into the Internet, if your Internet-enabled network has a sniffer, someone has
breached your network security. One scenario is that he or she has come from the
outside and placed a monitoring device on your network. The other scenario is that
one of your own is up to no good. Either way, the situation is grave.
Security analysts characterize a sniffer attack as a second-level attack. The
cracker has already worked his or her way into your network and now seeks to further
compromise the system. To do so, he must begin by capturing all the user IDs and
passwords. For that reason (and for the information a sniffer gathers), a sniffer
represents an extremely high level of risk.
However, sniffers can catch more than simply user IDs and passwords; they can
capture sensitive financial data (credit-card numbers), confidential information
(e-mail), and proprietary information. Depending on the resources available to the
cracker, a sniffer is capable of capturing nearly all traffic on a network.
NOTE: I do not believe that, in practice,
any sniffer can catch absolutely all traffic on a network. This is because as the
number of packets increases, the chances of lost packets is high. If you examine
technical reports on sniffers, you will discover that at high speeds and in highly
trafficked networks, a more-than negligible amount of data can be lost. This suggests
that sniffers employed by the good guys might be vulnerable to attacks themselves.
In other words, just how many packets per second can a sniffer take before it starts
to fail in its fundamental mission? That is a subject probably worth investigating.
Security technology has evolved considerably. Some operating systems now employ
encryption at the packet level, and, therefore, even though a sniffer attack can
yield valuable data, that data is encrypted. This presents an additional obstacle
likely to be passed only by those with deeper knowledge of security, encryption,
and networking.
Where Do Sniffers Come From and Why Do They Exist?
Sniffers are designed as devices that can diagnose a network connection. You will
remember that in Chapter 9, "Scanners," I referred to a UNIX command called
traceroute. traceroute examines the route between two points and
is used to determine whether problems exist along that route (for example, if one
of the machines aÚ g that route has died).
Tools such as traceroute are sniffers of sorts. However, a hard-core
sniffer is designed to examine the packet traffic at a very deep level. Again, this--like
the scanner--has a perfectly legitimate purpose. Sniffers were designed by those
aiding network engineers (and not for the purpose of compromising networks).
Some companies produce entire suites of sniffer applications designed to diagnose
network problems. The leading company in this industry is Network General Corporation
(NGC), which offers a wide variety of sniffer products, including
- The Sniffer Network Analyzer (I should mention that the term The Sniffer
is a registered trademark of NGC)
- A wide area network (WAN) Sniffer
- Network General Reporter
On What Platforms Will a Sniffer Run?
Sniffers now exist for every network platform, but even if they did not, they
would still be a threat to you. Here is why: Sniffers sniff packets, not machines.
Unless your network is entirely homogenous, a sniffer could exist there. As I pointed
out, a sniffer need be only on a single node of a network (or at a gateway) to sniff
traffic. This is because of the manner in which Ethernet broadcasts occur. Because
the traffic is broadcasted to all nodes on a network segment, any platform that you
have will do. Also, more sniffers for different operating systems emerge every few
months; because source is now available for a wide variety of systems, it seems likely
that trend will continue. Eventually, you will see the ultimate sniffer written for
Windows 95 with some sort of VB front end. You can bet on it.
Has Anyone Actually Seen a Sniffer Attack?
There have been many sniffer attacks executed over the Internet; these attacks
were disparate in terms of target and scope. Consider this security advisement update:
- In February 1994, an unidentified person installed a network sniffer on numerous
hosts and backbone elements collecting over 100,000 valid user names and passwords
via the Internet and Milnet. Any computer host allowing FTP, Telnet or remote log
in to the system should be considered at risk...All networked hosts running a UNIX
derivative operating system should check for the particular promiscuous device driver
that allows the sniffer to be installed.1
1Naval Computer & Telecommunications Area Master
Station LANT advisory.
-
Cross Reference: You can access the Naval
Computer & Telecommunications Area Master Station LANT advisory at http://www.chips.navy.mil/chips/archives/94_jul/file14.html.
Naturally, institutions and private companies are reluctant to state what level
of compromise might have occurred. But, there are many such victims:
- California State University at Stanislaus
- A United States Army missile research laboratory
- White Sands Missile Range
Cross Reference: For more information
about the Stanislaus incident, visit http://yahi.csustan.edu/studnote.html.
For more information about the U.S. Army missile research lab and White Sands
Missile Range incidents, see the GAO report at http://www.securitymanagement.
com/library/000215.html.
Universities seem to be consistent targets, mainly because of the sheer volume
of usernames and passwords that can be gleaned from such an attack. This also translates
into bigger and more complex networks. Network administration in a university is
quite a job, even if crackers aren't prowling around. How many times have you fingered
an account at a university only to find that the target was discharged or graduated
a year or more before? Two days before writing this chapter, I encountered exactly
that situation. Except that the individual had been gone 18 months. Even so, his
account was still active!
What Information Is Most Commonly Gotten from a Sniffer?
A sniffer attack is not as easy as you might think. It requires some knowledge
of networking before a cracker can effectively launch one. Simply setting up a sniffer
and leaving it will lead to problems because even a five-station network transmits
thousands of packets an hour. Within a short time, the outfile of a sniffer could
easily fill a hard disk drive to capacity (if you logged every packet).
To circumvent this problem, crackers typically sniff only the first 200-300 bytes
of each packet. Contained within this portion is the username and password, which
is really all most crackers want. However, it is true that you could sniff all the
packets on a given interface; if you have the storage media to handle that kind of
volume, you would probably find some interesting things.
Where Does One Get a Sniffer?
There are many sniffers available on many platforms. As you might expect, the
majority of these are commercial. Commercial sniffing applications are a good idea
if you have a real need to diagnose your network (or catch a cracker). They are probably
a poor idea if you simply want to learn about networking.
Gobbler (Tirza van Rijn)
Gobbler, shown in Figure 12.4, is probably the best sniffer for someone wanting
to learn a bit about network traffic. It was designed to work on the MS-DOS platform
but can be run in Windows 95.
Figure 12.4.
Gobbler's opening screen.
Operation of Gobbler might seem a little confusing at first. There are no menus
in the traditional sense (that is, the menus are not immediately apparent when you
start the application); the application just pops up, as shown in Figure 12.4. (The
menus are there; it is just that Gobbler is not the most user-friendly application.)
Depending on what package you get, you may or may not receive documentation. If you
do, it will be a PostScript document titled Paper.gs. Of the four locations
where I have found Gobbler, only one has the document. It is the first of the addresses
that follow.
Cross Reference: Gobbler is no longer
widely distributed; these links are quite remote. Expect some download time. Gobbler
can be found at
Press the F1 key after booting the application to view a legend that provides
information about the program's functions (see Figure 12.5).
Figure 12.5.
Gobbler's function and navigation help screen.
Gobbler runs on any PC running DOS, Windows, Windows 95, and perhaps NT. It can
be run from a single workstation, analyzing only local packets, or it can be used
remotely over a network (this is an especially useful function).
Contained within the program are some fairly complex functions for packet filtering
as well as an event-triggered mechanism (that is, one can specify a particular type
of packet that must be encountered before the deep logging process starts or stops).
Perhaps most importantly, Gobbler allows you to view both the source and destination
addresses for each packet without further effort (these are printed to the screen
in a very convenient manner).
The program allows you to view the recording process as it happens. This is a
vital element of its usefulness. As noted in one of the case studies presented with
the application:
- A bridge was having problems in getting through its startup sequence using the
bootp protocol. `The Gobbler' packet catcher was used to capture the packets
to and from the bridge. The dump file viewer and protocol analyzer made it possible
to follow the whole startup sequence and to track down the cause of the problem.1
1T.V. Rijn and J.V. Oorschot, The Gobbler, An
Ethernet Troubleshooter/Protocol Analyzer. November 29, 1991. Delft University
of Technology, Faculty of Electrical Engineering, the Netherlands.
ETHLOAD (Vyncke, Vyncke, Blondiau, Ghys, Timmermans,
Hotterbeex, Khronis, and Keunen)
A freeware packet sniffer written in C for Ethernet and token ring networks, ETHLOAD
runs well atop or in conjunction with any of the following interfaces:
- Novell ODI
- 3Com/Microsoft Protocol Manager
- PC/TCP/Clarkson/Crynwr
Further, it analyzes the following protocols:
- TCP/IP
- DECnet
- OSI
- XNS
- NetWare
- NetBEUI
One thing that is not available in the standard distribution is the source code.
This is unfortunate because some time ago, the source was available. However, as
the authors explain:
- After being flamed on some mailing lists for having put a sniffer source code
in the public domain and as I understand their fears (even if a large bunch of other
Ethernet sniffers are available everywhere), I have decided that the source code
is not made available.
What is interesting is that the program did have the capability to sniff rlogin
and Telnet sessions, though only with a special key that had to be obtained from
the author. As one might expect, even when this key was available, the author restricted
its access to those who could provide some form of official certification.
For a free sniffer executable on a DOS/Novell platform, ETHLOAD is probably the
most comprehensive currently available (this is certainly so for the PC platforms).
It is also more easily found than others (altavista.digital.com returns
approximately one hundred instances of the file name, and more than half of those
sites have the product).
Cross Reference: Here are a few sites
that offer ETHLOAD:
Netman (Schulze, Benko, and Farrell)
Netman is a little different from ETHLOAD in that you can obtain the source, although
the process is more complex than "ask and ye shall receive." It involves
money ($500 for educational institutions, $1,000 for private firms), and the development
team makes it clear that that source is not to be used for commercial purposes.
The team at Curtin University has developed a whole suite of applications in the
Netman project:
- Interman
- Etherman
- Packetman
- Geotraceman
- Loadman
- Analyser
Etherman is of main interest in tracing Ethernet activity. It is important to
note that this tool is no ordinary ASCII-to-outfile packet sniffer. As the authors
explain in Homebrew Network Monitoring: A Prelude to Network Management, Etherman
takes a whole new approach that is completely distinct from its counterparts:
- In this project, we attempt to extend the goals of these by visualizing network
data. This has been achieved by applying a graphical model to a collection of continuously
updating network statistics.
True to their claims, these individuals created an extraordinary tool. The program
presents a black screen on which addresses, traffic, and interfaces are all represented
as points within the network (connection points or flows of data between these are
represented in red). This accurate graphical model is altered as traffic varies.
The entire suite of applications constitutes a formidable arsenal for network
analysis and management. In the hands of a cracker, this suite could prove quite
a weapon. However, the main features of the Etherman program, at least, run in X.
It is extremely unlikely that a cracker would be running X apps on your network without
your knowledge. If this is going on, you better wake up and mind your network;
your problems are deeper than a sniffer.
Cross Reference: The Netman project, papers,
and all binaries for these programs are located at http://www.cs.curtin.edu.au/~netman/.
NOTE: The Netman suite of applications
was reportedly coded on the Sun and DEC platforms (SPARC and Decstation 5000, respectively).
Information about porting is scarce, but this much is certain: This application runs
only on UNIX platforms. Moreover, remember when I suggested that some sniffers might
lose data on high-speed, high-volume networks? Packetman is apparently one such application,
although the problem is reportedly limited to the SunOS platform. This application
is probably the most functional sniffer suite for the UNIX platform (if not in terms
of superb functionality, at least in design).
Esniff.c (the Posse)
Esniff.c is a sniffer program that is always distributed in source form (C language),
designed primarily to sniff packet traffic on the SunOS platform. It is probably
the most popular among crackers. It is already coded to capture only the beginning
portion of each packet (and thereby capture user login IDs and passwords).
Cross Reference: Esniff.c is available
at many locations, including
Sunsniff (Author Unknown)
Sunsniff is also designed specifically for the SunOS platform. It consists of
513 lines of C source, coded reportedly by crackers who wish to remain anonymous.
It works reasonably well on Sun, and is probably not easily portable to another flavor.
This program is good for experimentation.
Cross Reference: Sunsniff is available
at
linux_sniffer.c (Author Unknown)
This program's name pretty much says it all. It consists of 175 lines of C code,
distributed primarily at cracker sites on the Net. This program is Linux specific.
It is another utility that is great for experimentation on a nice Sunday afternoon;
it's a free and easy way to learn about packet traffic.
Cross Reference: linux_sniffer.c is available
at
Nitwit.c (Author Unknown)
This C source (159 lines, excluding comments) is distributed primarily at cracker
sites. When compiled, it runs as a NIT (Network Interface Tap) sniffer. It is yet
another SunOS-only utility. The authors anonymously claim that the utility is:
- ...better than CERT's `cpm' because the sniffer can be reading in normal (non
promiscuous) mode from /dev/nit and nittie.c will sense this.
I would closely examine the source before employing this utility. This utility
emerged from the back alleys of the Net.
Cross Reference: Nitwit.c can be found
at www.catch22.com/Twilight.NET/phuncnet/hacking/proggies/sniffers/nitwit.c.
How Do I Detect a Sniffer on My Network?
The short answer to this question is: You don't. Here lies one of the reasons
sniffers are so threatening to security. They are largely passive applications and
generate nothing. In other words, they leave no trace on the system.
One way to detect a sniffer is to search all current processes being run. This
isn't entirely reliable, of course, but you can at least determine whether a process
is being run from your machine. Commands differ from platform to platform in performing
this operation. Those with DOS, Windows for Workgroups, or Windows 95 might have
a problem. However, those using UNIX or Windows NT can easily obtain a list of current
processes. In UNIX, issue the following command:
ps -aux
or
ps -augx
This command results in a listing of all processes, who initiated those processes,
what percentage of the CPU those processes are using, what percentage of memory,
and so on. The output comes in standard table form on STDOUT. If a process
is still running, it should be listed here (unless your ps or other binaries
have been trojaned).
Another method is to go searching for the sniffer. There are only so many sniffers
in existence. Chances are a cracker is using a freeware version. There is a possibility
that the cracker has written his or her own. In this case, you are in trouble and
will spend much time reconciling your directories. This is a complicated procedure,
and I am unaware of a utility that does expressly this. On the UNIX platform, you
likely will have to hack a program for yourself.
NOTE: Programs like ps (in fact,
most programs) can be hidden from the ps query by changing their argv[0]
(their first argument) to the name of a program one that is innocuous and not so
suspicious.
NOTE: Directory reconciliation
is a fancy way of saying you need to perform frequent backups (ideally, once a day).
The trick is to hack a program that takes the list of files on each backup and compares
them to the backup on the following day. Include a type of file field, which contains
the information you normally glean from the file command. This command reports
the status of the file (whether it is binary, text, sound, and so on). If a file
in a user's directory was a compiled binary one day and a shell script the next,
it might not necessarily mean anything is wrong, but it is worth noting. A number
of programs can help you per-form file reconciliation and are treated in Chapter
11, "Trojans." Some of these programs are Tripwire, ATP, and Hobgoblin.
Some utilities, however, can identify whether your system has been thrown into
promiscuous mode. These can at least detect whether a running sniffer would even
work under your current configuration. Nitwit.c is one such utility.
What Can I Do to Foil a Sniffer?
Foiling a sniffer attack is not a difficult task. You have quite a few choices
and what you pick will probably depend on how paranoid you truly are. The rest will
depend on cost.
Your main concern is probably the transmission of truly sensitive data (namely,
user IDs and passwords). Some of these cross the network in plain (or clear)
text and, when captured with a sniffer, are easily read. Solutions to this problem
are straightforward and cost effective.
Encryption
At various points in this book, I mention a product called Secure Shell, or SSH.
SSH is a protocol that provides secure communications in an application environment
such as Telnet. It is built on the client/server model, as are most protocols out
there. The official port that the SSH server binds to is 22. Connections are negotiated
using an algorithm from RSA. After the authentication procedure is complete, all
subsequent traffic is encrypted using IDEA technology. This is typically strong encryption
and is suitable for just about any nonsecret, nonclassified communication.
For quite some time, the original SSH has been lauded (rightly so) for being the
chief communications protocol that provided security by encrypted session. However,
that all changed in mid-1996. SSH forged an alliance with Data Fellows, and F-SSH
currently provides high-level, military-grade encryption to communication sessions.
It provides the strongest encryption available to the general public for communications
across TCP/IP.
If you employ F-SSH on your site, usernames and passwords become less of an issue.
To my knowledge, there have been no instances of anyone cracking such an encryption
scheme. If you employ this product, even if a sniffer is present, the value of the
information gleaned would be negligible. The hard part is getting your staff to use
it.
People sometimes receive new policies and authentication procedures poorly. In
short, you might have to demonstrate to your local users exactly how easy it is to
use SSH.
Both free and commercial versions of SSH and F-SSH exist. The free version is
a UNIX utility; commercial versions for Windows 3.11, Windows 95, and Windows NT
are available.
What Are Some Other Ways to Defeat Sniffer Attacks?
The generally accepted way to defeat sniffer attacks is to employ safe topology.
That sounds easy enough, but involves some cost.
Are you familiar with that puzzle game that consists of a series of numbered tiles?
The object of the game is to arrange the numbers so they appear in sequential, ascending
order using the fewest possible moves. When working with network topology (under
cost constraints by management), you are playing a game much like the tile game.
Here are the rules:
- Network blocks should only trust other network blocks if there is a reason.
- The network blocks should be designed around the trust relationships between
your staff and not your hardware needs.
That established, let's have a look. The first point is this: a network block
should be composed of only those machines that need to trust one another. These typically
belong in the same room or, at worst, within the same office. Your accounting staff,
for example, should be bunched together in some portion of the building (see Figure
12.6).
Figure 12.6.
The accounting office.
From the diagram in Figure 12.6, you can immediately see one difference in this
configuration as compared to the others earlier in this chapter. Notice that each
of the stations is hardwired to the hub. (There is no closed-circuit wrap, like you
often see in small Novell networks. I see that kind of configuration all the time
in medical and legal offices.) Furthermore, the hub is wired to a switch. The major
difference is that because the segment is hardwired in this fashion, packets can
only be sniffed within that network segment. Thus, the remaining portion of the network
(beyond the switch) is protected from sniffing activity. This technique is commonly
referred to as compartmentalization or segmentation.
TIP: You can also use bridges or routers
to perform this segmentation. This may be more suitable, depending upon your configuration
and finances. In fact, an older PC or workstation can be made to act as a bridge
or a router.
In segmentation, costs rise dramatically. Suppose you have 50 departments. Does
that mean you need 50 hubs, 50 switches, and a router to tie them together? Possibly.
It depends on how paranoid you really are. If you are doing sensitive work, then
yes, you will be spending money on hardware. But consider the advantages: If an evil
accounting employee wants to plant a sniffer, he can get no more than he could by
physically tampering with his coworker's workstation. Moreover, if a sniffer is found
on one of the three stations in accounting, there are only a limited number of individuals
who could have placed it there.
The problem is a matter of trust. Some machines must trust one another in order
to traffic information between themselves. Your job as a system administrator is
to determine ways in which to create the fewest trust relationships possible. In
this way, you build a framework that can tell you when a sniffer is placed, where
it is, and who could have placed it.
The problem is, in most offices, there is no real level of trust. The average
American business is in the business of making money. Tech support is expensive and
so is the downtime to restring a network. Additionally, there can be serious costs
involved in that restringing. What if all the wiring is embedded in the walls? These
are all issues that you must consider. In legacy networks, these are real problems.
Also, you must consider the level of risk. What are you protecting? What are you
planning to do regarding the Internet? These are the real issues. If you intend to
connect your LAN to the Net, a firewall is not going to be enough. Relying solely
on a firewall is a bad idea because new cracking techniques are always emerging.
Are firewalls impenetrable? Vendors say yes, as long as they are properly configured.
However, think about that statement for a moment. There was a time, not long ago,
when shadowed password schemes were touted as pretty close to infallible (in spite
of the fact that everyone deep in security knew that NIS would remain a weakness
that could render the best shadowing a wet noodle). Crackers can already scan behind
a firewall and determine the services running there. That is the first and most important
step.
It will not be long before firewalls get cracked, so be prepared. Your first concern
should be the worst case: If an intruder cuts through your armor, how far can he
or she get? Try to think of it in terms of a path or a trajectory. Starting at your
Web server and working your way back, how deep do the various levels of trust go?
For example, the Web server probably trusts one machine, which we'll call workstation1.
How many machines does workstation1 trust? How many of those machines trust
others? In other words, worst case scenario, where will the cracker finally run out
of machines to compromise?
Your job is to prevent that worst-case scenario from becoming a disaster. You
do so by ensuring that if an intruder places a sniffer, that sniffing activity is
confined to a very small area.
If I ran a large LAN connected to the Net, I would be sniffing the traffic on
it. There are products that can reliably and conveniently present the results of
such sniffing in tabular form. A good storage device, such as a Jazz drive, makes
an excellent target to save those sniffer logs.
Summary
In this chapter, you learned a bit about sniffers:
- Sniffers capture packet traffic across a network, usually an Ethernet.
- These can be placed surreptitiously on your drives.
- A sniffer can catch all packet traffic on a particular network block (or segment).
- Prevention of compromise is a two-fold process: encryption and compartmentalization.
- Encrypted communications can be used to prevent the capture of passwords if a
sniffer attack is underway.
- Detection methods are scarce because sniffers leave little trace. However, you
can run file-reconciliation utilities to determine new files on the system.
- You can monitor processes as they occur.
I assert that you can benefit greatly by running a sniffer on your network, even
if only for a day. This will familiarize you with what a cracker is facing to implement
such an attack. Also, after you are proficient with a sniffer, you can see for yourself
what type of information can actually be gleaned from your particular network configuration.
Lastly, sniffer or no sniffer, trace the levels and relationships of trust on
your network. You might be surprised to find that this path extends through the larger
portion of your network for one reason or another. This becomes more complicated,
depending on how many interfaces you are running and how many protocols run on them.
For example, if your firm is running Novell in one area, AppleTalk in another, TCP/IP
in another, DECnet in another, NFS in another, and so forth, you have your job cut
out for you. Starting at any given point, how far can you travel before you reach
a trust roadblock?
Cross Reference: Levels of trust and relationships
between network segments will be examined further in Chapter 28, "Spoofing Attacks."
Spoofing relies almost solely on trust relationships and has little to do
with passwords. (After all, who needs a password if two machines already trust one
another?)
These considerations are all relevant to the sniffer issue. In closing, sniffers
are very powerful tools for crackers, but only if you let them be. Moreover, if you
find one on your network, do not immediately remove it. Instead, install one of your
own and find out who is pulling the strings. Successful conclusions to network break-ins
almost never begin with confrontations. They begin with stealth. You cannot go to
the halls of justice without evidence.
© Copyright, Macmillan Computer Publishing. All
rights reserved.
|
