Bluehost.com Web Hosting $6.95

RE: [Snort-users] Using Snort & DB to remove false alarms

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 ...


Go Back   Usenet Forums > System Security and Security Related > Snort

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 04-06-2004
Kreimendahl, Chad J
 
Posts: n/a
Default RE: [Snort-users] Using Snort & DB to remove false alarms


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
Reply With Quote
Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On




All times are GMT +1. The time now is 12:48 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0