Re: Active response... some thoughts.

From: fr0ck9 <fr0ck9(at)yahoo.com>
Date: Wed Feb 05 2003 - 17:42:14 EST

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_saifullah@hotmail.com]
Sent: Monday, February 03, 2003 2:18 PM
To: focus-ids@securityfocus.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_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,
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,
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.....
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
technical
> > solution.
now.
> > http://mailplus.yahoo.com
> >
>
>
> ---
> UOL, o melhor da Internet

---

Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com Received on Wed Feb 5 18:14:37 2003