[Snort-devel] rules2sql.pl and sql2rules.pl
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
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
- 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,
RID) Much cleaner. Easier to make a web interface to deal with all
rules this way.
- Do not use TEXT. TEXT is EVIL
- RESP should be referencing a table of "types of responces" (like
- 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
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
consumption. Its ugly, evil, yucky and stuff. Much like RealSecure :)
More information about the Snort-devel