I would question line 4 in the ACL below. All IPv4 aware devices normally have validation check and should drop all traffic destined to the network ID address without an ACL.
From: [email protected] [mailto:[email protected]] On Behalf Of Junji Sent: Wednesday, June 06, 2012 6:56 AM To: [email protected] Subject: Re: [OSL | CCIE_Security] Using CAR & uRPF to block flood attack on an interface Hi all, The CERT advisor recommend the following action for Cisco devices in this kind of attack, particular, for me I prefer the first, ACL depends where are your router :-) http://www.cert.org/advisories/CA-1998-01.html By the way, I remember that smurf attack generate several icmp unreachable msg, that´s the way I used to check this kind of attack. Cisco Systems Cisco recommends the following configuration settings as protection against being used as an intermediary in smurf attacks: 1. Disabling IP directed broadcast for all interfaces on which it is not needed. This must be done on all routers in the network, not just on the border routers. The command "no ip directed-broadcast" should be applied to each interface on which directed broadcasts are to be disabled. Very few IP applications actually need to use directed broadcasts, and it's extremely rare for such an application to be in use in a network without the knowledge of the network administrator. Nonetheless, as when any functionality is disabled, you should be alert for possible problems. This is the preferred solution for most networks. 2. If your network configuration is simple enough for you to create and maintain a list of all the directed broadcast addresses in your network, and if you have a well-defined perimeter separating your own network from potentially hostile networks, consider using a filter at the perimeter to prevent directed broadcasts from entering the network. For example, if your network number is 172.16.0.0, and you uniformly use a subnet mask of 255.255.255.0, then you might use Cisco access list entries like 3. access-list 101 deny ip 0.0.0.0 255.255.255.255 172.16.0.255 0.0.255.0 4. access-list 101 deny ip 0.0.0.0 255.255.255.255 172.16.0.0 0.0.255.0 5. Note that this is not a complete access list; it's simply two entries. See the Cisco documentation for more information on configuring access lists. The best place to apply such a filter is usually on the incoming side of each router interface that connects to the potentially hostile network. This solution may be administratively infeasible for networks using variable-length subnet masks, or which have complex external connectivity. There is also some possibility that legitimate directed broadcasts may be being sent into your network from the outside, especially if you're working in a research environment. In addition to these protections against being used as an intermediary in a smurf attack, Cisco recommends that you take steps to prevent users within your own network from launching such attacks. For "stub" networks which do not provide transit connectivity (most corporate and institutional networks, many smaller ISPs), this is usually best done by installing filters at the network perimeter to prevent any packets from leaving your network unless their IP source addresses actually lie within your network's address space. For the example network above, you might place the following entry in the incoming access lists on the interface(s) facing your internal network: access-list 101 permit ip 172.16.0.0 0.0.255.255 0.0.0.0 255.255.255.255 access-list 101 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 Regards On Tue, Jun 5, 2012 at 6:25 PM, Elizabeth .... <[email protected]<mailto:[email protected]>> wrote: Kings, Back to your original question - How to block smurf attacks on an interface other than using "no ip directed-broadcast" and no ACL. Well I think you might use two methods: 1. uRPF - use the ip verify unicast reverse-path command on the input interface on the router at the upstream end of the connection. The router will verify that it has a reverse path for the spoofed ICMP packet and drop the packet if no path exists. CEF must be enabled 2. Use CAR to rate limit ICMP packets - if ping must be allowed, you can limit the amount of ICMP traffic. have a look at the following Cisco Doc http://www.cisco.com/en/US/tech/tk59/technologies_white_paper09186a0080174a5b.shtml Regards, Elizabeth ________________________________ From: [email protected]<mailto:[email protected]> To: [email protected]<mailto:[email protected]> Date: Tue, 5 Jun 2012 19:22:32 +0000 CC: [email protected]<mailto:[email protected]> Subject: Re: [OSL | CCIE_Security] Blocking flood attack on an interface Oh, no CCIE Number that you actually passed!!!!! Just Blah, blah .... What a waist of space .... ________________________________ Date: Tue, 5 Jun 2012 15:10:53 -0400 Subject: Re: [OSL | CCIE_Security] Blocking flood attack on an interface From: [email protected]<mailto:[email protected]> To: [email protected]<mailto:[email protected]> CC: [email protected]<mailto:[email protected]> Gents I am sorry about this episode that we are having here in this thread. It could be the time of month :) makes me laugh that I am being demanded to provide my number. I think I should post my plague once I receive it. There won't be any more reply from my side on this topic. I am sorry again. On Tuesday, June 5, 2012, Elizabeth .... wrote: Well, what a waist of time & space to discuss with you ... What's your CCIE number, that you can really prove that you'd passed the Lab!!!! Please do not replay!!! Regards, Elizabeth ________________________________ Date: Tue, 5 Jun 2012 14:17:29 -0400 Subject: Re: [OSL | CCIE_Security] Blocking flood attack on an interface From: [email protected]<mailto:[email protected]> To: [email protected]<mailto:[email protected]> CC: [email protected]<mailto:[email protected]> It's not my comments which are abusive. Its yours and It's you who is ignorant and probably jealous as well. A lot of ppl on this forum know me personally and virtually and they know what I meant by comments. Keep your retardness to yourself and Bring something useful to this forum. Iam on this forum for sometime and am trying to work with various people to make it better. When you have no idea what others meant then keep your reply to your self. Visit various pathetic forums and see what those wanna bees are discussing. Goto Cisco website and see where Cisco announced about v4 and then see the comment of user who asked, "how many 'lab' in this new version 4" Do you have any idea what hat user was asking about? You wouldn't know I bet. Enough said. On Tuesday, June 5, 2012, Elizabeth .... wrote: Fawad, No need for your abusive commends.... It's been just 5 - 6 days since you passed your exam, and now what are you such an expert .... So, if you do not have respect for others, maybe it would be better that you abstain for posting on this forum!!! Regards, Elizabeth ________________________________ Date: Tue, 5 Jun 2012 09:37:55 -0400 From: [email protected]<mailto:[email protected]> To: [email protected]<mailto:[email protected]> CC: [email protected]<mailto:[email protected]> Subject: Re: [OSL | CCIE_Security] Blocking flood attack on an interface A lot depends on the question. It would be mentioned in he question how to resolve it, there would be some clear hints. Don't believe on the answers posted on the forums for floating questions. A lot of those wanna bees are pretty down low in technology and they are just posting anything that would come to their mind. On Tuesday, June 5, 2012, Kingsley Charles wrote: Not ACL but some interface command should be the answer. I just saw this question floating... With regards Kings On Tue, Jun 5, 2012 at 2:58 PM, Matt Hill <[email protected]<mailto:[email protected]>> wrote: Off the top of my head... An ACL with the broadcast address as the destination? (???) Cheers, Matt CCIE #22386 CCSI #31207 On 5 June 2012 18:03, Kingsley Charles <[email protected]<mailto:[email protected]>> wrote: > Hi all > > How do we block smurf attacks on an interface other than using "no ip > directed-broadcast"? I can't think of any other commands. > > > With regards > Kings > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com<http://www.ipexpert.com> > > Are you a CCNP or CCIE and looking for a job? Check out > www.PlatinumPlacement.com<http://www.PlatinumPlacement.com> -- FNK _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com<http://www.ipexpert.com> Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com<http://www.PlatinumPlacement.com> -- FNK -- FNK _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com<http://www.ipexpert.com> Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com<http://www.PlatinumPlacement.com> _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com<http://www.ipexpert.com> Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com<http://www.PlatinumPlacement.com>
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
