[Snort-users] Hardcore -r question

John Sage jsage at ...2022...
Mon Jun 11 23:11:04 EDT 2001


Marty:

That did it!

Thanks!

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...

[3] 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 
got confused...

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 ;-)

Thnx,

- John


>     -Marty
> 
> 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[3] == 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?
>>
>>- John


<snipped to conserve bits in preparation for the upcoming bit shortage>





More information about the Snort-users mailing list