[Snort-users] sizing a snort ids system?

Mike Andersen mike at ...207...
Mon Aug 14 12:45:27 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. :-)

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

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

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

I'll think I draw my little "ASCII art" again ;-)

  +---------+      +--------+     +---------------------+
  | Sniffer +----->+ SQL DB +<--->+ analyst application |
  +---------+      +----+---+     +---------------------+
              | 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. :-)

"All language designers are arrogant.  Goes with the territory..."
(By Larry Wall)

More information about the Snort-users mailing list