RE: Active response... some thoughts.

["Brian Laing" <Brian.Laing () Blade-Software com>]

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_lima () uol com br] 
Sent: Friday, January 31, 2003 8:35 AM
To: b_paul_palmer () yahoo com
Cc: focus-ids () securityfocus 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/