[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Synproxy still needed with max-src-conn-rate ???
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.