[Snort-sigs] False positive sid:498

Mike Pomraning mjp-snortsigs at ...1399...
Wed Mar 23 11:24:02 EST 2005


On Tue, 22 Mar 2005, Paul Schmehl wrote:

> Shouldn't this rule exclude port 25?
> /usr/local/share/snort/attack-responses.rules:alert ip any any -> any !25
> (msg:"ATTACK-RESPONSES id check returned root"; content:"uid=0|28|root|29|";
> classtype:bad-unknown; sid:498; rev:6;)

Ah, but then you miss the reverse UNIX bindshell masquerading as an SMTP
client, which may be an acceptable risk in your environment.  If you'd
prefer a different risk, you could use flowbits to define protocol-specific
"opaque" regions to be ignored by certain sigs:

   # Ignore SMTP "DATA" from clients
   alert tcp any any -> any 25
     (msg:"SMTP DATA begun"; content: "|0D 0A|DATA|0D 0A|";
	  flowbits:set,opaque; flowbits:noalert; ...)

   # Un-ignore SMTP client chatter
   alert tcp any any -> any 25
     (msg:"SMTP DATA ended CRLF.CRLF"; content "|0D 0A 2E 0D 0A|";
	  flowbits:unset,opaque; flowbits:noalert; ...)

   # Ignore HTTP response bodies
   alert tcp any 80 -> any any
     (msg:"HTTP Response Headers Ended"; content "|0D 0A 0D 0A|";
	  flowbits:set,opaque; ...)

   # Now, find our ATTACK-RESPONSES
   alert tcp any any -> any any
     (msg:"ATTACK-RESPONSES id check returned root";
	  flowbits:isnotset,opaque; ...)

No more of those pesky security mailing lists tripping sigs via email and web
archives!

Because flowbits is generic, this approach sketched above is brittle (read:
F-Ns galore).  What about rejected DATA commands from misbehaving clients,
so that "opaque" is never unset?  What about pipelined HTTP requests?  Etc.
It's hardly full-blown protocol awareness, but it is an option.

Regards,
Mike
-- 
Michael J. Pomraning, CISSP
Project Manager, Infrastructure
SecurePipe, Inc. - Managed Internet Security




More information about the Snort-sigs mailing list