What Network Sniffing Tools Do You Use?

network-nose asks: "I work as a Network Administrator in a 500 user manufacturing facility in southeastern Wisconsin. My job is to keep the company running as close to 100% of the time as possible while trying not to spend any money on up to date hardware and software. As of late, we have been having quite a few network problems that can only really be resolved by sniffing packets. I am wondering what tools the rest of you network guys and gals out there use in a corporate environment for analyzing packets. Of course, the more reasonbly priced the better, but I know you usually get what you pay for."

Comments

I'm not a network admin

[ObviousGuy]

What kinds of problems can only be figured out by sniffing packets? Rogue programs? Unauthorized porn downloads? Illegal P2P activity?

On a properly configured network, where are the points of failure that can't be figured out with any other method besides packet sniffing? If these problems exist, would it be worthwhile to incorporate functionality directly into the networking software to watch for these problems and fix them automatically?

Re:I'm not a network admin

[timmarhy]

i find packet sniffing to be the fastest way to find problems. I just use tcpdump and take a look at the traffic. look at applications does you know good since they never tell you exactly what they are sending out. using tcpdump i found a major issue in one of our applications ( was reading a database table in an infinte loop) this had gone unoticed for years, and no one ever though why the network was so so congested

Along similar lines

[lewko]

Although only useful for fun, and not serious network analysis, have a play with Etherpeg

EtherPEG works by capturing unencrypted TCP packets off your local network, collecting packets into groups based on TCP connection (determined from source IP address, destination IP address, source TCP port and destination TCP port), reassembling those packets into order based on TCP sequence number, and then scanning the resulting data for byte sequences that suggest the presence of JPEG or GIF data.

Or in other words, fire it up, plug in a data projector and watch everyone's porn. Interesting side-effect: It makes (most) people a lot more careful what they browse if they know the results will be displayed for everyone's amusement. Mercifully, it's also a lot less likely these days to see The Goatse flying across the screen.

Re:tcpdump and/or ethereal

[Autonin]

Actually -s 0 is better.

10/100BaseT Ethernet, which pretty much everyone uses these days, is limited to 1500 snaplen. But the good old FDDI was a whopping 4500!

With -s 0, it basically means "All" - you don't have to think about what transmission medium you're using.

I also usually name my packet captures with extention *.pcap, and just make Ethereal be the default *.pcap file handler.

I'll also use tcpdump to whittle my pcaps down. Say I capture for a long time and end up with a 500MB+ pcap. Opening this in most any workstation with Ethereal will cause you to wait awhile, and could actually crash your box (yay for WinXP pre-fetch!).

So when I've found a particular port or host I want to extract from a stream to make the pcap more managable, I'll do something like this:

tcpdump -s 0 -r infile.pcap -w outfile.pcap host x.x.x.x and port xxx

Sometimes, I'll use tethereal instead to go a little deeper. tethereal is ***SLOW*** compared to tcpdump, but the granularity is worth it sometimes. Just set it going, and go get a coffee or something.

When examining a capture of some malware trying to spread, often times it will SYN several hundred machines without getting a reply. Trolling through these can be a pain. But by using tethereal, you can make what I call "Jesus" pcaps (no SYN's). To make it complete, I also filter RST's like so:

tethereal -r infile.pcap -w outfile -R "tcp.flags.syn==0 && tcp.flags.reset==0"

There is a way to do this in tcpdump, but it's much more complicated. Besides, you need the break anyway, right? :)

Re:Ethereal

[MrBlue VT]

I agree, Ethereal is a godsend. Made it easy to reverse engineer a protocol I needed to replicate in one of my projects.

Only feature I wish it had would be the ability to ARP poison switches. Etherape has this ability and it is nice for listening on unmanaged switches.

Otherwise, ethereal is a great product. Nice filtering and easy to follow streams. It also will do a lot of legwork for you and figure out what higher level protocol is being used over TCP.

"Sniffing" for HTTP

[jtheory]

I used Ethereal for a while, sniffing simple HTTP traffic, sorting out cookie issues and so on (I'm not a netadmin -- mostly web app development)... and it was darned handy.

Of course, when I found the live http headers plugin for Mozilla it was exactly what I needed -- just the headers, scrolling by realtime, and no more sniffing needed.

Yeah, this is slightly OT (which may be good in a discussion that seems to be a long string of ethereal links, all +5) -- but I wanted to point out to those people out there who think they "need a sniffer" -- unless you're a network admin, you probably don't.

[Plus the Futurama quotes in the /. headers are entertaining]

Re:Ethereal

[necronom426]

Agreed.

My first job was to look after a Novell server and a network of 30+ machines with no training apart from what I could pick up along the way and from my experience with PC's. Another job I was looking after a Unix box for the first time and didn't know how to do much.

Recently I got a free label printing program from a web site for my Mother to use at work (she was hand writing 100's of addresses on envelopes that were printed from a computer!) The "computer guy" at the company said they couldn't do labels (even though they use Word) so I go her this free one. I had to explain to him how to find a directory on the PC! They do have a network and the main computer guy who set it up was in another country, but they had put this other person in charge of the PC's and he didn't know anything about them. Another time I had to tell him how to find the size of a hard drive...