Considerations for Network Sniffing

In order to do ethical and productive sniffing, you should follow the following guidelines.

Always Get Permission

Network sniffing, like many other security functions, has the potential for abuse. By capturing every transmission on the wire, you are very likely to see passwords for various systems, contents of e-mails, and other sensitive data, both internal and external, since most systems don't encrypt their traffic on a local LAN. This data, in the wrong hands, could obviously lead to serious security breaches. In addition, it could be a violation of your employees' privacy, depending on your company policies. For example, you might observe employees logging into their employee benefits or 401(k) accounts. Always get written permission from a supervisor, and preferably upper management, before you start this kind of activity. And you should consider what to do with the data after getting it. Besides passwords, it may contain other sensitive data. Generally, network-sniffing logs should be purged from your system unless they are needed for a criminal or civil prosecution. There are documented cases of well-intentioned system administrators being fired for capturing data in this manner without permission.

Understand Your Network Topology

Make sure you fully understand the physical and logical layout of your network before setting up your sniffer. Sniffing from the wrong place on the network will cause you either to not see what you are looking for or to get erroneous results. Make sure there is not a router between your sniffing workstation and what you are trying to observe. Routers will only direct traffic onto a network segment if it is addressed to a node located there. Also, if you are on a switched network, you will need to configure the port you are plugged into to be a "monitor" or "mirror" port. Various manufacturers use different terminology, but basically you need the port to act like a hub rather than a switch, so it should see all the traffic on that switch, not just what is addressed to your workstation. Without this setting, all your monitor port will see is the traffic addressed to the specific port you are plugged into and the network's broadcast traffic.

Use Tight Search Criteria

Depending on what you are looking for, using an open filter (that is, seeing everything) will make the output data voluminous and hard to analyze. Use specific search criteria to narrow down the output that your sniffer shows. Even if you are not exactly sure what you are looking for, you can still write a filter to limit your search results. If you are looking for an internal machine, set your criteria to see only source addresses within your network. If you are trying to track down a specific type of traffic, say FTP traffic, then limit the results to only those on the port that application uses. Doing this will make your sniffer results much more usable.

Establish a Baseline for Your Network

If you use your sniffer to analyze your network during normal operation and record the summary results, you will then have a baseline to compare it to when you are trying to isolate a problem. The Ethereal sniffer discussed in this chapter creates several nice reports for this. You will also have some data to track your network utilization over time. You can use this data to decide when your network is becoming saturated and what the primary causes are. It might be a busy server, more users, or a change in the type of traffic. If you know what you started with, you can more easily tell what and where your culprit is.

Tcpdump: An Ethernet Traffic Analyzer Tcpdump Author/primary contact: University of California, Lawrence Berkeley Laboratories Web site: www.tcpdump.org Platforms: Most Unix License: BSD Version Reviewed: 3.8.1 Mailing lists: tcpdump-announce@tcpdump.org This list is for announcements only. tcpdump-workers@tcpdump.org This list is for discussion of code. It will also receive announcements, so if you subscribe to this list you don't need to subscribe to the other one. Both lists are archived, so you can search the old postings. The code discussion list is also available in a weekly summary digest format.

There are many sniffers available, both free and commercial, but Tcpdump is the most widely available and inexpensive. It comes with most UNIX distributions, including Linux and BSD. In fact, if you have a fairly current Linux distribution, chances are you already have Tcpdump installed and ready to go.

Installing Tcpdump

Tcpdump does exactly what its name implies: it dumps the contents of the TCP/IP packets passing through an interface to an output device, usually the screen or to a file.

Running Tcpdump

There are a number of filter operations you can perform on the output to look for a specific type of traffic or lessen the overall amount of output. Indeed, on a busy network, unfiltered Tcpdump output will cause your screen to scroll faster than you can read it! However, for a quick demo of the power of Tcpdump, invoke it from the command line by simply typing:

tcpdump

You will see all the TCP traffic passing your machine's Ethernet card, unfiltered. It might look something like the example in Listing 6.1.

Listing 6.1. Tcpdump Example

12:25:38.504619 12.129.72.142.http > 192.168.1.3.3568: . ack

  1418369642 win 31856 <nop,nop,timestamp 72821542 25475802> (DF)



12:25:38.504758 192.168.1.3.3568 > 12.129.72.142.http: . ack

  1 win 40544 <nop,nop,timestamp 25486047 72811295> (DF)



12:25:38.507753 192.168.1.3.4870 > 65.83.241.167.domain:

  11414+ PTR? 142.72.129.12.in-addr.arpa. (44) (DF)



12:25:38.561481 65.83.241.167.domain > 192.168.1.3.4870:

  11414 NXDomain*- 0/1/0 (113)



12:25:38.562754 192.168.1.3.4870 > 65.83.241.167.domain:

  11415+ PTR? 3.1.168.192.in-addr.arpa. (42) (DF)



12:25:38.609588 65.83.241.167.domain > 192.168.1.3.4870:

  11415 NXDomain 0/1/0 (119)





12:25:38.610428 192.168.1.3.4870 > 65.83.241.167.domain:

 1416+ PTR? 167.241.83.65.in-addr.arpa. (44) (DF)



12:25:38.649808 65.83.241.167.domain > 192.168.1.3.4870:

  11416 1/0/0 (69)



12:25:43.497909 arp who-has 192.168.1.1 tell 192.168.1.3



12:25:43.498153 arp reply 192.168.1.1 is-at 0:6:25:9f:34:ac



12:25:43.498943 192.168.1.3.4870 > 65.83.241.167.domain:

  11417+ PTR? 1.1.168.192.in-addr.arpa. (42) (DF)



12:25:43.533126 65.83.241.167.domain > 192.168.1.3.4870:

  11417 NXDomain 0/1/0 (119)



12:25:44.578546 192.168.1.1.8783 > 192.168.1.255.snmptrap:

  Trap(35) E:3955.2.2.1 192.168.1.1 enterpriseSpecific[specific-   trap(1)!=0] 43525500

 [|snmp]

This might look a little confusing at first, but if you break it down it starts to make more sense. The first number is a timestamp, broken down into fractions of a second, because on a busy network there will be many packets per second on the wire. The next number is the source IP address of the packet followed by > (a greater than sign), and then the destination address. Finally, there may be some comments and other data. You can see several different kinds of traffic in this example, including DNS traffic (domain), ARP, and SNMP.

By default, Tcpdump runs until stopped by you pressing Control+C or another interrupt signal. When Tcpdump stops, it prints a summary of all the traffic it saw. The summary statistics include:

• Packets received by filter. This is the count of packets processed by the Tcpdump filter. It is not a count of all the TCP packets on the wire unless you ran Tcpdump without any filter criteria.

• Packets dropped by kernel. The number of packets that were dropped due to a lack of resources on your system. This feature may not be supported on all systems. Even when it is, it may not be accurate if there is a lot of saturation on the network or your sniffer machine is very slow.