is not specified, both will be matched. In addition to specifying one direction, the following combined direction modifiers can be used: src or dst and src and dst.
In a similar way, if a type is not specified, a host type will be assumed. Note that you need to specify at least one object to compare to; the host modifier will not be assumed if you would only specify an IP address as filter and will result in a syntax error.
The direction and protocol can be omitted to match a type in both source and destination across all protocols. For example, dst host 192.168.1.1 would only show traffic going to the specified IP. If dst is omitted, it would show traffic to and from that IP address.
The following are the most commonly used BPF protocols:
• ether (filtering Ethernet protocols)
• tcp (filtering TCP traffic)
• ip (filtering IP traffic)
• ip6 (filtering IPv6 traffic)
• arp (filtering ARP traffic)
In addition to the standard components, there is a set of primitives that do not fit in one of the categories:
• gateway (matches if a packet used the specified host as gateway)
• broadcast (for broadcast, not unicast, traffic)
• less (less than, followed by a length)
• greater (greater than, followed by a length)
These primitives can be combined with the other components. For example, ether broadcast will match all Ethernet broadcast traffic.
Capture filter expressions can be strung together using logical operators. Again, with both the English and the logical notation:
• and (&&)
• or (||)
• not (!)
For example, here are some filters for systems named alpha and beta:
• host beta (captures all packets to and from the alpha system)
• ip6 host alpha and not beta (captures all IP packets between alpha and any host except beta)
• tcp port 80 (captures all TCP traffic across port 80)
Debugging Capture Filters
Capture filters operate on a low level of the captured network data. They are compiled to processor opcodes (processor language) in order to ensure high performance. The compiled BPF can be shown by using the -d operator on tcpdump, Dumpcap, or TShark, and in the Capture Options menu in the GUI.
This is useful when debugging a problem where your filter is not doing exactly what you were expecting. The following is an example output of a BPF filter:
As previously mentioned, using the -d operator will show the BPF code for the capture filter. And, used in the example above, the -f operator will show the libpcap filter syntax.
Following is a line-by-line explanation of the BPF:
• Line 0 loads the offset for the second part of the source address.
• Line 1 compares the packet at the offset to 2030405 and jumps to line 2 if it matches, or line 4 if it doesn't match.
• Lines 2 and 3 load the offset for the first part of the source address and compare it to 0001. If this also matches, it can return 65535 to capture this packet.
• Lines 4 through 7 do the same as lines 0 through 3 but for the destination address.
• Lines 8 and 9 are instructions to return.
You can use this method of analyzing the filter step by step to verify where the filter is going wrong.
Capture Filters for Pentesting
We suspect you already know this, but we'll add this, just in case: “Pentesting” is short for penetration testing, the art of testing a computer, network, or application to search for vulnerabilities. Any pentesters reading this book are familiar with the concept that you end up getting blamed for every problem that happens on the network even if you aren't connected to it at the time. As such capturing data on a pentest is helpful when you need to prove to upset clients that you genuinely had nothing to do with the switch dying or a business-critical SCADA system exploding. It is also helpful when you need to review your packet captures for general information gathering or post-test analysis and reporting.
The following snippet would capture all your outgoing traffic to serve as a logbook for your actions on the network. It captures only traffic coming from your network card identified by the MAC address and saves it split up in multiple time-stamped files prefixed by pentest. Notice that Dumpcap was used here instead of the GUI or TShark.
dumpcap – f "ether src host 00:0c:29:57:b3:ff" – w pentest – b filesize:10000
You can run this snippet in the background, as running an entire instance of Wireshark would tie up too much of the system resources.
Saving only the outgoing traffic is not much use for pentest analysis. To capture all traffic going to and from your testing machine combined with broadcast traffic, use the following snippet:
dumpcap – f "ether host 00:0c:29:57:b3:ff or broadcast" – w pentest – b filesize:10000
As you can see, only the src directive was dropped, and a broadcast expression was combined with the Ethernet expression using the or statement.
The following pentesting snippet can also be used to capture traffic to and from a list of IP addresses, such as all the IPs that are in scope for your pentest. This applies to cases where you are using multiple virtual machines and thus MAC addresses, but you want to be able to log all relevant traffic.
dumpcap – f "ip host 192.168.0.1 or ip host 192.168.0.5"
The list of hosts could get a little large to type by hand, so it is more practical to store your in-scope targets in a hosts.txt file and use it instead. To generate the filter itself, use the following one-liner and strip the last or:
cat hosts.txt | xargs – I% echo – n "ip host % or "
Display Filters
To get started with display filters, we begin with a brief explanation of the syntax and available operators, followed by a walkthrough of a typical use that should get you up to speed in no time.
The display filter syntax is based on expressions returning true or false by using operators for comparison. This can be combined with Boolean logic operators to combine several expressions so that you can really drill down your results. See Table 1-1 for the most common comparison operators.
Table 1-1: Comparison Operators
Source: http://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html
