Sunday, June 28, 2009

Simpler IP Range Matching with Tshark Display Filters

In today's SANS ISC journal, the story IP Address Range Search with libpcap wonders how to accomplish the following:

...how to find SYN packets directed to natted addresses where an attempt was made to connect or scan a service natted to an internal resource. I used this filter for addresses located in the range 192.168.25.6 to 192.168.25.35.

The proposed answer is this:

tcpdump -nr file '((ip[16:2] = 0xc0a8 and ip[18] = 0x19 and ip[19] > 0x06)\
and (ip[16:2] = 0xc0a8 and ip[18] = 0x19 and ip[19] < 0x23) and tcp[13] = 0x02)'

I am sure it's clear to everyone what that means!

Given my low success rate in getting comments posted to the SANS ISC blog, I figured I would reply here.

Last fall I wrote Using Wireshark and Tshark display filters for troubleshooting. Wireshark display filters make writing such complex Berkeley Packet Filter syntax a thing of the past.

Using Wireshark display filters, a mere mortal could write the following:

tshark -nr file 'tcp.flags.syn and (ip.dst > 192.168.25.6 and ip.dst < 192.168.25.35)'

Note that if you want to be inclusive, change the > to >= and the < to <= .

To show that my filter works, I ran the filter against a file with traffic on my own 192.168.2.0/24 network, so I altered the last two octets to match my own traffic.

$ tshark -nr test.pcap 'tcp.flags.syn and (ip.dst > 192.168.2.103 and ip.dst < 192.168.2.106)'

137 2009-06-28 16:21:44.195504 74.125.115.100 -> 192.168.2.104 HTTP Continuation or non-HTTP traffic

You have plenty of other options, such as ip.src and ip.addr.

Which one do you think is faster to write and easier to understand?


Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.

6 comments:

Eugene Kogan said...

Thanks for posting this. I had the exact same thought when I read the ISC blog solution. In this case, simpler is definitely better.

Netfortius said...

Unfortunately I have never been able to compile tshark on HP-UX, whereas tcpdump was just fine ... so there is some use for the "old dog" :)

Stefan

Jay Brown said...

I think there is something to be said about the granularity that the old school filters lend, and I myself, have been beating myself bout the head and neck to learn them (call me a glutton for punishment). I found some of the subtleties for filters in snort, tshark and wireshark annoyed me, but the old school filters were pretty universal. I agree though; for people who just want the job done, macros all the way......

Anonymous said...

Totally agree. I tire of seeing hairy-chested uber-geek teeth-pulling methods of doing jobs that there should be simple methods to get done.

Netfortius: If you're doing network analysis on HP-UX, I think you're nuts. On the other hand, there are probably less tcpdump exploits constructed to compromise HP-UX than there are for tshark targets on linux...

JimmytheGeek said...

Yeah - tcpdump, with its relatively primitive dissectors - is a safer platform than tshark. tshark does more, it's more complex, it has more vulnerabilities. That buys you the ability to do some neat stuff, but be aware of the cost.

yurisk said...

I have to disagree, tcpdump in various forms has been implemented on myriad of devices (most security
related) , while tethereal/tshark has been not. E.g. Checkpoint products (including Sofaware ones) / Fortinet products/ eSafe (Aladdin) / and list goes on.
All of them have tcpdump AND bf
filters capabilities and none has tshark ones.

So when doing live analysis on such devices I still have to remember bf filters syntax. And best way to remember it is to use it all the time. So even when I have the tshark luxury I still use tcpdump filters , and BTW the one above not that complex .
Cheers