[Snort-sigs] Rules across tcp headers & http headers/payload

lists at ...3397... lists at ...3397...
Mon Mar 4 13:17:31 EST 2013

On 03/04/2013 04:50 AM, Andy Richards wrote:
> 1) a tcp syn sent to the client followed by...
> 2) a http POST from the client to certain URL for example "POST /someurl" followed by...
> 3) a http payload to the client for example beginning with "HTTP/1.1 200 OK..." followed by...
> 4) a tcp fin to the client

Your firewall shouldn't be passing traffic with invalid state, so I believe #1
to be unnecessary.  You could probably do this with flowbits but I'm not certain
it's going to scale verify well.  Example, I'm uncertain of direction, so I'm
going 'any any'

alert tcp any any -> any any (msg:"NOALERT HTTP POST to /someurl";
flow:established,to_server; content:"POST"; http_method; content:"/someurl";
http_uri; flowbits:set,custom.http.req; flowbits:noalert; sid:x; rev:1;)

alert tcp any any -> any any (msg:"NOALERT HTTP 200 Response from POST to
/someurl"; flow:established,from_server; content:"200"; http_stat_code;
flowbits:isset,custom.http.req; flowbits:set,custom.http.resp; flowbits:noalert;
sid:x; rev:1;)

alert tcp any any -> any any (msg:"HTTP Req to /someurl with HTTP 200 Resp and
TCP FIN set"; flow:established,to_server; flags:F*;
flowbits:isset,custom.http.resp; sid:x; rev:1;)

I really don't understand the use case though and this is kind of a really
horrible way to abuse the IDS.  Seems like an intelligent firewall not passing
invalid state traffic and W3C logs would produce more reliable information.

More information about the Snort-sigs mailing list