Tuesday, July 26, 2011

tcpdump and ngrep

Yesterday, I tweeted the following:
tcpdump -nnvvAi eth1 -s0 | grep "Doug Burks is teaching SANS SEC503 Intrusion Detection In-Depth in Portland"
 So what does it all mean?

-nn This option disables name resolution for IP addresses and port numbers.  Some versions of tcpdump do this with a single "-n", but the double "-nn" option should work on all of them.
vv This option enables Very Verbose output.  It wasn't strictly needed for the purposes of this command, but I'm in a habit of using it.
A This option prints just the ASCII text in the packets.  This is useful when looking for strings like "Doug Burks is teaching SANS SEC503 Intrusion Detection In-Depth in Portland" or "c99shell".
i This option allows you to specify the Interface (in this case eth1).  eth1 on my Security Onion box at home is connected to a Dualcomm Switch Tap that monitors all ingress/egress of my home network.  Doesn't everybody do full packet capture at home?
-s0 This option sets the snaplen. By default, tcpdump only captures 68 bytes and would therefore not see the entire payload of the HTTP connection.  Setting snaplen to 0 forces tcpdump to capture the entire packet regardless of its size.
grep Since we had tcpdump output in ASCII, we can easily use the standard grep command to look for interesting text strings.

I was waiting on someone to ask the question "Why not use ngrep instead?".  tcpdump's advantage is that it is more universally available than ngrep.  If you're doing Incident Response on a Unix box of some kind, chances are that it already has tcpdump installed and you can use that to look for suspicious traffic as defined above.

Most Unix boxes do not have ngrep installed by default.  But let's assume that you've got a dedicated IDS platform such as Security Onion which just so happens to include ngrep by default.  Here's the  ngrep version of the command:
 ngrep -d eth1 -s0 "Doug Burks is teaching SANS SEC503 Intrusion Detection In-Depth in Portland"
Here we use the "-d eth1" option to force ngrep to listen on device eth1 and the "-s0" option to force ngrep to look at the entire packet.  Note that, unlike tcpdump's default snaplen of 68 bytes, ngrep defaults to 65536, so this option isn't strictly needed here, but is included for completeness.  After specifying these options, we simply tell ngrep what string to look for.

Doug Burks is teaching SANS SEC503 Intrusion Detection In-Depth in Portland Oregon 8/22 - 8/27.  Sign up today!


Anonymous said...

I saw this over at Pauldotcom.com and thought it was pretty interesting. To work on the Mac I had to use:

sudo tcpdump -nnAi en0 -s0 | grep "apple.com"

from my admin account. There was more information about how to packet capture on apple support pages:



Steve Holden said...

I noticed when I dropped the -vv option I got time stamps back. Is there a way to get time stamps while using verbose mode?

Doug Burks said...

Hi Steve,

I'm not sure that I understand your question. Here's what the tcpdump man page says:
"By default, all output lines are preceded by a timestamp."

There are also some "t" options to control timestamp behavior:

-t Don't print a timestamp on each dump line.

-tt Print an unformatted timestamp on each dump line.

-ttt Print a delta (micro-second resolution) between current and previous line on each dump line.

-tttt Print a timestamp in default format proceeded by date on each dump line.

-ttttt Print a delta (micro-second resolution) between current and first line on each dump line.

Please let me know whether or not that helps.

Doug Burks

Steve Holden said...


Maybe this is just a Mac OS X issue ... when I do:

sudo tcpdump -nnAi en0 -s0 | grep "apple.com"

And then in my browser try to go to "hot.apple.com" I see the DNS captures with timestamp info at the beginning of the output.

But when I do:

sudo tcpdump -nnvvAi en0 -s0 | grep "apple.com"

I don't get any timestamp at the front, I just get the IP address of my host. The data in the verbose mode is much better IMHO so having -vv seems like a good thing.


Doug Burks said...

I don't think it's a Mac OS X issue. tcpdump on Mac OS X seems to have the same timestamp behavior as tcpdump on other platforms.

Perhaps you are experiencing the results of browser and/or DNS caching. Try this...

In your first terminal window, execute the following:
sudo tcpdump -nnAi en0 -s0 | grep "apple.com"

In a second terminal window, execute the following:
sudo tcpdump -nnvvAi en0 -s0 | grep "apple.com"

In a third terminal window, execute the following:
nslookup newtest.apple.com

Both of the first two terminal windows should then show the DNS lookup for newtest.apple.com and both should have the timestamps.

Hope that helps!

Doug Burks

Steve Holden said...

I'll give you suggestion a look next time I'm at my Mac.

BTW ... I did get this to work on Windows 7 with Windump/WinPCap/Powershell:

windump -nnvvAi 1 -s0 | select-string "apple.com"


Anonymous said...

Though I think the discussion of -s 0 is beneficial, I thought it worth pointing out that for recent versions of tcpdump the default snaplen is now 65535. Of course, old versions abound so -s 0 is important to know.

Keep up the great work on Security Onion, Doug.

Doug Burks said...

Hi Anonymous,

Thanks for your comment. I did include this extra discussion of the -s option when I posted this article on PaulDotCom:

Anonymous said...

Great post.

Related to:

tcpdump -nnAi eth1 -s0 | grep "evil"

Can you provide examples of "evil". That is, what are some things we should be looking for?

Doug Burks said...

Part of defending your network is knowing what's considered "normal" and what's considered "evil" for YOUR network. I don't know anything about your network so I can't define "evil" for you. You might look at the Snort and Emerging Threats IDS rule sets for some ideas. Hope that helps!

Anonymous said...

Thanks for the response! I'm currently taking the SANS 502 class (onemand) and a few generic items we're mentioned such as monitoring for an IP header value other than 5 or the frag bit set but a packet size smaller than 500 bytes. So I was wondering if there is a 'checklist' of generic items to monitor for such as the above mentioned.


Marty Brandon said...

Very useful information I needed to debug my web application.


Marty Brandon