If you're going to compile and install Apache from source, use the Apache Toolbox.

Securing Apache

Apache recently featured in a list of security problems. They generally boil down to configuration mistakes. Points to note when installing, configuring and mantaining Apache include:

CGI scripts

Probably the biggest problem. Upload and CGI directories need to be distinct (so people can't upload "improved" CGI scripts) and as small as possible.

Apache2 makes it easier to run different scripts or even different Virtual Hosts as different users, rather than as the user that Apache is running as.

Chroot prisons

Running in a chroot prison limits the damage than can be done should an application be compromised. See chroot(2) for details. Apache2 has better support for this.

See also:

FireWalling Apache

You probably should FireWall the Apache user from connecting out to the InterNet unless you know that they actually have to. Doing this prevents a lot of exploits that people will attempt against your WebSite. The same idea can be applied to other services.

iptables --insert OUTPUT --match owner --uid-owner www-data --protocol tcp --syn --jump REJECT
iptables --insert OUTPUT --match owner --uid-owner www-data --protocol tcp --syn --jump LOG

Two minute Apache 2 self signed SSL configuration

Can't get much better than this! From the Ubuntu forums:

apt-get install apache2
apache2-ssl-certificate -days 3650

and answer the questions. It will default to 30 days if you don't specify your own number!

Enable ssl: a2enmod ssl
Configure a vhost:

cp /etc/apache2/sites-available/default /etc/apache2/sites-available/ssl
a2ensite ssl

"/etc/apache2/sites-enabled/ssl" should look like this:

NameVirtualHost *:443
<VirtualHost *:443>
(... configure the directories too...)

In /etc/apache2/ports.conf, add Listen 443
In the middle of /etc/apache2/sites-available/ssl file, insert these two lines:

SSLEngine On
SSLCertificateFile /etc/apache2/ssl/apache.pem

/etc/init.d/apache2 force-reload and you're away.

Extra information in directory listings

You can have additional information displayed at the top and bottom of a mod_autoindex directory listing by putting the text in a file called HEADER and README, respectively. Either file can any have FileExtension (or none). To enable this feature, you will need MultiViews on to be in effect for that request.

Apache and IPv6

Tell apache to listen on "::", which is the ipv6 version of, on whatever port. Eg, in httpd.conf:

 Listen :::80
 BindAddress ::

If you want a VirtualHost available on both IPv4 and IPv6, then give it a name that resolves to both a v4 and v6 address. It won't work if you give use a name that doesn't have a v6 address, and then try to use ServerName or ServerAlias. Eg:

$ host             A
$ host -t aaaa AAAA record currently not present
$ host -t a         CNAME       A
$ host -t aaaa         CNAME       AAAA    2002:CB61:A32:0:0:0:0:1

Doesn't Work:


(Apache can't resolve to an IPv6 address, so this vhost won't be available via ipv6.)

Does work:


Rotating your logs

Want to rotate all of your separate VirtualHost log files without restarting Apache? Use a little-known tool that comes with Apache called rotatelogs(8).

Change your TransferLog lines to:

TransferLog "|/path/to/rotatelogs /your/log/file.log 64800"

Read the ManPage for more information, or replace with CronoLog which has more features.

Errors on log rotation

Some people encounter a problem where apache dies on logrotation. It's not the actual rotation that's the problem, it's the "graceful restart" that the logrotate program sends to apache. This only seems to affect people using Debian Woody, and only with some undetermined set of conditions. Here is our setup:

ii  apache                   1.3.27-0.1.ipv6.r2       Versatile, high-performance HTTP server
ii  apache-common            1.3.27-0.1.ipv6.r2       Support files for all Apache webservers
ii  libapache-auth-ldap      1.6.0-3                  LDAP authentication module for Apache
ii  libapache-mod-gzip              HTTP compression module for Apache
ii  libapache-mod-ldap       1.4-3                    Apache authentication via LDAP directory
ii  libapache-mod-perl       1.27-3.ipv6.r1           Integration of perl with the Apache web server
ii  libapache-mod-ruby       0.9.7-2                  Embedding Ruby in the Apache web server
ii  libapache-mod-ssl        2.8.9-2.4                Strong cryptography (HTTPS support) for Apache
ii  libapache-reload-perl    0.07-1                   Reload changed modules in a mod_perl environment

We are using backports of apache 1.3, for IPv6 support. Other possibly relevant info:

ii  php4                     4.1.2-7.0.1
ii  php4-cgi                 4.1.2-7.0.1
ii  php4-ldap                4.1.2-7.0.1
ii  php4-pgsql               4.1.2-4
ii  phppgadmin               2.4.1-2

Also using a 2.6 series Linux Kernel.

When it happens, the following is in /var/log/apache/error.log:

[Wed Feb 23 06:26:00 2005] [notice] SIGUSR1 received.  Doing graceful restart
accept_mutex_on: Identifier removed
[Wed Feb 23 06:26:03 2005] [notice] Apache/1.3.27 (Unix) Debian GNU/Linux PHP/4.1.2 mod_ssl/2.8.9 OpenSSL/0.9.6c mod_perl/1.27 configured
-- resuming normal operations
[Wed Feb 23 06:26:03 2005] [notice] suEXEC mechanism enabled (wrapper: /usr/lib/apache/suexec)
[Wed Feb 23 06:26:03 2005] [notice] Accept mutex: sysvsem (Default: sysvsem)
[Wed Feb 23 06:26:03 2005] [alert] Child 6894 returned a Fatal error...
Apache is exiting!

Each time that the reload fails, there is a message about accept_mutex_on or accept_mutex_off: Invalid argument in the error.log file that isn't present when the reload succeeds.

Also note the logrotate runs the 'postrotate' section (in apache's case, the reload) every day, even if it only rotates the log files every week.

Suggested workarounds include:

  • replacing '/etc/init.d/apache reload' in /etc/logrotate.d/apache with '/etc/init.d/apache restart', although that will result in your server being inaccessible for at least several seconds.
  • using cronolog or something else, and remove apache from the logrotate system.
  • use the 'HUP' signal instead of the 'USR1' signal. (See

Apache-ssl with AuthUserFile complains "User not found"

  • This can occur if you have:
 LoadModule auth_module /usr/lib/apache/1.3/
 LoadModule apache_ssl_module /usr/lib/apache/1.3/

The solution is to swap the order so that apache_ssl_module comes first. (obscure!)

  • Another possible cause is that SSLFakeBasicAuth option has been enabled when trying to use the standard basic auth i.e. "AuthType? Basic" (this seems to have hit a number of debian users after the upgrade to sarge)

The solution is to turn off SSLFakeBasicAuth.

Getting Apache2 + mod_auth_ldap + ldap over SSL/TLS working

  • You should only do this if you have already got your webserver running through SSL/TLS, otherwise your LDAP details will go between the client and server in plaintext !
  • Make sure you have mod_ldap and mod_auth_ldap enabled (under debian use a2enmod)
  • You need to add the following two lines to your main apache2.conf to enable SSL:

This assumes that you have a CA cert that has signed your LDAP servers key. The documentation suggests that if mod_ldap is compiled against openldap, you may not require this to be the case, but you must add some sort of CA cert to make mod_ldap enable SSL. BASE64_FILE indicates that the CA file is in the (default for openssl) PEM format.

  • Check that your main apache2 error log lists something like the following when it starts up:
[notice] LDAP: Built with OpenLDAP LDAP SDK
[notice] LDAP: SSL support available
  • Add your authentication configuration to your Location, Directory or .htaccess files
<Location /path/to/auth/stuff>
   AuthType Basic
   AuthName "MyAuthArea"
   AuthLDAPURL "ldaps://<HOST>/ou=People,<BASEDN>?uid"
   Require valid-user

See also