Re: IDS detection approaches

["Sec urity" <security () brvenik com>]

On 10/11/07, Control Zed <cntlzed () gmail com> wrote:
> On 10/10/07, Sec urity <security () brvenik com> wrote:
>
> [snip]
>
>
> > > What if you send 1,000,000 packets with the following payload to port
> > > 1434/UDP?
> >
> > Well...
> >
> > 1) If it is a real concern you should have configured a default global
> > threshold or the latency thresholds if inline. This default global
> > would have kicked in and prevent this kind of resource exhaustion.
>
> > 2) Your attempt at resource exhaustion is still nefarious activity as
> > is your sending a payload to the SQL Server that is in essence an
> > attempt to overflow the buffer of 96 bytes. That a null causes a fail
> > to exploit is irrelevant.
> >
> > 3) It is not a false positive, it is a positive match on shenanigans
> > targeted at the SQL server. At most it is an unsuccessful attack to
> > exploit the system.
>
>
> Just digressing from the regex and pattern matching arguments.
>
> The point that was being made was the target here was not the SQL server but
> the IPS. So the security device is being attacked, but the admin won't
> realize this because she sees them as attacks against the SQL server and she
> may not even know who is launching the attack (connectionless, spoofed, bots
> blah blah).

This is always something that exists as a threat by stateless
protocols, it matters not that it is a null payload or a real payload,
the result is the same, as is the reality that this is malicious
traffic on the wire. I would argue that using a null payload is
actually falling short of the goal of resource exhaustion in so far as
the analyst can easily eliminate it. Sourcefire (Creators of Snort)
also provides more automatic methods to do this work for the analyst
by determining if the payload has any chance of affecting the target
and adjusting the events accordingly. This serves to highlight the
important events that need review and lower the relevance of the rest
of the events.

> Just wanted to understand what kind of thresholds would help in avoiding
> resource exhaustion if you want to note every IP from which an attack was
> launched against your systems.
>
> ~Z

There are several classes of thresholds available within Snort, which
one used depends entirely on the need. From
http://www.snort.org/docs/snort_htmanuals/htmanual_280/node330.html#Event_Thresholding

There are 3 types of thresholding:

    * limit

      Alerts on the 1st m events during the time interval, then
ignores events for the rest of the time interval.

    * threshold

      Alerts every m times we see this event during the time interval.

    * both

      Alerts once per time interval after seeing m occurrences of the
event, then ignores any additional events during the time interval.

It is a compromise between the survivability of the systems and the
security of the networks they oversee. Many choose security and others
choose survivability under concerted attack. Which one is right for
you entirely depends on what your goals are.

------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it 
with real-world attacks from CORE IMPACT.
Go to http://www.coresecurity.com/index.php5?module=Form&action=impact&campaign=intro_sfw 
to learn more.
------------------------------------------------------------------------