Securing a Linux Web Server: A Primer

Over the next couple of weeks and months, LinuxSecurity editors and contributors will be writing a series on Linux Web Server Security. This week, we’re summarizing the risks Linux administrators face when trying to secure their systems, as well as outlining the first steps that should be taken toward ensuring that your systems are secure. This series will dive deeper into topics including preventing information leakage, firewall considerations, protecting file and directory permissions, securely running PHP applications, monitoring logs and how to verify the security of a Linux server.

Much of this information originated from the Linux Security HOWTO, a comprehensive resource written by LinuxSecurity.com Founder Dave Wreski more than twenty years ago to offer the Linux community a place to start with securing their systems before much of the existing open source security documentation was created, now updated to reflect modern security principles and practices.

With the growing prevalence of Linux web servers globally, security is often touted as a strength of the platform for such a purpose. Due to the transparency of Linux source code, vulnerabilities are identified and fixed very rapidly and, as a result, Linux generally fares better than alternative proprietary OSes when it comes to security. However, a Linux-based web server is only as secure as its configuration, and the unfortunate reality is that often many Linux servers are quite vulnerable to compromise due to misconfigurations and poor administration. While specific configurations vary wildly due to factors such as environment and specific use cases, there are various universal steps to securing a Linux web server that can be taken to ensure basic security considerations are in place.

 

Misconfigured Servers Carry Great Risk

A selection of serious security risks are associated with the compromise of a web server, including the use of the hijacked server as a source of malware or the creation of a spam-sending relay, among other malicious activities. Even if the operating system and packages are fully patched with security updates, a misconfigured server can still be compromised.

 

Server Security: A Fundamental, And Often Neglected, Aspect of System Hardening

Many aspects of a system’s overall security are contingent upon server security. For instance, securing web applications begins with configuring the server itself strictly with security in mind. It is common for server owners to deploy various layers of security to react in real-time to hacking attempts and threats for HTTP requests. However, securing the server as a whole and any running services to the highest level is the first fundamental step to mitigating the risk of being hacked or compromised.

With the abundance of malware being installed into web applications hosted on Linux-based servers, it is clear that many servers are configured with little or no security in mind. For users of personal blogs, a compromise is often both an embarrassment and an inconvenience. However, for small and large businesses alike, having your company’s site or blog serving up malware due to a compromise often results in a significant loss of business and creates a very poor reflection of your company's IT services on the public, as well as on potential clients. As you can see, server security is of utmost importance - and should be a top priority for all server owners and system administrators. 

That being said, let’s take a look at some risks administrators face, considerations that should be made and steps that can be taken improve the security of your Linux web servers. This series will provide general information that can be applied to improve the security of any Linux server, but will focus predominantly on securing an Apache web server.

 

Information Leakage

Information leakage, or the actions of revealing information to an unauthorized party, carries severe consequences for both businesses and individuals including data compromise, reputation damage and financial loss. Information leakage can be the result of either intentional actions such as those taken by malicious insiders, or unintentional actions such as employee negligence. Luckily, there are various measures that system administrators can take to secure web servers against this serious threat.

The first and relatively trivial configuration changes that should be made to secure a Linux server are to disable any potential sources of information leakage. All Linux distributions have poor default configurations in regards to preventing information leakage. As a result, it is imperative that the correct manual configurations are made in order to protect sensitive data.

Potential sources of information leakage that Apache web server administrators should disable include the directory browsing listing, the ETag header, the Trace HTTP request and SSL v2/v3. Administrators should also ensure that the server version banner has been removed. Let’s take a closer look at these configurations and how they can be made.

 

Remove Server Version Banner

Removing the server version banner is one of the first configurations that Apache server administrators should consider to prevent information leakage. It is critical not to expose what web server version you are using, as this information can be exploited by malicious hackers. 

The Apache default configuration shows Apache Version and OS type. To hide this information from unauthorized parties. Edit your httpd.conf config file to add or modify the following directives if they don’t already exist.

ServerTokens Prod
ServerSignature Off

Save and exit, then restart apache.

 

Disable Directory Browser Listing

It is critical that Apache server administrators disable directory browser listing to prevent visitors from being able to see the files and folders listed under root or subdirectory. When directory browser listing is disabled on a server, a forbidden error message will be displayed when a user attempts to access this information. To disable directory browser listing, add -Indexes to the Options directive for the required directory. Edit the config file corresponding with the virtual domain you’re configuring and add “Options -Indexes” to the Directory section corresponding with the directory for which you wish to disable indexes.

<Directory /var/www/mysite>

    Options -Indexes

</Directory>

Be sure to restart apache after you’ve saved the file. If you don't have administrator access to the system or just want to easily manage directory listing on a per-directory basis, you can use the above Options -Indexes directive in the htaccess file corresponding with the directory, too.

 

Disable the ETag Header

The ETag header should always be disabled, as it allows remote attackers to obtain sensitive information such as inode number, multipart MIME boundary and child processes. To mitigate the risk of potential exploits associated with the compromise of this sensitive information, edit your apache config and add the following

Header unset ETag

FileETag None

Restart apache for the change to take effect.

 

Disable Trace HTTP Request

The Trace HTTP method is enabled by default in an Apache web server. Failing to disable this HTTP request can provide malicious hackers with access to cookie information, and can also result in a Cross Site Tracing attack. To disable the TRACE request so all such requests are blocked with 405 Method Not Allowed, edit your apache config and add the following:

TraceEnable off

Restart apache for the change to take effect.

 

Disable SSL v2 & v3

SSL v2 and v3 are ridden with security flaws, and must be disabled to prevent Man-in-the-Middle attacks which can result in data tampering or theft. Disabling SSL v2 and v3 is also essential to PCI compliance and penetration testing. To configure an Apache web server to accept only the latest versions of TLS and reject all SSL v2/v3 connection requests, edit the ssl.conf file in your apache config directory and add the following:

