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

[Kreimendahl, C. J <Cha...@um...>]

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...=20

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:ma...@ve...]=20
Sent: Friday, September 20, 2002 3:36 AM
To: sno...@li...
Cc: rma...@li...; 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=20
end we have been working on a project to do just that - RuleMANager for
Snort=20
The web-site is a little out of date (rman.souceforge.net) - it will be=20
updated later this week when I release 0.0.5a - but it allows for
management=20
of rules, rule groups, preprocessors and variables on multiple sensors
with=20
an ACID style front end and stores all this in a MySQL backend  as a set
of=20
extension tables for the snort db structure.  If you or your company
would=20
like to contribute and improve this project in any way we (the three
RMAN=20
developers) would love to have your contribution.

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

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

Regards
Mark

- --=20
Mark Vevers.    ma...@if... / ma...@ve...
Principal Internet Engineer, Internet for Learning,
Research Machines Plc. (AS5503)
- --
GPG Key: =
http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xB08F3CA3
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=3D
=3DVwYD
-----END PGP SIGNATURE-----