Securing Apache

(Ping! Zine Issue 3) – The Apache Project’s web server package is the most widely deployed Open Source web server on the Internet. While available for a variety of operating systems, Apache is the HTTP daemon of choice for the various flavors of Unix used in the hosting markets. RedHat, Debian and other Unix distributions bundle Apache with their operating systems.

This article will discuss some tricks and tips to securing Apache in a *nix environment. Most of these techniques are Apache-specific but are dependant on the fact that your operating system itself is secure. The Center For Information Security has great strategies and benchmarking utilities for ensuring your O/S is properly tightened up for Internet exposure (visit their website at www.cisecurity.org for more information).

Build it — They will exploit
Creating a secure Apache environment starts with the configuration and compilation of the main Apache code. Since Apache is modular, you can select or deselect functionality specific to your server’s application and security requirements. This is critical for security because the fewer the modules you select, the fewer services will run and generically speaking, running fewer services will reduce your server’s susceptibility. Apache comes with a number of features that enhance functionality at the expense of introducing security liabilities. Avoid providing such functionality unless you have a really large need to do so.

Depending on your configuration and ultimately your role for Apache, you can work with the various modules to provide the necessary functionality without compromising security or weighing down your server with unnecessary overhead. Some modules that fall into the “be warned” category include:

• Mod_autoindex – Generates directory listings if a document specified by DirectoryIndex doesn’t exist. This can be overridden by not including the Indexes option in the directory configuration. Proceed with caution as it allows users to view directory contents if no default file (i.e., index.html) is found.
• Mod_cgi – Enables and handles the execution of CGI scripts. Proceed with caution as poorly written CGI scripts can compromise security.
• Mod_include – Enables and handles all server-side-includes (SSIs). By default it is disabled unless the directory configuration has the Includes option set. As with mod_cgi, poorly coded SSI calls can potentially cause problems.
• Mod_status and Mod_info – Enables real-time server status and configuration information. Information of this type should be locked down in a password-protected area if used.
• Libproxy – Enables functionality for making your server an HTTP/1.0 caching proxy server. Using this makes it possible for potential abusers to bounce requests off your server, taking advantage of trusted-host relationships and bypassing certain firewall restrictions.

Stay Current With Your Code
When an Apache user discovers a potentially dangerous vulnerability, the Apache Software Foundation issues a patch to fix the hole, or provides detailed instructions on how to fix the issue.  Because of the massive Apache user-base, many users never know the patches exist.

The Apache HTTP Server Project’s Announcements List (http://httpd.apache.org/lists.html) provides an opt-in/opt-out approach to keeping the user-base updated on security and functionality flaws, as well as methods of repairing them. Other mailing lists available through the ASF provide other reading materials involving the project and it’s people.

Don’t Give Away The Store
In the world of Unix, the root account is God. If a would-be hacker takes over your web server that’s running as root, your intruder now has God status on your server and can do literally anything. For this reason, Apache should always run as a purpose-built user that’s permitted to do anything required for a web server and nothing more.

Typically the User and Group configuration directives should specify your generated user and either that users group, or the group Nobody. Regardless of who the user is, it is important to make sure that the user only has read permission on web documents and execute permissions on CGI documents in the web directories.

Be exceptionally careful when configuring your Alias and ScriptAlias directives. Aliases provide access to specified directories, while ScriptAlias gives CGI/Execute permissions to files in the specified directories. Two examples:

Alias  /icons/ /home/httpd/icons/
ScriptAlias  /cgi-bin/  /home/httpd/cgi-bin/

These directive settings globally allow users to include files /icons/, as well as run scripts from /cgi-bin/. Review all your aliases carefully and disable or remove any that aren’t used or absolutely necessary. The same rules apply to Handlers. For example:

AddHandler cgi-script .cgi

AddType text/html .shtml
AddHandler server-parsed .shtml

AddHandler send-as-is asis
AddHandler imap-file map

Disable SSIs if they are not going to be supported. Map and Asis can be disabled, as you should be using ScriptAlias rather than .cgi handlers for processing cgi scripts. ScriptAlias limits the CGI files to a single directory, where adding a handler is global. As mentioned previously, don’t enable the server-status handler unless you’re planning on locking it down somehow.

Don’t Leave The Light On
No matter how restrictive your permissions on CGIs, they are still a security flaw. While not entirely practical, going over CGI programs that will be running on your server to check for potential security violations and rogue code might be an option. If you host multiple sites for a variety of users, consider using a CGI Wrapper. These utilities allow CGIs and SSIs to be run as alternate users with alternate permissions from the web server user.

Apache includes a module called suEXEC that provides wrapper functionality. CGIwrap is another such utility that provides security checks as well as means to change the ID of a running CGI.  If your CGIs need to write to files, those files can be owned by the user who owns the script, and are accessible through that account only.

Trust But Verify
Powerful scripting languages such as Perl, PHP, Python and TCL process input, interact with databases and a server’s file and operating systems, but do so at a potential dangerous risk in security. For example, if you are using Perl, make it a habit to use taint checks and turn on warnings:

#!/usr/local/bin/perl –Tw

Warning messages alert you to possible coding issues or problems with variables. Taint checks generate errors if you use values that have been provided directly by a user. In your code, you can untaint such values by matching them against regular expressions that ensure their safe use. For example, you can strip out all characters other than letters and numbers before you pass a value to the shell. A common security breach can be caused by a script running a shell command and application without first validating the users input.

Keep in mind that changing the Perl path in your scripts may make scripts that used to run quietly become very verbal with messages – a sure sign that taking the time to investigate Perl’s complaints is in order.

Chroot or Not to Chroot
A step towards a more secure Apache is running the server in a chroot “jail”. This method can be time consuming to set up, and is not infallible. A chrooted environment offers distinct immunity to many exploits, mainly because of the lack of a shell – even if an intruder succeeds in executing system commands, escaping a chrooted environment can be troublesome at best.

However, because it can graciously hog system resources without being completely foolproof, the method is not widely used. You can find more details on the chroot set up process by visiting http://www.linuxsecurity.com/docs/Securing-Optimizing-v1.3/chap29sec254.html.

Don’t End Up Blaming Yourself
The most important thing you can do to keep your server secure and free of riff-raff is to pay attention. Keep on top of recently uncovered vulnerabilities that affect any installed software or services. Check your applications for issues like buffer overflows or similar security problems, and review your log files on a very frequent basis — especially the error log — for signs of unwanted activity. For example, when an attacker scans a server for common vulnerability scripts or tries to read files outside the directory root, the logs will record an excessive number of 404 errors.

Advertisement