[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