RE: Using Snort & DB to remove false alarms

["Kreimendahl, Chad J" <Chad.Kreimendahl () umb com>]

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] 
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) = 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



-------------------------------------------------------
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_id70&alloc_id638&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