From: Sean C. (Upp_and_Upp@hotmail.com)
Date: Sat Jul 29 2006 - 15:33:11 ART
Hi David,
I had posted some info on Smurf Attacks in an earlier posting. It doesn't
directly answer your question, but maybe of value anyway. Also, I can't
stress enough the value of CiscoPress book, Cisco Router Security Firewall:
There was an excellent thread on this last year on GroupStudy. In
particular, Jongsoo did a great job at describing the differences between
smurf-amplifier and the spoofed source-target:
http://shop.groupstudy.com/archives/ccielab/200505/msg00716.html
Also, one of the follow-up emails (from Tim ie: ccie2be) documents the info
from Cisco Router Security Firewall (which is a great book to learn about
various things you might see in the Security section on the lab).
HTH,
Sean
----- Original Message -----
From: "David Redfern (AU)" <David.Redfern@didata.com.au>
To: "Victor Cappuccio" <cvictor@protokolgroup.com>; <ccielab@groupstudy.com>
Sent: Friday, July 28, 2006 7:00 PM
Subject: RE: SMURF ATTACK
Thanks for your feedback Victor,
I can see that the below link has a 2 line acl which rate-limits you
from being either a smurf reflector or end target.
I guess technically if you are asked to prevent your internal network
from smurf attacks then you are, by rate limiting ALL icmp packets.
This looks good for use in the real world.
Although you are affecting not just the attacks specifically but all
icmp traffic, and not by blocking but by rate-limiting.
I also realise that the udp echo is really a 'fraggle attack' but some
some people do refer to it in the same category as a smurf attack.
Rather than go do every router and do a 'no ip directed broadcast', if
you are asked to create an acl on your border router to protect (block)
you from both a smurf or fraggle attacks then I assume that this would
mean your network being used as the reflector (an 'icmp echo' or 'udp
echo' to any or your subnets network or broadcast addresses) or from
being the end smurf victim ('icmp echo-reply' or 'udp echo'(source port)
which could be from any outside source to any target in your network.
Hence I cannot think of another acl which stops you from being the
smurf/fraggle reflector or end target other than the below. Problem is
you cannot ping outside your network if you use this in the lab. But do
you need to, the backbones can still ping you. Do you need to be able to
ping the backbone routes as part of the grading?
I'm am not sure.
Lab requirements may say 'ensure full network connectivity to the
backbone', well you are, just not for icmp originated from internally.
Does grading test pings from internal routers to the backbone. I don't
know. It deftinately tests pings from the backbone to all your internal
networks, which will work with the below acl, which may pass the full
connectivity requirement.
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 udp any 0.0.0.255 255.255.255.0 eq echo
deny udp any 0.0.0.0 255.555.255.0 eq echo
deny icmp any any echo reply
deny upd eny eq echo any
permit any any
I reckon that any question regarding this may be open to interpretation.
As you can see, no one can agree.
You may potentially kill your whole lab, by blocking something that is a
requirement for the grading process.
I guess the bottom line is to ask the proctor to clarify the
requirements of the question, and grading.
After all, the main thing that you KNOW what impact your config will
have. Then work around the requirements of the question and grading
process.
Any thoughts and ideas on this are appreciated!
Regards,
David Redfern
Managed Services Support Engineer
Dimension Data - Global Service Centre
Level 1, 10 Dorcas Street, South Melbourne
+61 3 9626 0887
GSC: 1800 638 457
International: +61 (0)3 9626 0497
david.redfern@didata.com.au
-----Original Message-----
From: Victor Cappuccio [mailto:cvictor@protokolgroup.com]
Sent: Friday, 28 July 2006 11:16 PM
To: David Redfern (AU); ccielab@groupstudy.com
Subject: RE: SMURF ATTACK
Hi David.
Please look at this link
http://www.cisco.com/warp/public/63/car_rate_limit_icmp.html
They use only 2 lines, for the SMURF Attack access-list 102 permit icmp
any any echo access-list 102 permit icmp any any echo-reply
The UDP Part that you have is for Fraggle attacks Please see this post
also http://www.groupstudy.com/archives/ccielab/200604/msg00843.html
Has a great simulation of a Smurf Attack and also Cris Explains the
differences very well
Hope that help
Victor.-
-----Mensaje original-----
De: nobody@groupstudy.com [mailto:nobody@groupstudy.com] En nombre de
David Redfern (AU) Enviado el: Jueves, 27 de Julio de 2006 06:47 p.m.
Para: ccielab@groupstudy.com
Asunto: SMURF ATTACK
Hi Guys,
I've seen a few different acl's for preventing smurf attacks to your
internal network from the backbone.
Although I'm not sure of the best to use.
Just wondering what everyone thinks of one I have come up with below.
The first 4 lines block smurf attacks using my internal network as the
reflector.
(traffic to the network and broadcast address of any of my subnets)
The next 2 lines block my from being the final target of the smurf
attack.
(as this reply could be coming from anywhere and destined to any of my
internal hosts 'any any' is used)
The problem I see is that lines 5 and 6 this will block my internal
pings to the backbone.
Although the backbone can still ping my internal routers so I'm not sure
if this is a problem at all.
What do you guys think.
Can you see any problems with this or is there a better one?
Applied Inbound
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 udp any 0.0.0.255 255.255.255.0 eq echo deny udp
any 0.0.0.0 255.555.255.0 eq echo deny icmp any any echo reply deny upd
eny eq echo any permit any any
************************************************************************
****
*
*
- 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.
************************************************************************
****
*
*
This archive was generated by hypermail 2.1.4 : Tue Aug 01 2006 - 07:13:48 ART