On Fri, Jan 8, 2010 at 10:48 AM, Joe Greco <jgreco@ns.sol.net> wrote:
Putting a stateful firewall in front of that would be dumb; the server is completely capable of coping with the superfluous SYN's in a much more competent manner than the firewall.
The trouble with blanket statements about "all stateful firewalls" and "all servers" is there are lots of different firewall and server platforms. Stateful firewalls can implement SYN cookies, and at least a couple do. Firewalls do not need to build a state entry for partial TCP sessions, there are a few different things that can be done, such as the firewall answering on behalf of the server (using SYN cookies) and negotiating connection with the server after the final ACK. As a result, spoofed TCP packets don't consume state. Multiple IPs they can _receive_ traffic to required, next? Spoofed UDP is a much bigger problem, because there is no connection establishment. And it's probably not sane to put certain public-facing UDP services such as large public DNS service IPs (e.g. 8.8.8.8) behind most forms of stateful filter. But that's not the average case, by any means, most servers are not DNS servers. Servers consume state just like firewalls do.... E.g. A public FTP server that opens a process for each connection, goes down in a connection flood, when kernel process slots are used up, long before the firewall. Servers running a robust OS completely and correctly configured to perfectly protect themsleves (resource limits, etc), no Windows OSes, with unwanted open ports, is a wholly unwarranted assumption for real-world server environments. In the best cases it does hold up (to a great extent). In other cases, it's an operational fantasy; it would be nice if that could be relied upon.... --- -J