Best practices for HTTP Denial of Service configuration

Question

A security audit has been performed for Sitecore setup.

One of the issues revealed is about "HTTP Denial of Service"

Description:

A malicious user with a computer can send a specially crafted sequence of HTTP packets to mount a Denial of service attack on the server. This will result in legitimate users not being able to access the services.

Test findings:

The website stopped responding during the attack simulation. The auditor simulated the HTTP slow body attack

Recommendation:

Please refer the document in the link to fix the issue. The idea is to configure the HTTP server in a specific manner to time out malicious sessions. https://blog.qualys.com/securitylabs/2011/11/02/how-to-protect-against-slow-http-attacks

Following the link i understand the following settings need to be adjusted for IIS7:

• maxAllowedContentLength, maxQueryString, and maxUrl attributes
• headerLimits to configure the type and size of header your web server will accept.
• Tune the connectionTimeout, headerWaitTimeout, and minBytesPerSecond attributes of the <limits> and <WebLimits> elements to minimize the impact of slow HTTP attacks

What are the best practices to configure above variables? What are your recommendations to identify above attributes? Are these changes likely to affect any of the default functionality in Sitecore backend and how can we avoid those?

Answer 1

Slow HTTP attacks are denial-of-service (DoS) attacks that rely on the fact that the HTTP protocol, by design, requires a request to be completely received by the server before it is processed. If an HTTP request is not complete, or if the transfer rate is very low, the server keeps its resources busy waiting for the rest of the data. When the server’s concurrent connection pool reaches its maximum, this creates a denial of service. These attacks are problematic because they are easy to execute, i.e. they can be executed with minimal resources from the attacking machine.

Microsoft has confirmed the vulnerability in a security bulletin and released software updates. February 2014 Microsoft has released a security bulletin at the following link: MS14-009

Most enterprise sites/datacenters will have DoS defender specialized hardware, firewalls, load balancers, etc. DoS attacks should be blocked just while entering your hosting infrastructure not at the end when request is being processed by web server.

Below are some configuration recommendations that may help preventing DoS attacks (tested with Sitecore 8.1 rev. 160519). Suggested configuration changes will not guarantee 100% protection. I would rather say it will defend from “junior” attackers with limited resources. Requests from let’s say 10000 different locations that bypass configuration limitations and dynamic IP restrictions will put a lot of stress on your web server and eventually cause denial of service.

Request Limits <requestLimits>

Requires Request Filtering feature has to be enabled.

Maximum URL length (Bytes)

• Default value : 4096
• Recommended value : 2048

Maximum query string length (Bytes)

• Default value : 2048
• Recommended value : 1024

Allow unlisted verbs

• Default value : true
• Recommended value : false (Make sure to configure listed verbs)

maxAllowedContentLength

• Default value : 30000000, which is approximately 28.6MB.
• Recommended value : Recommended value for Sitecore setup will vary based on requirements to upload media. For CD server such value can be minimized, while for CM server you may want to upload large size files i.e. have value maximized.

Configuration instructions: https://www.iis.net/configreference/system.webserver/security/requestfiltering/requestlimits

Website <limits>

connectionTimeout

• Default value : 00:02:00 (two minutes)
• Recommended value : 00:00:30

Configuration instructions: https://www.iis.net/configreference/system.applicationhost/sites/sitedefaults/limits

Application host <webLimits>

connectionTimeout (Specifies the time that IIS waits before it disconnects a connection considered inactive).

• Default value : 00:02:00 (two minutes)
• Recommended value : 00:00:30

headerWaitTimeout (Specifies the time that the server waits for all HTTP headers for the request to be received before disconnecting the client.)

• Default value : 00:00:00 (disabled)
• Recommended value : 00:00:30

minBytesPerSecond (Specifies the minimum throughput rate, in bytes, that HTTP.sys enforces when it sends a response to the client. The minBytesPerSecond attribute prevents malicious or malfunctioning software clients from using resources by holding a connection open with minimal data.)

• Default value : 240 bytes
• Recommended value : 500 bytes

Configuration instructions: https://www.iis.net/configreference/system.applicationhost/weblimits

Dynamic IP Restrictions

The Dynamic IP Restrictions Extension for IIS provides IT Professionals and Hosters a configurable module that helps mitigate or block Denial of Service Attacks or cracking of passwords through Brute-force by temporarily blocking Internet Protocol (IP) addresses of HTTP clients who follow a pattern that could be conducive to one of such attacks. When an attack pattern is detected, the module will place the offending IP in a temporary deny list and will avoid responding to the requests for a predetermined amount of time.

Dynamically blocking of requests from IP address based on either of the following criteria:

• The number of concurrent requests.
• The number of requests over a period of time.

Module download and configuration instructions https://www.iis.net/downloads/microsoft/dynamic-ip-restrictions

Answer 2

While I'm sure you'll find a combination of these parameters to work, I would suggest at all costs finding a way to secure the content management server behind a VPN or some form of IP-based security first of all.

If they can't reach the server then the attack has been foiled and your system is additionally more secure against brute-force / poor Sitecore passwords.

I'd be pretty concerned with manipulation of ContentLength, QueryString, and URL properties without extreme testing.

I know in the past I've had to lengthen timeouts to work-around poorly performing Sitecore 7 installs as some operations can be unavoidably slow, so you probably can't go too low with those timeouts.

Answer 3

Your best bet is to keep the values in a config file instead of keeping them in IIS. If you need to change the values, you simply do them in the web.config

<httpRuntime maxQueryStringLength="32768" maxUrlLength="65536"/>

other possibilities as illustrated on microsoft's website:

https://www.iis.net/configreference/system.applicationhost/sites/sitedefaults/limits https://www.iis.net/configreference/system.applicationhost/weblimits

Answer 4

DDoS prevention technology has come a long way since this question was initially asked. The solutions discussed in this Q&A, while insightful, are now largely irrelevant, thanks to modern WAF/CDN technologies. In most cases, it is now entirely sufficient to handle DDoS prevention at the edge rather than at the origin.

Modern DDoS prevention looks like:

1. Securing sensitive / private endpoints via IP restriction or services such as Cloudflare Zero Trust.
2. Proxying traffic through WAF/CDN services such as Azure Frontdoor or Cloudflare.
3. Reducing attack surface by only allowing traffic via the WAF/CDN proxy. In other words, ensuring that all website domains and subdomains are routed through a proxy, and configuring the server and its associated networks to reject all traffic except that coming from the proxy.