Wireshark Reviews

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