Hi Eugene, I think that depends, because you can ping the network address, isn´t? The router should route this kind of packet, if you permit in some access-list any packet to network 172.16.0.0. Remember that use ACL on this case, is only if you have a small network.
On Wed, Jun 6, 2012 at 7:34 PM, Eugene Pefti <[email protected]>wrote: > 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]> > 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] > To: [email protected] > Date: Tue, 5 Jun 2012 19:22:32 +0000 > CC: [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] > To: [email protected] > CC: [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] > To: [email protected] > CC: [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] > To: [email protected] > CC: [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]> 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]> 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 > > > > Are you a CCNP or CCIE and looking for a job? Check out > > www.PlatinumPlacement.com**** > > ** ** > > > > -- > FNK > > _______________________________________________ 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**** > > > > -- > FNK**** > > > > -- > FNK**** > > > _______________________________________________ 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**** > > > _______________________________________________ > 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**** > > ** ** >
_______________________________________________ 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
