[Snort-devel] rules2sql.pl and sql2rules.pl
cmg at ...81...
Mon Jan 29 11:39:35 EST 2001
Thanks for your comments. Lots of things I thought about but didn't
immediately see the answer so made them TEXT for the time being. I'm
going through and implementing your suggestions and I had a couple
questions. If I it's not in my reply, I agreed with enough to not
I'm heading back to the drawing board now.
Brian Caswell <bmc at ...227...> writes:
> - SRC, DEST should be of type CIDR. (available in postgresql only
That was my initial idea for SRC / DEST but but negation , iplists
(![184.108.40.206/24,220.127.116.11/16]) and variable names keep that from
I can break this up into a few tables and solve this problem
> - 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)
I'll agree with this. I'll need to think a lot more on how to
represent the hosts correctly for this.
> - SPORT & DPORT should be INT4
:1024 and 4,535,3215 were a problem to represent this way. I suppose
it should be yet another table so that I could have port groupings for
rules. I am beginning to think I was too much in parser-think mode
when I wrote this SQL.
> - TTL should be INT2.
I thought ttl could have > and < but it can't ( for right now ).
> - instead of CHAIN, have "activatedby" and "activates" (INT4,
> RID) Much cleaner. Easier to make a web interface to deal with all
> rules this way.
Yeah it ended up being a bit more noisy to code once I started writing
the perl scripts. I'll change this out. I glanced the activate and
dynamic code and there doesn't seem to be anything specifying that
chain couldn't be a string.
> - 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.
<,> problem - need to solve with the a table with a binary option.
> - fragbits should be a bunch of binary options
> - FRAGR, FRAGD, FRAGM, +, -, *
Yes that makes sense too.
> - Um... what is priority? (talking about the content table) This should
> be called "order"
SQL ignornace. Thanks.
> 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".
My initial idea was "depending on the sensor id, the variable values
would be different" but I'll agree that is too short sighted.
Customizing on targets and policies through some more tables will be
I also tried to make the SQL somewhat simple so that one wouldn't have
to see too many tables to get something useful done but I believe i've
made it too simple.
> Oh, and your SQL states that I should have got a copy of the GNU public
> license with the tgz. I didn't. :)
Oops.. You _should_ have but I forgot so feel free to write FSF for
your own copy :)
> 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 :)
Chris Green <cmg at ...81...>
You now have 14 minutes to reach minimum safe distance.
More information about the Snort-devel