[Snort-sigs] ATTACK RESPONSES id check returned <blah> sigs

Jon warchild at ...288...
Tue Jan 28 07:12:17 EST 2003

On Mon, Jan 27, 2003 at 12:02:23AM -0500, Jason Brvenik wrote:
> Jon,
> within will do just what you are looking for.
> You could also do a generic rule that should false minimally by 
> anchoring each content behind the last with the distance modifier.
> RESPONSE id check detected"; flow:from_server,established; 
> content:"uid="; nocase; content:"("; distance:0; within:5; content:")";
> distance:0; within:10; classtype:bad-unknown; sid:1000000; rev:1;)

Thats certainly a good idea, especially for oddball non-standard web server
installs that use another uid that isn't used in the snort ruleset.
Something like this would be great if you were monitoring machines that you
had no control over or access to, because they could theoretically be using
any uid they wanted and you may not detect it.  

> I don't know of any id checks that need to be nocase but that doesn't 
> mean they are not there so I added it.
> I also think that with the limitations of $HTTP_SERVERS and $HTTP_PORTS 
> and flow:from_server it is pretty safe to open up the destination to any 

Good point.  I've actually been doing something similar where I run two
snort instances per interface -- one has $HOME_NET set to the machines I
care about and $EXTERNAL_NET is !$HOME_NET, and the other is the exact
opposite.  This usually means that I don't have to make any rule-specific
variable changes, yet I still get a pretty accurate coverage of attacks
coming into the networks I watch and I can also see attacks originating
_from_ the networks I watch.  

> I thought about adding a depth check to the first content match but that 
> would eliminate an id check following some other output like an ls or 
> cat /some/file or something so I left it out. For performance reasons I 

Meaning that the search would stop at a depth of 512 into the packet?  I
guess that'd be a matter of preference.  I'm not too keen on what
performance impact using depth would have.

> I would be interested to hear if this falses at all. It seems pretty 
> unlikely to me except for a web page on your site that has this content 
> on it. In that case you own the web server and can pass for that 

The id check rules in their current state give false positives dozens of
times in a given day.  Almost every time its because the string "uid=" is
on a web page and one of the "apache/nobody/http" strings is also on there.
I'm hoping that the 'within' changes will minimize them.


More information about the Snort-sigs mailing list