Harden your Apache web server

Batten the Hatches

Article from ADMIN 62/2021
By
Cyberattacks don't stop at the time-honored Apache HTTP server, but a smart configuration, timely updates, and carefully considered security strategies can keep it from going under.

Whether you compile Apache yourself or use a package from a repository, you need to keep the software up to date and shut down vulnerabilities as soon as possible. One way to keep on top of important information is to subscribe to Apache's Announce mailing list [1].

In addition to the web server software itself, you also need to ensure that interpreters such as PHP, Python, and Perl and the web applications you use are secured. Last but not least, every security-conscious admin patches the underlying operating system on an ongoing basis.

Installation, Modules, and Updates

As a first step, you should disable unnecessary modules. On Debian and Ubuntu this task is quite easy thanks to the a2dismod command. Otherwise, you will have to search for the LoadModule directive.

The primary candidates for disabling include autoindex, CGI/CGId, Include, UserDir, and suEXEC. To determine which modules are already built-in, type apache2 -l, and after disabling modules, call the apache2ctl -t command before restarting Apache; this action triggers a syntax check of the configuration. The results will show, among other things, whether the module you wanted to disable is still referenced.

The use of a firewall – either centrally or directly in the operating system – is also useful. In this way you can limit, for example, the number of incoming connections per IP (connlimit with iptables; meters or dynamic sets with nftables). Also, it is often not necessary to allow all outgoing connections on a web server. For example, the iptables rule

# iptables -A OUTPUT -m owner --uid-owner www-data -m state --state new -j DROP

disallows outgoing traffic from the www-data system user that does not belong to any existing connection.

You can achieve additional security at the operating system level with SELinux (Red Hat, SUSE) or AppArmor (Debian, Ubuntu). Both extensions implement mandatory access control (MAC) and are extremely powerful, but they also require some training.

To be in a position to respond promptly to failures, you will want to monitor the web server with a monitoring solution like Icinga or Zabbix. Other useful extensions include intrusion prevention and detection systems (IPS/IDS) from the open source sector such as Suricata or OSSEC. Comprehensive security management also includes checking logfiles for potential attacks and, ideally, integrating them into a security information and event management (SIEM) system.

Configuration

Currently Apache 2.4 Core has 90 configuration directives [2]. In any case, you should be familiar with the Directory, Files, Limit, Location, and VirtualHost configuration groups. For those who have been using Apache for many years, it is best to take a look at the changes in version 2.4 [3], which include the new mod_authz_host access module with the Require directive, which replaces the previous Order/Allow/Deny syntax.

Without explicit configuration, the Directory directive allows access to the entire root filesystem, which can be prevented by the configuration shown in Listing 1. Depending on requirements, you can then proceed to assign more privileges to the subdirectories you actually use.

Listing 1

Directory Configuration

<Directory "/">
  Options None
  AllowOverride None
  Require all denied
</Directory>
<Directory "/var/www/html/">
  Require all granted
</Directory>

Enabling FollowSymLinks allows symbolic links to be followed on the filesystem. Remember that a symbolic link could be used to access the /etc/passwd file. A more secure variant here is SymLinksIfOwnerMatch, which only follows the link if the symlink and target owners are identical.

Options controls the functions available in a directory. Indexes affects the directory listing; Include and ExecCGI allow or disallow server-side includes with mod_include and CGI scripts with mod_cgi, respectively. A very restrictive configuration of the Options directive might be:

<Directory "/var/www/html/">
  AllowOverride None
  Options -Indexes -Includes -ExecCGI -FollowSymLinks
</Directory>

Options also support inheritance through the use of + and -. In the following configuration, FollowSymLinks and Includes are in effect for the /var/www/html/help directory:

<Directory "/var/www/html/">
  Options Indexes FollowSymLinks
</Directory>
<Directory "/var/www/html/help">
  Options +Includes -Indexes
</Directory>

The AllowOverride directive deserves special attention because it determines the handling of the very powerful .htaccess files, which None disables. You can use AuthConfig, FileInfo, Indexes, and Limit to allow certain settings. If direct access to the Apache configuration is possible, you generally want to avoid using .htaccess. It makes sense to separate the configuration from the content.

Like Directory, the Files directive can be used to impose restrictions for specific file names, as in the example in Listing 2, which prohibits downloading .htaccess and .htpasswd files. Limit lets you restrict access to certain HTTP methods. In this case, only a successfully authenticated user has access to the specified methods. The Location directive refers to the URL and should only be used when dealing with content outside the filesystem.

Listing 2

Restrictions

<Files ".ht*">
   Require all denied
</Files>
<Limit POST PUT DELETE>
   Require valid-user
</Limit>
<Location /status>
   SetHandler server-status
   Require ip 192.0.2.0/24
</Location>

Directory and Files are always processed first. DirectoryMatch, FilesMatch, and LocationMatch support the use of regular expressions, as in:

<FilesMatch "\.(gif|jpe?g|png)$">

Always pay attention to the context in which individual directives apply, as illustrated in the official documentation (Figure 1).

Figure 1: Excerpt from the Apache HTTP documentation that also shows the context of the directive.

Security Issues

The ServerTokens and ServerSignature directives are often referred to in security discussions. In general, obfuscating the web server software or version number does not genuinely improve security, but you will definitely want to update. After all, you don't want to paint a target on your forehead because the web server reports an outdated version.

ServerSignature is set to Off by default, which means that Apache normally does not add a footer to the pages with Apache Server at www.example.com Port 443 . In contrast, ServerTokens defaults to Full, and the resulting output is a header. You can query this header with wget -s (--server-response).

The usual recommendation is to use a different setting to avoid revealing too much information immediately about the web server. The minimal variant Prod means that the server only outputs the Apache name:

ServerSignature Off
ServerTokens Prod

The FileETag and TraceEnable directives also need to be disabled by setting them to None and off, respectively, for security reasons.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Life cycle management with Foreman and Puppet
    Virtual machines seem to be ideal for spare capacity. They are easy to create and remove – if only all those time-consuming administrative tasks like assigning IP addresses, setting up backups, and monitoring were more manageable. Having the right tools can help.
  • Setting up HTTP/2 on the Apache HTTP Server with PHP compatibility
    If you are running PHP applications, setting up HTTP/2 on the Apache HTTP Server can be a bit confusing because of some incompatibilities between the Apache HTTP/2 module and the Prefork multiprocessing module.
  • Setting up SSL connections on Apache 2
    To spoil the day for lurking data thieves, Apache administrators only need three additional directives – and a handful of commands.
  • Lua for Apache

    Lua is a small, lean, and fast scripting language – ideal for working with web servers. Version 2.4 of the Apache web server is the first to offer a matching module that has a few quirks – and pitfalls, if you dig more deeply.

  • Activate HTTP/2 on web servers
    HTTP/2 offers reduced website load times and other performance benefits, along with the promise of server push.
comments powered by Disqus