Re: [Snort-devel] Re: [Snort-users] Announce: FLoP-1.2.0

From: Dirk Geschke <Dirk_Geschke(at)genua.de>
Date: Wed Apr 07 2004 - 10:05:29 EDT

Hi Alex,

>
> > http://www.geschke-online.de/FLoP
>
> Please can you elaborate on the following limitation described on the FLoP

there are a few tables not filled up by the "normal" FLoP processes.

This is mostly:

sig_class
reference
reference_system
sig_reference

The first contains the relation between the classtype number (event.classification) and the textual representiation in etc/classification.config.

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

    reference:cve,CVE-1999-0675;

is mapped to

   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0675

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

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

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:

http://www.snort.org/snort-db/sig.html?sid=<sig_sid>

So for the "normal" rules this works well without these entries.

And finally there are some parts missing in the sensor table:

interface
filter
detail

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.

Best regards

Dirk

---

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-devel mailing list
Snort-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-devel Received on Wed Apr 7 10:41:53 2004