Wireshark Reviews

Multitrace analysis can be the most interesting, rewarding and unfortunately, most frustrating exercise an analyst will face.

Before we get to the packet analysis, setting up your tools for simultaneous capturing can be a feat in itself.

The time issue is the most critical when using 2 devices since the time is used to calculate the delay, jitter or latency. Some people are fine with syncing both devices to a common ntp server.

Then there’s the “how the #!!$!@#!!” do I physically capture . This is where you have to be familiar with the problem, the network you are working on and what equipment is available to you. If you are lucky enough to be able to change the speed and duplex to 100 half duplex a good old hub fits the bill. Other than the mirror/span command, a tap is also very helpful. Trust me every one of these suggestions comes with their own caveats. You may have to try different tools for different scenarios.

For example, if I am doing a simple pc bootup/login baseline, I am interested in things like total data transferred, which IP’s I am talking to, protocols used, errors, etc. In this case speed and duplex is not important and I can go with a hub. But if I was troubleshooting why something is taking too long, like a backup or replication, changing the speed and duplex would not be a good idea.

If you are lucky enough and can capture from one device, the time accuracy issue goes away and life does get a bit easier. But now you have 2 different captures in the same trace, Yikes!!!! Not to mention that different network interfaces have different latency or behaviors. I remember trying a usb to 10/100 ethernet adapter to capture packets and quickly realized that this adapter added 30 ms to every packet. Again, if I was troubleshooting latency, this won’t do.

Lastly, if you’re fortunate enough, you might even have an application that takes multiple trace files and calculates all sorts of stuff out for you (hmm.. next article?).

In this example I use Wireshark, my laptops WiFi and Ethernet ports to capture my packet traversing a residential home router. I show some tips and tricks along the way and hope this will help you out.

www.youtube.com/watch

Documenting a Problem With Wireshark

I remember talking to a group about the ‘superman syndrome’ where the analyst wants to swoop in and save the day. I explained that like most forensic tasks, protocol analysis can be tedius, confusing and downright boring at times. Alright who wants to capture some packets now!?

If you can’t see it, you can’t fix it. That is why I like to use protocol analysis to minimally document the problem that I’m experiencing. Even if the packets don’t show any anomalies, that worth knowing as well, isn’t it? If you do see an anomaly, you might not have the solution but at least you know what it looks like when its broken.

Ideally protocol analysis is most helpful when you have two traces to compare; the good and bad trace. In most realistic scenarios, the client will not have a good trace and just the current bad trace. I’m our classes I review how to make use of what you have.

In this example the customer had a DSL line with an issue and another DSL line what worked fine. The customer mentioned that whenever the DSL circuit ‘acted up’, they simply rebooted the modem. Both DSL circuits went to the same carrier, ordered at the same time, provisioned the same way and even use the same hardware. Perfect, example of something I can compare. I also noticed that these are not just modems, but they route, dhcp, firewall and NAT.

What I found, is that the problem circuit was having issues passing larger frames, while the other had no issues. After the reboot the problem circuit now behaves like the good one. Upon further investigsation I noticed the problem modem had older firmware and suggested they get that firmware updated.

So, even though I couldn’t ‘fix’ the problem, we know exactly what the problem is and what to look for if the problem returns.

www.youtube.com/watch

I am surprised that this exercise we do in class still proves to be helpful as well as quite popular.

There are many utilities out there to help find rogue servers, but why bother when you already have Wireshark installed. When you get comfortable with this exercise you can save some steps by creating a capture filter for just DHCP packets, or better yet, just DHCP server packets. As always with protocol analysis, there are many ways to do this exercise and this is just my preference since it forces me and the attendees to review the DHCP process as they go through the packets.

Rogue DHCP servers are becoming more common these days since a DHCP server can simply be a part of an application loaded on your computer. The introduction of tablets and smart phones that can provide hotspot support, are also DHCP servers. I even see more applications out there that turns your laptop into a WiFi hotspot so you can tether it to your tablet or smart phone.

Don’t worry, I haven’t forgotten the classic example of an employee who wants wireless access in a nearby conference room and simply connects the LAN port of his wireless router at his desk and starts dishing out IP addresses.

I like the added twist where I ask people to identify the legitimate DHCP based on paying attention to the story, not the packets. I can’t tell you how many times I figure out a problem by going back to the user and having a conversation rather than going over the trace a million times.

I think people forget that Wireshark and protocol analysis is an exercise in forensics and you need a story for context and to make sense of the packets.

I have said many times that many times the answer comes from the story, not the packets.

www.youtube.com/watch

While troubleshooting a Wifi performance issue on a large BYOD network, I was explaining to the customer a lot of people on a wireless network sending a lot of small packets can cause a performance issue by robbing precious time from other Wifi clients.

They didn’t quite understand how this could happen since many users’ computers and phones are idle and just simply connected to the WiFi network. I illustrated the impact of having common applications installed on a smartphone/tablet as well as browser extensions or add-ons would have on a network by using Wireshark.

The trickiest part of this exercise is actually capturing the Wireless packets. You can use Riverbed’s Airpcap adapter, or any other vendors WiFi packet capturing product. Just keep in mind that in many cases where you have encryption enabled, its easier if you join that network to see the packets.

To this day I am surprised how many network analysts lack WiFi troubleshooting tools and either rely on their wired lan tools or strictly use the vendors monitoring applications as their sole source of information. I remember a few years ago I did a tools presentation for a vendor and asked the group how much confidence they would have in their auto mechanic if he only had one tool on the bench, or if he lacked specialty tools for your specific car’s make and model.

With Wireshark I was able to give them an ‘under the hood’ view of their network. You don’t need to have an extensive protocol analysis background to quickly realize that this is one busy network. As I have many times in the past, “Packets don’t Lie”.

On a wired network this is less of an issue since a wired network is more bandwidth bound. On a wireless network at home this isn’t an issue either since you aren’t sharing the wireless network with as many people.

In this case, the customer had over 200 people on an access point which cumulatively creates an issue.

In this video I use Wireshark to illustrate the traffic generated by these various applications.

www.youtube.com/watch'v=xDuRhQ6swrI