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

mike.andersen at ...208... mike.andersen at ...208...
Mon Jul 31 07:50:01 EDT 2000

I've spent some time with snort, and like it very much. Mostly because
it has the ability to pump the data directly into the database, but I
also see the advantages of using signatures for trapping some of the
events.  The GPL license is also a big advantage.

Our plan is to build a set of tools on top of snort to ease the
analysing work.  I also believe that I'm able to convince my employer
that we would benefit of release our code under the GPL.

Well, enough of that.  The real issue of this mail is the database
interface/module.  I've been going through the RFC's, and have some
questions/comments on the way snort is saving the data in the database.

Let's take a look at each protocol:

RFC791                  Snort		bits
Version                                 4
IHL                                     4
Type of Service         ip_tos	8
Total Length                    	16
Identification          ip_id		16
Flags			 	3
Fragment Offset         ip_off          13
TTL                     ip_ttl          8
Protocol                ip_proto	8
Header Checksum                 	16
Source IP               ip_src (x4)	32
Destination IP          ip_dst (x4)	32
Option                          	24
Padding                                 8

Why split up the ip_src and ip_dst into four different elements?
Personally I would like to have them represented as two 32bits integers
(and use a netmask to get the highest and lowest address for an select
statement).  It would also be nice to have a timestamp in this table.

RFC793                  Snort		bits
Source Port		th_sport	16
Destination Port	th_dport	16
Seq Number				32
Ack Number				32
Data Offset				4
Reserved				6
URG			th_flags	1
ACK			   "		1
PSH			   "		1
SYN			   "		1
FIN			   "		1
Window                  th_win          16
Checksum				16
Urgent Pointer          th_urp          16
Options                         	24
Padding                                 8

Why not log the SEQ and ACK numbers too?  That would make it much easier
to see the packets together as a session.  I'm not sure about the
reserved and options fields, but I like to be able to take a look at
everything when I'm investigating an incident. :-)

RFC792                  Snort		bits
Type			type		8
Code			code		8
Checksum				16
div 32 bit				32
IP hdr + 64b data			256

There is a 32bits field here that is used for some of the values in the
code field.  Why not log it?  The IP header and the 64 bits of data, are
they of any interest?  Again, I like to see everything... :-)

RFC768                  Snort		bits
Source Port		uh_sport	16
Destination Port	uh_dport	16
Length                  uh_len          16
Checksum				16

Seems that everything is logged... :-)


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

And a question: 

What about develop a standard database layout for anomaly based IDS?  Or
does this already exist?

mike, http://www.src.no/home/mike/
Brain fried -- Core dumped

More information about the Snort-users mailing list