Ethereal

---

Ethereal is a nice, graphical front end to packet-capture files created by several different packet sniffers, including tcpdump and WinDump. It also has its own “live” packet-sniffing capabilities using the tethereal tool and the pcap library. By using Ethereal on previously created capture data files, you can navigate through the details of the captured session, including packet data.

Ethereal is freely available for both Windows, Linux, Unix, and some Mac operating systems and is downloadable from http://www.ethereal.com/. It requires that you have a pcap library already installed. It also requires that you have GIMP Toolkit (GTK) libraries installed, because it uses GTK for its graphical interface. Windows users get lucky, as the GTK DLLs now come with the binary. Except for the tool installation options, installs for both operating systems are pretty standard, so we’ll skip straight to the implementation.

Note 

Ethereal consists of several built-in tools that are installed by default in both Unix and Windows installations. You can choose to skip installation of some of these components, but doing so may disable certain capabilities of the Ethereal tool.

Implementation

The easiest way to run Ethereal is on a packet-capture file that has already been created using tcpdump -w capture.dump (or WinDump). In that case, we can open the dump file (choose File | Open). The Open Capture File dialog box, shown here, opens:

In this dialog box, you can choose a file to open as well as specify such options as name resolution and additional packet filters. Ethereal packet filters can be specified when reading in capture files or performing live captures. (Packet filters are covered more in a moment.)

Let’s open the file capture.dump and see how Ethereal displays the data. Figure 16-1 shows the file display.

Figure 16-1: Ethereal display of a telnet-session dump file created by WinDump

As you can see, due to the graphical nature, Ethereal is a much cleaner interface than tcpdump or WinDump. The top pane contains information similar to the other two tools, but we can actually navigate through the data here. In Figure 16-1, the fourth packet of the connection is selected. In the middle pane, we can view detailed information about each header of the packet, including TCP, IP, and Ethernet header information. If the packet is part of an application-level protocol (such as TELNET), you can view specific application protocol information. In Figure 16-1, Ethereal translates and decodes some of those Telnet options we’ve discussed in previous chapters. The third pane contains a hex and ASCII dump of the actual contents of the packet. By pointing and clicking, we can obtain any bit of information we want about any packet in the connection, including the data.

Packet Filters

Ethereal’s GUI makes it easy to create packet filters either for live captures (via Edit | Capture Filters) or packet-capture files (via Edit | Display Filters). Clicking the Filter button in the bottom left-hand corner will bring up the Display Filter List dialog box, where you can filter data from the currently displayed dump file.

You can name your filters and save them for later use, so you can load them again later by simply pointing and clicking. Type in a name for your filter, then type in your filter string, and click the New button to add it to your list of filters. After you learn Ethereal’s filter syntax, you will be able to type filter strings directly in this dialog box. Until you know Ethereal’s filter syntax, however, you can click the Add Expression button to create filters graphically in the Filter Expression dialog box shown in Figure 16-2.

Figure 16-2: Adding expressions to the filter using the Filter Expression dialog box

Ethereal becomes much more powerful than tcpdump and WinDump with its ability to filter against almost any packet characteristic (including many application-level protocols such as FTP) and any value using drop-down lists. In the Filter Expression dialog box, we look for only TCP SYN packets (beginnings of TCP connections). We can use Boolean expressions and and or to combine these filters.

Ethereal Filter Strings

If you need to use Ethereal filters to focus on particular packets in a dump, you’ll have to learn a different syntax from the one you’re used to with tcpdump or WinDump. While this can be annoying, Ethereal makes up for it by giving you many more filtering options from which to choose. The following table shows you some example Ethereal filter strings as well as their tcpdump counterparts.

Goal	Tcpdump Command Line	Ethereal Filter String
Show us everything but SSL web traffic	tcpdump not port 443	tcp.port != 443
Show us all outgoing web traffic from 192.168.1.100	tcpdump src host 192.168.1.100 and dst port 80	ip.src == 192.168.1.100 and tcp.dstport == 80
Show us all UDP packets with a length (packet size) of 24 bytes (8 bytes for header, 16 for data)	tcpdump 'udp[4:2]=24'	udp.length==24
Show us all outgoing TCP packets from 192.168.1.100 with the SYN flag set	tcpdump 'tcp[13] & 2 != 0 and src host 192.168.1.100'	tcp.flags.syn == 1 and ip.src == 192.168.1.100

