rman-devel

[Rman-devel] Suggested work-around for the catch-22 issue

[Michael B. <mic...@se...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I was thinking, if the sensor is not known (like first time you start the 
sensor) then 

snort -T <other options>

should be issued to put the sensor in the database. I also suggests a 
extractrules gets a --init option that add the sensor to the rman sensor 
table.

Another idea is also to have a 'default' sensor that is part of a default 
group that has a bunch of rules the user think he wants to start off with. 
Basicly anything that removes the catch22 would be nice.

What do you guys think about it?

Best regards
 Michael Boman

PS
 The active response hacking has been suffering lack of progress lately as I 
got busy with other tasks. It is still on my todo list however.
DS

- -- 
Michael Boman
Security Architect, SecureCiRT (A SBU of Z-Vance Pte Ltd)
http://www.securecirt.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9vmSSds5fQJiraJwRAgwJAKCjZs1GKHq6lD4dh+E6VqpZTXuzlQCdFfWr
xvxiByyJho3wIr1jYvnZvq8=
=xBVN
-----END PGP SIGNATURE-----

[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-----

Re: [Rman-devel] Re: Automatic response on a per sensor/per rule

[Michael B. <mic...@se...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 20 September 2002 18:27, Mark Vevers wrote:
> Looks great - commit the changes to the dbschema and I'll create the diffs
> for the db upgrade path.

Changes commited.

> > > I already have a small patch for ACID which lists Rman alongside
> > > Arcachnids and snortDB - you just click on the RMAN link in the
> > > triggered signature and up pops a new window / tab  with the rule
> > > listed ....
> >
> > Cool. Send the patch this way?
>
> I'll send it with the Javascript.   Time to get web-site writing.

What about putting the ACID patch in contrib directory?

/Mike

- -- 
Michael Boman
Security Architect, SecureCiRT (A SBU of Z-Vance Pte Ltd)
http://www.securecirt.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9ivuzds5fQJiraJwRAj69AKCzjWwP+TZMvQ+ulpJa9j4u/Q+DQgCgy4QN
YyHb7cLDohk7M+DqjWCLL3k=
=0W+j
-----END PGP SIGNATURE-----

Re: [Rman-devel] Re: Automatic response on a per sensor/per rule

[Mark V. <ma...@ve...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike,

On Thursday 19 Sep 2002 11:50, Michael Boman wrote:
> Come think of one more autoresponder: rule tagging could be concider a
> response if you want to do it selective based on rule/sensor level...
> Basicly this can be used to add options to any rule you want to just chan=
ge
> for certain sensors...
Probably true - but I need to think about rule tagging and logging a bit mo=
re=20
=2D - anyway creative users can probably think of ways to do it as you sugg=
ested.

> There is a few tricks and tips mentioned at
> http://www.lugs.org.sg/downloads/iptables-july-2002.tar.gz
Thanks - I'll have a look.

> > > Anyway, so far I've got this:
>
> CREATE TABLE `rman_responders` (
>   `responder_id` int(11) NOT NULL auto_increment,
>   `name` varchar(255) NOT NULL,
>   `description` blob,
>   PRIMARY KEY (`responder_id`)
> ) TYPE=3DMyISAM;
>
> CREATE TABLE `rman_responses` (
>   `response_id` int(11) NOT NULL auto_increment,
>   `responder_id` int(11) NOT NULL,
>   `description` varchar(255) NOT NULL,	# <- Changed from name
>   `options` blob,
>   PRIMARY KEY (`response_id`, `responder_id`)
> ) TYPE=3DMyISAM;
>
> CREATE TABLE `rman_rules_response` (
>   `rid` int(11) NOT NULL,
>   `response_id` int(11) NOT NULL,
>   PRIMARY KEY (`rid`,`response_id`)
> ) TYPE=3DMyISAM;
>
> CREATE TABLE `rman_sensor_responders` (
>   `sid` int(11) NOT NULL,
>   `responder_id` int(11) NOT NULL,
>   PRIMARY KEY (`sid`,`responder_id`)
> ) TYPE=3DMyISAM;
>
> > > Please gimme some comments on it ;)
> >
> > All looks fine apart from a missing 'p' and the missing auto_increment =
in
> > rman_responses and extra s ....
>
> As you see now above, that is taken care of.
Looks great - commit the changes to the dbschema and I'll create the diffs =
for=20
the db upgrade path.
<snip>
> Javascript is not really my strength... Would be nice with some code ;)
OK - I'll dig it out this afternoon.   Just juggling some bandwidth on our=
=20
transits at the moment.

> > I already have a small patch for ACID which lists Rman alongside
> > Arcachnids and snortDB - you just click on the RMAN link in the trigger=
ed
> > signature and up pops a new window / tab  with the rule listed ....
>
> Cool. Send the patch this way?
I'll send it with the Javascript.   Time to get web-site writing.
Cheers
Mark
=2D --=20
Mark Vevers.    ma...@if... / ma...@ve...
Principal Internet Engineer, Internet for Learning,
Research Machines Plc. (AS5503)
=2D --
GPG Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xB08F3CA3
=46ingerprint: 85BA 30C4 9EC8 1792 4C8C   C31E 58B5 3D1C B08F 3CA3
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9ivgqWLU9HLCPPKMRAi/0AJ9Xc7V2oUZejhwS4esrmRVevXOvvwCgh+Pd
RLsy3eBhnYx0iNi/nHlHB0Q=3D
=3DFQvL
=2D----END PGP SIGNATURE-----

[Rman-devel] Changing specific links to $PHP_SELF where appropitate..

[Michael B. <mic...@se...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In my quest to understand the code I have changed some self-refering pages to 
$PHP_SELF. Nothing broke, and I find the code more portable (ie: I can rename 
any file and it still works, except for external links of course.. - Works 
great when you want to re-use code.. think vars.php and preprocessors.php..)

Anyway, should I commit the changes? Or wait for now?

/Mike

- --
Michael Boman
Security Architect, SecureCiRT (A SBU of Z-Vance Pte Ltd)
http://www.securecirt.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9ivY6ds5fQJiraJwRAg6XAJ0dxswwy/JC2jL8rqL2tE1qCeXxBwCeLu54
6bf/yFnrnMUAfRfxbwBkpbw=
=AX/k
-----END PGP SIGNATURE-----

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

[Mark V. <ma...@ve...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 19 Sep 2002 17:50, Kreimendahl, Chad J  wrote:

> It's been mentioned a few times very recently, and so our company would
> like to contribute a bit of data structure to the snort project.
>
> We've been using this structure (with other tables), to generate rules
> files for our different sensors.  The header part of it all is fairly
> unsophisticated, and the rules parts should be sufficient.  We'd love to
> offer our services to make snort load its config from a DB.
Chad,
I agree that a DB based config is a valuable addition to snort - and to tha=
t=20
end we have been working on a project to do just that - RuleMANager for Sno=
rt=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 managemen=
t=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 backe=
nd=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 rul=
e,=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

=2D --=20
Mark Vevers.    ma...@if... / ma...@ve...
Principal Internet Engineer, Internet for Learning,
Research Machines Plc. (AS5503)
=2D --
GPG Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xB08F3CA3
=46ingerprint: 85BA 30C4 9EC8 1792 4C8C   C31E 58B5 3D1C B08F 3CA3
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9it3SWLU9HLCPPKMRAt/CAKCPRotPAmGyjlCOdU3JbU69HfIxBACfV5Gf
zikKjuYzZx2XWVyS2u9ieQ0=3D
=3DVwYD
=2D----END PGP SIGNATURE-----

Re: [Rman-devel] Re: Automatic response on a per sensor/per rule

[Michael B. <mic...@se...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 19 September 2002 16:45, Mark Vevers wrote:
> Mike,
> (Sig OK this time!)
>
> On Thursday 19 Sep 2002 03:38, you wrote:
> > And probibly more to come.... Automated response is increasing ROI, as
> > less manual labor is needed - good for those hardly-never-false-positive
> > rules.. Like anything that access .ida / .printer etc on a webserver is
> > bad, as it is basicly only kiddies and viruses that does that anyway..
> > YMMV of course....

Come think of one more autoresponder: rule tagging could be concider a 
response if you want to do it selective based on rule/sensor level... Basicly 
this can be used to add options to any rule you want to just change for 
certain sensors...

> Indeed - that's exactly the kind of rule I use.  I've also done some work
> on a set of rules for IP tables which completely nullifies the OS detection
> for both nmap and queso.  (NMAP comes back with 'N' or no response to *ALL*
> tests!  Unfortunately I managed to loose them in an HD crash before I
> managed to back them up.   Oh well - at least I know it's possible.

There is a few tricks and tips mentioned at 
http://www.lugs.org.sg/downloads/iptables-july-2002.tar.gz

Fabrice is a good friend of mine, and he's quite good at the iptable stuff ;)

> > > Ok, I'd like to keep this is generic as possible rather than hard
> > > coding support for two specific variants into the code.   So I'm
> > > thinking of the following:
> > > rman_responders - a table containg a list of the flex response packages
> > >   fields:    responder_id, name, description.
> > >
> > > rman_responses - A table which contains a list of responses:
> > >   fields: response_id, responder_id, name, options
> > >
> > > rman_rules_response - A table to link rules to responses
> > >   fields: rid, response_id
> > >
> > > rman_sensor_responsders - A table to link sensors to responders
> > >   fields: sid, responder_id.
> >
> > Ok... How is the relationship between
> >
> > rman_responders.responder_id
> > rman_responses.responder_id
> > rman_sensor_responders.responder_id
>
> Ok responder_id is the master - relates to SnortSam or FlexResp or
> MyOwnPerlHack (tm ;-) - rman_responses.responder_id links the response to a
> particular responder - i.e. flexresp uses block etc and SnortSam has all
> sorts of options - i.e. for each responder you can have a variety of
> responses.
>
> Rman_sensor_responders is a table to link responders to sensors - i.e. each
> sensor can have one or more responders and each responder can be active for
> one or more sensors.  A rule (as extracted on the sensor) only has the
> options for that responder included if that responder is listed as active
> for that sensor:
>
> Sensor 1 has repsonders 0 and 1
> Sensor 2 has responder 2
> Sensor 3 has responder 0
> Sensor 4 had responder 1 and 2
> Which gives the following table:
> 	sid	responder_id
> 	1	0
> 	1	1
> 	2	2
> 	3	0
> 	4	1
> 	4	2
>
> A bit like the way rules can belong to more than one group and groups can
> have more than one rule .... (I  know you probably know this but just in
> case you don't all I am doing is reducing a many<->many relationship to a
> many<->one<->many relationship - i.e. third normal form).
>
> Rman_rules_response works the same way and links rules to responses.
>
> > ?
> >
> > Need to build a nice SELECT statement ;)
>
> That's the one .......
>
> SELECT options FROM rman_responses JOIN rman_rules_responses USING
> (response_id) JOIN rman_sensors_reponders USING (responder_id) WHERE
> rman_sensors_responders.sid =? AND rman_rules_responses.rid = ?
>
> Not sure that's right - (off the top of my head without having added the
> tables or any data into a db to test but it *might* work ... ;-).   Also,
> better make sure we've got the right indicees in there - we may have to
> replace the JOIN with a STRAIGHT JOIN to force the index order if the
> optimizer gets it wrong.
>
> > Anyway, so far I've got this:

CREATE TABLE `rman_responders` (
  `responder_id` int(11) NOT NULL auto_increment,
  `name` varchar(255) NOT NULL,
  `description` blob, 
  PRIMARY KEY (`responder_id`)
) TYPE=MyISAM;

CREATE TABLE `rman_responses` (
  `response_id` int(11) NOT NULL auto_increment,
  `responder_id` int(11) NOT NULL,
  `description` varchar(255) NOT NULL,	# <- Changed from name
  `options` blob,
  PRIMARY KEY (`response_id`, `responder_id`)
) TYPE=MyISAM;

CREATE TABLE `rman_rules_response` (
  `rid` int(11) NOT NULL,
  `response_id` int(11) NOT NULL,
  PRIMARY KEY (`rid`,`response_id`) 
) TYPE=MyISAM;

CREATE TABLE `rman_sensor_responders` (
  `sid` int(11) NOT NULL,
  `responder_id` int(11) NOT NULL,
  PRIMARY KEY (`sid`,`responder_id`)
) TYPE=MyISAM;

> > Please gimme some comments on it ;)
>
> All looks fine apart from a missing 'p' and the missing auto_increment in
> rman_responses and extra s ....

As you see now above, that is taken care of. 

> > Yes.. As soon we can do responses we should warn/inform the user that we
> > now support it naitivly.. maybe even strip that part out of the
> > rman_rules.options and stick it where it really belongs? Comments?
>
> We'll give them a version where both are available otherwise they'll
> complain

Sounds fine with me.

> > I belive your structure is much more flexible.. Trying to visulize how to
> > build the gui around it thought.. would need to be some 'add' buttons and
> > a drop-down menu...
>
> Adding responses to rules - they choose the responder and then choose the
> list of responses from a drop down menu.   This will require some
> javascript probably.   If you're OK with that fine - if not I can send you
> some example code from another in-house project ....

Javascript is not really my strength... Would be nice with some code ;)

> > At the same time we go stable (same definition of stable as ACID uses) we
> > should seek some co-marketing from Roman with ACID.. You know, create
> > links so that you can switch between ACID and RMan as you please and so
> > on... What do you think about that?
>
> I already have a small patch for ACID which lists Rman alongside Arcachnids
> and snortDB - you just click on the RMAN link in the triggered signature
> and up pops a new window / tab  with the rule listed ....

Cool. Send the patch this way?

/Mike

- -- 
Michael Boman
Security Architect, SecureCiRT (A SBU of Z-Vance Pte Ltd)
http://www.securecirt.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9iavsds5fQJiraJwRAl7iAKDe14Cti++ZYho73iD/GCX2Kl7NqwCghXA3
pnZElxKZGJEQnilXSoLfF44=
=pa1c
-----END PGP SIGNATURE-----

[Rman-devel] Re: Automatic response on a per sensor/per rule

[Mark V. <ma...@ve...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike,
(Sig OK this time!)
On Thursday 19 Sep 2002 03:38, you wrote:

> SnortSam can do CISCO ACLs (both routers and pix firewalls) as well...
> Trying to find time to make SnortSam talk watchguard firewalls as well...
Indeed but it didn't quite fit what we wanted it to do so I knocked up a bit
of perl and a db structure to hold the config and it now reads its list of
people to respond to from the aggregated list of 'skript kiddies' ....

> > You know three now!
>
> And probibly more to come.... Automated response is increasing ROI, as le=
ss
> manual labor is needed - good for those hardly-never-false-positive rules=
=2E.
> Like anything that access .ida / .printer etc on a webserver is bad, as it
> is basicly only kiddies and viruses that does that anyway.. YMMV of
> course....
Indeed - that's exactly the kind of rule I use.  I've also done some work o=
n a
set of rules for IP tables which completely nullifies the OS detection for=
=20
both nmap and queso.  (NMAP comes back with 'N' or no response to *ALL*=20
tests!  Unfortunately I managed to loose them in an HD crash before I manag=
ed=20
to back them up.   Oh well - at least I know it's possible.

> > Ok, I'd like to keep this is generic as possible rather than hard coding
> > support for two specific variants into the code.   So I'm thinking of t=
he
> > following:
> > rman_responders - a table containg a list of the flex response packages
> >   fields:    responder_id, name, description.
> >
> > rman_responses - A table which contains a list of responses:
> >   fields: response_id, responder_id, name, options
> >
> > rman_rules_response - A table to link rules to responses
> >   fields: rid, response_id
> >
> > rman_sensor_responsders - A table to link sensors to responders
> >   fields: sid, responder_id.
>
> Ok... How is the relationship between
>
> rman_responders.responder_id
> rman_responses.responder_id
> rman_sensor_responders.responder_id
Ok responder_id is the master - relates to SnortSam or FlexResp or=20
MyOwnPerlHack (tm ;-) - rman_responses.responder_id links the response to a=
=20
particular responder - i.e. flexresp uses block etc and SnortSam has all=20
sorts of options - i.e. for each responder you can have a variety of=20
responses.

Rman_sensor_responders is a table to link responders to sensors - i.e. each=
=20
sensor can have one or more responders and each responder can be active for=
=20
one or more sensors.  A rule (as extracted on the sensor) only has the=20
options for that responder included if that responder is listed as active f=
or=20
that sensor:

Sensor 1 has repsonders 0 and 1
Sensor 2 has responder 2
Sensor 3 has responder 0
Sensor 4 had responder 1 and 2
Which gives the following table:
	sid	responder_id
	1	0
	1	1
	2	2
	3	0
	4	1
	4	2

A bit like the way rules can belong to more than one group and groups can h=
ave=20
more than one rule .... (I  know you probably know this but just in case yo=
u=20
don't all I am doing is reducing a many<->many relationship to a=20
many<->one<->many relationship - i.e. third normal form).

Rman_rules_response works the same way and links rules to responses.

>
> ?
>
> Need to build a nice SELECT statement ;)
That's the one .......

SELECT options FROM rman_responses JOIN rman_rules_responses USING=20
(response_id) JOIN rman_sensors_reponders USING (responder_id) WHERE=20
rman_sensors_responders.sid =3D? AND rman_rules_responses.rid =3D ?

Not sure that's right - (off the top of my head without having added the=20
tables or any data into a db to test but it *might* work ... ;-).   Also,=20
better make sure we've got the right indicees in there - we may have to=20
replace the JOIN with a STRAIGHT JOIN to force the index order if the=20
optimizer gets it wrong.  =20

> Anyway, so far I've got this:
>
> CREATE TABLE 'rman_responders' (
>   'responder_id' int(11) NOT NULL auto_increment,
>   'name' varchar(255) NOT NULL,
>   'description' blob,
>   PRIMARY KEY ('responder_id')
> ) TYPE=3DMyISAM;
>
> CREATE TABLE 'rman_responses' (
>   'resonse_id' int(11) NOT NULL,
*****^p^                                         ^auto_increment^
>   'responder_id' int(11) NOT NULL,
>   'name' varchar(255) NOT NULL,
>   'options' blob,
>   PRIMARY KEY ('response_id', 'responder_id')
> ) TYPE=3DMyISAM;
>
> CREATE TABLE 'rman_rules_response' (
>   'rid' int(11) NOT NULL,
>   'response_id' int(11) NOT NULL,
>   PRIMARY KEY ('rid','response_id')
> ) TYPE=3DMyISAM;
>
> CREATE TABLE 'rman_sensor_responsders' (
                                                      ^responders^
>   'sid' int(11) NOT NULL,
>   'responder_id' int(11) NOT NULL,
>   PRIMARY KEY ('sid','responder_id)
> ) TYPE=3DMyISAM;
>
> Please gimme some comments on it ;)

All looks fine apart from a missing 'p' and the missing auto_increment in=20
rman_responses and extra s ....

> > Then - any rule can have a response associated with it for up to N
> > responders and could even have more than one response for a given
> > responder.  Each sensor can then be configured for any responder.   For
> > both flexresp and snortsam they are configured by adding options to the
> > rules list of options which should allow us to keep this generic.   We
> > probably should mark the use of the react keywords in rules by users as
> > deprecated and discontinue it at somepoint.
>
> Yes.. As soon we can do responses we should warn/inform the user that we
> now support it naitivly.. maybe even strip that part out of the
> rman_rules.options and stick it where it really belongs? Comments?
We'll give them a version where both are available otherwise they'll compla=
in

> > I'm open to debate on the db structure - if you'd prefer to do it your
> > way I think we should use SETs instead of adding multiple fields to the
> > rules. Anyway let me know what you think.
>
> I belive your structure is much more flexible.. Trying to visulize how to
> build the gui around it thought.. would need to be some 'add' buttons and=
 a
> drop-down menu...
Adding responses to rules - they choose the responder and then choose the l=
ist=20
of responses from a drop down menu.   This will require some javascript=20
probably.   If you're OK with that fine - if not I can send you some exampl=
e=20
code from another in-house project ....

> >   I guess flexible response handling could be the major component of
> > 0.0.6a. Many thanks for your involvement on this - it reminds me to keep
> > going - I'm generally feeling a bit out if it at the moment and it helps
> > to have someone to keep you on track .....! ;-)
>
> I agree.. It's nice to know that the things you are working on are
> appriciated. A 'Thank You!', 'Good Work!' every now and then always boost
> the moral.
>
> Maybe we should start using the -devel list, to show that the project is
> not dead? I think the 'alpha' status is one reason people doesn't try out
> RMan, and the other one should be that there is virtually no traffic on t=
he
> mailinglists, website outdated etc..
Probably - cc'ing now.

> We can keep the 'alpha' status a while more until we have all the features
> in (ie: as long we change the DB structure), but after we have frozen the
> DB structure (stopped adding features every other week) we should go into
> beta/rc status.
Yup thats the plan as far as I'm concerned - I need to do some more on sens=
or=20
status and overall management but I think I've got the db structure I want.

> I think it would be worth to mention that RMan is used in production
> systems and is not known to cause any problems yada yada yada... You know,
> we eat our own dog food etc... This to encurage more people to give RMan a
> try.
Indeed - wrote the rules to pick up the Slapper worm and sent it round the=
=20
sensors .... 100000 alerts later (and not false positives either) before I=
=20
managed to seal it out of the network at all borders ...!

> At the same time we go stable (same definition of stable as ACID uses) we
> should seek some co-marketing from Roman with ACID.. You know, create lin=
ks
> so that you can switch between ACID and RMan as you please and so on...
> What do you think about that?
I already have a small patch for ACID which lists Rman alongside Arcachnids=
=20
and snortDB - you just click on the RMAN link in the triggered signature an=
d=20
up pops a new window / tab  with the rule listed ....

Keep up the good work!

Regards
Mark

> PS
> Oh, I also belive we should stick a DB version into the DB, just like ACID
> has it.. extractrules.pl should know what kind of data the database can
> support, so you can use a newer extractrules.pl with a older database (so
> it doesn't try to extract data that isn't there). What do you think?
Sounds good - will do.
Mark.
=2D --=20
Mark Vevers.    ma...@if... / ma...@ve...
Principal Internet Engineer, Internet for Learning,
Research Machines Plc. (AS5503)
=2D --
GPG Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xB08F3CA3
=46ingerprint: 85BA 30C4 9EC8 1792 4C8C   C31E 58B5 3D1C B08F 3CA3
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9iY7AWLU9HLCPPKMRAkySAJ9cTHfHnPVzjTYLFs2DSAuZtlgGQwCcDMzy
DY+n5zTgzvsnosazG10DgJA=3D
=3Deqxm
=2D----END PGP SIGNATURE-----

[Rman-devel] Re: Added features

[Mark V. <ma...@if...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'll post these as soon as I receive them.

Cheers
Mark

=2D --=20
Mark Vevers.    ma...@if... / ma...@ve...
Principal Internet Engineer, Internet for Learning,
Research Machines Plc AS5503
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9bfuFWLU9HLCPPKMRAu6YAJ9QYtrfnzIDMYu+aI7KiyjJRFO4vQCZAX/o
eCvVRclOH2Gc+5/kv3MUsPo=3D
=3Dn8Dy
=2D----END PGP SIGNATURE-----

[Rman-devel] Added features

[Michael B. <mic...@se...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

I've added a few features locally.

1) Import (Create/Update) of variables from snort.conf
2) Import (Create/Update) of preprocessors from snort.conf
3) Maintainence of preprocessors in the WWW gui

