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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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