From: David Redfern \(AU\) (David.Redfern@didata.com.au)
Date: Sun Aug 20 2006 - 22:18:39 ART
Only problem I see is with the icmp echo-reply lines.
deny icmp any 0.0.0.255 255.255.255.0 echo-reply
deny icmp any 0.0.0.0 255.255.255.0 echo-reply
If you are the end target of the attack receiving echo-replies from the
reflector network then this echo reply would/could be destined for host
addresses in your network. A server for example the DOS is targeting.
The acl only block echo-replies to the 0 or 255 address, which is not
where the target will be.
Maybe you have to block icmp any any echo-reply coming in but this this
stops you from being able to ping the backbone. Only way around this I
know is to to a reflective acl.
If you get an answer to this one please let me know
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Peter Plak
Sent: Monday, 21 August 2006 7:47 AM
To: Aamir Aziz
Cc: ccielab@groupstudy.com
Subject: Re: ICMP Flooding vs SMURF Attack
Is it possible to have a udp with source echo, sourced from the network
(
x.x.x.0) or broadcast (x.x.x.255)?
The source udp echo is probably from the reflector, so it's replied to
the destination network or broadcast I would presume.
Then I would say for the udp streams it's:
deny udp any 0.0.0.255 255.255.255.0 eq echo deny udp any 0.0.0.0
<http://0.0.0.255/> 255.255.255.0 eq echo deny udp any eq echo
0.0.0.255 255.255.255.0 deny udp any eq echo 0.0.0.0 <http://0.0.0.255/>
255.255.255.0
gr
On 8/20/06, Aamir Aziz <aamiraz77@gmail.com> wrote:
>
> Yes i agree with you that the UDP source is missing here, but the
> question is what is most suitable or lets say what is required in the
> lab, how about if we go for something like this:
>
> deny icmp any 0.0.0.255 255.255.255.0 echo deny icmp any 0.0.0.0
> 255.255.255.0 echo deny icmp any 0.0.0.255 255.255.255.0 echo-reply
> deny icmp any 0.0.0.0 255.255.255.0 echo-reply deny udp any 0.0.0.255
> 255.255.255.0 eq echo deny udp 0.0.0.255 255.255.255.0 eq echo any
> deny udp any 0.0.0.0 255.255.255.0 eq echo deny udp 0.0.0.0
> 255.255.255.0 eq echo any permit ip any any
>
> this one makes any sense?
>
> Thanks
> Aamir
>
> > >
>
>
> On 8/20/06, Peter Plak <plukkie@gmail.com> wrote:
> >
> > Hi Aziz,
> >
> > I have also spent lot of time to this task. I found a link which
> > enters the explanation of smurf / fragle and protection best so far.
> >
> > http://www.windowsecurity.com/whitepaper/Characterizing_and_Tracing_
> > Packet_Floods_Using_Cisco_Routers.html
> >
> > <http://www.windowsecurity.com/whitepaper/Characterizing_and_Tracing
> > _Packet_Floods_Using_Cisco_Routers.html+>
> >
> > If I look at your list, I would say, almost there. What in my
> > opinion misses is the udp source eq echo.
> > I would replace the udp lines with any any. Cause udp echo is rarely
> > used nowadays, it's likely that you will have many hits compared to
icmp.
> >
> > So, I think the list totally will be then:
> > deny icmp any 0.0.0.255 255.255.255.0 echo deny icmp any 0.0.0.0
> > 255.255.255.0 echo deny icmp any 0.0.0.255 255.255.255.0 echo-reply
> > deny icmp any 0.0.0.0 255.255.255.0 echo-reply deny upd any any eq
> > echo deny upd any eq echo any permit ip any any
> >
> > What you think?
> >
> >
> > On 8/20/06, Aamir Aziz < aamiraz77@gmail.com > wrote:
> >
> > > Hi there ppl
> >
> > I just wanted to clear something, if the tast says that certain
> > router is experiencing attack via ICMP and UDP flooding does it mean
> > SMURF ATTACK?
> >
> > and would the following ACL work to mitigate this flooding issue?
> >
> > deny icmp any 0.0.0.255 255.255.255.0 echo deny icmp any 0.0.0.0
> > 255.255.255.0 echo deny icmp any 0.0.0.255 255.255.255.0 echo-reply
> > deny icmp any 0.0.0.0 255.255.255.0 echo-reply deny upd any
> > 0.0.0.255 255.255.255.0 echo deny upd any 0.0.0.0 255.255.255.0 echo
> > permit ip any any
> >
> > Thanks
> > Aamir
> >
> > ____________________________________________________________________
> > ___ Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Sep 01 2006 - 15:41:57 ART