Help with content rules looking for the absence of a hex pattern (large ICMP modification)

[Matt Kettler <mkettler () evi-inc com>]

I posted this over on snort-sigs a while back (12/24/02) and got no 
response, so I'm now going to re-post this over on the more general 
snort-users list. This is pretty rule-format-and-structure oriented, so 
feel free to skip it if writing custom rules isn't in your idea of snort usage.

I have yet to figure out why the rule doesn't work as I expect, so there's 
either a flaw in my understanding of snort rules (quite likely) or a bug in 
snort's handling of rules (remotely possible).

There do seem to be other rules in the 1.9.0 ruleset which use this type of 
negated-hex-content construct, such as sid:1838 rev:3. So as best I can 
tell at this point most of my reasoning is sound.

------------------------

Ok, I'm a bit confused here.. I'm running snort 1.9.0 and I got tired of 
the Large ICMP rule firing off like crazy at all the DNS latency probes 
that use huge ping packets full of 00's. So I made a minor tweak to try to 
ignore these, but it still matches.

Is there a typo or logic bug in my rule that isn't obvious?

icmp.rules:alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP Large 
ICMP Packet"; dsize: >800; content:!"|000000000000000000000000|"; depth:40; 
reference:arachnids,246; classtype:bad-unknown; sid:1000499; rev:3;)

To my understanding, that rule should look for an ICMP packet over 800 
bytes in length which does not have 12 consecutive bytes of 00 within the 
first 40 bytes of the body. Originally I made the depth limit 20, but when 
it was still matching I bumped it up to 40 in case the 20-byte IP header 
was being used as part of the data searched. Yet it still matches them

Here's the first 40 bytes of a sample packet that matched the above rule 
dumped out of a tcpdump binary log from snort (yes, the remaining 1460 
bytes of data are also 00's):

4500 05dc 199d 4000 f101 8ca8 d140 19f0
c0a8 3202 0800 f7ff 0000 0000 0000 0000
0000 0000 0000 0000

Breaking that first 40 bytes down we have 20 bytes of IP header:
4500 05dc 		(IP version 4, 5*4 = 20 bytes of header, Normal ToS, 1500 byte 
total length)
199d 4000               (ID=6557, IP flags= DF, frag offset =0)
f101 8ca8               (ttl = 241, proto = ICMP, header checksum = 0x8ca8)
d140 19f0               (src = 209.64.25.240, ns2.mcmaster.com)
c0a8 xxxx   		(dest = 192.168.xx.xx, my internal address for my nameserver, 
after NAT)

4 bytes of ICMP header
0800 f7ff               (ICMP type 8, code 0 (echo-request), checksum 0xf7ff)

4 bytes of ICMP-echo-request ID and sequence number
0000 0000

and 12 bytes of 00's (and a whole lot more that follow that)
0000 0000 0000 0000 0000 0000

So no matter how I look at the depth, and data of this packet, there are 12 
consecutive bytes of 00 within the first 40 bytes of data. It doesn't 
matter if the data is searched starting from the start of the IP header, or 
starting after the echo-request sequence number, there's still a string of 
12 00's there.


So what obvious little bit am I overlooking that's letting this rule match 
despite my content:! specifier?





-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users