Using Snort & DB to remove false alarms

["Sean Wheeler" <s.wheeler () netprotect ch>]

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) = webserver->dst_ip(ALERTB)
&
attacker->src_port(ALERT A) = 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 =
array(1001201,1001202,1001203,1001204,1001205,1001206,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 =
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 = 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=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/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users