1

I work on a web service which could be the target of a denial-of-service attack. We have in place some mitigations against "SYN flood" style attacks. But there are other "application-level" attacks against our service, where a malicious/broken client could repeatedly instruct the web service to perform expensive tasks.

We can identify these abusive clients at the application layer, i.e. in our server processes. Once our process has identified an abusive client connection, we'd like to reduce our level of service to that client.

A naive method would be to terminate the TCP connection with close(2), shutdown(2), or similar. But then the the client can immediately reconnect (up to the connections/second limit set to mitigate SYN floods), and this reconnection is expensive for us due to TLS handshakes and other connection setup costs. We're looking for a way to stop the client interacting with our service for a while, but a clean TCP connection termination does not do this.

However, if our process were able to terminate the TCP connection uncleanly, the abusive client would be delayed for some time before it reconnects, thus providing a "cool off" period. By "unclean termination", I mean closing the TCP connection (both halves of the full-duplex) on the server side, without sending any FIN packet to notify the client of termination, and without sending any further packets referring to that connection. This would delay the client while the client considers the connection still in the ESTABLISHED state (which is 13-30 minutes on Linux).

However, I can't see any way for a UNIX/Linux process to uncleanly terminate a TCP connection. close(2), shutdown(2) and similar all seem to cleanly terminate the connection, and provide no options for an unclean termination.

Does any option exist in UNIX/Linux for immediate, unclean TCP connection termination, as a mitigation to DOS attacks?

Jim Fisher
  • 11
  • 1

2 Answers2

0

What you should be looking into is a firewall and fail2ban. iptables is still pretty much standard for Linux distros and fail2ban will work with most services. What you would want to do is configure fail2ban to monitor a specific log file using a specific regex pattern to know when one of these 'problematic' clients is connecting, then have fail2ban automatically add the firewall rule to either drop or reject the connection. fail2ban is configurable with how to leave the firewall rule so you could block a client for 5-minutes, or 5-days, whatever you want really.

You can also use a web-application firewall (WAF) for this type of stuff too.

As far as a DOS attack is concerned, depending on how it's being done, you may be out of luck with a local firewall and may have to get with your upstream provider to black-hole routes or hosts that are known to be problematic and causing major service disruption. It sounds like you're not in this type of position and just have a potential application layer issues to workaround, so this is overkill.

Andrew
  • 2,142
  • 2
  • 19
  • 25
0

Once our process has identified an abusive client connection, we'd like to reduce our level of service to that client.

Since you've already mentioned that there is cost associated to establish a new connection, I'd recommend you to consider alternate approach than to terminate the connection. May be you can consider to rate limit that connection to 1 byte per minute or something similar. With this approach you can still keep the resources of an attacker busy at minimum cost on your side. If you have more time and want to be creative, redirect all such connections to one server in your environment so that other servers do not waste their open files limit. As Andrew has mentioned, you can also consider using fail2ban once you have confirmed that connection is from attacker and it is safe to ban it for few hours.

Nehal Dattani
  • 581
  • 2
  • 10