First, we need to install the Apache web server. If you are using Debian, download the .deb (available from any Debian mirror in the web section). As an example we will be using Debian 2.1.
# dpkg --install apache_1.3.6-15_i386.deb or # apt-get install apache
For Redhat, download the .rpm from the Redhat Contrib network, or your local Redhat mirror, and install.
# rpm -ivh apache-1.3.6-1.i386.rpm
To compile apache from source, download the latest Apache tar file from http://www.apache.org/httpd.html, untar it, and read the INSTALL. For more complete instructions, see http://www.apache.org/docs/install.html.
Find the config files for Apache - for Debian, it is in /etc/apache/conf, for Redhat, in /etc/httpd/conf. A typical set of config files consists of:
access.conf httpd.conf srm.conf mime.typesAs of Apache 1.3.6, the main config file to edit is httpd.conf. Previously, it was split between httpd.conf, access.conf, and srm.conf, but these have all been merged.
There are several important configuration options that affect security. The first is the user that the web server runs as (User and Group, in httpd.conf). It is best to choose a user that has as few privileges possible - ideally, a user created just for the purpose of running the webserver daemon. Create this user (I generally call it www-data, as this makes it obvious what this account is for), give it a secure password, and ensure that it has minimal access to the system and its functions. Also ensure that access to the www-data account is given only to those with a genuine need - that is, as few as possible. This also means if the web server's security is compromised, they only have access to a user account with only minimal permissions.
Another important configuration item which is sometimes overlooked, is the server admin (ServerAdmin, in httpd.conf). Set this to a sensible email address, which is checked by more than one person - for example webmaster@your.domain.com. If there are any security problems, having a valid email address checked by more than one person ensures the problem will be rectified in the shortest possible time.
The next item, and most possibly the most important, is the document root: this defines where the documents are served from (DocumentRoot in httpd.conf, or in srm.conf). It doesn't really matter where this is, only that it has appropriate permissions that only allow the www-data user (as above) to write to it. The user data directory (UserData in httpd.conf or srm.conf) specifies where the web server looks for a ~user request. The value of this is appended to the user's home directory.
By default, Apache usually comes with automatic indexing of directories enabled (IndexOptions in httpd.conf or srm.conf). This means any requests for a directory that don't find a index file, will build an index of what is in the directory. In many cases, this is a security issue, as you many only want people seeing files that you specifically link to. To turn this off, you need to remove read permissions from the directory (but not the files inside) - that is, chmod 411. Depending on the ownership of the directory, it should look like:
# ls -l /var/www/protected d-wx--x--x 2 www-data www-data 1024 Jul 28 08:12 protected/Then, any requests for this protected directory should return an error message something like:
Forbidden You don't have permission to access /protected/ on this server.It is also possible to hide files in this manner by using the IndexIgnore option - by default, it is set to:
IndexIgnore */.??* *~ *# */HEADER* */README* */RCSwhich means any backup, header, readme or RCS (Revision Control System) files are not shown in the automatically generated index. This can be used for other files, for example if you have some metadata you wish to store in the directories, but do not wish it to be available via the web server.
For a more flexible way of protecting data, there is a facility to password protect areas of the website. This is done by a .htaccess file (specified in httpd.conf or srm.conf by AccessFileName). This file will allow you to specify users (or groups) that are allowed to access the directory. An example of a .htaccess file would be:
AuthName restricted stuff AuthType Basic AuthUserFile /path/to/httpd/users require valid-userThis means that, for the directory the .htaccess file is in, the user will be prompted to enter a username / password combination for a valid user in the flat file database in /path/to/httpd/users. To add users into this file, it is a simple matter of using htpasswd (provided with Apache) in the following manner:
# htpasswd -c /path/to/httpd/users usernameThis will create the users password file, and from then on, you can simply add users in a similar manner (but without the -c). Apart from using a flat file, you can also use a database (dbm and mysql), PAM (Pluggable Authentication Modules), and system passwords, but these are beyond the scope of this article.
To access files outside of the document root, aliases are used (Alias in httpd.conf or srm.conf). These are of the format:
Alias /alias/ /path/to/where/It is important to know what aliases are on your web server, and ensure that they do not allow access to any sensitive data.
To allow CGI scripts, you need to specify where they are located by:
ScriptAlias /cgi-bin/ /path/to/cgi/It is vitally important that any files in the CGI directory are known and checked for security problems. Also, never put arbitary binaries that accept any commands from the user in this directory - for example, a perl binary.
Another common way of enabling CGI scripts is to map a file extension to the CGI handler. However, it is important to understand the implications of this, as this will allow any local users to create CGI scripts, without having to pass them through any checks you may desire to ensure they are secure. However, in the right case, for example, over a restricted area of the website, it may be useful. It is enabled in srm.conf or httpd.conf by:
AddHandler cgi-script .cgiOne popular way of allowing dynamic content is by the use of server side includes (SSI). This is done in a similar way to enabling CGI scripts - you need to associate a specified file extension (usually .shtml) with the server side include handler, as follows:
AddType text/html .shtml AddHandler server-parsed .shtmlOnce again, as with CGI scripts, it is important to be aware of the implications of enabling it. For more information, see the documentation on mod_include. A more generic way of handling both CGI scripts, and server side includes, amongst other things, is by the use of <Location> and <Directory> directives, and this will be covered in a future article.
As you can see, Apache has many options, but simply enabling them without being aware of the implications can cause security problems. Next time, we'll be covering some of the more advanced features available under Apache to protect your data.
Brad Marshall is a Systems Administrator for Plugged In Software, a Brisbane based software development company. He has been using Linux for more than 5 years, and has a BSc majoring in Computer Science.