[Snort-devel] rules2sql.pl and sql2rules.pl
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.
> 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 :)
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
roesch at ...48...
More information about the Snort-devel