The server alone handles a syn attack much better, 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.
> Also they obviously block traffic, which is a security benefit. "So do stateless ACLs in hardware - much more efficiently." I wouldn't say much more efficiently, since more advanced load balancers and firewalls route via asic's and fpga's. > Also, what if the attack has spoofed source addresses, and is > evasive of > profiling. In other words, what are you going to null route. The > ingress path of the attack packets would have to be traced and cut off > at the border of upstream providers, killing legit traffic as well. " Appropriate detection/classification/traceback tools and S/RTBH handle most of this; the rest is where intelligent DDoS mitigation capabilities come into play. Stateful firewalls don't do this, and the stateful part is what makes them fall down. " 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. That's even if such an effective system actually existed. 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. " Again, they a) don't do what you're asserting they do and b) don't scale. This isn't a matter of opinion, it's a matter of operational experience and fact. Putting stateful firewalls in front of servers is both unnecessary and counterproductive. " Microsoft.com runs without a stateful firewall. However that wasn't my argument. My argument was the claims you made depend on the level and type of attack, and that the arbor networks system is not effective in all situations. Hence the one size fits all solution is not adequate in all situations, and the solution is not always effective. Anyways I have always been impressed with their products. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Roland Dobbins Sent: Wednesday, July 01, 2009 12:10 AM To: Cisco-nsp Subject: Re: [c-nsp] DNS rewrite & global capabilities On Jul 1, 2009, at 11:02 AM, Quinn Mahoney wrote: > irewalls do have features, > for instance, they can proxy a tcp-syn connection and not send it to > the > server if it doesn't get an ack. Doesn't scale. Server alone handle this much better, even without syn- cookies. > Also they obviously block traffic, which is a security benefit. So do stateless ACLs in hardware - much more efficiently. > Also, what if the attack has spoofed source addresses, and is > evasive of > profiling. In other words, what are you going to null route. The > ingress path of the attack packets would have to be traced and cut off > at the border of upstream providers, killing legit traffic as well. Appropriate detection/classification/traceback tools and S/RTBH handle most of this; the rest is where intelligent DDoS mitigation capabilities come into play. Stateful firewalls don't do this, and the stateful part is what makes them fall down. > An advanced firewall or load balancer (that multiplex's the > connections) would be able to mitigate this attack. Again, they a) don't do what you're asserting they do and b) don't scale. This isn't a matter of opinion, it's a matter of operational experience and fact. Putting stateful firewalls in front of servers is both unnecessary and counterproductive. ----------------------------------------------------------------------- Roland Dobbins <[email protected]> // <http://www.arbornetworks.com> Unfortunately, inefficiency scales really well. -- Kevin Lawton _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
