The theft of customer data concerns companies and private individuals, as well as law enforcement agencies. Volumes of customer data usually are stolen from poorly protected online stores. After that, the illegal use of this data is almost impossible to prevent. Securing the web server is crucial. In this article, I look at the security of web servers using Apache and the Qualys SSL Server Test [1]. To begin, I look at communication between server and client.

Delivering websites by Transport Layer Security (TLS) is now standard procedure. Thanks to Let's Encrypt, the costs have fallen significantly, so that even web servers that do not require an organization validation (OV) or extended validation (EV) can be secured at low cost.

The security of communication over TLS affects web servers and clients in every case, but the focus is on protecting transferred application data. The server test operated by Qualys has established itself as a reference for testing secure TLS configurations. In the next step, I will look at which parameters you can use to take your web server ranking right up to A+; then, I investigate how you can protect your applications, the host system, and thus, existing identity data with simple options.

Ranking A+

For an A+ ranking in Qualys server testing, you only need to check a few points of your configuration. The test checks connection security in four categories: Certificate, Protocol Support, Key Exchange, and Cipher Strength (Figure 1).

Figure 1: The Qualys SSL Server Test checks the security of websites and identifies the potential for optimization.

A standard Let's Encrypt certificate has a key length of 2,048 bits and uses SHA256/RSA as the signature algorithm. Without any further changes to the parameters, such a certificate already achieves the full 100 points in the category.

The test also determines the supported SSL/TLS protocols for the Protocol Support category. Old and insecure protocols lead to point deductions. The full 100 points are currently only available if you only use TLS 1.2. Since this excludes older clients (Android older than 4.4 or Internet Explorer older than 11), you should also activate TLS 1 and TLS 1.1 in the configuration. This will give you 95 points, which is still enough for an A+.

The evaluation for the Key Exchange is similar to Protocol Support. The 90 points needed for an A+ can be reached with 2,048-bit prime number parameters. To reach the full 100 points, calculate a 4,096-bit prime number and limit the elliptic curves used to secp521r1, secp384r1, and prime256v1. To do this, adjust the configuration of the values ssl_dhparam and ssl_ecdh_curve for Nginx. In the Apache configuration, pass the values to OpenSSL with the SSL-OpenSSLConfCmd Curves directive, and use the SSL-OpenSSLConfCmd ECDHParameters Automatic directive to enable automatic negotiation of the best possible curve, because not all modern clients support each of the three curves.

The Cipher Strength evaluates the cipher suites used. Opinions differ on the selection. Simply try out the ciphers you have selected with the server test. You should get at least 90 points, which is enough for an A+, as long as you don't have any cipher suites in the list that cause an explicit devaluation. One hundred percent in the Cipher Strength rating is available with the restriction to

AES256+EECDH: ES256+EDH:!aNULL

In addition to the categories, the use of HTTP Strict Transport Security (HSTS) is required for an A+. For Apache, you need the extension mod_headers for the configuration directive Header always set Strict-Transport-Security "max-age= 31536000; includeSubDomains", whereas Nginx can handle add_header Strict-Transport-Security "max-age= 31536000; includeSubDomains" always; out the box. With this setting, web browsers are instructed to communicate exclusively by TLS with the server of the domain (and all subdomains) for the configured period.

Protecting Host Systems

In addition to communication, the host system must also be protected against unauthorized access. This includes access to the filesystem as well as protection during the execution of dynamic scripts and the connection of application servers by proxy or the Web Server Gateway Interface (WSGI). The carefully selected settings at least make automated attacks against your web servers more difficult for potential attackers.

A big step in securing the host system is the use of additional security modules such as AppArmor or SELinux. Although AppArmor's learning curve is relatively steep compared with SELinux, the more complex SELinux policies also allow a correspondingly finer configuration of security parameters. Possible gaps in web applications that allow access to other system resources can thus be fundamentally mitigated because an attacker cannot act freely from the security context of the web server. However, even if SELinux cannot be enforced, there are effective ways to provide basic protection.

Another extensive protection measure is the use of a web application firewall such as mod_security . This extension can be used for both Apache and Nginx and is based on the rules of the Open Web Application Security Project (OWASP) [2]. Regardless of the web application used, these rules can be used to fend off entire classes of attacks, such as SQL injections, cross-site scripting, or remote code execution.

If you move the application data of your web server to its own partition, you can still implement some security aspects with Linux on-board resources. Mount this partition directly with the flags nosuid, noexec, and nodev. With nosuid, you prevent the execution of a program with the rights of the file owner; noexec prevents the execution of any binary programs; and nodev blocks the use of special device files such as block devices located in the partition. This measure is quickly implemented, apart from the effort of adjusting the partitioning.

The verbosity of the server software itself is repeatedly seen as a weak point, and probably rightly so. By revealing the Linux distribution, the Apache or Nginx version used can give an attacker a lot of information. For example, it is possible to discover how regularly the system is updated through skilful observation. This allows an attacker to estimate whether and for how long your system is likely to be vulnerable to a specific vulnerability.

Vulnerabilities in other software can also be exploited if their patch level is known. Therefore, it is best to turn off the display of the server signature for the pages generated for Apache with the ServerSignature Off directive. Additionally, you should prevent Apache from disclosing its version in the Server HTTP header field, which you can do with the use of ServerTokens Prod. Under Nginx, you can achieve the same results if you configure server_tokens off for the entire server.

Many automated attacks against web servers are based on the execution of scripts that are located on other web servers and must first be downloaded. Depending on which applications you run on your web server, you should prevent all outgoing connections of the web server user, if possible, using iptables. If you need outgoing connections (e.g., for automatic updates of your web applications), you should know the target servers and release them explicitly. Even if such a setting is useful for all system users of the server, the rule can be restricted to the web server user using the owner module for iptables.

Conclusions

TLS is fortunately on the advance thanks to Let's Encrypt. Linux security enhancements such as SELinux and AppArmor provide basic protection against local web server users taking steps beyond their intended competencies. Web application firewalls such as mod_security protect web applications against standard attacks; against targeted attacks, it ultimately helps to limit your web server's ability to provide information and communicate.