SSLProtocol all -SSLv2 -SSLv3

Once you have saved your config and restarted, you should verify your SSL configuration.

 

Review Additional Running Services

It is critical to review and disable any services running on the host that are not required. Many administrators run a 'web server' and unknowingly are running a host of other services simultaneously, which all need to be carefully reviewed and secured.

If other services are running on the same web server, the banner for those services should be edited to remove any broadcast of the version number or other non-required information that could potentially be leaked. 

 

Firewall Considerations

All Linux servers should make use of the built-in software firewall which, in most cases, is iptables. Iptables makes a very easy command line interface for managing the firewall - there is no need to write intricate iptables scripts. Debian and Ubuntu incorporate an application called ufw which is a command line interface for iptables. Using ufw, simple commands can open or close ports, without the user being an iptables wizard.

Regardless of whether or not additional firewalls are in place, the host internal software firewall should always be enabled. Only allowed services should be able to communicate in and out of specified ports and network interfaces. Consider if a company's perimeter firewall is compromised. In this case, the only layer of defense would be the software firewall on the host. Similarly, if the host is compromised through a web application, restricting access to network traffic of that host will provide some protection against island hopping or other intrusions.

ModSecurity is an excellent free and open-source web application firewall that can be used with Apache. You can download ModSecurity download . Installation, configuration and troubleshooting documentation is available on Github.

Multiple other great free and open-source firewalls, which you can learn about in this TechRadar.pro article, are also available to Linux users.

 

Disabling ICMP – Not Required

Administrators will often disable or filter ICMP requests, though doing this has no security benefits. In the case of something like DNS, ICMP requests are actually used in the DNS spec to query if a server is available before sending the DNS request. ICMP replies are extremely beneficial to web servers as well and can serve in troubleshooting a web server that appears to not be responding to HTTP requests. The threat of a ping flood is minimal today. Unless the attacker has considerably larger network bandwidth than the target, the flood attempt is going to cause little effect. Ping echo replies take very little CPU from the target to reply to - making the threat of a ping flood a bit like throwing many small pebbles in an attempt to take down a brick wall. This is why the majority of modern DoS attacks focus on HTTP requests instead of ICMP - driving up CPU and memory usage from the web server is far more effective to execute. In short, there is no reason to disable ICMP.

 

Permissions

File and directory permissions in Linux is often a confusing topic which leads to differing views, especially in the case of web directories and files. The worst advice, which should never be followed, is to change files or folders to 777. This allows anyone in the world to execute or write to your server. The best example of this is rogue WordPress plugins that malicious hackers push to servers via a simple HTTP POST command. If directory permissions are 777, anyone can read, write or execute anything in that directory - and anyone can post malicious code.

Apart from the read/write/execute permissions, ownership permission also needs attention. The web directory on your server should not be owned by the Apache user. A regular user should be the owner of the web directory, and the group should be the Apache user. Even if the read/write/execute permissions are accurate, a rogue or runaway process or PHP application can then have full access to make changes to your entire web directory.

Unfortunately, this ownership change can make the push button upgrades for Drupal and WordPress problematic. 

The binary and configuration directory permissions must also be protected. In Apache, the permission for binary and configuration is 755 by default, meaning that any user can access the conf and bin folder and view the configuration of the server. Administrators should consider disallowing access to the main config files by restricting ownership and file permissions on these files. 

 

PHP Applications

Running PHP on a Linux server is required for many popular applications such as Drupal and WordPress, among others. New vulnerabilities are being found in not only poorly written PHP code, but in the language itself, at an alarming rate. Since PHP is often paired with MySQL, a PHP compromise can mean a compromise of the accompanying MySQL database for the web server. Hence, it is critical to be on top of any PHP software or plugin updates. Do not install or use PHP code from unknown sources. For blogging software, minimize the number of plugins or extensions in use. If a plugin or add-on is not activated or in use for the blog or website, remove the unused files from the server.

Ensure that 404 pages for the server do not provide any extraneous information and do not interpret what was put in the URL bar. Visit a random 404 page on the web server as a test. The resulting 404 page should only provide a generic 'Sorry, that page was not found', and should not try to interpret or relay results that the user placed in the URL bar. 404 pages that allow user input manipulation are an entry point for attackers to craft XSS and other malicious attempts.

Learn about other PHP security best practices in this NixCraft tutorial.

 

Monitoring Logs

Logs are a critical part of monitoring the security of a web server. Many Linux distributions offer tools for automating log monitoring. The Logwatch application sends a daily email report of all of the logs on the server to inform on varying log entries such as the number of emails sent, potential web attackers, SSH attempts and IPs causing errors in logs.

In a large corporate environment it is common to send logwatch emails along with other mail directed to the root user (cron errors and other system messages) to a single company email list. Administrators in the company then subscribe to that single email list to stay informed of any alarming notifications in various servers' logs for the company.

Learn how to install and use Logwatch in this TechRepublic tutorial.

 

Conclusion

Linux is a popular operating system for web servers and web hosting, and is unfortunately also becoming an increasingly popular target for compromise - mainly due to misconfigurations and poor administration. Strict security considerations are needed to ensure that attacks and attempts to insert malicious code are avoided. Taking care to reduce information leakage, restrict permissions, keep PHP and other applications updated, and monitor all server logs will help Linux server administrators stay on top of potential attack vectors and avoid compromise. 

Got a tip for securing a Linux web server that hasn’t been addressed in this article? Please let us know in the Comments section below and we’ll include it here. Next week we will take a deeper dive into preventing information leakage.