[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
addresses).

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?

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