RE: ICMP Flooding vs SMURF Attack

From: Victor Cappuccio (cvictor@protokolgroup.com)
Date: Tue Aug 22 2006 - 00:29:24 ART


Hi, I would do this

interface Serial0/0
 rate-limit input 16000 2500 2500 conform-action transmit exceed-action drop
 priority-group 1

R2#show run | in access-list 101
access-list 101 permit icmp any 0.0.0.255 255.255.255.0 echo log
access-list 101 permit icmp any 0.0.0.0 255.255.255.0 echo log
access-list 101 permit udp any 0.0.0.255 255.255.255.0 eq echo log
access-list 101 permit udp any 0.0.0.0 255.255.255.0 eq echo log
R2#show run | in access-list 102
access-list 102 permit tcp any any eq bgp
access-list 102 permit tcp any eq bgp any

Victor.-

-----Mensaje original-----
De: nobody@groupstudy.com [mailto:nobody@groupstudy.com] En nombre de Dusty
Enviado el: Lunes, 21 de Agosto de 2006 11:10 p.m.
Para: David Redfern (AU)
CC: Peter Plak; Aamir Aziz; ccielab@groupstudy.com
Asunto: Re: ICMP Flooding vs SMURF Attack

Group,

This is a very interesting discussion. Let's change the direction a bit.

Here is my scenario for smurf attack:
Configure the external interface (s0/0) to protect smurf attack from the
internet. Allow 16kps bandwidth and burst up to 1/4 of the rate. However,
you need to prioritize your bgp routing protocol.

Let see who can configure this scenario.

Dusty

