Technical Reference: Apache 2.0 DMZ Secure Server Install
This document is a guide to installing and hardening an Apache 2.0 web server to common security standards. It will guide you through practical measures to harden your Apache server, by way of example.
Because a web server is often placed at the edge of the network, it is one of the most vulnerable services to attack. Therefore, it's vital that you follow this guide to ensure that:
1) The opportunity to compromise the web server is limited
2) Should the web server be compromised, the damage potential to the rest of the network, data, and systems is limited.
1. Prepare the host operating system
1.1 Install and secure the host operating system.
Follow the hardening guidelines in the The Center for Internet Security. Hardening the host O/S ensures that, should someone compromise the security of your web server, the amount of damage that they could inflict will be minimized.
1.2 Create the directories to hold the Apache files
It's important to separate the binaries /bin, docs (/htdocs), and logs (/logs) into separate partitions on the system. You can choose whatever root you want, but this example will use /opt/apache2 as the root directory for the Apache web server.
1.3 Create the host groups for administering and running the server.
Create a distinct group for all the users who will have permission to change the configuration, start, and stop the web server. For example, if you want to call the group "webadmin", create it like this:
# groupadd webadmin
Create a distinct group for the web server user – no one will actually log into this group, but it will only be used to hold the userid which will run the web server. For example, if you want to call that group "webserv", create it like this:
# groupadd webserv
Take note that you should not create a "web developer" group on this host. Since this is a hardened production host you must not provide web developers login accounts on this system. Instead, developers should deploy documents and code to the server using your code/content deployment system, such as Kintana's Apps*Integrity.
1.4 Create an unprivileged host user id to run the server.
Never run the web server as root; if the web server is ever compromised, the attacker will have complete control over the system. Instead, the best way to reduce your exposure to attack when running a web server is to create a unique unprivileged userid for the server application. The userid nobody is often used for this purpose, but a userid and group that are unique to the web server is a more secure solution.
By default the web server uses privileged ports (port 80 and 443) and, when configured for secure operation, must have root privileges to open its log files and start the dæmon. (Therefore, the web server daemon will have to be started as "root", unless you configure it to use a port higher than 1024.) Once the server's startup tasks are complete, all active instances can run as the unprivileged user.
Use the following command line entries as patterns for creating a group and user for the web server. Here's an example if you were to use "webserv" as the user:
# useradd -d /opt/apache2/htdocs -g webserv -c "Web Server" webserv
1.5 Lock down the web server account
It's important that no one can successfully execute a password guessing attack against this account, so in this step, we'll restrict this account so that no one can log into it.
1.5.1 Issue this command to lock the password for the web server account:
# passwd –l webserv
Password changed.
1.5.2 To be sure the account is locked, issue the command:
# grep webserv /etc/shadow
…a :!: at the beginning of the line indicates that the password is locked.
1.5.3 Issue this command to remove the shell for this account:
# usermod –s /bin/false webserv
1.5.4 To be sure the account is locked, issue the command:
# grep webserv /etc/passwd
…/bin/false at the end of the line indicates that the shell is set to a non-existent shell.
1.5.5 Test the web server account to be sure you can't login. Issue this command to try to log in:
> login webserv
2. Download and verify Apache source code
By default, web servers return information about the product and version they are running in the Server variable of the HTTP header. This information can be very useful to hackers, enabling them to target attacks to that specific server. To prevent that information from being returned from the web server, this step shows you how to modify that header and build your own copy of the web server.
Because web servers often host sensitive information, or allow users to log in with plain-text passwords, it's important to encrypt the HTTP traffic. Therefore, this section will show you how to configure mod_ssl on your web server.
Note: Don't build the web server on your production, hardened host. Build it on a staging or development server (with identical O/S), and then copy it to your production host.
These steps will guide you through downloading Apache source code, validating it, compiling it, and installing it. We don't recommend use of pre-compiled or DSO versions. DSO versions may allow a hacker to introduce new "features" without having to recompile the code.
If you intend to add other module to your Apache web server installation, repeat the validation steps below for each module you add.
2.1 Download the latest version of Apache 2.0
Ensure that you retrieve the latest copy, so that you have cumulative bug fixes and security patches. You can download it from the Apache site.
From here, download four files:
1) The Apache source code itself, called something like httpd-2.0.45.tar.gz.
2) The PGP keys for the Apache signers: a file named "
KEYS
"
3) The PGP key for this source distribution, called something like httpd-2.0.45.tar.gz.asc
4) The MD5 checksum for this source distribution, called something like httpd-2.0.45.tar.gz.md5
wget http://www.apache.org/dist/httpd/httpd-2.0.45.tar.gz
wget http://www.apache.org/dist/httpd/
KEYS
wget http://www.apache.org/dist/httpd/httpd-2.0.45.tar.gz.asc
wget http://www.apache.org/dist/httpd/httpd-2.0.45.tar.gz.md5
2.2 Verify PGP signature for the Apache source
To ensure that you have an authentic version from the Apache Group, and that it's not been tampered with (remember, there are many mirrors from which you can download the Apache source), you should check the PGP signature. If you don't have PGP installed on this server, you can validate these files on another machine.
a) If you don't already have them in your PGP keyring, import the public keys from the Apache Group into your keyring:
~> pgp –ka
KEYS
b) Check the PGP signature:
~> pgp httpd_2.0.45.tar.gz
…if the signature is correct, you should get something similar to this:
-- CUT --
File 'httpd-2.0.45.tar.gz.asc' has signature, but with no text.
Text is assumed to be in file 'httpd-2.0.45.tar.gz'.
Good signature from user "Justin R. Erenkrantz
".
Signature made 20
03/03/31
07:49
GMT
WARNING: Because this public key is not certified with a trusted signature, it is not known with high confidence that this public key actually belongs to: "Justin R. Erenkrantz
".
The fact that it says, "Good Signature from…" is what we're looking for here. The WARNING statement indicates that we've not verified this signature with a 3rd party, which is ok here.
2.3 Verify the MD5 checksum for the Apache source.
MD5 is a way to validate the integrity of the file itself, much more reliable than checksum and similar methods. Normally, mismatches in the MD5 checksum from the Apache source are the result of download errors or file corruption. If you don't have MD5 on your system, you can download it from here.
Compare the results of these two commands – visually inspect them to ensure they match (if they don't, download it again):
~> pwd
/usr/local/build
~> cat httpd-2.0.45.tar.gz.md5
MD5 (httpd-2.0.45.tar.gz) = 1f33e9a2e2de06da190230fa72738d75
~> md5 apache_1.3.27.tar.gz
MD5 (httpd-2.0.45.tar.gz) = 1f33e9a2e2de06da190230fa72738d75
2.4 Extract the zipped Apache source file.
Finally, you need to unzip and untar the source file.
~> /pwd
/usr/local/build
~> tar xvfz httpd-2.0.45.tar.gz
This will create a new directory under your current one, named "httpd-2.0.45".
3. Create SSL certificates
SSL support requires an SSL library on your system, such as OpenSSL. If you're not sure how to find and install it, look at the Apache 1.3 hardening guide. This section will walk you through configuring your SSL certificate for encrypting your HTTP traffic. It will help you build a validated certificate and install it on your web server. We'll add the configured certificates to the Apache configuration in the next step.
3.1 Create a key and certificate request for your web server
Using OpenSSL, the following command will create a 1024-bit private key named, "private.key" and generate a certificate signing request (CSR). You need to have the CSR signed by a Certificate Authority (CA) who can validate your identity. When prompted to input information, note the answers in bold print below. (Answer the prompts with the information relevant for your server, of course).
Note: If you provide a challenge password, you will be unable to start the web server unattended. We don't recommend providing a challenge password, just leave it blank.
~> pwd
/usr/local/build
~> openssl req -nodes -newkey rsa:1024 -keyout /usr/local/build/server.key -out /usr/local/build/server.crt
Using configuration from /usr/share/ssl/openssl.cnf
Generating a 1024 bit RSA private key
................++++++
.......++++++
writing new private key to 'server.key'
-----
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:NC
Locality Name (eg, city) []:
RTP
Organization Name (eg, company):XianCo Systems, Inc.
Organizational Unit Name (eg, section) []:InfoSec
Common Name (eg, YOUR name) []:xianshield.xianco.com
Email Address []:webmaster@xianshield.xianco.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Most importantly, make sure your "Common Name" above matches the DNS name of your server. The locale information is less important, but we think it's best to use the locality of the server itself.
3.2. Submit CSR for validation/signing by a CA.
Next, you need to submit your CSR for signing by a CA. This will eliminate the "warning dialog" that a browser will pop up when a user accesses your site. This is because the user's browser has a set of trusted CAs that will prevent you from being notified if the web server's site certificate is signed by a CA you've trusted in your browser already (such as Verisign or
DST
). In this example, we will submit the request to your company's CA for signing. (You can use another CA if you want).
Send your request for a certificate to the CA. Include your name, your web server (Apache, in this case) your OS, and of course, the .csr (certificate signing request).
3.3 Rename your certificate files
The names aren't important, they just have to match what's in conf/ssl.conf. You will receive 2 files from the
PKI
team. The first file will be your server certificate (and will probably be named
.cer), the 2nd file is the certificate chain. Here, we'll rename them to fit what's specified in conf/ssl.conf.
mv "XianCo CA (01-03).cer" ca.crt
mv xianshield.cer server.crt
3.4 Copy certificates to your server.
Since you received these certs via email, and they're now sitting on your laptop, we need to copy both server.crt and ca.crt to the server. We'll copy them up to /usr/local/build. We'll move them both to the appropriate locations under conf/ssl.conf later.
scp *.crt xianshield:/usr/local/build/.
<div class="MsoNormal" style="margin: 0in 0in 0.0001pt 57.75pt; font-size: medium; font-family: 'Trebuchet MS'; background-color: rgb(255, 255, 2