The Dark Side of Packet Capture

Pretty much anything you can discover through packet capture can be discovered by anyone else using packet capture in a similar manner. Moreover, some technologies that were once thought to be immune to packet capture, such as switches, are not as safe as once believed. Make sure the Dark Side stays with you by reading this excerpt from the O'Reilly book, Network Troubleshooting Tools.

Network Troubleshooting Toolsby Joseph D. Sloan

1.7. Dark Side of Packet Capture

What you can do, others can do. Pretty much anything you can discover through packet capture can be discovered by anyone else using packet capture in a similar manner. Moreover, some technologies that were once thought to be immune to packet capture, such as switches, are not as safe as once believed.

1.7.1. Switch Security

Switches are often cited as a way to protect traffic from sniffing. And they really do provide some degree of protection from casual sniffing. Unfortunately, there are several ways to defeat the protection that switches provide.

First, many switches will operate as hubs, forwarding traffic out on every port, whenever their address tables are full. When first initialized, this is the default behavior until the address table is built. Unfortunately, tools like macof, part of the dsniff suite of tools, will flood switches with MAC addresses overflowing a switch's address table. If your switch is susceptible, all you need to do to circumvent security is run the program.

Second, if two machines have the same MAC address, some switches will forward traffic to both machines. So if you want copies of traffic sent to a particular machine on your switch, you can change the MAC address on your interface to match the target devices' MAC address. This is easily done on many Unix computers with the ifconfig command.

A third approach, sometimes called ARP poisoning, is to send a forged ARP packet to the source device. This can be done with a tool like arpredirect, also part of dsniff. The idea is to substitute the packet capture device's MAC address for the destination's MAC address. Traffic will be sent to a packet capture device, which can then forward the traffic to its destination. Of course, the forged ARP packets can be sent to any number of devices on the switch.

The result, with any of these
three techniques, is that traffic will be copied to a device that can
capture it. Not all switches are susceptible to all of these attacks.
Some switches provide various types of port security including static
ARP assignments. You can also use tools like
arpwatch to watch for suspicious activities on
your network. (arpwatch is described in .) If sniffing is a concern, you may want to
investigate what options you have with your switches.

While these techniques could be used to routinely capture traffic as
part of normal management, the techniques previously suggested are
preferable. Flooding the address table can significantly degrade
network performance. Duplicating a MAC address will allow you to
watch traffic only to a single host. ARP poisoning is a lot of work
when monitoring more than one host and can introduce traffic delays.
Consequently, these aren't really techniques that you'll
want to use if you have a choice.

1.7.2. Protecting Yourself

Because of the potential for abuse,
you should be very circumspect about who has access to packet capture
tools. If you are operating in a Unix-only environment, you may have
some success in restricting access to capture programs. packet
capture programs should always be configured as privileged commands.
If you want to allow access to a group of users, the recommended
approach is to create an administrative group, restrict execution of
packet capture programs to that group, and give group membership only
to a small number of trusted individuals. This amounts to setting the
SUID bit for the program, but limiting execution to the owner and any
group members.

With some versions of Unix, you might
even consider recompiling the kernel so the packet capture software
can't be run on machines where it isn't needed. For
example, with FreeBSD, it is very straightforward to disable the
Berkeley packet filter in the kernel. (With older versions of
FreeBSD, you needed to explicitly enable it.) Another possibility is
to use interfaces that don't support promiscuous mode.
Unfortunately, these can be hard to find.

There is also software that can be
used to check to see if your interface is in promiscuous mode. You
can do this manually with the ifconfig command.
Look for PROMISC in the flags for the interface.
For example, here is the output for one interface in promiscuous
mode:

Alternately, you could use a program like
cpm, check promiscuous mode
from CERT/CC. lsof, described in , can be used to look for large open files that
might be packet sniffer output. But if you have Microsoft Windows
computers on your network or allow user-controlled computers on your
network, this approach isn't enough.

While it may appear that packet
capture is a purely passive activity that is undetectable, this is
often not the case. There are several techniques and tools that can
be used to indicate packet capture or to test remote interfaces to
see if they are in promiscuous mode. One of the simplest techniques
is to turn your packet capture software on, ping an unused IP
address, and watch for DNS queries trying to resolve that IP address.
An unused address should be ignored. If someone is trying to resolve
the address, it is likely they have captured a packet.

Another possibility is the tool
antisniff from L0pht Heavy Industries. This is a
commercial tool, but a version is available for noncommercial uses.
There are subtle changes in the behavior of an interface when placed
in promiscuous mode. This tool is designed to look for those changes.
It can probe the systems on a network, examine their responses, and
usually determine which devices have an interface in promiscuous
mode.

Another approach is to restructure your
network for greater security. To the extent you can limit access to
traffic, you can reduce the packet capture. Use of virtual LANs can
help, but no approach is really foolproof. Ultimately, strong
encryption is your best bet. This won't stop sniffing, but it
will protect your data. Finally, it is always helpful to have clearly
defined policies. Make sure your users know that unauthorized packet
capture is not acceptable.

1.8. Microsoft Windows

In general, it is inadvisable to leave
packet capture programs installed on Windows systems unless you are
quite comfortable with the physical security you provide for those
machines. Certainly, packet capture programs should never be
installed on publicly accessible computers using consumer versions of
Windows.

The programs
WinDump95 and WinDump are
ports of tcpdump to Windows 95/98 and Windows
NT, respectively. Each requires the installation of the appropriate
drivers. They are run in DOS windows and have the same basic syntax
as tcpdump. As tcpdump has
already been described, there is little to add here.

ethereal is
also available for Windows and, on the whole, works quite well. The
one area in which the port doesn't seem to work is in sending
output directly to a printer. However, printing to files works nicely
so you can save any output you want and then print it.

One of the more notable capture programs
available for Windows platforms is netmon
(Network Monitor), a basic version of which is included with Windows
NT Server. The netmon program was originally
included with Windows NT 3.5 as a means of collecting data to send to
Microsoft's technical support. As such, it was not widely
advertised. Figure 1-5 shows the packet display
window.

Figure 1-5 Figure 1-5. netmon for Windows(Click image for larger view in a new window)

The basic version supplied with
Windows NT Server is quite limited in scope. It restricts capture to
traffic to or from the server and severely limits the services it
provides. The full version is included as part of the Systems
Management Server (SMS), part of the BackOffice suite, and is an
extremely powerful program. Of concern with any capture and analysis
program is what protocols can be effectively decoded. As might be
expected, netmon is extremely capable when
dealing with Microsoft protocols but offers only basic decoding of
Novell protocols. (For Novell protocols, consider Novell's
LANalyzer.)

One particularly nice feature of netmon is the
ability to set up collection agents on any Windows NT workstation and
have them collect data remotely. The collected data resides with the
agent until needed, thus minimizing traffic over the network.

The program is, by default, not installed. The program can be added
as a service under network configuration in the setup window. It is
included under Administrative Tools (Common). The program, once
started, is very intuitive and has a strong help system.

--
That was our final segment from the O'Reilly book, Network Troubleshooting Tools. For further information on that title, click the cover image at right.