Web server security: Web server hardening

February 18, 2020 by

Patrick Mallory

A web server is not just any other device that you employ in your network environment. Unlike other devices sitting behind layers of defenses and firewalls, web servers sit at the rim of your network and are designed to share information about your organization with the outside world, regardless of who they are. 

Therefore, it is no surprise that a web server is often the first place that hackers look when they are considering attacking a target. Without the proper precautions and preparations, these devices are weak enough to give attackers the foothold that they need.

Learn Network Security Fundamentals

Build your skills with seven hands-on courses covering network models and protocols, wireless and mobile security, network security best practices and more.

Start Learning

A quick look through the most common web-based cyberattacks lead back to web servers sharing too much device information, SQL injection, session management-based attacks and even a failure to install the latest patches. In other words, if left with their default configurations, your organization will quickly find some of your most important information exposed — or worse — with the forensic trail leading straight back to your web server. 

So what can your organization do to harden your web server to keep attackers at bay — or at least frustrated enough to find a weaker target? In this next part of the Infosec Skills web server protection series, we will review some of the best practices when it comes to web server hardening.

Web server hardening best practices

Disable the signature

A common way attackers begin to probe a web server for possible exploitation is by sending a remote request that pulls back valuable information served up by the server signature. Also known as the server footer, disabling the server signature prevents the server name, server version number and other information such as recent error messages, module information and other directory information from displaying upon request or when a 404 error page is presented. If you want to protect your Apache web server from enumeration, for example, go to your web server’s configuration file and modify the code by adding in the command “ServerSignature Off” and “ServerTokens Prod.”

Log server access

By default, Apache and Windows servers are not configured to capture login information as users authenticate into the device and perform other requests. In Apache, these logs can be customized for your organization’s specific needs, written directly to a file or sent to an external application. Conditions can also be set so specific criteria presented are excluded or included. While the information logged can be broad, key information could include the IP address of the requestor, the session ID, the host and bytes received/sent, among others.

Disable the HTTP Trace and Track requests

Although allowing your web server to respond to HTTP Trace and Track requests could be used for legitimate purposes, such as debugging connection errors within your network, these protocols can also compromise the security of your web server. One of the most common exploitation methods are cross-site scripting attacks, where attackers could use and manipulate the TRACE and TRACK methods to intercept normal traffic connections, session cookies and possibly any data in transit.

The best way to address this issue is to disable the TRACE HTTP method by adding a directive command into the httpd.conf file of an Apache web server. For example:

TraceEnable Off

Reload Apache

Create non-root users

Another best practice security measure, which applies not only to web servers but all operating system administration, is to create and use non-root accounts for basic administrative and management tasks. By doing so, your organization can add another layer of defense in case an attacker obtains non-root credentials to the web server.

In Linux/Debian, for example, this can be done with a simple “sudo adduser [username]” command followed by assigning that new account to the administrative “sudo” group and assigning that new account its appropriate privileges. When needed, that new account can perform its administrative-like functions using a preceding “sudo” command.

Restrict IP access

If your web server is used for only limited purposes such as internal organizational information sharing, hosting a static website or testing and developmental efforts, it can be configured to only allow specific IP addresses or network. 

The range of IP addresses to accept or deny can be configured in your site Directory in the httpd.conf file. For example, a network address can be presented with the Allow directive:

<Directory /samplewebsite>

Options None

AllowOverride None

Order deny,allow

Deny from All

Allow from 10.10.10.0/24

</Directory>

Disable SSLv2 and SSLv3

Despite being full of well-known security issues, many web servers still run SSL 2.0/3.0 and TLS 1.0/1.1 protocols by default, putting any data transferred over these encryption methods at risk. Because of this, SSLv2 and SSLv3 as well as TLS 1.0 and 1.1 should be disabled while TLS 1.2 is enabled in its place. 

In your web server’s ssl.conf file, navigate to the SSL Protocol Support section and add, for example, the following lines:

SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

SSLProtocol +TLSv1.2

You also have the option of enabling your web server to encrypt traffic with SSL certificates, allowing your organization to leverage HTTPS protocols to securely transfer data. If your organization processes payments or offers member-specific functionality, using SSL certificates will not only protect PII but also help your website earn better rankings on search engines.

Disable directory listing

Similar to disabling web server signatures, web servers also by default display the content of the documents and files in the root directory when an index.html file is missing. This means that a potential attacker could possibly view all of the files and subdirectories that are presented to the browser.

To turn of this function, in the Options directory set the value to either “None” or -Indexes in order to look like the following: 

<Directory /var/www/SampleWebsite>

Options None

Order allow,deny

Allow from all

</Directory>

Eliminate unused modules

If you installed your web server with the default operating system configuration, then there’s a high chance that there are many unused or unrequired modules running. The more services and functions that a web server is running, the more opportunities a potential hacker will have to exploit your network; because of this, a simple but easily overlooked best practice is to disable and turn off any unnecessary services, ports or functions. 

For example, there are 65,535 available ports each server could possibly service. Your server clearly doesn't need all of them open and receptive. 

Any unnecessary internal or external ports and modules should be turned off. To confirm which modules are running on your web server, use the following command:

grep LoadModule /etc/httpd/conf/httpd.conf

To disable a certain module, insert a hash mark at the beginning of the line of that service and restart your web server.

Install Mod_evasive and Mod_security

Now that you have disabled all unused services, there are two that you should consider enabling: Mod_security and Mod_evasive. The former is an open-source IDS and prevention engine, while the latter provides your web server with built-in evasive capabilities if it detects that your website may be under attack.

Mod_security works as a supplemental firewall for the web server, allowing you to monitor traffic in real-time while also disabling host connections if the module suspects potential brute-force password attacks. Mod_evasive is used to help to prevent DDOS attacks by closing connections if too many requests come into a certain website too quickly, if a certain child process request is attempting to create too many concurrent requests or if any host IP is trying to access the web server even if blacklisted.

Constantly check for patches

Last, but certainly not least, you need to constantly check for updates and patches for your server. This should not just be a one-time function after installation. In Linux, regularly use the “sudo apt update” command to install the latest patches and fixes. Of course, this should be done in accordance with larger infrastructure change and patch management processes by administrators trained to perform patching procedures. 

Bringing it all together

While this article covers ten of the most common web server hardening techniques, no single method or combination of methods can guarantee that your website will be defended against a determined cyberattacker. 

However, by actively using web vulnerability scanners, constantly patching, continuously tuning your web server to meet the specific needs of your organization and considering these best practices, your organization can drastically raise the level of effort it would take an attacker to exploit your network. This means frustrating the attacker and possibly forcing them to move on to an easier target.

Learn Web Server Protection

Get hands-on web server security skills with nine courses covering infrastructure, hardening, command-line utilities, web application firewalls, active defense and more.

Start Learning

Sources

• wstg/document, OWASP
• The Apache HTTP Server Project, Apache