Slow HTTP DOS Attack

[dross]

Our customer is having problems with Slow HTTP DOS (denial of service) attacks. They would like to know if there is any way of mitigating this.

I have checked the knowledge base and splash and can't find anything.

I have advised them of the following;

Reject / drop connections with HTTP methods (verbs) not supported by the URL.

Catalogs | Protection | HTTP Specific Settings

Limit the header and message body to a minimal reasonable length. Set tighter URL-specific limits as appropriate for every resource that accepts a message body.

Catalogs | Protection | HTTP Specific Settings

Set an absolute connection timeout, if possible. Of course, if the timeout is too short, you risk dropping legitimate slow connections.

Virtual Server | Connection Management | Timeout Settings

connect_timeout

keepalive_timeout

timeout

max_transaction_duration

Is there any way of performing the following;

"The backlog of pending connections allows the server to hold connections it’s not ready to accept, and this allows it to withstand a larger slow HTTP attack, as well as gives legitimate users a chance to be served under high load."

The main way the SteelApp protects against Classic DOS attacks is using Rate Shaping and Service Protection. However, these are mostly based around max numbers of connections or large amounts of bandwidth, there is not as much to do with minimum rates.

I have raised a support ticket and they advised the following;

I have raised a case with Support and they have advised the following;

We do have an open feature request to add a configuration option for something that will counter such attacks.

An option could be to use a configuration key (added in 9.6) at the virtual server level, max_transaction_duration, to specify the maximum duration of a transaction, regardless of whether data is being sent over the connection.  If this time is exceeded, the client connection will be closed. This value can be overridden on a per-request level using the new TrafficScript function request.setMaxTransactionDuration.  The currently active value can be queried in TrafficScript with request.getMaxTransactionDuration.  This way you can dynamically set timeouts, based on given criteria, using a TrafficScript rule.  Some examples are shown in the TrafficScript Guide.

The WebApp Firewall primarily focuses on vulnerabilities listed by OWASP (https://www.owasp.org/index.php/Main_Page) so would not be of any use for this type of attack.

Does anybody else have any suggestions about how to mitigate these attacks?

[krap_rz]

Have you take a step back and relook the network level setup? If the source of attack from certain network address perhaps firewall can blocked it.

If its random, try to look into users-agent or try to implement https (ssl to steelapp, http to backend).

[aannavarapu]

Hi Duncan

Your suggestions are spot-on with respect to the timeouts. The timeout setting is best recommended to be set to a little greater than the average of the legitimate connections. However, this does not guarantee a complete mitigation of the attacks. A combination of timeouts, header & body size limits etc will help prevent a majority of such attacks.

In addition to the HTTP specific timeout settings, use traffic script checks for any attack specific patterns such as user-agent or urls or any other repetitions of the header values for new connections in a short time.

Regards,

Arun

[sameh]

Are you talking about the "slowloris" DoS? Slowloris (software) - Wikipedia, the free encyclopedia

If so, it should not affect the backend servers since STM will buffer the request before passing it to the backend.

Whenever under attack, check first if you can find a simple pattern: same request header, same originating IP, same URI, that you would be able to block before it causes ressource starvation.

[aannavarapu]

Hi Duncan

Do you have any more updates on this query?

Regards,

Arun