On Fri, Aug 26, 2005 at 02:01:55PM -0700, [EMAIL PROTECTED] wrote: > Man I love replying to my own posts. I think I should ask the real > question, does synproxy work because it's only looking for a SYN followed > by a SYN+ACK, so therefore 2 SYN's from the same source IP would be denied > ? If so in that case it's a different animal than max-src-con-rate, which > makes more sense.
The two features can be used separately and together, I'm not sure how you mean one would make the other superfluous. One scenario is an external host sending you a flood of spoofed SYNs. It won't be able to complete the TCP handshake (as it won't get your replies). Since the handshakes don't complete, max-src-conn-rate does not limit anything in this case (it only applies to connections who completed the handshake). But synproxy will filter those SYNs from reaching your real server. Another scenario is an external host flooding you with non-spoofed connections, completing each handshake, causing a massive load of concurrent connections. In this case, synproxy doesn't help protecting the real server, as the external host IS completing the handshakes. But max-src-conn-rate allows you to limit how many connection the external host may establish per second. Maybe you assumed that synproxy would prevent multiple concurrent connections from the same peer. It doesn't. The peer can simultanously establish many connections. synproxy merely delays handing over the connections to the real server while each individual handshake hasn't completed. Multiple handshakes may be ongoing at the same time. So, no, max-src-conn-rate doesn't make synproxy less useful nor the other way around, and using both together is not 'overkill'. Of course, neither NEEDS the other to work, either. Daniel
