[Snort-users] Using Snort & DB to remove false alarms
Kreimendahl, Chad J
Chad.Kreimendahl at ...4716...
Tue Apr 6 08:52:13 EDT 2004
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
From: Sean Wheeler [mailto:s.wheeler at ...2876...]
Sent: Tuesday, April 06, 2004 5:16 AM
To: Snort Users
Subject: [Snort-users] Using Snort & DB to remove false alarms
Firstly I mean a false alarm in the sense of the attack signature not
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
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
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)
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
of doing so automagically.
Details below :
I created a proof of concept script which based on a simple array of
"confirming false alarm signatures"
( 491 is one that exists in the common snort sigs ..others are
The script builds a reference DB table of attack sigs vs "confirming
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
| attack_sid | msg | response_sid |
| 336 | FTP CWD ~root attempt | 491 |
| 489 | INFO FTP no password | 491 |
(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
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
Taking it further :
You could use threshold suppression aswell, so you no longer see alerts
because "weeding" figured out the Webserver A is not vulnerable to that
attack sig X.
It would be possible using the above methodogoly abeit 1/2 days work at
point, we can use snort itself as one mechanism for identifying "false
Your thoughts ??
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
Snort-users mailing list
Snort-users at lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
Snort-users list archive:
More information about the Snort-users