[Rman-devel] Re: Automatic response on a per sensor/per rule
Status: Alpha
Brought to you by:
mvevers
Menu
▾
▴
[Rman-devel] Re: Automatic response on a per sensor/per rule
|
From: Mark V. <ma...@ve...> - 2002-09-19 08:50:46
|
=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-----
|
