Deep Network Investigation with Wireshark

When you need to know exactly what is happening on your network, the Wireshark network protocol analyzer can tell you. The program, which includes both a graphical interface and a full complement of command-line utilities, is free of cost and Free Software, licensed under the GPLv2.
Wireshark is powerful tool that acts as a network eavesdropping utility for intercepting and analyzing both wired and wireless network traffic, and like any good tool can be used both for good and for ill. The only way to foil this sort of snooping is by encrypting your network transmissions, and even then, because your packet headers cannot be encrypted, a snoopy person can still glean information such as IP addresses, encryption certificates, and network protocols. If you’re wondering why packet headers cannot be encrypted, think about it – routers need to read the headers so they know where to send the packets. Encrypting headers would be like encrypting the addresses on paper letters.
Respect other people’s networks and privacy, and use Wireshark for testing and diagnostics only on your own networks.

Prerequisites

Wireshark runs on Linux, Mac OS X, and Windows; I’m running it on Linux. To use the software on a wired Ethernet interface, the wired NIC must be put into promiscuous mode, which Wireshark does automatically. Wireless NICs must support monitor mode. You can run the command iw list to see if your WIC supports monitor mode, and Wireshark will helpfully show a list of NICs on your PC that can be put into a capture mode.
Wireshark is a complex and powerful application built on more than a million and a half lines of code. Do not run Wireshark as root, because this is not safe. Malformed traffic could compromise your system, so the way Wireshark separates privileges ensures safer operation. The dumpcap command performs the packet capture; this is the only part that requires root privileges. dumpcap can be run independently, without running Wireshark. Wireshark provides a friendly graphical interface for dumpcap, and it runs in userspace.
On many Linux distributions (including CentOS) Wireshark is configured by default to run with complete functionality as an ordinary user, with the appropriate permissions set up by the installer. A notable exception is Debian and Debian-based distros such as Ubuntu and Mint. You could run dumpcap or tshark as root to capture network traffic, save your capture to a file, and then analyze the saved file with Wireshark. While this is a common method for capturing and analyzing network traffic, it’s convenient to be able to use Wireshark any way you want as an ordinary user. To do this on Debian, run dpkg-reconfigure wireshark-common and select the option to configure Wireshark to run as an ordinary user. Then use the usermod command to add your user to the wireshark group. Log out and log back in to activate your new group membership, and you’re ready to go.
The aforementioned dumpcap is a slick little command-line packet capture utility that is about one-tenth the size of the popular tcpdump. While you can capture packets via the graphical interface, the Wireshark GUI is quite a bit more demanding of system memory and CPU cycles than dumpcap, so using dumpcap on the command line is a good option for long-term persistent captures, such as for an intrusion detection or network monitoring system.
tshark is a terminal-based version of Wireshark, with all of the same features without the overhead of the graphical interface.
To use Wireshark wisely, you should have a thorough understanding of TCP/IP and filter your traffic according to whatever criteria make sense for your needs; otherwise you’ll either be buried in data or you’ll miss stuff. Wireshark includes a graphical filter builder, and the project provides a complete filter reference in the Wireshark documentation.
The example filters in this article are display filters used in the Wireshark GUI. You can create them with the filter builder, or paste or type them into the Filter field. These have a different syntax than the capture filters used when running dumpcap by itself.

Verifying Encryption

Let’s see just how useful Wireshark can be. Suppose you’re not sure if encryption for a particular network service is really working. You don’t have to guess because Wireshark will show you. As an example, let’s compare a plain-text email transmission with one protected by transport layer security (TLS).
To start, open Wireshark and click the network interface you want to use:

Starting Wireshark and selecting the network interface.

Next, click the Expression button next to the Filter box to open the filter builder. Here we’re testing a POP mail account:

Using the filter builder to create a simple POP protocol filter.

Note that this is a simple “is present” filter that does no matching or comparing, so it shows all POP traffic. Click OK, then click Apply, then click Capture -> Start. When you check your email, you’ll see everything that passes between your mail server and mail client in Wireshark’s window. This figure shows what unencrypted POP mail looks like; you can read everything, including the login username, password, and entire message.

