Being that UDP is connectionless, a rst will not have
an effect. If the IDS has the ability to do an ICMP
Unreachable, then you might be able to affect the
attacking device.

-----Original Message-----
From: Ali Saifullah Khan
[mailto:ali_saifullahhotmail.com]
Sent: Monday, February 03, 2003 2:18 PM
To: focus-idssecurityfocus.com
Subject: Re: Active response... some thoughts.

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/
>
>

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

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