[Snort-users] Questions/Suggestion: Which data to put in the DB?

Mike Andersen mike at ...207...
Wed Aug 2 14:33:15 EDT 2000

[Jed Pickel]
| My only hesitation is that makes it significantly more difficult for a
| human to interact directly with the database (I actually do most of my
| analysis by interacting manually with the db).

I understand that. :-) Our company does most of the anomaly-based
analysis by reading text files generated from the different IDS's This
consumes too much time, which is the reason that we are spending
resources to develop a complete new set of tools/applications.  In my
head I already see how I want the tools/application to help me when I'm
analysing the network traffic. :-)

| That being said, should we make this switch, I want to be certain that
| someone is working on some some apps to present data and do analysis
| based on data in the database. Anyone? :-)

My plan is (as soon as I know and agree to the database format :-) to
start developing python modules to help generating SQL queries (like
converting the ip + netmask into a select statement on the 32bits

We are also talking about building modules to import data to the
database from the NFR binary files.

| If we do make this switch I think it would be a good idea to include
| both the four one byte columns and the one four byte column until the
| 1.7 release so we can transition smoothly.

Sounds like a good idea.  Hmm... Is it difficult to make two modules,
one for the database that already exist, and one for the "new" one?

Or some kind of a "beta" module with the new format, which we can use
for testing?

I'm going to post a draft for a database layout that we can use as a
basis for further discussions.

| > But for IP packages that are not generating an event (if you are
| > using snort only to collect packages)?
| The way things are right now, you can only log events that are
| triggered by matching a rule.

Does this mean that every package is generating an event, which is
logged to the event table?

| I think it is a good idea to include the more I think about it.  Then
| you could (for example) write a cool app that queries the database and
| writes out tcpdump files.

Ah... that would have been a nice feature.  The only problem is that it
would not work on full 100Mb/s network, if the payload is included
(which would produce around 12MB each second, if I'm correct).

What about a feature that let you log the payload for traffic on given
port (selected by the user)?  For example, include payload only for
traffic on port 80 and 23?

One database to rule them all, One database to find them,
One database to bring them all and in the darkness bind them.

More information about the Snort-users mailing list