From: Victor Cappuccio (cvictor@protokolgroup.com)
Date: Sun Jul 30 2006 - 03:21:01 ART
Yeap David, you are right about pinging from the BB sorry my bad, And
Thanks: D for the clarification.
But in anyways, look at the Access-list 169 in this link
http://www.cisco.com/en/US/tech/tk59/technologies_tech_note09186a0080149ad6.
shtml#topic12
looks something very similar from the configured access-list in your email.
But there is something that I do not understand, you said that ICMP Echoes
from The BBs could be allowed, if so, then your access-list (line 5) is not
correct.
1 deny icmp any 0.0.0.255 255.255.255.0 echo
2 deny icmp any 0.0.0.0 255.255.255.0 echo
3 deny udp any 0.0.0.255 255.255.255.0 eq echo
4 deny udp any 0.0.0.0 255.555.255.0 eq echo
5 deny icmp any any echo reply ! denying in anyways ICMP
6 deny upd eny eq echo any
7 permit any any
I've read the Jonsoon Thread forwarded by a dude here (sorry man I do not
know what I did with your email, maybe to much coffee today, but thanks in
anyway), and with your contribution and I guess that your access-list (first
4 lines) are correct but line 2 is missing echo-reply as the destination
protocol and line 4 the eq part of the protocol should be in the Source Part
of the Access-list
I think I finally understood what means Directed Broadcasts. (*a, used for
reference below)
0.0.0.255 255.255.255.0 == 192.168.1.255 (The Broadcast of that Address)
0.0.0.0 255.255.255.0 == 192.168.1.0 (The Network of that Address),
BUT In a /24 right???
I've enabled ip directed broadcast to see this stuff working, I have I
pinged from a Remote Side, spoofing the IP Address that is globally
reachable and I have received this:
*Mar 2 21:05:38.544: IP: s=204.12.1.4 (Serial0/0.15), d=200.100.125.0
(Serial0/0.13), g=255.255.255.255, len 100, forward directed broadcast
..((please note that the addresses used here are from my lab, and they are
not from real networks))..
So here we have the Famous Smurf Packet, for the Directed Broadcast Network
And if we apply this access-list
Extended IP access list OhGoD
2 deny icmp any 0.0.0.0 255.255.255.0 echo log-input
5 permit ip any any
To the interface receiving the attack, I receive this log
*Mar 2 21:09:38.552: %SEC-6-IPACCESSLOGDP: list OhGoD denied icmp
204.12.1.4 (Serial0/0.15 ) -> 200.100.125.0 (8/0), 1 packet
But What if we have a /25 ?
That should then be
0.0.0.128 255.255.255.0
0.0.0.128 255.255.255.0 for the fist part of the range. Right?
But what if we have several networks assigned
Say
200.100.1.0/24
200.100.2.0/24
200.100.3.128/25
How could the access-list be elaborated? If my interpretation of the (*a) is
right, I think that more easy is to disable Directed Broadcast in all parts
from the network.
Please bear in mind that I'm not a Native English Speaker, so any
thoughts/ideas/ and flames ;) on this are very welcome!
Thanks again!!
Victor.-
-----Mensaje original-----
De: David Redfern (AU) [mailto:David.Redfern@didata.com.au]
Enviado el: Viernes, 28 de Julio de 2006 10:01 p.m.
Para: Victor Cappuccio; ccielab@groupstudy.com
Asunto: 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