page 1 | 2
Apache is the most popular web server on this planet. It is open source and can adapt to whatever your web serving requirements may be, from simple single website to complex multiple subdomains with URL rewriting. Apache relies on one single text file /etc/httpd/conf/httpd.conf to do its job. You can edit the contents of this file with any text editor to provide browser access to all web sites on the server.

You can either have one web site per IP address or group a number of sites to a single IP address. Make sure that the web server's log (/var/log/http) directory is properly configured. The access logs can get quite large quickly with high-traffic sites. The log rotator can be of big help to reduce the storage requirement of large log files so this service needs to be configured properly and working.

The error logs need to be monitored frequently (preferably on a daily basis) to watch for operation errors from the web server (missing pages, scripting problems, etc.) and potential denial-of-service attacks or unauthorized access. If soft links are supported, the actual directories need to be monitored closely for any potential security breach.

Following are common tips to harden the security of your web server.

1. The default user id for the apache web server httpd daemon is apache:apache. You should assign a specific non-root Linux user account with restrictive read-write-execute privileges to run the httpd binaries. No other users can access this user id's files and directories except root. Make sure you do not allow non-root users to modify any files that root either executes or writes on in any directories referenced by the apache daemon httpd.

2. Move the default DocumentRoot (/var/www) which hold the data hiearchy of your web site to a different directory. This simple safeguard may prevent many inexperienced intruders from probing the server, once they do not find the root path of your dedicated server at the expected location.

3. Do not allow direct access to file system such as /bin /etc, /bin, etc. If your web server needs to execute binary scripts that require tools in these system directories, investigate and approve on a case-by-case basis so no unexpected security compromise is encountered.



4. Use relative paths (../../ for example) to hide the hiearchy of data on your web server. If possible, use the parent directory above the chroot directory so that access to these directories directly from the browser address bar is not possible.

5. Avoid the use of server side includes and cgi binaries if using scripting language such as PHP. In case of PHP, more robust security can be achieved with the use compiled codebytes together with the Zend optimizer engine or bcompiler. The PHP scripts are stored on the server as binary code bytes and are not human readable in case the server is compromised. The script should have provisions to check for the server's domain name or IP address, so that these scripts will not run as is on other servers without extensive modifications.

6. Protect your log files (both error and access logs) typically stored in /var/log/httpd. Check your log files for error messages regarding security break-in attempts and warnings or notices from your scripting host. An automated script scheduled at a predetermined interval (cron jobs) can scan the log files and alert any potential risks. You need to configure and at a minimum check for the following error conditions:

400, bad request
401, unauthorized. The error document must use a local reference (no http://, for example, /home/myserver/allsites/unauthorized.html). You need to pay special attention to this error since it means an invalid user id and password were supplied to access the page producing the error.
403, http forbidden.
404, http not found. You need to provide a default or custom page for this error. This response is most likely caused by a dead link (removing a page without properly updating all links). It can also come from a potential intruder typing in the browser address bar to probe hidden page present on the dedicated server.
405, http method not allowed

Set the LogLevel directive to info so that other warning and critical error messages are recorded. This includes other levels: emerg, alert, crit, error, warn, and notice. This setting will increase the size of the log file significantly but the information recorded can be invaluable to determine the cause and history of a security breach. A simple log rotator can be implemented to limit the size of the log file.
page 1 | 2