[Snort-users] sizing a snort ids system?

Jed Pickel jed at ...153...
Mon Aug 14 17:31:36 EDT 2000

> [Jed Pickel]
> | 
> | It does seem that the problem you are trying to point out her is
> | with all of the space consumed by the string "NULL MESSAGE".
> Nope, my point is that it's logging a lot of unnecessary entries.  My
> problem here is that I don't see why each package has to generate an
> event.  In my head an event is a hint about something you have to do
> some further investigating on. :-)

I think the word "event" is a bit too semantically overloaded; thus,
causing confusion. The whole purpose of the "event" table is to hold
meta data that is not part of other data structures.

> | The "event" table keeps track of additional meta-data that is not a
> | part of a [ip|tcp|udp|icmp] header. It is necessary to keep track of
> | information such as a timestamps, names of signatures, and event id
> | numbers.
> The only information I can see that is necessary for every package is
> the timestamp.  The rest is only useful when you have a match on one of
> the signatures.  Therefore I'm also arguing that the timestamp should be
> moved into the ip table so we can reduce the total amount of information
> put into the database (read: event table :-).

I eventually hope to support non-IP network information in this
database format (such as ARP, IPX, ethernet headers, ppp headers, raw
packets etc). It will be necessary to store timestamp information
for them as well and I do not want to include a timestamp in every one
of these new tables; therefore, I still believe that the timestamp
information belongs in the event table.

> | If you have found a situation where you do not want to log this
> | information let me know and I can make a configuration option to
> | disable logging any info to that table.
> Well, I don't see this as an "all or nothing" case.  When we got a match
> on one of the signatures (for example a scan), I would like to have an
> entry in the event table about that.  That entry points me to the ip
> table, and from there I can collect all necessary data around the event.

Actually, the way things currently are you will not get any entries
in the database unless you match one of the signatures. You could of
course have a signature that just logs every TCP|UDP|ICMP packet. I
am guessing that this is what you are doing and just leaving out a
"msg:" identifier for that signature.

> Hmm... Is it possible that we are looking at the database from two
> different perspectives?  When I think about the database, I'm not
> thinking about snort at all, but on how I would like to represent the
> IDS information.  And from this angle I see snort as one of the tools
> that can put the data into the database for me...

Actually, I think our perspectives are identical. ;) 

> I'll think I draw my little "ASCII art" again ;-)
>   +---------+      +--------+     +---------------------+
>   | Sniffer +----->+ SQL DB +<--->+ analyst application |
>   +---------+      +----+---+     +---------------------+
>                         ^
>                         |
>                         v
>               +---------+---------+
>               | Tools for finding |
>               |     anomalies.    |
>               +-------------------+
> The main part here (from my point of view) is the database.  I want to
> put as much of the logic into it as possible.  This also includes the
> knowledge of normal traffic (servers, services and legal clients), and
> if possible the configuration information to the sniffer. :)
> Entries in the event table can be used to help pointing out known
> attacks, but the database must be constructed in a way that makes it
> easy for others to create tools that are working directly on the
> database itself to find possible attacks.  From the database's point of
> view, both snort and possible other tools, should log events in the same
> way (putting the same type of data into the same table).  This will
> again make it much easier to develop a complete IDS application where
> snort is just playing a small (but important) part. :-)

Yes... I do believe that we share the same view here. 

I think you understand that having a timestamp in the iphdr table does
not make sense when we add support for non-IP protocols. Would you say
that the real issue here is that we need here is to find a word for
the event table that does not cause misunderstanding? If so, do you
have any suggestions?

* Jed

More information about the Snort-users mailing list