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:
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:
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.
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.
...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.
Comments
Stefan
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...
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