[Snort-sigs] Rules across tcp headers & http headers/payload
andy.richards.iit at ...2420...
Tue Mar 5 05:23:58 EST 2013
Thanks both that very useful especially the example you have given. I'll give flowbits a go. Yes your, correct point one is invalid, my example should have been syn followed by the usual syn/acks before the http post so I can add this into the rule. More importantly I think your comments in regard to performance and use of Snort are more important as you have confirmed that I could be using Snort for something it's not really designed to do. May something like network behavioural analysis would be the way to go with Snort feeding packets and alerts into such a system maybe via the unix_alertsock to identify such behaviour?
Most useful thanks.
Sent from my iPad
On 4 Mar 2013, at 18:17, lists at ...3397... wrote:
> 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