[prev in list] [next in list] [prev in thread] [next in thread] 

List:       focus-ids
Subject:    RE: Questions about filtering
From:       idslist <ids () packetstorm ! org>
Date:       2002-07-15 17:13:39
[Download RAW message or body]



On Mon, 15 Jul 2002, Aigars Grins wrote:

> Hi,
>
> > So I write a rule using whatever tool I have
> > available to do something
> > like so: (pseudocode)
> >
> > if (tcp.src == x.x.x.x and tcp.dst == y.y.y.y
> > and tcp.dst_port == 80 and
> > rule == "iis.frontpage.vti_bin")
> > {
> >   #ignore this since we have validated this traffic
> >
> > }
> >
>
> I haven't seen such _generic_ filtering capabilities available across
> _multiple_ IDSs, but NFR will tell you that, if the filter cannot be tuned
> enought, you can always redifine the filter/backend that actually produced
> the alert so as to follow your rule above. You'll have to learn N-Code, but
> that's no great obstacle (it's rather similar to C or Perl and the _basics_
> are easily learned). There are of course problems with this approach as
> well, such as that when the next release of filters/backends from NFR is
> available you'll have to re-implement you changes.. A more long-term
> solution might be to convince their Rapid Response Team to make a more
> generic change to the code so that you might be able to filter the alerts
> out using the COTS version.
>
> --
> Aigars
>
>

Well I can do it in NCode currently by editing the .nfr files and creating
my own "conditional wrappers". But there are 2 problems:

1. I dont want the security guy managing this system taking up all my time
writing rules. Id rather there be an easier mechanism for him to deal with
this so I can do what i need to do. Since they guy has no programming
experience at all, NCode is out.

2. Like you mentioned, if i edited those files i would be in a fix when
the next updates occured.


Thanks!

-Greg

[prev in list] [next in list] [prev in thread] [next in thread]