I am learning about DDOS and the techniques to mitigate it. TCP Keepalive is used to check if the other host is still up and if the host does not acknowledge the tcp keep alive message, the connection is terminated.

I am wondering if these messages can be used to mitigate DDOS attacks. The server under attack can reduce the time in which it contacts the client whether it is still up or not. The server can use Unicast Reverse path forwarding to prevent IP spoofing and if the attack is being done from legitimate hosts using botnets, can the server use tcp's keepalive message technique in anyway to close the dead connections and prevent itself from being DDOSed ? Is there a way to detect TCP half open connections and close them using tcp keep alive?

  • I have read something along these lines (in fact, I think, going further and putting inbound connections in a WAIT state so that the attacking botnet runs out of resources - reflection attacks aren't usually well designed), but the reality is that DDOS attacks are better handled upstream by dedicated systems and simply absorbed rather than reflected. Mar 17 '18 at 9:05

DDOS is a very broad term and includes a variety of attacks. TCP keep alive is only relevant for already established TCP connections, which usually excludes attacks using IP spoofing in the first place. This means that it is not relevant for the majority of DDOS attacks which are attacks using a high bandwidth (like amplification attacks using spoofed IP addresses) or SYN flooding.

This leaves attacks like Slowloris which try to tie resources on the servers by keeping many connections open or attacks which do a proper TCP handshake from a user space application and then abandon the connection without closing. TCP keep alive would not work against the first since there is a proper client which replies as expected to TCP keep alive. It might help with a naive implementation in the second case but this could be modified to handle TCP keep alive too without using more memory.

In short: it might help for very specific and rare kinds of DDOS. But even for this DDOS it might be more effective to use instead an idle timeout on the connections and adapt the timeout dynamically depending on the number of open connections and the specific state of the connection. This would probably cover more kind of attacks.


Your machine has no way of knowing whether the source IP address of a packet was spoofed. To a first approximation, RPF only applies to routers. If you have multiple interfaces to multiple upstream providers, it will cut down the traffic by a factor of N, where N is the number of interfaces, of course; how many upstreams do you have?

TCP KEEPALIVE has nothing to do with this. You may be thinking of tcp syn cookies, which you can enable with an appropriate sysctl option.

All this is mostly irrelevant anyway, except if your threat model is a couple of kids with nothing else to do. DDOS attacks, for a very long time now, simply clog your incoming pipe. It doesn't matter whether your machines can stay up if there is no link capacity left for them to receive any useful traffic!

If you are really worried about a determined attacker, you'll need protection from your upstream provider, and in more serious cases from a dedicated anti-ddos service (easy to find, I do not want to promote any particular one).

Hope this helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.