Some network capture tools allow you to capture only a subset of the bytes that are actually transmitted across the wire. This is useful if you only want to get an idea of the type of packets that are going across the wire but not what actual data those packets have, which can greatly reduce the size of the packet capture. The downside, of course, is that you get only a limited amount of information. If disk space is not an issue, feel free to capture it all. Just be mindful that you are capturing and storing all traffic traversing that network cable, which can quickly become a significant amount.
There are ways to limit the size of the capture. For example, instead of truncated packet data, capture only specific packet types and not all traffic. If someone wants to send you a capture, or if you want to see specific traffic, you can have Wireshark capture only the traffic you want, saving space. Everything is done using the right filters – and that section is coming soon enough!
Packet Bytes Pane
What follows the Packet Details pane is the Packet Bytes pane. This pane is at the bottom of the screen and wins the award for least intuitive. At first glance, it simply looks like gibberish. Bear with me for a couple of paragraphs; it will all make sense soon.
Offsets, Hex, and ASCII
You can see the Packet Bytes pane is divided into three columns. The first, left-most column simply counts incrementally: 0000, 0010, 0020, and so on. That's the offset (in hexadecimal) of the selected packet. Here, offset simply means the number of bits off from the beginning – again, counting in hexadecimal (where 0x0010 = 16 in decimal). The middle column shows information, in hexadecimal, at that offset. The right-hand column shows the same information, but in ASCII. For example, the total amount of information from the very beginning (offset 0000) to offset 0010 is 16 bytes. The middle column shows each of the 16 bytes in hex. The right-hand column shows each of the 16 bytes in ASCII characters. When a hexadecimal value doesn't translate to a printable ASCII character, only a “.” (period), is shown. So the Packet Bytes pane is actually the raw packet data as seen by Wireshark. By default, it is displayed in hex bytes.
Right-clicking the pane gives you the option to convert the hex bytes into bits, which is the purest representation of the data, though often this might not be as intuitive as the hex representation. Another neat feature is that any row you highlight within the Packet Details pane causes the corresponding data within the Packet Bytes pane to be highlighted. This can be helpful when troubleshooting Wireshark's dissection, as it allows you to see exactly which packet bytes the dissector is looking at.
Filters
When you start your first packet capture, a lot will probably be going on in the Packet List pane. The packets move across the screen too fast to make sense of anything meaningful. Fortunately, this is where filters can help. Filters are the best way to quickly drill down to the information that matters most during your analysis sessions. The filtering engine in Wireshark allows you to narrow down the packets in the packet list so that communication flows or certain activity by network devices becomes immediately apparent.
Wireshark supports two kinds of filters: display filters and capture filters. Display filter are concerned only with what you see in the packet list; capture filters operate on the capture and drop packets that do not match the rules supplied. Note that the syntax of the two types of filters is not the same.
Capture filters use a low-level syntax called the Berkeley Packet Filter (BPF), whereas display filters use a logic syntax you will recognize from most popular programming languages. Three other packet-capturing tools – TShark, Dumpcap, and tcpdump – also use BPF for capture filtering, as it's quick and efficient. TShark and Dumpcap are both command-line packet-capturing tools and provide analysis capabilities, the former being the command-line counterpart to Wireshark. TShark, covered more deeply with example output, is introduced in Chapter 4. The third, tcpdump, is strictly a packet-capturing tool.
Generally, you use capture filters when you want to limit the amount of network data that goes into processing and is getting saved; you use display filters to drill down into only the packets you want to analyze once the data has been processed.
Capture Filters
There are times when capturing network traffic that you can limit the traffic you want beforehand; at other times you will have to because the capture files will grow too large too fast if you don't start filtering. Wireshark allows you to filter traffic in the capture phase. This is somewhat similar to the display filters, which you will read about later in this chapter, but there are fewer fields that can be used to filter on, and the syntax is different. It's most important to understand that a capture filter screens packets before they are captured. A display filter, however, screens what saved packets are displayed. Therefore, a restrictive capture filter means your capture file will be small (and thus a smaller number of displayed packets, too). But using no capture filter means capturing every packet, and thus a large capture file, on which display filters can be used to narrow the list of packets shown.
While it makes sense for Wireshark to capture everything by default, it does actually use default capture filters in some scenarios. If you are using Wireshark on a remote session, such as through Remote Desktop or through SSH, then capturing every packet would include many packets relaying the session traffic. Upon startup, Wireshark checks to see whether a remote session is in use. If so, a capture filter to filter out remote session traffic is in use by default.
The building blocks of a capture filter are the protocol, direction, and type. For example, tcp dst port 22 captures only TCP packets with a destination port of 22. The possible types are:
• host
• port
• net
• portrange
Direction can be set using src or dst. As you suspect, src is for capturing from a specified source address, while dst can specify the destination address. If it 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