I've implemented a means of distributing the www.sco.com/32 or any other DDoS destination network block around my own AS and blocking it by routing to null on the edge routers. no need to update heaps of routers at the edge and when the attack its over simple to restore connectivity to DDoS destination.
Basically. (relies on having BGP on all edge routers). Advertise the destination that is getting DDoS etc in BGP as a longer prefix (if it's more then a /32 make sure you think about load balanced servers, block the range). Set next-hop to RFC1918 address (assuming you route it to null on the edge routers). Make sure you filter the routes out to your ebgp neighbors besides they really shouldn't be accepting /32's anyway right? ;). Benefit is that any DDoS traffic will be dropped at edge, (keeping core happy, and upstream/wan/peer links low :) ). disadvantage, zero connectivity to that blocked destination. (Otherwise you could always play with some table-map function and do some fancy rate-limit base policies via BGP distribution with specific community string). Regards Phillip On Fri, 30 Jan 2004, bcm wrote: > Is anyone taking any special precautions given the potential for a sudden increase > in aggregate packets per second across your networks come Sunday afternoon when the > original Mydoom virus enters into its DOS phase? > > Does anyone know if the virus' assault will be slowed if it is unable to reach > www.sco.com? I am hoping that if it cannot reach SCO's site that the HTTP GET > command will be slow in returning, effectively reducing the volume of traffic a > single PC is capable is generating. I am having a difficult time artificially > forcing the virus to start its attack in a lab environment, so I am unable to > confirm this. > > Any input would be appreciated. Thanks! > >