[Snort-users] Tagging into the DB and back out again
s.wheeler at ...2876...
Fri May 30 11:58:04 EDT 2003
Creating a rule using tagging and logging to DB works great. Except that
their is a unique id for each tagged packet (example 20 packets logged into
One of those packets aka ID's refer to the starting alert and others are the
So when viewing the results from a frontend :
Traditionally each unique ID refers to a unique event....but in the case of
tagging 20 unique ID's refer to a single instance of an alert being
triggered, with 20 following packets.
So getting the info into the DB is not a problem, it's reading it back out
into a usable/readable and user followable manner.
I would like to indicate via the frontend :
1 instance of "WOOP !! Alert for HTTP Tagging custom alert" and not 20
instances of "WOOP !!Alert......"
When clicking on the above example(1 instance of "WOOP"), a story of the
next 20 following packets is displayed, so that you can follow the
conversation ( whole point behind tagging)
Each tagged packet has a Unique ID.
tagging can be done over X count in seconds OR X count in packets with
either following the session or the host (direction flag) tag type
If you have the rules parseable you could look at how the tagging was
constructed and then strip out the relevant packets, which comprise a tagged
But let's assume you used the tag type host, if you tried to assemble the 20
packet tagged alert, you could end up with a mixed up tagged story if that
host was running multiple simultaneous sessions which were logged to the DB.
Bottom line is my little brain is going around and around playing the
Snort 2 logging to a Mysql DB.
If anyone has ideas regarding the reassembly of tagged sessions from a DB
and the differentiating of a tagged session from a traditional session, I
would love to hear your ideas, as my Friday evening slightly toasted brain
is taking strain on finding a reliable manner in which to do this.
More information about the Snort-users