Wireshark Reviews

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.

http://www.youtube.com/watch?v=OBT5XGOA3EU

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.

http://www.youtube.com/watch?v=uyvEa7Nh80A

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.

http://www.youtube.com/watch'v=xDuRhQ6swrI