Harden your Apache web server
Batten the Hatches
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).
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
(incl. VAT)