[Snort-users] Draft: Database layout

Jed Pickel jed at ...153...
Mon Aug 7 14:36:42 EDT 2000

> Here is a draft that we can use as a basis for further discussions about
> the layout of the database.

Comments included inline below..

>  * Which data type is best for storing icmp_data?

I plan to implement this as a text field with the contents being the
base64 representation. As for the packet payload, it will be either
base64 or ascii depending on whether or not the user has the "-C"
command line switch.

>  * What is the best way to represent TCP flags in the database?
>    Personally I believe that it's easier for both human and machine to
>    use the suggested method.

I think we will stick with the current unless anyone is strongly
opposed to this. Note that the extra tables (distributed separately
from snort because of size) can help make these flags easier to
read/process by mapping the number to their corresponding values for
each flag. These tables are available at the following URL:


> Hmm... does anyone know any good tools that I can use to draw a database 
> diagram?  And runs under Linux? 

Good question. I guess emacs doesn't count. ;) Interested to hear if
anyone has an answer.

> ## Changes  from the original:
> ##	Added:
> ##		- tstamp	Timestamp (automaticly updated in MySQL)

I am opposed to this because a timestamp is not part of an IP
header. I would like to restrict this table to only what is in a IP
header. The event table is intended for this sort of data. To
associate an ip header with a timestamp you could just join with
the event table.

> ##		- ip_ver	The IP version	      
> ##		- ip_ihl	Internet Header length
> ##		- ip_len	Total Length (of datagram)
> ##		- ip_flags	Various control Flags

Hmm... I just noticed that the IPHdr structure in decode.h does not
have a field for the ip_flags. I guess you could get that by doing a
bitmask with the first three bits of the fragment offset. I will do
some testing to see if this works as I expect.

> ##		- ip_chks	Header Checksum
> ##		- ip_opt	Options

See comments below about options (both TCP and IP).

> ## Changes from the original:
> ##	The names starts with tcp instead of th

This comment makes sense, but th is consistent with how these values
are represented in the snort source; thus, I am reluctant to make that
change. Anyone else feel strong about this? 

> ##	Added:
> ##		- tcp_seq	Sequence Number
> ##		- tcp_aseq	Acknowledgment Number
> ##		- tcp_doff	Data Offset

> ##		- tcp_res	Reserved bits
> ##		- tcp_urg	
> ##		- tcp_ack
> ##		- tcp_psh
> ##		- tcp_syn
> ##		- tcp_fin

Right now these are represented as a single INT. It is necessary to
be able to separate these out into different fields for easier
programatic processing and human readability. The current way to get
this info is by using the snortdb-extra.gz tables that can be
downloaded at www.incident.org/snortdb/snortdb-extra.gz. Using those
tables you can map the th_flags column to get the reserved

> ##		- tcp_chks	Header Checksum
> ##		- tcp_opt	Options

Because options are optional, and there are an unknown number of them
we are using in this field an option id number. Actual option data is
then stored in a separate table with one option per row. So then to
see all of the options in this table you would SELECT in the option
table based on the option id. You will see when this is ready to be 

> ##   	Question:
> ##		Which format is better for flags, true/fals or all bits
> ##		represented in one TINYINT?

There would be some wasted space even with using a tinyint if we use
one for each field. Sticking with the current way they all go into one
> ## Changes from the original:
> ##	The names start with udp instead of uh
> ##	
> ##	Added:
> ##		- udp_chks 	Checksum

Same comment here as in with the tcp versus th above.

> ## Changes from the original:
> ##	The names starts with icmp
> ##
> ##	Added:
> ##		- icmp_chks	Checksum
> ##		- icmp_div	Used depending on icmp_type

I am not quite sure what the "div" field is. I will have to take a
look at that RFC.

> ##		- icmp_data	IP header + 64 bits of data	

Same comment here as in with the tcp versus th above. Mostly to remain
consistent with the source code. It may be an option to update the
snort source code to the ways that you suggest. I will see how hard
that would be.

* Jed

More information about the Snort-users mailing list