[Snort-devel] Re: [Snort-users] Announce: FLoP-1.2.0
Dirk_Geschke at ...1344...
Wed Apr 7 07:06:06 EDT 2004
> > http://www.geschke-online.de/FLoP
> Please can you elaborate on the following limitation described on the FLoP
> web page:
> "- Some informations in the database are missing or have to be inserted by
> another method, for example the classification. This can be easily done
> with a simple perl script."
> I assume that this means that FLoP is not directly equivalent to mudpit or
> barnyard in this respect.
there are a few tables not filled up by the "normal" FLoP processes.
This is mostly:
The first contains the relation between the classtype number
(event.classification) and the textual representiation in
There is a perl script in FLoP-1.2.0/contrib/classification.pl
which will insert these informations.
The next two tables contain the URL references where you can
find further informations about the signature. The reference_system
contains only etc/reference.config and reference contains how
to map the reference entries to the given reference of the rule.
is mapped to
the mapping cve -> http://cve.mitre.org/cgi-bin/cvename.cgi?name=
is done in the reference_system table.
In reference there is a mapping between the ref_tag (in this
example CVE-1999-0675) whith the reference_system (http://cve...).
The real magic happens then in sig_reference. Here you
find the relation between these things:
sig_id is the link to the signature,
ref_id is the link to the reference table, there you find
the ref_system_id which links to the reference_system.
(the ref_seq is a counter if there are more than one reference
mentioned in the rule.)
As you can see: It it a little bit confusing and sounds like a
In fact: These informations are based on the rules and for each
rule you have one or more entry. But they will probably never
change. So why bother about transfering all these informations
from the snort sensor to the database each time? You have to
check these four tables for every alert you try to insert.
I think this should be done via an external program.
(And ACID does not need these informations at all to
One problem to insert all these values in the database is
the relation between sig_id and ref_id. I think instead
of sig_id you should use the sig_sid. This is the reason
why the perl skript is not ready yet.
To enter these information once and then actualize them
if something changes would be a much better way instead
of touching all the tables for each alert.
Actually the database scheme wants a link between
sig_id -> ref_id instead of sig_sid -> ref_id. But
this is only relevant for interpreting the data like
programs as ACID would do. ACID actually takes (if
the references are not present) the links to the
orginal snort page:
So for the "normal" rules this works well without
And finally there are some parts missing in the
The last one is obsolete, the filter is not forwarded.
This would mean that for each modified command line filter
a new sensor is registered in the database.
The interface is missing too. I still think of one
snort process on one machine. Then it should be clear
which interface is sniffed.
But in princripal it is not a problem to change/insert
these last values.
More information about the Snort-users