[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
| Why split up the ip_src and ip_dst into four different elements?
| 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
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
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. :-)
| Seems that everything is logged... :-)
| 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
| 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. :-)
| 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. :-)
| And a question:
| What about develop a standard database layout for anomaly based
| IDS? Or does this already exist?
| 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. :-)
Never make anything simple and efficient when a way can be found to
make it complex and wonderful.
More information about the Snort-users