> 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. "
That's not saying a whole lot. You could always get more bandwidth and more servers. That doesn't mean it's not helpful to have a specialized device multiplexing the connections to the servers, and doing more sophisticated analysis of the packets before sending them to the server. > 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. " You are claiming that certain firewalls/load-balancers can't firewall and inspect packets at millions of packets per second. This claim is inconsistent with current data. > 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. " These packets are the same as legit packets, I do not believe a fully effective automated system exists. > 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. " Not really saying a whole lot again. My argument was not that the products you refer to aren't a part of an effective security solution. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Roland Dobbins Sent: Wednesday, July 01, 2009 1:24 AM To: Cisco-nsp Subject: Re: [c-nsp] DNS rewrite & global capabilities 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 <[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/
