In this introductory article, I will present several methods for helping to secure DNS and Web Servers. I am using BIND 9.9.4 and Apache HTTPD 2.4.6 on CentOS 6.4. BIND and HTTPD are by far the most common DNS and Web Server platforms. I will show how to build the software from source, as well as perform an initial secure configuration. I will presume a minimal installation of CentOS 6.4. If you’re using another Linux or UNIX variant, you will need to adjust the procedures accordingly. This article presumes that the reader is already familiar with DNS and Web Servers, particularly BIND and HTTPD.

Fully hardening these services is a very complex subject and we only touch on the major aspects of configuration below.

Planning your installation

It is best to perform the software installation on dedicated filesystems in order to contain any damage should a software component become compromised. Logical volume management makes this easy. For example, on the system I’m installing to, /usr/local and /var/log are separate filesystems, as will be /var/chroot. Ensure that the operating system is fully patched prior to commencing the installation. You should also ensure that appropriate security hardening has been performed on your host operating system. There are hardening procedures for a wide range of UNIX and Linux operating systems available at (http://cisecurity.org) that may be fit for your purposes.

Whilst the following examples are performed on a single test machine, in Production you should only use one service per server. This is not the best approach from a security perspective as it leaves multiple avenues open on a server for compromise – exploit HTTPD and you’ve potentially got access to exploit BIND, for instance. It also leaves the fallout from a Denial-of-Service attack on one service to bring down any others on the server.

Using many physical machines for relatively low-resource hungry services is not cost-effective. A virtualisation mechanism such as KVM (Kernel Virtual Machine) on Linux and Zones or Logical Domains on Solaris could be used to partition a physical host to serve multiple services in a more secure fashion.

You should also plan for high-availability. The exploitation of a single webserver, for example, shouldn’t bring down your entire web site or application. Clustering and/or load-balancing are two mechanisms that can be used to implement such high-availability.

Multiple levels of firewalling should also be used. Network-based firewalls as well as host-based (e.g. iptables) can be used in combination with the steps outlined below to provide a defence-in-depth type approach to security.

Compile from source

To get the latest security updates, it’s worth considering compiling your software from the latest source code. Doing this, there is a danger of introducing stability issues (due to bleeding-edge functionality), so you should also bear that in mind. You can always use your system’s packaging system to “roll-your-own” packages to distribute your compiled software in an efficient and manageable way. In this article, I’ll be covering compilation from source, but will not cover packaging as it is dependant on the UNIX/Linux variant being used. Compiling from source will also leave you with leaner binaries, and you can compile-in the bare support required, which again closes off security issues with certain modules. For example, if you don’t need proxy support for your Apache instance, don’t bother compiling it in.

First, we need to configure the build environment by installing the appropriate packages. On CentOS, as with other RHEL-derivatives, we will use yum:

This will install the gcc and g++ compilers (for C and C++ respectively), as well as make, and all the required dependencies. We also install the OpenSSL development libraries, as these are required for some aspects of BIND functionality that we want (for example, DNSSEC). Perl is also required for BINDs internal symtables. pcre-devel is required for HTTPD.

Next, download the latest BIND, HTTPD, APR and APR-util source tarballs. BIND can be obtained from http://www.isc.org, APR and APR-util from http://apr.apache.org and HTTPD from http://httpd.apache.org. I will presume that both have been downloaded to /usr/local/src on our DNS/Web Server, and that your unprivileged user has write permissions to this directory.

We will start with BIND, so extract the tarball:

Next, we need to configure BIND as with any other standard software compilation routine – we use configure to prepare the build, specify which options we want (and which we don’t), prior to performing the make and actually compiling the software.

The configure and build should be performed as a non-privileged user. You can run ./configure --help to obtain a list of available options. Let’s change to the appropriate directory, and run configure:

We enable threads, and specify an installation prefix of /usr/local/bind-9.9.4. This will be symlinked to /usr/local/named, giving us an easy method of upgrade. We can compile and install new versions of the software side-by-side to the existing installation, and then just update the symlink. A rollback then just involves changing the symlink back to its original state. At the end of the configure, a report is displayed showing what we enabled, and what we didn’t enable:

If you require other features, run configure again to enable them. Now, we can actually compile the software with make:

This may take a while, depending on your system. Next, install the compiled software to the location we specified with --prefix:

Finally, create a symlink as previously outlined:

Check that the installation was successful:

BIND is now built and is ready for configuration. We will move on to compiling Apache next, and then return to configuring and securing our BIND installation.

Prior to building HTTPD, the Apache Portable Runtime needs to be installed. The following process achieves this:

Next, we can compile Apache HTTPD using the same configure, make, make install process. Let’s extract the software:

Configure the software. I will enable a few features for our Apache HTTPD instance. I’ll enable mod_rewrite and a few proxy modules. I’ll also enable SSL and specify the prefork MPM.

Compile the software, and symlink as required:

Apache HTTPD is now fully installed. It’s configuration file is located at /usr/local/http/conf/httpd.conf. Check the version to verify the installation:

We can now move on to configuring the software.

BIND Chroot

The most important concept in securing BIND is the concept of the chroot (change root). A chroot jail is set up for the calling process (in this case: named) setting the root directory of that process to a specific path, rather than /. The new root directory is inherited by all children of the calling process. This jails the process(es) so that if it is exploited, any potential damage is limited to the confines of the chroot.

I will create a logical volume for the /var/chroot tree. 1GB should be fine for our purposes. This procedure will be different depending upon your OS/volume manager, and you may wish to exclude it if you already have a separate /var filesystem and do not think that a new filesystem is required for /var/chroot. I prefer keeping the chroot on its own volume:

Create a filesystem on the device. Instead of using the indirect block scheme for storing the location of data blocks in an inode, use extents instead. This is a much more efficient encoding which speeds up filesystem access, especially for large files.

Create the mountpoint:

Add to /etc/fstab:

Now, the filesystem is ready to be mounted:

We can now begin configuring the chroot tree. Start by creating the directory structure:

The directories created are as follows:

/var/chroot/named – the top of the chroot tree

/var/chroot/named/dev – directory for device files

/var/chroot/named/etc – directory for configuration files

/var/chroot/named/var – directory for data files

/var/chroot/named/var/log – directory for log files

/var/chroot/named/var/named/pri – directory for primary zone files

/var/chroot/named/var/named/sec – directory for secondary/slave zone files

/var/chroot/named/var/run – directory for state/PID/lock files

Next, we add a non-privileged user and group that BIND can run as. Running BIND as a non-privileged user will prevent the damage that can be done should the named process be exploited. I use the convention of assigning the TCP/UDP port number as the UID and GID, so, first check that 53 isn’t in use as a currently assigned UID/GID:

If nothing is returned, go ahead and create the group and user:

We can now use rndc-confgen, a tool provided with BIND, to generate a very basic rndc.conf and named.conf. We will make two copies of the same generated configuration. rndc-confgen produces rndc.conf at the top of the generated file, and a commented named.conf excerpt at the bottom, with the same RNDC key that is generated in the top half, making it easy to get the RNDC configuration correct. RNDC is used for controlling the nameserver.

This command may appear to hang as it waits for entropy – if it does you can generate entropy by running a disk I/O intensive command in another terminal, such as:

Next, we use sed to perform a transformation on our named.conf template. We replace named.conf in place with a new named.conf.new version. The first sed command deletes the last line of input ($d), then each line has the first two characters removed (s/^..//). Then the 15^th until last lines are printed (15,$p). All other lines are suppressed (as the –n option has been passed to sed). The result is a bare-bones named.conf, that can replace our original.

After performing this transformation, the contents of the two files is as follows:

With our base configuration in place, we now need to create the appropriate device files within the chroot. BIND requires three on Linux - /dev/{null,random,zero}.

To obtain the correct major and minor device numbers for these devices, and the fact that we need character devices over block devices, you can use ls to view the existing devices under /dev and then translate those into the chrooted device files. Alternatively you can obtain them from the kernel documentation at https://www.kernel.org/doc/Documentation/devices.txt.

The leading c indicates a character-based device, all have a major device number of 1, and minor device numbers as shown above.

Use mknod to create /var/chroot/named/dev/{null,random,zero} as follows:

Copy /etc/localtime into the chroot:

We now need to create the root.hints file if we’re wishing to provide a recursive service. This list, returned via the dig command for all nameserver resource records (NS) in the root zone (.):

Next, set appropriate ownership over the chroot tree for our non-privileged account:

As a further step, we can create /dev/log inside our chroot if we are using syslog. I’ll just be using BINDs logging features outside of syslog for the purposes of this article. If you wish to use syslog, then update your syslog configuration (and SELinux if required) to create /dev/log within the chroot tree.

BIND is now ready to run out of the chroot. Specify the non-privileged user (-u option), the chroot tree root (-t option) and the configuration file location relative to the chroot (-c option). Start it in the foreground with the -g option the first time you run it and check for errors. BIND will chroot(2) after initial start up:

If BIND starts correctly at this point, shut it down by hitting ^C. Drop the -g and start BIND in daemon mode, again specifying the chroot with -t:

You can now install an appropriate /etc/init.d script (or control BIND manually with rndc). We can now perform further configuration of BIND and implement further security.

To control BIND manually with rndc, use the following command format:

Examples include reloading a zone:

And reloading the nameserver after a configuration change:

Read the rndc manual page for more information on this important command.

Securing BIND

We can now begin to tune the BIND configuration for our needs. As each BIND configuration is very different, I will cover core security aspects of it only. DNSSEC is beyond the scope of this article, but should also be considered when securing your nameserver.

Views are an important concept in BIND, and provide a way to offer a different set of zone files to clients matching certain criteria. We can, for example, provide a recursive service with cache query enabled to an internal network of hosts whilst providing a locked-down authoritative service to all other clients. Locking down to whom you provide recursive service is very important. Misconfigured DNS servers can be used in Denial of Service attacks for DNS amplification, so ensure that you only allow hosts to recursively query your nameservers if specifically required to do so.

Let’s consider a network with all local “internal” hosts on 192.168.100.0/24. We’d start by defining an ACL in named.conf:

We can then create our two views:

With this configuration, any hosts in the mynets ACL can query the DNS cache, and perform recursive queries. External hosts are able to perform non-recursive queries for resource records in any zones defined in view external, and are unable to query the nameserver cache.

You can also specify match-destination as the view match criteria which is useful for situations when different views are being offered via different network interfaces on the system.

The allow-query-cache and allow-recursion options (as well as the more general allow-query directive) can also be placed in the options block for a global default. We can use these directives to define who can query what on our nameserver.

Now that we have secured our nameserver with respect to who can query and how, we should now look towards how zone transfers are secured. You may not need to have zone transfers at all, in which case the allow-transfer { none; }; configuration directive should appear within your options block. If you have slave nameservers, then you can specify an ACL containing your slave servers, and apply that either per-view or per-zone. For example:

We should also restrict dynamic DNS updates by using the allow-update {}; directive. If dynamic updates are required, lock them down as much as possible by turning them off globally, and then only allowing the updates per zone, for example:

You can also use TSIG (transaction signatures) to secure zone transfers. TSIG can provide security in a pairwise manner between two servers, and can be used to sign and secure zone transfers via a pre-shared key mechanism. TSIG utilises a one-way hash function to provide authentication and data integrity.

For this example, let us presume our master nameserver is ns1.example.com (192.168.100.1), and our slave is ns2.example.com (192.168.100.2). To generate the key, we’ll use the dnssec-keygen command that is installed along with BIND. As the name suggests, the dnssec-keygen command is also used for generating the keys required for DNSSEC operation. Here, we use it to generate the HOST key to be used for our TSIG authenticated transfers.

On the master server, issue the following command to generate the key. You can use a key length of 128, 256 or 512 bits. The longer the key, the harder it will be to crack. Generate the key in the /var/chroot/named/etc directory:

The output is the filename prefix of the .private and .key files that will be generated:

The .key file contains a DNS KEY record that can be inserted into the appropriate file when DNSSEC is employed. We are interested in the .private file. Run cat against the file, and note down the key:

On the master server, create the /var/chroot/named/etc/tsig.key file as follows:

And on the slave server:

Next, on both nameservers, include the key file into named.conf. The path should be relative to the chroot:

On the master server, restrict each zone’s ability to be transferred only with the appropriate key:

Restart / reload the BIND instances once configuration is complete.

Logging is also an important step in securing your BIND installation. If you have configured your syslog implementation to provide a /dev/log device within the chroot jail, you can use logging statements such as the following to log to syslog:

This will log messages at severity info and higher via the syslog facility local7. Ideally your syslog configuration should forward all syslog messages to a centralised remote syslog server.

You can also log locally as follows:

This will maintain 5 versions up to size 100M of the default log. There are many other categories of logging that can be defined, such as queries and notify. Further information on the logging facilities offered by BIND can be found in the Administrator’s Reference Manual (https://kb.isc.org/article/AA-00845 ).

A final item worth changing is BIND’s version string. By default, the following query will return the version of BIND running, for example:

This can provide information to somebody looking to exploit a vulnerable BIND version. Therefore, set version to something else within your options block in named.conf, for example:

Or, just set it to any empty string.

After making any configuration changes to named.conf, either reconfigure or reload BIND with rndc.

Securing HTTPD

Securing Apache HTTPD is a complex subject, and this section will outline a brief selection of “quick-win” security-hardening steps. For a 100-page hardening guide that covers these steps (and much more) in greater detail, download the Apache security benchmark from http://www.cisecurity.org).

As with BIND, we should ensure that our Apache instance runs as a non-root user. Looking at our default httpd.conf supplied at /usr/local/httpd/conf/httpd.conf, User and Group of daemon are specified. I will create a user/group of www, with UID and GID of 80, first checking that the UID and GID are not already in use:

Next, update httpd.conf with the correct values:

You can now start httpd:

If all is well, you can install a script under /etc/init.d, configure the service to start at the appropriate runlevel as defined by your operating system, etc. You will also need to update the DocumentRoot for the configuration, or for any defined VirtualHosts.

Ensure that logs are configured. Each VirtualHost should log to its own file for ease of auditing. For example:

You should further ensure that a log rotation mechanism (for example, logrotate on Linux or logadm on Solaris) is employed to rotate the logs at an appropriate interval. Archival should also be configured – depending on your needs, as should the regular removal of old logs. I’ve written plenty of scripts for various log archival needs, and one method is to copy the logs to a central log server, md5sum both the local copy and the new copy, then delete them locally if the md5sums match as it indicates the remote copy on the log server is good.

The Apache instance is only as secure as any dynamic content being served by it via modules such as mod_perl and mod_php. Ensure that those modules are up-to-date and locked down as per any appropriate documentation shipped with the module’s source code.

By default, Apache error pages will give away information regarding the Apache version, OS and IP address of the serving host. This should be disabled by setting the following in httpd.conf:

Now the only information returned will be “Apache”.

To prevent users from uploading their own .htaccess files with snippets of HTTPD configuration in them, consider globally disabling this with:

Ensure that any modules you do not require are disabled in httpd.conf by commenting them out with the # character, e.g.:

You should also consider purchasing SSL certificates and providing HTTPS service if the content is to remain secure – for example if users are entering credit card numbers into forms on your site. If you are running a local application (for example, an intranet-based application within an organisation) it may be enough to create self-signed certificates. Using SSL certificates will also give clients security that they are connecting to the host that they expect, and will also mitigate man-in-the-middle attacks by providing encrypted communication between client and server. Ensure that you monitor the expiration date of certificates in Production so that they are renewed prior to expiry.

SSL can be slightly resource-intensive for large sites. In those environments, a load-balancer with hardware-based SSL-acceleration may be a wise investment.

Apache Options can be used to define options to be applied per directory (for example, FollowSymLinks and Indexes – the defaults). If you don’t wish to give away a directory index listing, you should include

within any appropriate <Directory> stanzas. If you don’t need Apache to follow symbolic links either, it is more desirable to set Options to None.

The HTTP TRACE method is implemented and enabled by default, and this can be open to abuse. Ensure the following is set in httpd.conf:

After making any changes to httpd.conf, ensure that you reload httpd:

If needed, a Web Application Firewall such as mod_security (http://www.modsecurity.org) can be utilised for an array of request filtering rulesets and other security features. One of mod_security’s experimental features is to provide a simple way to chroot Apache HTTPD. Another option for chrooting Apache is mod_chroot (http://www.cyberciti.biz/tips/chroot-apache-under-rhel-fedora-centos-linux.html).

Conclusion

Running web-based services requires a multi-faceted approach to maintain high levels of availability and functionality whilst still being locked-down and secure. This article has described the procedure for compiling and installing BIND and HTTPD from source, and has outlined some major points around securing and hardening the services offered by this software. Whilst it is not exhaustive it should provide food for thought for administrators looking to secure their web-based services.

This article was previously published in Pentest Magazine.