Still to do
extractrules.pl: need to hack so that preprocessors are exported from 
database.

In the pipeline:
Import, Maintain and Export of config variables

Where should I send the patches? How do you want the patches?

Best regards
 Michael Boman

PS
 Done against version 0.4
DS

- -- 
Michael Boman
Security Architect, SecureCiRT (A SBU of Z-Vance Pte Ltd)
http://www.securecirt.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9bTB9ds5fQJiraJwRAkRsAJ9h8XpAoJPwxNsGAFT8exrTI9Kq3QCgwg5z
5WTn6JYYj4aFICTtPYutbWc=
=J9sP
-----END PGP SIGNATURE-----

[Rman-devel] SNMP status issues + extractrules.pl updates

[Michael B. <mic...@se...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have some issues getting SNMP status working. I am no SNMP guru so I was 
hoping someone could give me a hand.

I also see that SNMP is a undocumented 'feature'.

I have changed the extractrules.pl file:

Original:
- ---------

while(@resarray=$sql->fetchrow_array) {
    $vars{$resarray[0]}=$resarray[1];
}

foreach $var (sort keys(%vars)) {  
    print FILE "var ".$var." ".$vars{$var}."\n";
}

Changed to:
- -----------

while(@resarray=$sql->fetchrow_array) {
    print FILE "var ".$resarray[0]." ".$resarray[1]."\n";
}


The reason is that: (sort keys(%vars)) sorts the whole thing and $HOME_NET 
gets declared AFTER other variables are using it. The change makes the 
db.vars be created in the order they are in the database.

Best regards
 Michael Boman

- -- 
Michael Boman
Security Architect, SecureCiRT (A SBU of Z-Vance Pte Ltd)
http://www.securecirt.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9KVXfds5fQJiraJwRAvg6AJ98HoDJWG3RUbNIdxwkJUKxCnzDsQCgqBxv
M5CnyUa1BrVOyndmYiEUaDM=
=iIMM
-----END PGP SIGNATURE-----