Active network analysis with Wireshark

Let's get back to the network layer and see what Wireshark can do for us once we establish a presence on the LAN. I've been sniffing for a few minutes on a network with several actively browsing clients. In a short period of time, I have a juicy amount of data to analyze:

As we can expect in today's world of casual web browsing, almost all traffic is TLS-encrypted. It's hard to even read the news or search for a dictionary definition without passing through a tunnel. Sniffing isn't what it used to be in the old days, when sitting on a LAN in promiscuous mode was everything you needed to intercept full HTTP sessions. So, our goal here is to apply some statistical analysis and filtering to learn more about the captured data and infer relationships.

In the previous section, we looked at WLAN statistics. Now that we're established on the network, we can get much more granular with protocol and service level analysis.

Let's learn a little more about everyone chatting on the network. In Wireshark parlance, we call all the individual devices endpoints. Every IP address is considered an endpoint, and endpoints have conversations with each other. Let's select Endpoints from the Statistics menu.  

I'm interested in this endpoint with an ASN belonging to the Orange network in France. I right-click to apply a filter based on this particular endpoint:

Now, I'm going to review just the HTTP 200 responses from this particular endpoint. I use this filter and apply it:

ip.addr==81.52.133.24 and http contains 200

I've narrowed down five packets of interest out of the 33,644 that we captured. At this point, I can right-click any packet to create a filter for that particular TCP session, allowing me to follow the HTTP conversation in an easy-to-read format:

So, what's going on with this display filter? The syntax should be familiar to coders. You start with a layer and specify subcategories separated by a period. In our example, we started with ip and then specified the IP address with addr. The address subcategory is an option for other layers; for example, eth.addr would be used to specify a MAC address. Wireshark display filters are extremely powerful and we simply don't have enough pages to really dive in, but you can easily build filters from scratch by reviewing packets manually and honing in on the data you need. For example, we were just filtering out packets from the endpoint that belongs to the AS5511 network in France. Could I filter any packets from France?

ip.geoip.src_country==France

Let's take GeoIP a step further by looking for any TCP ACK packets going to Mountain View, California:

ip.geoip.dst_city=="Mountain View, CA" and tcp.flags.ack==1

Let's look for any SSL-encrypted alerts where the TCP window scale factor is set at 128:

ssl.alert_message and tcp.window_size_scalefactor==128

I know what the hacker in you is saying: we can build out Wireshark display filters to fingerprint operating systems such as p0f. Very good, I'm so proud! How about we look for packets that are not destined for HTTPS while matching a Linux TCP signature and layer-2 destined for the gateway (in other words, leaving the network, so we're fingerprinting local hosts)?  

ip.ttl==64 and tcp.len==0 and tcp.window_size_scalefactor==128 and eth.dst==00:aa:2a:e8:33:7a and not tcp.dstport==443

I warned you that this would get fun.