Hi Ali,
        No, it would have no effect. This is why IDS's that are doing
active response against UDP send ICMP error messages back to the client
for "connections" it's trying to kill. Pretty much any IDS that does
active response against UDP attacks works this way.

Thanks,
Abe

--
Abe L. Getchell
Security Engineer
abegetchellqx.net
> -----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/
> >
> >
> 

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