[c-nsp] DNS rewrite & global capabilities

Maxwell Reid max.reid at saikonetworks.com
Wed Jul 1 21:49:19 EDT 2009


HI Quin & Roland,

It's a known fact that both "state" tracking and bandwidth are finite  
resources... the other finite resource that isn't talked about much is  
dollars for arbor boxes :-) The point I think is to balance the  
architecture in a manner that leaves bandwidth as the final  
bottleneck; at that point toss the "interesting" traffic into a  
sinkhole and filter it, drop it  etc.  but you need to get to that  
point first.

 From a foundation perspective, Roland is correct in stating that a  
well designed and configured server farm floating anycasted IP's can  
handle a load far greater than a single upstream firewall; but often  
times for various reasons a "well designed" server farm includes a mix  
of stateless filtering at the edge of the cluster farm, stateful  
filtering and multiplexing the next level down, and finally enough  
servers to handle the load up until the point of bandwidth  
exhaustion.  Yes, it's multiple "attack points" or layers of potential  
failure, but It's pretty naive to expect people to bolt their systems  
to the Internet  enmasse with Iptables of pf as their primary means of  
access control.

Sinkhole routing is also not a be all end all solution.   
Sophisticated, DDoS prevention is great if your dealing with the  
absolute end target in the chain of a reflection or amplification  
attack.   It even works really well when the "attackers" are using the  
same automated patterns, or scripts, or doing something silly like  
violating protocol rules or behavior. Granted, that will cover about  
90% of the miscreant attacks out there but It's harder to automate  
such a response if the attacks are well distributed and the attacker  
is adhering to know protocol behaviors.... even looking at backscatter  
isn't as reliable an indicator as it used to be.

~Max





On Jun 30, 2009, at 10:24 PM, Roland Dobbins wrote:

>
> On Jul 1, 2009, at 12:09 PM, Quinn Mahoney wrote:
>
>> Without a firewall proxying the tcp connection?  That would depend  
>> on how many servers
>> there are and what the firewalls can handle.  The server never gets
>> traffic from the spoofed addresses with the firewall, or from a
>> load-balancer that multiplex's the tcp connections.
>
> There isn't a firewall made which has the capacity to handle this  
> more efficiently than a well-configured server or server farm.
>
>> I wouldn't say much more efficiently, since more advanced load  
>> balancers
>> and firewalls route via asic's and fpga's.
>
> I certainly would, and do; they none of them run into the mpps, as  
> routers can and do.
>
>> If the packet is the same as a normal request but a spoofed address,
>> you're going to have some trouble even with automated systems looking
>> for no syn/ack, and then hunting the source down and automatically
>> blocking the true sources at the ingress of the upstreams.
>
> Not with appropriate detection/classification/traceback tools.  This  
> isn't new technology.
>
> And blocking at the edges isn't generally accomplished  
> automatically, but manually, upon demand.  Intelligent DDoS  
> mitigation devices can and do black automatically.
>
>> That's even if such an effective system actually existed.
>
> They do, see above.
>
>> While the load-balancer or advanced firewall never sent the  
>> connection to the server, and the
>> device is designed to be able to handle allocating memory for bogus
>> connections.
>
> They never send the legitimate traffic, either, being overwhelmed by  
> the DDoS.
>
> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>
>        Unfortunately, inefficiency scales really well.
>
> 		   -- Kevin Lawton
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/



More information about the cisco-nsp mailing list