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_limauol.com.br>
To: <b_paul_palmeryahoo.com>
Cc: <focus-idssecurityfocus.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/
>
>

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