Batten the Hatches

Fending Off DoS Attacks

The following directives are useful for hardening Apache against denial-of-service (DoS) attacks:

• RequestReadTimeout
• TimeOut
• KeepAliveTimeout
• LimitRequestBody
• MaxRequestWorkers (was MaxClients)
• MaxConnectionsPerChild (was MaxRequestsPerChild)

The timeout options affect how long Apache keeps connections open. Current Apache 2.4 versions usually use sensible defaults (e.g., in version 2.2, RequestReadTimeout was still set to  ).

LimitRequestBody also has a value of zero in the current Apache version, which means that a client is always allowed to transmit unlimited volumes of data. MaxRequestWorkers can be used to control how many simultaneous HTTP connections are allowed and should always be set to reflect the available RAM. MaxConnectionsPerChild does not have a limit by default. A limit can be useful to tell processes to release RAM in case of memory leaks.

HTTP Headers

By defining HTTP headers, you can enhance website security in several ways. On the one hand, you can do this in the HTML code and with server-side scripting languages. On the other hand, you could opt for a centralized approach through the Apache configuration. The examples in Listing 3 show possible application scenarios.

Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
Header always set Strict-Transport-Security "max-age=63072000"
Header always append X-Frame-Options SAMEORIGIN
Header always set X-XSS-Protection "1; mode=block"
Header always set X-Content-Type-Options nosniff
Header always set Content-Security-Policy "default-src 'mailto' 'self'"

The HttpOnly flag prevents cookies being read with scripting languages such as Java or VBScript. The Secure flag transmits the cookie only if an encrypted HTTPS connection exists. The Strict-Transport-Security header enables HTTP Strict Transport Security (HSTS) for a domain and ensures that, on future visits, the browser will always automatically call the specific domain by HTTPS and deny HTTP access. The remaining options are aimed at providing protection against cross-site scripting (XSS) and similar attacks on the browser.

Mozilla HTTP Observatory [4] provides a good overview of security measures already implemented on a website and suggests further recommendations (Figure 2).

Figure 2: Mozilla HTTP Observatory shows that the German Linux Magazin website still has potential for optimization.

TLS/SSL Configuration

With most browsers now warning users against unencrypted HTTP connections, HTTPS connections are already part of a web server's standard configuration.

Mozilla SSL Configuration Generator [5] is a good starting point for a sensible configuration: You specify the server software, including the exact Apache and OpenSSL versions, and then select the desired security level (Figure 3). The default is Intermediate , which is fine in most cases. If you want particularly high security, select Modern , which means that only TLS 1.3 is supported and it will surely lock out some visitors on busy sites. Optionally, you can enable HSTS and Online Certificate Status Protocol (OCSP) stacking; both are recommended.

Figure 3: Mozilla SSL Configuration Generator helps find the best possible Apache TLS configuration.

The result is a prebuilt configuration (Figure 4) you can adopt into your own Apache settings. Before restarting to enable the configuration, you again need to check the syntax by typing apache2ctl -t.

Figure 4: Above the configuration, the Mozilla generator indicates from which web browser versions HTTPS access will be possible.

The TLS Checklist Inspector [6] and SSL Labs [7] can help you check the TLS configuration. The German Checklist Inspector follows Technical Guidelines 03116, Part 4, of the German Federal Office for Information Security [8]. These guidelines are also a good source when it comes to serious recommendations on the subject of TLS/SSL.