[Snort-devel] rules2sql.pl and sql2rules.pl

Martin Roesch roesch at ...48...
Mon Jan 29 11:25:31 EST 2001

On a similar note, I'd like at some point to start thinking about
modifying Snort to be able to read rules/configuration data from a
database.  This is still a few months down the road, but I just wanted
to give you guys a heads up that doing good work on a schema now will
reward us all later. :)


Brian Caswell wrote:
> Chris Green wrote:
> > Well, despite my better judgement, I wrote a schema for postgresql
> > ( helped along by reading a db book while in the ER ) and a couple
> > shoddy perl scripts to support it.
> Before you get any farther, this is a good start.
> The only reason I have so many comments is that I have already
> started building a database.  The database is finished, the interface
> to it, however... is not.  I started writing a plugin to snort to
> pull its configuration from a database. Lets just say... that its
> quite ugly.
> Hopefully my comments are self-explainitory, but if not... just ask.
> I'll try harder.
> - TEXT is an EVIL data type.  Don't use text.  varchar is good.
> - You are missing "PASS" as a rule type
> - Do not put GID in the same table as the rule.  Have a seperate
>   table to do cross referencing.  (That way we can have multiple
>   classifications for a rule.  [IIS, HTTP, and NT for example]
> - DO NOT USE TEXT.  Yes, I said it before, but its really important.
> - RPC is always going to be INT4,INT2,INT2.  100000,*,* can translate
>   to "100000","",""   So don't use TEXT
> - session should be a binary.  (Its either printable, not printable, or
>   blank)
> - FLAGS should be stored in a seperate table, like direction is.  It
>   would be much easier to deal with.
> - SRC, DEST should be of type CIDR.  (available in postgresql only
> - SRC & DEST should *really* be referencing a SRCID and DESTID from a
>   different table.  (This is needed for targeted IDS.  Then we can say
>   "Rules A,B, D is for DMZ.  Rules A, C, D are for WEB_SERVERS)
> - SPORT & DPORT should be INT4
> - TTL should be INT2.
> - instead of CHAIN, have "activatedby" and "activates"  (INT4,
> references
>   RID) Much cleaner.  Easier to make a web interface to deal with all
> the
>   rules this way.
> - Do not use TEXT.  TEXT is EVIL
> - RESP should be referencing a table of "types of responces" (like
>   direction)
> - FLAGS should be a series of binary options.
>   - TCPSYN, TCPFIN, TCPPUSH, +, -, * and so on
> - dsize should be int2.
> - fragbits should be a bunch of binary options
>   - FRAGR, FRAGD, FRAGM, +, -, *
> - Um... what is priority?  (talking about the content table) This should
>   be called "order"
> Its a good start, but your database does not lend itself to developing
> multiple policies.  The version I have been working on tries to take
> into
> account policies for difference sensors and TARGETS.   You should have a
> method of grouping together "rules" into "policies" and then setting up
> "sensors" with specific "policies".
> Oh, and your SQL states that I should have got a copy of the GNU public
> license with the tgz.  I didn't. :)
> I would release the code that I have right now, but its not ready for
> human
> consumption.  Its ugly, evil, yucky and stuff.  Much like RealSecure :)
> -brian
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/snort-devel

Martin Roesch
roesch at ...48...

More information about the Snort-devel mailing list