Re: smurf attacks and other DOS attacks

From: istong@stong.org
Date: Mon Jan 16 2006 - 13:08:20 GMT-3


Presumably if you control your boundary router and place
this command on it to prevent it from becoming a
reflector - you never get to the next step which is your
targets getting flooded with ICMP. Secondary measures
(in the event the attack originates inside your network or
somehow gets past your boundary) should include some
of the other items I mentioned previously.

Thanks,

Ian
http://ccie4u.com
Rack Rentals starting at only $12 before discount

> no ip directed broadcast will stop you from becoming a
> reflector for a smurf attack, but will not help if you are
> the target of the attack, as the target of a smurf attack
> gets a flood of ICMP echo-reply packets, typically aimed
> at one or more unicast addresses within the target
> network.
>
> Chris
>
>
> On 1/16/06, istong@stong.org <istong@stong.org> wrote:
> >
> > One simple way to address those types of DOS attacks is
> > to use "no ip directed broadcast" on your interfaces.
> > You should
> > also consider some of the other best practices at the
> > interface level such as "no ip redirects, no ip
> > unreachable, no ip proxy-arp..."
> >
> > As mentioned it's certainly a good idea to rate limit
> > your ICMP traffic. Unicast RPF is another to consider
> > assuming you don't have asymetric routing. If you have
> > multiple connections as well as
> > asymetric routing then you have to look at loose mode
> > versus strict mode. Often I've seen people just create
> > anti spoof filters using ACLs. I.E. don't allow packets
> > from outside my network to come in with a source IP of
> > my address space and
> > similarly don't allow packets out of my network unless
> > the source IP is that of my address space. Workable if
> > you have a
> > known aggregated address space - not so workable if you
> > don't know all your internal IP spaces or they are not
> > aggregatable
> > into a managable range of addresses.
> >
> >
> > Thanks,
> >
> > Ian
> > http://ccie4u.com
> > Rack Rentals starting at only $12 before discount
> >
> >
> >
> > > If yo uare the victim of a smurf attack, you will be
> > > receiving a large number of icmp echo-replies from
> > > valid source addresses. If you are the victim of a
> > > fraggle attack you will be receiving a large number of
> > > UDP echo replies from valid source addresses.
> > >
> > > unicast RPF does not help here, the best solution is
> > > to rate limit incoming echo replies.
> > >
> > > Chris
> > >
> > >
> > > On 1/15/06, midatlanticnet@gmail.com
> > > <midatlanticnet@gmail.com> wrote: >
> > > > i saw somewhere on this message board a solution to
> > > > Smurf attacks. That solution used 8 lines in an
> > > > extended ACL's permiting ICMP and UDP echo and
> > > echo-reply, then rate limited the ACL using CAR. Here
> > > > > is my mine question: If I want to limit a smurf
> > > > attack to a max of 128K, and normal 8kbps using
> > > > CAR...why not use the "verify unicast" command on
> > > the interface and have that point to a permit any any
> > > > ACL...then rate limit that ACL to the above
> > > parameters. >

Ian Stong
http://www.ccie4u.com
"Rack Rentals and Lab Scenarios starting at only $12"
support@ccie4u.com

_________________________________________

Check your Email accounts at MyEmail.com

Login from home, work, school. Anywhere!



This archive was generated by hypermail 2.1.4 : Wed Feb 01 2006 - 07:45:49 GMT-3