From the last two examples in particular, you can see how tcpdump’s syntax requires substantial knowledge about TCP and UDP header structure to filter on characteristics of the TCP or UDP headers. Ethereal tries to obfuscate all these details by using symbolic names and a hierarchy based on protocols. Notice how much cleaner Ethereal’s tcp.flags.syn syntax is than tcpdump’s binary mathematics!

Another advantage Ethereal has over tcpdump is the ability to include application layer protocols in their filter string syntax. For example, FTP passwords are passed in clear text using the PASS command. If you wanted to see only FTP packets containing a USER or PASS request command, you could use this filter string:

ftp.request.command == "PASS" or ftp.request.command == "USER"

You’d end up with something like this:

Or, if you wanted to do something similar with basic web server authentication, you could use this filter string:

http.authbasic

This checks for HTTP packets containing authentication information. If you select a packet and expand the “Hypertext Transfer Protocol” and “Authorization” information, you can see the user’s username and password.

Ethereal Tools

Ethereal offers many additional tools in the package. Choose Tools | Follow TCP Stream to piece together a telnet session, as shown in Figure 16-3.

Figure 16-3: Following a TCP stream

In the Contents window, we can re-create parts of the actual TCP session. We can use ASCII or hex decoding, we can view the entire conversation or a specific side of the conversation, and we can save it all to a file or printer. (Although you can’t see the color in Figure 16-3, the blue text in this session window comes from the server and the red text comes from the client.) Once again, we’ve captured poor bob’s password (bob123).

You can attempt to decode the packet by using one of the many available protocols. Normally there’s no need to do this, as Ethereal detects the protocol and does the decoding automatically for most captures.

From the Tools menu, you can also perform a TCP stream analysis on throughput, round-trip time, and TCP sequence numbers. Figure 16-4 shows an analysis using time and sequence numbers. This gives you an idea of how much data was sent at which points in the connection, because sequence numbers increase by the size of the data packet.

Figure 16-4: Time/sequence number graph

Figure 16-5: Throughput graph

In the throughput graph shown in Figure 16-5, we can clearly see that most of the data in this connection was sent at the beginning of the connection (probably the telnet options).

Each graph shown in Figures 16-4 and 16-5 has multiple options including zoom and orientation.

We can also access a summary dialog box, shown in Figure 16-6, that provides a breakdown of the connection, including the length of the connection in seconds, the number of packets, the filter used to capture the packets, and speed information. To open this dialog box, choose Tools | Summary.

Figure 16-6: The Summary dialog box

The Protocol Hierarchy Statistics dialog box, shown next, tells you detailed packet and byte information for each type of packet involved in the connection. You access this dialog by choosing Tools | Protocol Hierarchy Statistics.

More Preferences

You can change several default preferences in Ethereal, including protocol preferences, GUI layout, and name resolution. You can see a list of supported protocols by right-clicking certain packet characteristics. You can change the way the data is formatted and print it to hard copy. You can use the Match and Prepare options (accessible via right-clicks on packets or from the Display menu) to filter based on particular characteristics. Choose Match if you want to create and execute a filter based on the match you select, or choose Prepare if you just want to see the filter statement that gets created and perhaps modify it yourself. For example, if you’re browsing through a session and you see a particular protocol that interests you, left-click the packet in the top pane to bring up detailed information on the packet in the middle pane. Right-click that packet’s protocol in the middle pane, choose Prepare, and then choose Selected to prepare a filter string for all packets of that protocol. Choose Not Selected if you want to see all packets except packets of that protocol. You can use the And and Or options to combine your prepared filter strings with other strings already being used. When you’re ready to view the results from your filter string, click the Apply button at the bottom.

With Ethereal, you have a powerful tool for investigating every detail of a network communication. The possibilities seem endless.

Case Study: Righteous Uses of a Sniffer

You've seen a lot of ways sniffers can be used for immoral activities, such as invading others' privacy and stealing information. On the other side of that coin, sniffers can actually be used to debug network communications and make your network safer.

Bob works as a network administrator for a small company that has two offices: one in Washington, DC, and another in London. The long-distance phone charges for calls between the two offices are beginning to pile up. In an attempt to save money, Bob's boss decides that voice over IP (VoIP) is the answer.

Bob meets with the VoIP tech folks to discuss how to implement their solution. They will be installing two devices at the DC location to handle the VoIP. Because IP phones at both the DC and London offices are going to need to access these devices, they tell Bob that the devices will need public IP addresses. Currently everything on both the DC and London networks is NATed behind a single firewall (see Chapter 13 for more on NAT and firewalls), and Bob would like to keep it that way. The VoIP folks say they won't support the solution through a firewall, especially one that does NAT. They give Bob some technical documents on the devices and wish him luck.

