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

mike.andersen at ...208... mike.andersen at ...208...
Tue Aug 1 08:08:28 EDT 2000


[Mike Andersen]
| 
| Why split up the ip_src and ip_dst into four different elements?

[Jed Pickel]
| 
| The reason I changed to using four one byte ints instead of one
| four byte int was that I felt it gave greater flexibility for
| queries and sorting.

But doesn't it put a higher workload on snort?  And as long as we are
talking about clean B or C class addresses, it might be easier (for the
human), but what in the situations where you want to make a query for
all addresses in a range with for example 23 or 25 net bits?

| I wanted to avoid having to rely on a lot of processing of
| netmasks and such for applications, and I wanted to make SELECTs
| and sorting as quick as possible. 

Well, I have to disagree with you. :-) In most languages there are
functions available to do this kind of processing, and I don't believe
the overhead for such functions are any higher than the overhead of
functions that have to handle a .128 subnet mask.

| The other reason I decided to split the IP into four fields is that is
| generally how humans think about IP addresses, as four separate
| numbers.

I understand, but personally I like to have a clear distinguish between
representation and presentation of a dataset. :-)

| You can get the timestamp by joining the event table with the iphdr
| where both the "cid" (count id) and "sid" (sensor id) fields are
| equal.

But for IP packages that are not generating an event (if you are using
snort only to collect packages)?

[Jed Pickel] (...about TCP SEQ and ACK numbers..)
|
| Of course I have changed my mind on this now as there are
| attacks that always have the same SEQ and ACK numbers. :) 
| This one is actually on my todo list.

I'm looking forward to it. :-)

| Note that I am also in the process of writing code and database
| structure to supporting TCP and IP options. Checksum, reserved, and
| offset are the only other TCP fields I left out. I suppose I should
| include those too so we can end up with a standard database format for
| storing network data.

Really nice and I totally agree! :-)

| Note that I am also working on storing the data portion of the
| packet. I am planning to do this using either base64 or just ASCII
| with the binary filtered out (depending on what command line options
| are used to invoke snort - notably whether or not the -C is used with
| -d or not). I can use the same base64 routine to store the 256 bytes
| in the ICMP header.

What you are telling me here, makes me surer that snort might be the
right tool to use as the fundament for our own IDS tools. :-)

[Mike Andersen]
|
| UDP:
| Seems that everything is logged... :-)

[Jed Pickel]
| 
| Unless you want the checksum.. ;)

Hehe...  Actually I was spending some time thinking about that. :-)

Is there any reason that we would want to throw away that piece of
information?

[Mike Andersen]
|
| What about letting the user choose which data to put in the
| database, and what names to put on the fields?  The best is
| probably to have this as a run-time configuration, but even 
| being able to change this in an easy way before compilation 
| would help. :-)

[Jed Pickel]
| 
| I would like to avoid this because people have built and are
| building analysis applications based on this database format. 
| There is room to allow for different levels of logging (as 
| some people do not care about the details) while you and I 
| do. :) But leaving column names as a configuration option 
| could lead to chaos.

I see your point, and agree. :-)

[Mike Andersen]
|
| And a question: 
| 
| What about develop a standard database layout for anomaly based
| IDS?  Or does this already exist?

[Jed Pickel]
| 
| There is an IETF working group working on this. 

I've browsed through it, and got the understanding that it only cared
about the exchange format between IDS's.  I probably have to take some
time and read it more carefully. :-)


mike
-- 
Never make anything simple and efficient when a way can be found to
make it complex and wonderful. 





More information about the Snort-users mailing list