Keep in mind its not just the sensor, its also the network. If the
sensors is on the perimeter and the target is a decent way into the
network normal network delay would with a high degree of probability
prevent the reset getting there in time

Blade Software Nominated In The 8th ANNUAL SC AWARDS
click on http://www.scmagazine.com/awards to vote
*******************************************************************

-------------------------------------------------------------------
Brian Laing
CTO
Blade Software
Cellphone: +1 650.280.2389
Telephone: +1 650 367.9376
eFax: +1 208.575.1374
Blade Software - Because Real Attacks Hurt
http://www.Blade-Software.com
-------------------------------------------------------------------

-----Original Message-----
From: mb_lima [mailto:mb_limauol.com.br]
Sent: Friday, January 31, 2003 8:35 AM
To: b_paul_palmeryahoo.com
Cc: focus-idssecurityfocus.com
Subject: Re: Active response... some thoughts.

 Hi Paul,

  It is perfect your explanation, but an attacker can create
ways to keep a sensor busy enough so that "if the sensor is
fast enough" is not true. But I agree with you. TCP RST works
fine for me. Best Regards,

  Marcelo

> Actually, TCP RST is more than just a marketing
> solution. In practice, if the sensor is fast enough, a
> TCP RST can and often will prevent even single packet
> attacks. Here is why...
>
> A TCP RST does not cause orderly connection
> termination. It causes immediate connection
> termination. That is, the protocol stack is not
> required to deliver pending data and typically does
> not. If you also take into consideration that on most
> operating systems, applications are not dispatched
> immediately upon arrival of new data, there is a
> window of opportunity for the protocol stack to
> receive and process the RST even before the
> application can read the previously received data from
> the single packet attack!
>
> On most operating systems, when a process is moved
> from a wait queue to the run queue, it is not given
> immediate control of the CPU unless it has a
> "realtime" priority or the run queue is completely
> empty. Therefore, it will on average have to wait half
> a time slice before it can read its data. A typical
> time slice is 10ms. If the IDS can get the RST sent in
> under 5ms, it can often stop a single packet attack.
> The odds go up if the IDS is faster or the server is
> busy.
>
> >On Tuesday, January 28, 2003, at 08:31 AM, Garbrecht,
> Frederick wrote:
> >
> >> ummmm, just a technical quibble, but a TCP reset
> wouldn't work with the
> >> Sapphire worm because it propagates using UDP as
> transport, not
> >> TCP.....
>
> >It is just a minor quibble because the point is that
> the attack was
> >completely contained in a single packet. The same
> would have held true
> >if it was over a TCP/IP connection. Once the attack
> has been
> >completed, a TCP RST would provide no value. It is
> the proverbial
> >closing the barn doors after the horse is already
> out.
> >
> >RST is largely a marketing solution, not a technical
> solution.
> >
> >Todd
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>

---
UOL, o melhor da Internet
http://www.uol.com.br/

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]