Wireshark is a powerful, free tool that examines network packets and allows analysts to peer inside traffic for troubleshooting purposes and security assessment. In the first part of this series, I provided you with an introduction to Wireshark covering the installation and basic use of the tool. In this installment, I'll delve deeper into the advanced functions of the network analyzer, exploring the use of traffic filters to limit the number of packets appearing on your screen and offering best practices for writing Wireshark network traffic filters.
Why filter traffic?
If you've used Wireshark or another network traffic analyzer in the past, you probably already know the answer to this question! Capturing packets on a network can result in information overload, especially if the action is done for an extended period of time. It's easy to capture thousands of packets in the course of a few minutes. Sorting through that data without applying traffic filters, though, is like trying to find the proverbial needle in a haystack. Traffic filters, however, basically provide a "search" functionality that limits the amount of data appearing on the screen to that matching a user's customized criteria.
Applying filters to network packet captures
Applying a filter to captured packets is a straightforward process: Simply type a filter expression into the "Filter" textbox on the Wireshark screen and click "Apply" to run the filter against your active capture. Wireshark will hide any captured packets that don't match the filter expression.
Sounds simple, doesn't it? The art and complexity of writing Wireshark filters, however, lies in writing the correct filter expression to meet analysis requirements. Before attempting to write a filter, ask yourself a seemingly obvious question: What traffic do you want to see? While your initial answer to this question may be a plain English sentence, such as, "All Web traffic from the application server," you'll need to translate this functional description into a technical one that describes the characteristics of the packets themselves. For example, the technical specification might be "All TCP packets with a destination port of 80 and a source address of 172.16.1.32."
Once a technical specification has been developed, it will need to be translated into Wireshark's display filter language. In the above example case, the correct Wireshark filter is "tcp.dstport == 80 and ip.src == 172.16.1.32." Deconstructing this example, notice that it consists of two clauses joined by an "and" condition: one stating that the traffic must have a TCP destination port of 80 and another stating that the source address of the packet must be 172.16.1.32.
To narrow down the scope of the traffic captured by the filter, you can actually string together as many conditions as you like. Parentheses, as well as normal logical operators like 'and', 'or', 'xor' and 'not', may be used to group expressions together.
Wireshark: Network traffic filters and writing Wireshark expressions
Building customized conditions can be a little tricky until some of the intricacies of the filter language have been mastered. There are basically two options when constructing the commands: write the filter from memory (which you will be able to do one day!) or use Wireshark's expression builder. To use the expression builder utility, simply click the word "Expression" on the filter toolbar and fill in the fields in the pop-up window, as shown below.
See larger image
Wireshark uses colored text boxes to verify that a valid filter has been built. When an expression is highlighted in green, the filter entered is a valid one. If an error is made in the expression, the text box background color changes to red, alerting the user to the mistake.
After building a valid filter, simply click the "Apply" button to run it against the current packet capture. An example of a successfully applied filter appears below:
See larger image
One important note: The discussion in this tip addresses the writing of display filters for Wireshark. Display filters limit the amount of information that appears on the screen, but does not stop Wireshark from capturing packets that don't match the filter criteria.
Writing capture filters is what will limit the data pulled off the network in the first place. For this purpose, Wireshark uses standard libpcap filters, identical to those used by tcpdump, the open-source command-line tool for sniffing network traffic.
For more information on the specific criteria you may use in building Wireshark filters, review the Wireshark manual.
Security analysis with Wireshark filters
Wireshark is a security analyst's best friend. The use of display filters enables the mining of network traffic for a variety of interesting scenarios. Here are a few examples:
Monitor the network for connections using insecure protocols, such as telnet. The following filter will identify any TCP port 23 traffic that may contain cleartext authentication information: tcp.dstport == 23
Isolate traffic from a potentially compromised system. For example, you could use the following filter to monitor all traffic from 192.168.2.101: ip.src == 192.168.2.101
Investigate denial-of-service attacks. If your Web server exhibits the symptoms of a denial of service, you can use Wireshark to capture and analyze the relevant packets, allowing you to craft defenses against the threat. For example, the filter below captures all Web traffic headed to the server located at 192.168.3.134: ip.dst == 192.168.3.134 and tcp.dstport == 80
Those are just a few simple examples of how to use Wireshark as a security analysis tool. With the ability to create customized filters, you can search for any combination of parameters imaginable.
Now that you're familiar with the use of Wireshark filters, you should be ready to start using this powerful tool in a more advanced fashion. Try your hand at capturing some network traffic and using filters to mine through the haystack for that proverbial needle!
About the author:
About the author: Mike Chapple, CISA, CISSP, is an IT security professional with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Mike is a frequent contributor to SearchSecurity, a technical editor for Information Security magazine and the author of several information security titles, including the CISSP Prep Guide and Information Security Illuminated. He also answers your questions on network security.
This was first published in December 2008