One of the most important things to consider when installing Apache is what types of functionality the web server needs to have. For instance, are PHP scripts or Perl scripts going to be run? Will Server Side Includes be used in the application running on the web server? Once you can create a list of needed functionality, you can enable the appropriate modules. You can retrieve a list of all the enabled modules by using httpd:
# httpd –l Compiled-in modules: http_core.c mod_env.c mod_log_config.c mod_mime.c mod_negotiation.c
mod_status.c mod_include.c mod_autoindex.c mod_dir.c mod_cgi.c mod_asis.c mod_imap.c mod_actions.c mod_userdir.c mod_alias.c mod_access.c mod_auth.c mod_so.c mod_setenvif.c mod_perl.c
To disable modules, use the configure script before compiling and pass in any modules that should be disabled.
• For Apache 1.x./configure --disable-module=userdir
• For Apache 2.x./configure --disable-userdir
This method is used to remove built-in modules in Apache and does not apply to dynamic modules.
The modules shown in Table 3-2 could be a security risk and we recommend removing them in your Apache configuration.
Module Description
mod_userdir Allows username home folders to be present on the web server via the /~username/ request
mod_info Allows an attacker to view the Apache confi guration mod_status Displays runtime information about Apache status
mod_include Allows the use of Server Side Includes, which are rarely used today and can represent a signifi cant security risk
Implement ModSecurity
ModSecurity is an Apache module written by Ivan Ristic that works as a web application firewall. It has a huge amount of flexibility and is considered one of the best projects available in terms of helping to secure Apache against application and web platform attacks. Some of ModSecurity’s features are listed here:
• Request fi ltering
• Anti-evasion techniques • HTTP fi ltering rules • Full audit logging • HTTPS intercepting • Chroot functionality • Mask web server identity
Chrooting Apache
One of the standard rules in security is to practice defense in depth. When attackers break into a web server, one of the first things the attackers will do is attempt to access files on the system such as /etc/passwd, or escalate their privileges via a local exploit. In order to prevent this type of attack, a method of putting the Apache server in a contained environment, or “jail” of sorts, has been created, and it is called chrooting. By implementing this, Apache runs with limited privileges inside of its own contained file system. If attackers were to gain access to the file system, they would be stuck inside this jail environment with no access to the real file system. There are two methods to chrooting Apache that we’ll review here.
External Chrooting
This type of chrooting starts out with a file system that contains nothing but the basic shell. All processes and required dependencies need to be copied to this environment in order to run. This is a real containment method for Apache in that if an attacker breaks into a shell somehow, he has nowhere to go. The method to set up and configure this kind of jail is complex and requires research, depending on what software is required to run with the web application. To find out more detailed steps on how to set up this environment, see the “References & Further Reading” section at the end of this chapter.
Internal Chrooting
Internal chrooting is different from external chrooting in that during internal chrooting, the chroot is created from inside the Apache process. Apache starts out and initializes normally but then creates a chroot environment for the process to run. By default, Apache
does not support this kind of chroot method. However, a couple of people have created third-party add-ons that enable Apache to support this.
• ModSecurity supports a chroot environment via its SecChrootDir confi guration. Just set the value to the directory where you would like Apache to be jailed. • ModChroot is an Apache module that works in the same manner as the
ModSecurity chroot. Just set the ChrootDir to the proper directory. • Apache chroot(2) patch by Arjan De Vet is an actual patch to Apache that
enables support for internal chrooting.
Implement SuExec
Implementing an execution wrapper like SuExec allows you to run CGI scripts with the privileges of another user besides the default Apache web user. Used correctly, this can help enforce the principle of least privilege, which is an important element of building “defense-in-depth” into a web server. Let’s look at an example where SuExec could be used to provide least privilege.
A multihosted environment exists that allows each virtual-hosted web site to upload and host its own scripts. If SuExec is not used, any hole, or even a malicious web site administrator, could access the contents of any of the other web sites being hosted on that server. This can be a big problem, particularly if you have tested your web site and have taken all precautions to secure your code and create a good secure web configuration, only to find out you were hacked because one of the other virtual sites had a security issue and an attacker gained access via that route over which you had no control.
Now you can see why something like SuExec is important. Installing and configuring SuExec can sometimes be a complex and frustrating process. SuExec’s configuration is very strict and multiple things have to be set up properly. We suggest walking through the process using Apache’s documentation, which can be located in the “References & Further Reading” section at the end of this chapter.