[Snort-users] Hardcore -r question
jsage at ...2022...
Mon Jun 11 23:11:04 EDT 2001
That did it!
So [0:2] says start at byte 0 (the *first* byte), and examine two (which
would be the width of the 16-bit source IP), and [2:2] says start at
byte 2 (which is the *third* byte in and which is where the 16-bit dest
port starts) and go for two...
 and [3:1] kinda worked I guess because they were *kinda* looking in
the right place, (start at the third byte in and go for one..) but they
Martin Roesch wrote:
> Try 'tcp[2:2] == 111', I bet that'll work. BPF starts counting at zero
> for headers, so tcp[0:2] covers the first 16-bits of the tcp header,
> tcp[2:2] covers the second 16-bits (i.e. the destination port).
> You could also just say 'dst port 111'.
Yeah.. but that takes all the fun out of it ;-)
> John Sage wrote:
>>I'm playing with using the -r switch and tcpdump syntax on a binary log
>>file, and I'm having one heckuva time understanding why this command line:
>>snort -dv -r snort-0609 at ...2233... 'tcp[3:1] == 111 '
>>returns what it does.
>>I expect it to return packets with destination port 111, which it does,
>>but WTF? it returns five other packets with a value of 62319 as the
>>destination port, too.
>>This says, I think, go into the tcp header 3 bytes (first byte's zero,)
>>and a one byte offset into that, and look at it -- and if it's "111"
>>then true and show me the packet.
>>It does exactly the same thing if I say:
>>snort -dv -r snort-0609 at ...2233... 'tcp == 111 '
>>(Of course, if I just chill out and say "snort -dv -r
>>snort-0609 at ...2233... dst port 111" it works just fine...)
>>Anyway, what am I missing?
<snipped to conserve bits in preparation for the upcoming bit shortage>
More information about the Snort-users