On 8/21/06, David Redfern (AU) <David.Redfern@didata.com.au> wrote:
>
> Peter,
>
> I agree that there probably is further clues in the question. Eg, log
> icmp flood/smurf attack. Everything I can find on an 'icmp flood
> attack' indicates it uses unicast icmp echo's rather than echo-replies,
> which the smurf reply uses. If i was trying to log an icmp/smurf
> attack, i'd maybe add that too.
>
>
>
>
> permt icmp any 0.0.0.255 255.255.255.0 echo log
> permit icmp any 0.0.0.0 255.255.255.0 echo log
> permit udp any 0.0.0.255 255.255.255.0 eq echo log
> permit udp any 0.0.0.0 255.555.255.0 eq echo log
> permit icmp any any echo-reply log
> permit upd any eq echo any log
> permit icmp any any echo log
>
>
> First four lines are for smurf/fraggle reflector network, lines 5 and 6
> are for smurf/fraggle echo-replies to ANY end target on your network,
> last line is for icmp flood to ANY host in your network.
>
>
> Let me know what you think of the above acl for logging icmp/smurf
> attacks and if you think im missing something?
>
>
>
>
> ________________________________
>
> From: Peter Plak [mailto:plukkie@gmail.com]
> Sent: Monday, 21 August 2006 8:09 PM
> To: Aamir Aziz
> Cc: David Redfern (AU); ccielab@groupstudy.com
> Subject: Re: ICMP Flooding vs SMURF Attack
>
>
> not 100% sure anymore about syntax of udp I did:
>
> acl 130 permit icmp any 0.0.0.0 <http://0.0.0.0/> 255.255.255.0
> <http://255.255.255.0/> echo log-input
> acl 130 permit icmp any 0.0.0.0 <http://0.0.0.0/> 255.255.255.0
> <http://255.255.255.0/> echo-reply log-input
> acl 130 permit icmp any 0.0.0.255 <http://0.0.0.255/> 255.255.255.0
> <http://255.255.255.0/> echo log-input
> acl 130 permit icmp any 0.0.0.255 <http://0.0.0.255/> 255.255.255.0
> <http://255.255.255.0/> echo-reply log-input
> acl 130 permit udp any 0.0.0.0 <http://0.0.0.0/> 255.255.255.0
> <http://255.255.255.0/> eq echo log-input
> acl 130 permit udp any 0.0.0.255 <http://0.0.0.0/> 255.255.255.0
> <http://255.255.255.0/> eq echo log-input
> acl 130 permit udp any eq echo 0.0.0.0 <http://0.0.0.255/>
> 255.255.255.0 <http://255.255.255.0/> log-input
> acl 130 permit udp any eq echo 0.0.0.255 <http://0.0.0.255/>
> 255.255.255.0 <http://255.255.255.0/> log-input
> permit ip any any
>
>
> On 8/21/06, Aamir Aziz <aamiraz77@gmail.com> wrote:
>
> Peter,
>
> You said you lost points, what was ur ACL in the exam, I mean
> what did u put?
>
> Thanks
>
> Aamir
>
>
>
> On 8/21/06, Peter Plak <plukkie@gmail.com> wrote:
>
> David,
>
> You're 100% right about missing the unicast replies in
> the .255 and .0 subnets. But the correct answer is maybe hide in the
> question.
> My exam question was titled "log icmp attack / smurf
> attack".
>
> Smurf is often an attack to those .255 and .0 addresses.
> ICMP flooding often just to a unicast.
> Fragle with udp.
>
> So again, it's unsure what they want to see.
> In my question, I had to only log. My list was not
> allowed to block.
> I did not log icmp to unicast addresses, and i also
> logged udp. Maybe that;s why I didn't get the points.
>
> gr
>
>
>
> On 8/21/06, David Redfern (AU)
> <David.Redfern@didata.com.au > wrote:
>
>
> Only problem I see is with the icmp echo-reply
> lines.
>
> deny icmp any 0.0.0.255 <http://0.0.0.255/>
> 255.255.255.0 <http://255.255.255.0/> echo-reply
> deny icmp any 0.0.0.0 <http://0.0.0.0/>
> 255.255.255.0 <http://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 <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 <http://0.0.0.255/>
> 255.255.255.0 <http://255.255.255.0/> eq echo deny udp any 0.0.0.0
> <http://0.0.0.0/>
> < http://0.0.0.255/ <http://0.0.0.255/> >
> 255.255.255.0 <http://255.255.255.0/> eq echo deny udp any eq echo
> 0.0.0.255 <http://0.0.0.255/> 255.255.255.0
> <http://255.255.255.0/> deny udp any eq echo 0.0.0.0 <http://0.0.0.0/>
> <http://0.0.0.255/>
> 255.255.255.0 <http://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 <http://0.0.0.255/>
> 255.255.255.0 <http://255.255.255.0/> echo deny icmp any 0.0.0.0
> <http://0.0.0.0/>
> > 255.255.255.0 <http://255.255.255.0/> echo
> deny icmp any 0.0.0.255 <http://0.0.0.255/> 255.255.255.0
> <http://255.255.255.0/> echo-reply
> > deny icmp any 0.0.0.0 <http://0.0.0.0/>
> 255.255.255.0 <http://255.255.255.0/> echo-reply deny udp any 0.0.0.255
> <http://0.0.0.255/>
>
> > 255.255.255.0 <http://255.255.255.0/> eq echo
> deny udp 0.0.0.255 <http://0.0.0.255/> 255.255.255.0
> <http://255.255.255.0/> eq echo any
> > deny udp any 0.0.0.0 <http://0.0.0.0/>
> 255.255.255.0 <http://255.255.255.0/> eq echo deny udp 0.0.0.0
> <http://0.0.0.0/>
> > 255.255.255.0 <http://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
> <mailto: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
> <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 <http://0.0.0.255/>
> 255.255.255.0 <http://255.255.255.0/> echo deny icmp any 0.0.0.0
> <http://0.0.0.0/>
> > > 255.255.255.0 <http://255.255.255.0/> echo
> deny icmp any 0.0.0.255 <http://0.0.0.255/> 255.255.255.0
> <http://255.255.255.0/> echo-reply
>
> > > deny icmp any 0.0.0.0 <http://0.0.0.0/>
> 255.255.255.0 <http://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 <http://0.0.0.255/>
> 255.255.255.0 <http://255.255.255.0/> echo deny icmp any 0.0.0.0
> <http://0.0.0.0/>
> > > 255.255.255.0 <http://255.255.255.0/> echo
> deny icmp any 0.0.0.255 <http://0.0.0.255/> 255.255.255.0
> <http://255.255.255.0/> echo-reply
> > > deny icmp any 0.0.0.0 <http://0.0.0.0/>
> 255.255.255.0 <http://255.255.255.0/> echo-reply deny upd any
> > > 0.0.0.255 <http://0.0.0.255/> 255.255.255.0
> <http://255.255.255.0/> echo deny upd any 0.0.0.0 <http://0.0.0.0/>
> 255.255.255.0 <http://255.255.255.0/> echo
>
> > > permit ip any any
> > >
> > > Thanks
> > > Aamir
> > >
> > >
> ____________________________________________________________________
> > > ___ Subscription information may be found
> at:
> > > http://www.groupstudy.com/list/CCIELab.html
>
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> ************************************************************************
> ******
> - NOTICE FROM DIMENSION DATA AUSTRALIA
> This message is confidential, and may contain
> proprietary or legally privileged information. If you have received
> this email in error, please notify the sender and delete it immediately.
>
>
> Internet communications are not secure. You
> should scan this message and any attachments for viruses. Under no
> circumstances do we accept liability for any loss or damage which may
> result from your receipt of this message or any attachments.
>
> ************************************************************************
> ******
>
> _______________________________________________________________________
> 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:58 ART