An unencrypted login, password, and message in plain view.

By contrast, figure 4 shows a proper TLS-encrypted email message. Though the body is unreadable, note how much information is still in cleartext: IP addresses, protocols, port numbers, hardware brand names, and MAC addresses.

TLS-encrypted POP mail.

Using the pop filter is fast and easy, but the information it presents is incomplete because it does not capture the handshake and termination. To snag these you need to use the port numbers in your capture filter, like this:

tcp.dstport == 110 or tcp.dstport == 995

You can verify encryption for any service with Wireshark: SFTP, IMAPs, HTTPs – you name it, Wireshark sees it. Looking at Wireshark’s results helps illustrate the limitations of any particular form of encryption. For example, TLS encrypts only the login information and messages on their way to your mail server; once the message leaves your server it is most likely in the clear. If you have control of your own mail server, try sniffing traffic on both your LAN and Internet interfaces and compare. It is possible for TLS to be implemented on every mail server it passes through, but this is not a common practice; if you want end-to-end encryption, you need GnuPG. GNU Privacy Guard encrypts, decrypts, signs, and provides key management functions to encrypt and sign your data and communications.
Websites often host both encrypted and unencrypted pages – how can you see if they’re set up correctly? If you try filtering on tcp.dstport == 80 or tcp.dstport == 443, you’ll see all the behind-the-scenes exchanges between the web server and your browser for both your encrypted and unencrypted web pages. If you see your credit card number or username float by in the clear, then you have evidence of a problem.
What if the service you are inspecting uses a non-standard port? Again, Wireshark can show you what you need to know, including the destination ports.

Monitoring LAN Traffic For Infected Hosts

When you are tasked with monitoring LAN traffic for signs of malware, you need a way to capture all LAN traffic from a single point, which usually is a monitoring port on a network switch. (Please don’t use Ethernet hubs; this is 2012, the new millennium, and hubs are big fat bottlenecks. Managed Gigabit Ethernet switches with monitoring ports are inexpensive, so there is no excuse to not use them.)
You’ll die of old age before you ever parse a raw capture because of the sheer quantity of data, so here are some example filters you can easily modify to suit your own network. This example monitors all outgoing (source) traffic from a single network segment:

ip.src == 192.168.2.0/24

ip.addr == 192.168.2.0/24 captures both incoming and outgoing traffic.
If any hosts on your network are infected and spewing spam, chances are you won’t see anything in your log files or client sent-mail folders, because a compromised host will likely be infected with a special SMTP client that talks directly to the spammer’s mail server. To discover infected machines, you need to look for suspicious SMTP traffic. This filter captures outgoing traffic from your LAN segment and everything going to destination port 25:

ip.src == 192.168.2.0/24 and tcp.dstport == 25

You can trim the results by excluding your own mail server. Note the special syntax for excluding an IP address:

ip.src == 192.168.2.0/24 and tcp.dstport == 25 and !(ip.dst == 12.34.56.78)

If you see SMTP traffic heading for a strange mail server, you should be able to easily track down which computer it’s coming from because Wireshark shows you the source IP address.
You can also configure Wireshark to show hostnames. Go to Capture -> Options and check “Enable network name resolution.” This can give you a fast answer to the question, “Who is gumming up my network with all of this chatter, anyway?”

Me/NotMe

Clutter is always a problem with packet sniffing, so consider creating two filters to always use: one that excludes the machine Wireshark is running on, and one that captures only the Wireshark machine’s traffic. Use the first one when you’re sniffing other hosts on your network, and the second for troubleshooting your Wireshark machine. This example excludes all local traffic by filtering on the MAC address of the network adapter:

not ether host aa:bb:cc:22:33:44

Simply delete “not” to capture only local traffic.
Wireshark documentation is pretty good, but for deep study track down two excellent books: “TCP/IP Network Administration (3rd Edition)” by Craig Hunt is a great reference for Linux and Unix network administrators, and “Computer Networking: Internet Protocols in Action” by Jeanna Matthews is a wonderful packet analysis howto. It provides realistic hands-on exercises by including packet traces for all manner of network devices, such as routers, switches, and servers.

Tweet