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

Brian Caswell bmc at ...227...
Sun Jan 28 22:04:59 EST 2001


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.  
  TEXT is bad.  NEVER USE TEXT.  NEVER EVER.
- 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
AFAIK)
- 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




More information about the Snort-devel mailing list