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

Reply via email to