Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Proposal for mitigating DoS attacks

  • From: Alex Bligh
  • Date: Mon Jul 12 18:34:52 1999

Aaron,

> As I am familiar with it, the smurf is generally successful not by flooding
> the target hosts LAN, but rather its upstream network connection. 

Not for any smurf we have yet found - a smurf attack has a 99%
correlation with IRC servers. However, yes, it would be possible
for the perpetrators to orchestrate an automated attack on nodes
upstream of their point of attack. However, this would dissipate
the bandwidth they have available (given a limited input bandwidth
and number of reflectors).

However, remember not all attacks are SMURF.

Also note that blackholing router IP addresses generally does no
harm, esp. if you do peering between loopbacks, beyond the odd starred
out traceroute line.

> Infrastructure to take that one host off of the net quickly isn't going to
> help if its network thats being attacked.  If this proposal becomes widely
> accepted, it will only succeed in getting someone to modify the exploit to
> allow the attacker to input a netmask, randomly flooding every IP sharing
> the same link.  The effect will basically be the same, as far as I can tell.

If they flood more than one IP, yes, you have to blackhole more than
one IP. However, saying a proposal would mitigate less sophisticated
attacks and force more devious attacks is no reason to continue to
allow obvious attacks.
 
> The information that you can trust is that your attacker will cause large
> quantities of ICMP echo-reply (or sometimes UDP) packets to enter your
> network from amplifier source addresses.  The options I see are to either:

Remembering not all attacks are smurf or otherwise reflected attacks:
 
> - - Rate-limit or block ICMP echo-reply traffic, as close to the source as
>   possible.  This may be only at your network ingress, but it might be
>   interesting to see if the backbones really need to allow more than 5-20%
>   of the bandwidth of any link as ICMP echo-reply.

This is far more effective than applying my proposal. But having
"been there done that" (sorry) it's more useful to do both.

This technique is much improved by a separate (lower) rate-limit
per prefix you advertize. This means one party's ICMP response only
gets hit when *they* are attacked, and furthermore you can set the
limit lower. (Consider the case of a provider like, say, UU.net or
Sprint who no doubt receive many Mb/s of ICMP per ingress point
under non-attack conditions - an extra Mb/s of ICMP is enough to
wipe out a T1 customer, so a single ratelimit line is ineffective
for a provider of that size).

> - - Rate-limit or block traffic from amplifier source addresses.  If a
>   significant portion of the 'net were simply unavailable to these networks
>   until they turned off directed-broadcast, they would get fixed much
>   faster.  A BGP RBL-style feed would be the most easily maintainable, but
>   one could even just write a script to take the top 100 off of netscan.org
>   and add them access-lists.

A published list, and the ability to build a 20,000 line ACL for such
ratelimiting already exists. However, the router CPU power to apply
such an ACL is not (to my knowledge) in effect.

-- 
Alex Bligh
GX Networks (formerly Xara Networks)







Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.