Re: Active response... some thoughts.

["Ali Saifullah Khan" <ali_saifullah () hotmail com>]

Todd's question still remains. I'm sure you tried to clear it out, but does
a "TCP" RST have any effect on "UDP"-oriented connections ?
We're dealing with 2 different protocols here. The protocol behind the RST
packet being TCP raises the previous question, and that's what we're trying
to figure out here.

----- Original Message -----
From: mb_lima <mb_lima () uol com br>
To: <b_paul_palmer () yahoo com>
Cc: <focus-ids () securityfocus com>
Sent: Friday, January 31, 2003 9:34 PM
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/