This is a discussion on RE: [Snort-users] Using Snort & DB to remove false alarms within the Snort forums, part of the System Security and Security Related category; Maybe a better idea for this would be to use tagging of some sort and have another rule that if ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
Maybe a better idea for this would be to use tagging of some sort and have another rule that if it matches 404 on the first return packet... does not alert. The problem with this is that you'd not be able to generate an alert 'til the connection was closed... unless maybe there were some useful timer or packet count limiter to go along with it. (maybe add return-code information to the http_decode pp. alert tcp any any > any any (msg:"Successful GET of evilness"; uricontent:"/evilness.txt"; watchpackets:"server,1"; httprc:200;) watchpackets telling it to watch the next 1 packet returned from the server side of the connection. Httprc being the http return code... Another possible addition would be a combination of return codes into two groups "success" and "fail"... So httprc:[<all the return codes>|success|fail] -----Original Message----- From: Sean Wheeler [mailto:s.wheeler@netprotect.ch]=20 Sent: Tuesday, April 06, 2004 5:16 AM To: Snort Users Subject: [Snort-users] Using Snort & DB to remove false alarms Hi, Firstly I mean a false alarm in the sense of the attack signature not being relevent, below is an example attacker -> get /nawtybutnice.txt HTTP/1.0 ("attacker" looking for a known vuln cgi which we have a sig for (in example a txt file) webserver -> HTTP/1.1 404 (webserver responded with a 404 Not found) Ok so in our scenario we created a rule looking for the HTTP/1.1 404, this rule could just aswell have been created looking for the custom redirection which was implemented on the webserver for pages which could not be found. So now in the DB we have 2 entries : attacker triggered sig (ALERT A) webserver response triggered sig (ALERT B) Now we have allocated ALERT B sig as a confirming false alarm signature ( will get into the details in a little) if we can link the attacker->src_ip(ALERT A) =3D webserver->dst_ip(ALERTB) & attacker->src_port(ALERT A) =3D webserver->dst_port(ALERTB) ....etc By finding the relationship between the src & dst ips & ports .... we have found the attack and the failed response to that attack. So instead of now having to manually confirm (ALERT A) we can now have the process of doing so automagically. Details below : I created a proof of concept script which based on a simple array of "confirming false alarm signatures" $failure_response_sids =3D array(1001201,1001202,1001203,1001204,1001205,1001 206,1001207,491); ( 491 is one that exists in the common snort sigs ..others are homegrown) The script builds a reference DB table of attack sigs vs "confirming false alarm signatures" based on all the alerts I have in the DB presently. you can see a slice of this in the table below : mysql> SELECT attack_sid, msg, response_sid -> FROM `infrastructure_failed_confirm` -> LEFT JOIN rules_base ON infrastructure_failed_confirm.attack_sid =3D rules_base.sid; +------------+-----------------------+--------------+ | attack_sid | msg | response_sid | +------------+-----------------------+--------------+ | 336 | FTP CWD ~root attempt | 491 | | 489 | INFO FTP no password | 491 | ...blah ...blah ...blah (491 sig =3D INFO FTP Bad login) So now that we have such a map,which reads: if attack_sid 336 alert occurs and it is followed by a response_sid 491 and the src<->dst ip/ports match within a given timeframe (event,tcphdr tables) we have located a false alarm. Implementation could then be : Imagine a frontend : Show me alerts using "weed out the obvious" Y/N ? Y Script does the "weeding" as described above prior to displaying the alerts. Taking it further : You could use threshold suppression aswell, so you no longer see alerts from Webserver A because "weeding" figured out the Webserver A is not vulnerable to that attack sig X. Conclusion: It would be possible using the above methodogoly abeit 1/2 days work at this point, we can use snort itself as one mechanism for identifying "false alarms" Your thoughts ?? regards Sean ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=3D1470&al...3638&op=3Dcli= ck _______________________________________________ Snort-users mailing list Snort-users@lists.sourceforge.net Go to this URL to change user options or unsubscribe: https://lists.sourceforge.net/lists/...fo/snort-users Snort-users list archive: http://www.geocrawler.com/redir-sf.p...=3Dsnort-users ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Snort-users mailing list Snort-users@lists.sourceforge.net Go to this URL to change user options or unsubscribe: https://lists.sourceforge.net/lists/...fo/snort-users Snort-users list archive: http://www.geocrawler.com/redir-sf.p...st=snort-users |