The first thing Bob needs to do is determine exactly what happens when an IP phone boots up. How does it find the VoIP device? What ports does it use? Bob grabs a hub, two IP phones, one of the VoIP devices, and his laptop. After plugging them all into the hub, he starts tcpdump on his laptop and boots the phone.

He first sees BOOTP and DHCP requests as the phone attempts to acquire an IP address. Because there is no DHCP server on this hub, the phone never completes the bootstrap and errors out. Knowing this, Bob programs the phone with a static IP address and tries again.

This time, Bob sees broadcast UDP traffic on port 6678. The VoIP device responds on the same port. Bob notices that shortly after the VoIP responds, the phone appears ready to be used. Bob does the same with the second phone, and he then makes a call from one phone to the other. He sees a jumble of traffic pass on the screen—too much to analyze. He restarts his tcpdump command using the –w option to write the output to a dump file. After the call finishes, he can break down the dump more easily by loading the dump file into Ethereal. Upon examining the dump, he notices the following types of traffic during the call:

Bidirectional UDP traffic from phones to VoIP device on port 6115 Bidirectional UDP traffic from phones to VoIP device on port 6116 Bidirectional TCP traffic from phones to VoIP device on port 6677 Bidirectional UDP traffic from phones to VoIP device on port 6678

Bob has isolated the ports. Now, he's ready to test his setup through the firewall. He places the VoIP device on a private IP behind the firewall. He sets up the appropriate port forward from the firewall to the VoIP device and opens the ports on the firewall. After hooking his hub into the public network switch, placing the phone outside the firewall temporarily, and configuring it with a public address, Bob is ready to test the phone's functionality through the firewall NAT. He sets up a tcpdump sniffer laptop on his hub as well as behind the firewall so that he can watch the traffic as it passes from one end of the firewall to the other. He boots the phone, and nothing happens. What's going on?

Bob checks his sniffers. He doesn't detect any activity on port 6678 behind the firewall, so he surmises that it must not have gotten through. He checks his other sniffer and discovers the problem—all he sees is unanswered UDP broadcasts on 6678. Now that the VoIP device isn't on the same subnet as the phone, the UDP broadcasts won't reach the device. The phone needs to know where to find the VoIP device. Bob explicitly programs the phone with the public IP address of the firewall and reboots the phone. This time, traffic passes as expected.

There's still one more problem, though. Bob has two VoIP devices he needs to place behind his firewall in DC. He's already used up the ports on his only public IP address, so now what does he do? By going into the phone setup, he finds a way to change the 6678 port to something else. He chooses simply to increment it by two. He sets up a port forward from UDP port 6680 on the firewall to UDP port 6678 on the second VoIP device. He doesn't see any other port changes to make on the phone, so Bob hopes that by incrementing this port by two, it will increment all the other ports by two as well. He sets up the appropriate “plus two” port forwards for the second VoIP device, and gives it a shot.

The phone boots, but it never grabs an extension or gets a dial tone. Obviously, something is missing. Bob takes a closer look at his Ethereal dumps. He sees that the phone is correctly talking on the 6680 port to the second VoIP device through the firewall, but it's still using the default port numbers for everything else. The phone is confused because its initial communication goes to the second VoIP, but all other communications go to the first VoIP.

Bob decides to examine the contents of the packets passing on 6680. To his surprise, he sees the numbers 6677, 6115, and 6116 inside one of the packets coming from the firewall's port 6680 (meaning the second VoIP device's port 6678) to the phone. He deduces that the VoIP device must tell the phone which ports it should use for the rest of the communication; that's why it wasn't working. Lo and behold, Bob checks the second VoIP device and finds options for changing the other communication ports sent to the IP phones. He makes the changes on the second VoIP device, reboots the phone, and has success.

Using his trusty sniffer, Bob has been able to figure out how to get his VoIP solution working without using any additional public IP addresses or exposing any additional machines. Because the only remote IP phones that will be using these devices are coming from a single NAT firewall IP in London, Bob can keep access to these somewhat obscure (but nevertheless open) holes restricted. Had Bob not gone to the trouble, he would have had to change his network architecture to support a DMZ or site-to-site VPN type setup, requisition new IP space, or worse—leave the VoIP devices unprotected on the public network. This would be a horribly bad idea, because both VoIP devices have telnet and web services running on them for configuration and management purposes. By using sniffers, Bob was able to add functionality with minimal cost, minimal structural change, and maximum security.

---