Chris Sanders is a Senior Support Engineer for KeeFORCE, a technology consulting firm. Chris writes and speaks on various topics including packet analysis, network security, Microsoft technologies, and general network administration.
What are, in your opinion, the best tools for packet analysis?
If I were to be asked what tool I couldn’t live without then it would definitely be Wireshark. Analyzing things at “the packet level” is really where the meat of network analysis is, and to do that you have to have a proper packet sniffing application. There are quite a few of these out there, but Wireshark has always been my favorite for several reasons. First, it is one of the most widely used and accepted packet sniffers, so support is pretty readily available through its large community. Secondly, it has a nice GUI for those who fear the command line, but provides a command line alternative in the form of tshark. Along with these two things, it also uses the WinPCap capture driver which puts capture packets in a standardized format so that they can be exported to other applications if the need arises, allowing for great flexibility. Throw in the fact that it is freely distributed and it is really hard to beat.
Outweighing all of these is the fact that Wireshark is what I am comfortable with. I have found several people who are completely ineffective with Wireshark and will only use an application such as tcpdump, which is absolutely fine. Again, it’s all about what tools you are most comfortable with using.
When it comes to managing a large network, how important is the ability to visualize the data flowing across a network?
Important is really understating it. I would say it is near critical. I often like to compare a network analyst working on a computer network to a doctor working on a human body. Regardless of whether you are seeing a cardiac, neurological, or orthopedic specialist, all of these doctors start with basic measurements of your overall well being. Where as a doctor might complete a blood culture, a network analyst will view a protocol hierarchy; where a doctor would complete a full medical history to get baseline of the patients overall health, a network analyst will perform a few packet captures to get a baseline of the networks overall health. The idea here is that you have to know what makes something tick before you can focus in on a specific problem. Visualizing a problem on a network isn’t as easy as capturing a couple of packets and looking for the word “ERROR” in big bold print. You have to know what things look like when they are working properly to find the small subtleties that make the difference between a network in optimal health and one that creeps along at an alarming pace. The ONLY way to do this effectively is to be able to interpret the packets that are flowing across the wire.
Based on your experience, what advice would you give to users that are considering deploying wireless networks?
There are two big mistakes I see wireless network administrators make when they deploy a new wireless network.
The first of these is not planning for the future. The wireless administrator will deploy hundreds of access points and entirely blanket a company so that it’s employees can have wireless access. This works fine for a while, but what happens when this is a public service entity, such as a hospital or government location, and management decides they want to offer a separate point of wireless connectivity (a hotspot) for non-employees to connect to? In lots of cases, the wireless administrator did not purchase his wireless equipment with this type of growth in mind, and therefore has to bare a lot of expense to upgrade his hardware.
The second and MOST deadly mistake I see made is delaying security. Typically, management wants to implement a wireless deployment as fast as possible. So fast, that they don’t want to deal with deploying a proper security configuration. If I had a dollar for every time I’ve heard someone say, “Let’s just throw some standard WEP security on it until its up and running for a while and then we can add more security later.” Unfortunately, later usually never comes, and by the time it really matters it may be too late. If you are in an organization that transmits sensitive data over a wireless link, look into security now rather than later. Implementing 802.1x, WPA, Certificate Services, etc may take some initial legwork in the beginning of a deployment but it may very well be your saving grace further on down the road.
How long did it take you to write “Practical Packet Analysis” and what was it like? Any major difficulties?
Start to finish, writing PPA took about eight months. This was my first in print book and it really was a lot of work. I used to think that I wrote to teach people, but I’ve come to learn that I probably learn just as much writing about technical topics as people do reading them. The guys at No Starch were absolutely fantastic to work with and they let me work at my pace and do things my way, which made it that much better for a first time writer. It was a really fun project and I met a lot of really great people in the Wireshark community while doing it. I can’t wait to write a follow up to it.
What’s the most interesting fact you’ve become aware of while researching for your book?
Since writing this book, I’ve gotten a lot of e-mail from different people asking for assistance regarding packet analysis problems they encounter, which I’m always glad to offer some insight into. The funny thing is, a lot of these e-mails reference me as a “Wireshark Expert”, which I find kind of funny. Throughout the course of my book research I’ve come to figure out that anybody can be a Wireshark expert. It’s really just a program with a lot of different analysis tools in it. What makes someone really good at packet analysis is being an expert at the underlying protocols that make a network function. Just because I know how to create an IO graph or chart RTT times doesn’t mean that I understand how to follow the packet sequence of a DHCP zone transfer or figure out what a particular ICMP error code is. Packet analysis is no more centered on Wireshark as Astronomy is centered on a telescope. Sure, you need to know how to use the tool, but that tool is just a gateway into everything else you need to learn.
What are your future plans? Any exciting new projects?
I’m hoping to eventually write a second edition of PPA which will have quite a few more practical scenarios which should be beneficial to new PPA readers as well those who bought the first edition. Aside from that I continue to post new content to my blog related to both packet analysis and other topics that are of interest to network administrators. Speaking of which, you can check that out here.