[Snort-devel] DDL for snort rules in a DB

Kreimendahl, Chad J Chad.Kreimendahl at ...1167...
Sun Sep 22 19:41:02 EDT 2002


It's wonderful to have a front-end to manage the whole ruleset mess.
With revisions and such, it can definitely become a mess.  I'm not sure
we're going to be able to spend much time on the actual software you're
building, mostly because we already have a fairly well functioning snort
rules management program.  However, if it will help in the adoption of
snort rulesets in the database, as well as config with policies and all
the other wonderful stuff... We'd be happy to help.  We can certainly
contribute our ideas on data strucuture, and help resolve any issues
between the various databases.  I'm guessing if we get support from the
snort developers for all of this, we'll all want to agree on the most
versitile data structure.

I took a quick look at the db structure you've laid out... Definitely
looks similar to the ideas we had in mind.  I've wanted to get the other
parts of the config (besides the rules) into the DB in a more managable
form, but other wants for our monitoring have taken precedence.  I think
for it to be beneficial to everyone (having rules/config in db), there
should be a fairly simple command line tool to go through the revisions
and select which goes where... 

One thing I didn't notice, but I now think is very important is rule
ordering.  Since some rules by nature are within other rules... You may
have one rule hit, because it came before the next rule in the config,
while the real alert should have been the latter:

alert tcp any any -> any any (dsize: >20000; msg: something; ....)
alert tcp any any -> any any (dsize: >20000; content:"some_content"
msg:"something worse";....)

Given these two rules, you're more likely (in your config) to put the
second one first, so as to check all angles... Only real way to do this
is to allow for ordering of rules in a policy... Then just sort
regularly on the rest of the rules in the lot.  Unless I'm mistaken
about the way snort would hit this.

So... Any help in getting this database design to a common format would
be perfect... Hopefully we can have snort sucking from the teet of a DB
by the end of the year. (or at least valentines).

-----Original Message-----
From: Mark Vevers [mailto:mark at ...1209...] 
Sent: Friday, September 20, 2002 3:36 AM
To: snort-devel at lists.sourceforge.net
Cc: rman-devel at lists.sourceforge.net; Kreimendahl, Chad J
Subject: [Snort-devel] DDL for snort rules in a DB


Chad,
I agree that a DB based config is a valuable addition to snort - and to
that 
end we have been working on a project to do just that - RuleMANager for
Snort 
The web-site is a little out of date (rman.souceforge.net) - it will be 
updated later this week when I release 0.0.5a - but it allows for
management 
of rules, rule groups, preprocessors and variables on multiple sensors
with 
an ACID style front end and stores all this in a MySQL backend  as a set
of 
extension tables for the snort db structure.  If you or your company
would 
like to contribute and improve this project in any way we (the three
RMAN 
developers) would love to have your contribution.

The db-structure within RMAN contains pretty much every thing you
mentioned in 
your post - although I have yet to add the 'policy' layer.  We are also 
working on handling flexible-response/SnortSAM config in an intelligent
way - 
depending on time this should be available in the next month.

Should the snort developers choose to specify an official rule-set db
backend 
instead of the existing signature registration system (I would be more
than 
happy to modify RMAN to match) then a number of other problems will have
to 
be resolved - how to record pre-processor alerts which have no matching
rule, 
rules which changed or get deleted - the alert packet would no longer
have a 
valid reference to a rule.  Whilst not insurmountable this will require 
careful thought.

Regards
Mark

- -- 
Mark Vevers.    mark at ...1121... / mark at ...1209...
Principal Internet Engineer, Internet for Learning,
Research Machines Plc. (AS5503)
- --
GPG Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB08F3CA3
Fingerprint: 85BA 30C4 9EC8 1792 4C8C   C31E 58B5 3D1C B08F 3CA3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9it3SWLU9HLCPPKMRAt/CAKCPRotPAmGyjlCOdU3JbU69HfIxBACfV5Gf
zikKjuYzZx2XWVyS2u9ieQ0=
=VwYD
-----END PGP SIGNATURE-----





More information about the Snort-devel mailing list