7.3. Apache
| < Day Day Up > |
| Apache is the workhorse of the Internet. More sites run Apache than all other web server software packages combined by a margin of two to one. Its popularity stems from its maturity (it was one of the first production quality web servers ever), its price (it is released under a free license similar to the GNU General Public License), and its flexibility. Apache's near-infinite configurability, like BIND and Sendmail, however, cuts both ways. It creates a variety of opportunities for security issues. The standard Apache configuration probably releases more information about your system than you would like. It also makes it easy to inadvertently make files available that you did not intend to expose. It is the most commonly used web server, so hackers are well versed in the default configuration, know its weak spots, and know how to leverage them to learn about your system. There are two versions of Apache available, Version 1 and Version 2. Version 1 is mature and stable, and has been under development for almost as long as the World Wide Web has existed. Version 2 began development in 1998 and saw its first beta release in 2000. Despite the years of opportunity to migrate to Version 2, most web servers that run Apache still run version 1.3. If you have an existing infrastructure based on Version 1.3, there is no urgent reason to upgrade to Version 2. If you are starting from scratch, version 2 is a good place to start. You may find, though that you want the functionality that you can only get from modules written to the 1.3 API. You should strongly consider whether you want to use such modules, though, since their authors are not keeping up with the Apache product. Eventually Version 1 will be deprecated and its support will diminish. The threading and performance aspects of Apache have been reworked significantly in Version 2. In particular, the multiprocessing modules (MPMs) allow you to take advantage of your operating system and your particular kind of traffic patterns. If your traffic is steady and heavy, then the multithreading features of the threaded MPM will help you. Additionally, several modules (such as the all-important SSL module) are included by default. Configuring Version 2 is also easier than configuring Version 1. Enabling and disabling modules is done by simply commenting or uncommenting a single line. Modules do not have to be listed in a specific order or more than once in a Version 2 configuration file. The syntax of some popular directives associated with server aliasing and multi-homing have been made simpler as well. 7.3.1. Installing ApacheAs with most FreeBSD installations, you will want to install Apache on FreeBSD using the ports collection so that you have maximum control at build time. There are way too many build options to cover them all, so we discuss the most security-relevant ones. Apache 2 is not included in the OpenBSD ports collection, nor is it bundled with OpenBSD. You must retrieve the sources, configure, compile, and install by hand. Even so, consider reading the section on FreeBSD installation you'll be faced with many of the same choices and set many of the same options. You'll just use the configure script to make your choices. 7.3.1.1 FreeBSDApache 2 may be installed from ports/www/apache2. Before diving into the familiar make and make install, there are a number of options to consider. Note that, if you plan to use Apache in a jail(2) or chroot(2) environment (as described later in "Using Jail or Chroot"), you can choose between using the ports system to build or building from source. 7.3.1.1.1 Makefile optionsThe Makefile in ports/www/apache2 contains many options you can set at build time. If you run make show-options, you may peruse them. A subset of these options, mainly those that have security ramifications, are shown in Table 7-1.
You will control which modules you run and how they are configured by setting these options to make. Even if you're not going to use SSL (or you think you're not going to use it), there is no harm in building it. Simply comment it out in the httpd.conf file and you'll be safe. Even if a vulnerability is reported in mod_ssl and you built a vulnerable version of it, you won't be vulnerable if that module isn't loaded. Example 7-1 shows how to build Apache with a few more restrictive options. Often user IDs and group IDs for privileged users are below 500. Neither FreeBSD nor OpenBSD ship with a standard user ID higher than 100, except nobody on OpenBSD, who is 32767 for historical reasons. Example 7-1. Making Apache with non-default options% cd ports/www/apache2 % make SUEXEC_UIDMIN=500 SUEXEC_GIDMIN=500 \ SUEXEC_CALLER=www SUEXEC_UMASK=0027 7.3.1.1.2 Recording your use of Apache 2Having installed Apache version 2, take a moment to tell your ports system, that you use Apache Version 2 instead of Version 1. Most web-related ports will assume Apache 1 unless they find WITH_APACHE2=YES in your /etc/make.conf(5) file. When you build web-related ports, they will recognize that you use Apache 2 and configure themselves accordingly. At the time this was written, there were about 40 ports that recognized the WITH_APACHE2 flag. 7.3.1.2 OpenBSDIt's worth mentioning that OpenBSD 3.6 distributes Apache 1.3.29 already integrated into the base operating system and there are some compelling reasons to use it. As with all software integrated into the OpenBSD platform, it has been audited by project team members looking for security issues. They've not only audited it but they've also created a chroot environment for Apache! You'll see when we get to Section 7.5 that this is no small effort. In short, they have dotted a lot of i's and crossed a lot of t's for you, and they have a very good track record of doing things securely. Since OpenBSD's ports system does not have the portupgrade facility, tracking the version that is in the operating system is also one of the most reliable ways to stay up to date and take advantage of the team's efforts at securing the software. The bulk of the work for Apache 1 has been taken care of by the OpenBSD team, so we will cover installing, configuring, and securing Apache 2. Download the latest stable version of Apache from http://httpd.apache.org/, extract it using tar, and run the included configure script. This process should be familiar and routine to most system administrators. 7.3.1.2.1 Configure parametersYou will specify to the configure program the same sorts of parameters for your build process that the FreeBSD ports Makefile uses just in a different format. Table 7-2 shows the FreeBSD port option and shows how to set the equivalent configure option to the same default value.
At this point you can make and install Apache 2. Once installed, the security concerns for FreeBSD and OpenBSD are largely the same. 7.3.2. Configuring ApacheA few options and configuration issues apply generally. By default, your end users can influence an awful lot of Apache's behavior. Following the principle of least privilege, you should curtail their capabilities to just the minimum needed to achieve their goals. 7.3.2.1 User overridesMany configuration parameters for Apache can be overridden by your users if you aren't careful. To keep most of the behavior controlled by httpd.conf, you should disable functionality globally and re-enable it at the VirtualHost level and disable users' abilities to override httpd.conf settings with .htaccess files. As a rule you should be aware of which virtual servers or locations use specific features, and you should only enable the features each virtual server needs. The snippet of httpd.conf in Example 7-2 shows how you can generally disable PHP, enable it for a given VirtualHost, and then prevent users from overriding your settings. Example 7-2. Example httpd.conf fragment selectively enabling PHP# disable PHP generally php_flag engine off <VirtualHost www.example.com> DocumentRoot /usr/local/www/data/example # Enable PHP in this virtual server php_flag engine on Options IncludesNOEXEC AllowOverride None </VirtualHost> An important side effect of this configuration is that it disables the users' ability to override all options, PHP-related or otherwise. This is usually not a problem, because only a handful of options are ever overridden, and you can probably work those out on a case-by-case basis. Giving users the liberty to override arbitrary options in their .htaccess files will let them override decisions you have made in the httpd.conf file. 7.3.2.2 Protecting critical filesThere are several files that are worth protecting on most web servers. If you have interactive users logging into the server, it's obvious that you need to keep them away from these files. However, you should protect the files anyways as an application of "defense in depth." If you're using SSL (and most secure web servers do, these days), then you have a pair of very important files: your private key and your public key certificate. The process for generating a private key and a public key certificate, and then having it signed by a certificate authority (CA), is somewhat involved and beyond the scope of this chapter. If you need guidance on how to generate these keys, look at Chapter 17 of Web Security, Privacy, and Commerce by Garfinkel. It has more step-by-step instructions and some explanations. From this point on, we will assume you have a private key in a file named server.key and a public key certificate in server.crt. As you might guess, your private key needs very strict permissions all around. Your certificate may be more loosely protected since it is a public key, but placing it under the same protections isn't a bad idea. Since Apache is run as root and changes identity to some other user after loading these files, only root needs to read these files at all. If an attacker or malicious user is able to compromise these files, then she can defeat the primary protections of SSL. By knowing your private key she can decrypt the transmissions sent to your web server. If she finds a way to intercept traffic, he wins. The public key certificate and private key files are good candidates both for ACLs and/or filesystem flags, as described in Chapter 2. The default path to your public key certificate file is /usr/local/etc/apache2/ssl.crt/server.crt and the default path to your private key file is /usr/local/etc/apache2/ssl.key/server.key. Example 7-3 shows a series of commands that significantly restrict the permissions on these two files. Example 7-3. Restricting access to SSL certificate and key files% CERTDIR=/usr/local/etc/apache2/ssl.crt # create some variables % PKEYDIR=/usr/local/etc/apache2/ssl.key # to make the other commands % CERT=${CERTDIR}/server.crt # shorter % PKEY=${PKEYDIR}/server.key % setfacl -b ${CERT} ${PKEY} ${CERTDIR} ${PKEYDIR} # erase any existing ACLs % setfacl -m u:root:r ${CERT} ${PKEY} # root can only read the files % setfacl -m g:: ${CERT} ${PKEY} # group gets no permissions % setfacl -m o:: ${CERT} ${PKEY} # no one else gets permissions % setfacl -d u:root:r ${CERTDIR} ${PKEYDIR} # Make these ACLs the % setfacl -d g:: ${CERTDIR} ${PKEYDIR} # defaults in these directories % setfacl -d o:: ${CERTDIR} ${PKEYDIR} % chflags schg -R ${CERTDIR} ${PKEYDIR} # system immutable flag, tooExample 7-3 is a good example of using ACLs and filesystem flags in harmony. The ACLs set the overriding permissions on the files, and then the chflags(1) command keeps those permissions from changing as long as the system remains at a securelevel greater than 0.
If your Apache server configuration is rarely updated, you can gain additional security by setting the system immutable flag on the httpd.conf file. This will help prevent an attacker from being able to overwrite your configuration. If you add a lot of VirtualHosts or make changes to your configuration file regularly, consider breaking the volatile configuration elements out of the main httpd.conf file using the Include directive. You might then be able to use the user immutable flag on these files. This will probably thwart a variety of attacks, but it will not require you to reboot in order to make a change to your configuration. 7.3.2.3 Resisting denial of serviceApache's default configuration tries to keep serving web pages as long as it possibly can. Unlike Sendmail, which has various ways of degrading its service if it detects the load creeping up, Apache blithely keeps accepting requests up to the point that some critical resource is exhausted and imposes a hard limit. To help resist denial of service attacks related to resource exhaustion, you can tune your MaxClients in your httpd.conf file. MaxClients is the maximum number of child processes the master httpd will allow to run at a given time. It is not dynamic and it has no knowledge of what your server's capabilities are. You have to size it statically based on your best knowledge of your server's capabilities and its usage patterns. To tune MaxClients, you should start by looking at the size of a typical httpd process and consider how much RAM you have installed in your server. Using the tool top(8), you can see the size (both virtual and resident) of a process. Example 7-4 shows an httpd process in top's output. Example 7-4. Viewing process information with top(8)PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 25682 nobody 2 0 23212K 11512K poll 0:04 4.00% 4.00% httpd The httpd process in our example is 23 megabytes in virtual size, and is using 11.5 megabytes of actual RAM. It's normal for the virtual size to be much larger than the resident size, because the virtual size takes into account shared libraries and other areas of memory (e.g., memory mapped regions of device driver memory) that a process has available. Assuming the server in question has 512 megabytes of RAM, and we need to leave some available for processes other than Apache, we might choose 450 megabytes as our maximum memory allotment for Apache. Dividing 450 by 11.5 suggests that we should set MaxClients to be 39 or 40. After that, we are likely to start thrashing. This calculated number could still be high or low, depending on the complexity of the web pages that are being served. If every web page access requires a CGI program to run a query on a database, we might find that 40 concurrent accesses are not sustainable. If we have a single dynamic page that can cause the server to consume up to 100 megabytes of memory, we'll want to take that into consideration also. If after your calculations your MaxClients value results in serious performance problems, perhaps a memory or CPU upgrade is in order. 7.3.3. Module OverviewThere are a variety of modules that come with Apache. Each provides specific functionality; however, many of them also have specific security concerns. As a general principle, you should only enable modules for which you can identify a specific functional requirement. You should also periodically audit, or at least informally review, your use of Apache to see if modules are enabled that are not being used. In the following sections, we consider eight of the approximately 35 common modules. These eight either have the most significant security risks, are the most commonly used, or both. The CGI, PHP, and Perl modules are the biggest, most complicated, and most dangerous modules that most people run. We discuss how to build, install, configure, and run them safely. The other modules we discuss, while not trivial, are easier to configure properly and have fewer options to worry about. 7.3.3.1 mod_cgiThe CGI module is a critical part of Apache that allows programs to be executed and have their output served as the response to a web query. It is installed and enabled by default. Example 7-5 shows the default settings in httpd.conf for the CGI module, which are pretty reasonable. Example 7-5. Default CGI permissions in httpd.confScriptAlias /cgi-bin/ "/usr/local/www/cgi-bin/" <Directory "/usr/local/www/cgi-bin"> AllowOverride None Options None Order allow,deny Allow from all </Directory> The most important features here are AllowOveride None and Options None. They make it impossible to list the contents of the CGI directory or to do anything other than execute the scripts that live in /usr/local/www/cgi-bin/. Ideally, there should be very few CGI programs that actually live in the ScriptAlias directory. Instead, use a method of running CGI programs as specific users. The mod_suexec and cgiwrap mechanisms are both good ways to contain the potential damage from a poorly written CGI program. The section Section 7.3.4.5 describes how to install, configure, and run them. 7.3.3.2 mod_phpPHP is one of the most maligned web technologies available to run in Apache. It is an interpreted programming language, with a syntax similar somewhat to C++ or Perl. It can either execute as a standalone language, or embedded in web pages through mod_php. Most the dangers of PHP can be chalked up to its Perl-like tolerance of sloppy programming constructs, and the readily available mass of poorly written free PHP programs. You need to carefully consider what scripts you run, what privileges you give them, and how much you can contain potential damage. 7.3.3.2.1 PHP and permissionsPHP scripts execute as the web server's user ID (e.g., www) and group (again often www). This is problematic for a variety of reasons. If the script can be controlled through a code injection attack, it could conceivably kill the web server process (thus acting as a denial of service). Alternatively it could invoke shell scripts, and do virtually anything the www user could do on the system. The unprivileged web user, www, is not usually allowed to write in any part of the filesystem. This means that PHP-based programs will store data in a database, a specific directory that is writable to the www user, or a world-writable directory such as /tmp. A database is the preferable option, but it's not always an option if PHP is built without database support or the PHP applications themselves do not offer that option. This will tempt non-root users to create world-writable directories in the parts of the filesystem they control, so that their scripts can read and write data to permanent storage. World-writable directories are generally a bad idea, but even more so when accessed through PHP scripts of dubious quality. Try to stay aware of the ways your web developers use PHP, and make sure they have appropriate, permissions-regulated places to store their data. A database server like MySQL is probably ideal. Although we are focusing on mod_php, it is possible to build a PHP interpreter as a standalone executable and then invoke it as a CGI. This is not desirable from a performance point of view, but it can be useful on low-bandwidth sites where security is more important than performance. By making the PHP interpreter its own binary, you can use techniques like suexec or cgiwrap to have it execute in its own user context. Users could then run their own PHP code as their own user ID, reducing the potential damage from poorly written code. 7.3.3.2.2 mod_php Apache configurationTo secure the PHP runtime environment, configure it well and make sure that your users cannot circumvent your efforts. The PHP runtime environment is controlled in three places: the php.ini file, the httpd.conf file, and .htaccess files in individual directories. These files control the same set of options, but settings in the httpd.conf file override those in the php.ini file. Any .htaccess files in web content directories can override the httpd.conf options. This order of precedence is shown in Figure 7-4. Figure 7-4. Order of precedence of PHP configuration files What is important to note is that end users have the ability to create .htaccess files anywhere they can create web content. Thus, they can override your server-wide security choices if PHP options in .htaccess files are honored. If AllowOverride includes either Options or All, then users can override the httpd.conf file. Unfortunately, this is a binary option: users have full access to override all PHP settings, or no PHP settings. 7.3.3.2.3 PHP configurationWhile you can configure PHP in a variety of places, it makes the most sense to configure it in the php.ini file. Then, as long as you prevent users from creating their own configurations, you can rest assured that your PHP configuration is in a protected location associated with PHP, rather than commingled with your Apache configuration or distributed across user directories. PHP installs two example files: php.ini-dist and php.ini-recommended. Both of these will be found in /usr/local/etc on a default FreeBSD or OpenBSD ports installation of mod_php. The php.ini-dist file is not intended for use, but instead shows you what the default values are for all the options. It is heavily commented and a good source of information. The php.ini-recommended file lists settings that the PHP team thinks make for an efficient, secure configuration. The following settings help improve the security posture of PHP.
7.3.3.3 mod_perlPerl is a well-known scripting language that is extremely well-suited for writing CGI programs. Its built-in support for parsing strings and matching patterns makes it a powerful tool for web development tasks. Like PHP, Perl is modular, allowing developers to draw on the work of others. Perl's problems in a web context are similar to PHP's. Perl allows many dangerous syntactic structures like the backtick (`). Like PHP, many modules are written partially or totally in C or C++. This means that, even though Perl is a garbage collected language with automatic memory allocation, there may be commands and modules that can be invoked with bad arguments to exploit buffer overflows and the other vulnerabilities caused by poor programming in the underlying C or C++. If you operate a web server of any significance, you probably will be using one or more Perl scripts. It is one of the most popular languages for CGI programming. Like other standalone programs and scripts, Perl scripts can be executed as CGI programs without any special configuration just by placing the scripts in ScriptAliased directories. There is a distinct disadvantage to running Perl as a CGI if you are looking for performance. Each time a script executes, the entire Perl interpreter must be loaded into memory, perform significant runtime initialization, and then run your script. If your script is small and optimized, the time spent in this initialization probably dwarfs the time spent actually doing anything useful. If your web site is not popular, or the script is rarely run, this probably does not matter. The answer to running the interpreter as a CGI is mod_perl. The mod_perl module was created to load one instance of the Perl runtime environment into memory when the server starts. Then, all scripts can execute in this prepared environment. This provides major performance improvements. As an additional measure of security, add the line PerlTaintCheck On to your httpd.conf file. This requires Perl code that is executing under mod_perl to obey Perl's taint rules. This is the same as invoking perl -t to run the script. These rules effectively force developers to perform (at least trivial) input filtering. They must perform some transformation on any data that comes from outside the program (e.g., an environment variable, a web form input, and so on) before they can subsequently use that data in certain contexts. For example, a value that was provided to the script by a form element on a web page cannot subsequently be passed unmodified as an argument to an eval statement; some string replacement must be performed first. See the perlsec manpage for documentation on Perl's taint mode. While PerlTaintCheck is not bulletproof, it causes all mod_perl programmers to at least perform a few input checks on their code. In particular, because it is systematic and automatic, it helps programmers find places where they need input filtering. Good programmers will welcome the assistance and use it to help them harden their programs. 7.3.3.4 mod_includeThe mod_include module provides server-side-include (SSI) functionality. It's most often used to provide very simple and straightforward inclusion of one file within another. It can also execute commands on the server and insert the results of the command's execution into the file, before the file is sent to the web browser. It also provides a variety of convenience routines such as the ability to determine and print file modification times, file sizes, and the server's current time. HTML files are only parsed for SSI directives if mod_include and parsing are both enabled in the httpd.conf configuration file. Typically this means establishing the server-parsed handler for files ending in .shtml and enabling the Includes option on a web-visible directory. Some administrators also like to use the XBitHack directive so that any HTML files marked executable on the filesystem will also be server parsed. This is especially useful when taking existing sites and adding SSI functionality. You won't have to rename pages, so you don't have to update cross-references. The HTML fragment in Example 7-6 demonstrates several different mod_include directives. We discuss several security implications using it as a reference. The scenarios are ordered from least risky to most risky, with the final scenario effectively offering an attacker a variety of ways to totally compromise the web server. Example 7-6. HTML file using mod_include directives<h1>Server Information Page</h1> <p>This is our standard disclaimer:</p> <p><!--#include file="disclaimer.html" --></p> <p>Here is a dubious way to retrieve the date:</p> <p><!--#exec cgi="/cgi-bin/my-date" --></p> <p>Show the user what query string they used:</p> <p>You typed <!--#exec cmd="/bin/echo $QUERY_STRING" --></p> The first #include directive in Example 7-6 is the classic example of how SSI can be used simply and safely. Apache merely opens the file disclaimer.html (which, by the syntax in the example, must exist in the same directory as our example file) and inserts its contents directly into that part of the file before it is sent. The file disclaimer.html does not need, therefore, to be a complete HTML file. In fact, it need not contain any HTML tags at all in our example. It can, however, include SSI directives; and if it does, they will be parsed. The mod_include module can be used recursively and will continue to parse directives that it finds in each included file. Unless a dangerous use of SSI directives exists in disclaimer.html, this is a simple and safe use of SSI. For security reasons, the file specified in the #include directive may not be absolute: it may not begin with / nor may it contain ../ or any encoding of that string. Untrusted users are often allowed to create web pages on web servers, so this prevents directives such as <!--#include file="/etc/passwd" --> from divulging the contents of sensitive files. The next lines in Example 7-6 execute a CGI program called my-date from the server-wide /cgi-bin directory. This looks like CGI, but it is actually different. The output of the CGI command will be inserted unmodified into the middle of the body of the web page. Thus, if the output of the CGI program's output is not plain text or HTML, it is likely to look very bad when rendered in the web browser. Outside the context of mod_include, CGI programs can return any kind of data. They can send images, spreadsheets, movies, or any other MIME[1] content type. When executed by a server-side include, however, their data will be embedded inside a document, so it only makes sense to send text or HTML.
When invoking a CGI through mod_include, an attacker can influence the environment in which the CGI executes through the query string and the user agent identifier. When a user requests a web page, he can specify a query string, even though the page does not process queries. For example, he can access the page via a URL like http://www.example.com/index.html?ATTACK=true. Despite the fact that index.html is a plain HTML file, this is legal syntax. If index.html invokes a CGI program through the #exec directive, the QUERY_STRING environment variable for that CGI program will be set to ATTACK=true. If the CGI program parses the QUERY_STRING variable, then an attacker can try to insert, for example, shellcode to make the CGI misbehave. Thus, a file that appears to be pretty safe at first glance can actually incorporate CGI code that is vulnerable. Lastly, Example 7-6 demonstrates how to execute a shell command directly from inside an HTML file. This a very bad practice, especially in our example, because we pass QUERY_STRING as an argument to a shell command. This gives an attacker the opportunity to craft query strings that can be passed directly to programs executing on the host system. A specially crafted URL such as http://www.example.com/?foo;/bin/date will show foo, followed by the output of running /bin/date. Imagine the consequences if /bin/date were replaced with rm -rf /*! It wouldn't remove the whole filesystem, but it would remove everything the www user could remove. The availability of mod_include functionality can be limited on a system-wide, per-VirtualHost, or per-directory basis. Additionally, given how dangerous the #exec option can be, it can be restricted separately as shown in Example 7-7. Example 7-7. Permitting SSI while denying #exec<VirtualHost www.example.com> DocumentRoot /data/www/www.example.com Options None AllowOverride IncludesNOEXEC </VirtualHost> Unless you have a specific use for SSI, disable it. If you do have a specific need for it, enable it without enabling #exec. 7.3.3.5 mod_davThe DAV module was created to offer compatibility with the Distributed Authoring and Versioning (DAV) protocol, defined by the Internet Engineering Task Force (IETF) in RFC 2518. Microsoft created the DAV standard, which defines a variety of methods within HTTP. In addition to the usual GET, POST (and other less well-known methods) defined in RFCs 1945 and 2068, DAV defines methods like SEARCH and PROPFIND. In this way, products like Microsoft Outlook Web Access can use the same shared calendar and other shared resources that the proprietary clients like Outlook use. Unfortunately, Apache's mod_dav implements a free-for-all security model. Though you can restrict access to it in a robust manner, once a user is authenticated she is authorized to do anything. There is currently no way to map the authentication at the HTTP level to Unix authorization on the filesystem. If you cannot use digest authentication, at least protect the DAV traffic by using SSL. All the DAV directives work within SSL-enabled sessions. This will protect your user IDs, passwords, and the actual web content as it passes from the user's client application to your server. You may find performance suffers in such a situation, however. DAV sessions use many very small HTTP requests more than a normal web browsing session. Add the overhead of cryptography, and it may not be acceptable under heavy load. Enable mod_dav at your own risk. The primitive authentication/authorization capabilities create a situation where all users who have any access have full access to the data stored there. Such a permissions structure does not work for many organizations. Furthermore, if you accidentally fail to apply any restrictions to the DAV-enabled filesystem, then anyone who notices that DAV is enabled will be able to store arbitrary data there. You will quickly become a hot spot for trading illegal software. 7.3.3.6 mod_autoindexApache includes an automatic file and directory indexing module called mod_autoindex. It is helpful for people who just want to make files available through the Web with minimal effort. The module can be configured to understand a variety of file types, decorate the file listings with appropriate icons, and to display any README files that happen to be in the directory. mod_autoindex is also the module that determines what names of files will be displayed (and an order of precedence) when a URL is requested that does not correspond to a file. For example, the main web page for most web sites is usually named either index.htm or index.html. The contents of index.html are sent when the URL http://www.example.com/ is requested. When no index page is available, mod_autoindex sends a directory listing. It is often the case that novice web developers, or their web-authoring software, will choose a default filename for a web page that is something other than the traditional index.html. For example, if the directory is marketing, then the software or the developer will sometimes name the main file marketing.html. This would be accessible via a URL such as http://www.example.com/marketing/marketing.html. The novice developer might not realize he could have a prettier URL such as http://www.example.com/marketing/ by naming the file index.html. Imagine that the rest of that directory contains marketing materials that should not be downloaded directly; instead, they should only be available to someone after he fills out the form in marketing.html. If a visitor strips marketing.html off the end of the URL, however, he will see the directory listing, and can bypass the form altogether.
The worst impact of mod_autoindex, then, is that it sometimes makes it easy to bypass security-through-obscurity mechanisms on the server. It is not exploitable to gain unauthorized access to the system or cause any other major problem. Like other modules, it should be disabled unless you have a specific use for it. Also like other modules, it can be disabled by default and only enabled on specific areas. 7.3.3.7 mod_info and mod_statusTwo modules, mod_info and mod_status, provide information to an administrator about the running configuration. They can help you troubleshoot problems or just give you a current snapshot of the runtime status of your server. However, without any constraints, they are the next best thing to posting your httpd.conf file on your web site, which is probably something you do not want to do. Your security cannot realistically depend on obscurity, but there is no need to casually divulge configuration information. In the interest of keeping your server's configuration hidden from prying eyes, you should carefully consider whether you need to use mod_info and mod_status at all. If you do need to use them, you should consider how tightly you can control access to them. They are marvelous diagnostic tools for understanding how your server is configured. If an attacker can reach them, however, she can learn a great deal of information. It is tempting to simply restrict access to these modules to the local loopback address (e.g., 127.0.0.1 or localhost). After all, you are the administrator and only you can generate requests to the web server that originate on the web server, right? Consider the case where a user can put the following string in a web page and use server side include processing: <!--#include virtual="/server-info/" -->. The request for the server-info web page embedded in their HTML will originate from the local system. Remarkably, this request will succeed and the user will be able to embed your server's information in his own web page, which he can peruse. In general, you should disable these two modules except during times when you are specifically troubleshooting a problem. When they are enabled, only enable them in a VirtualHost that you control for system administration purposes. You should use some sort of username and password-based security, on top of IP address-based security. Instead of restricting access to localhost, allow connections only from your workstation, or an administrative host or subnet. 7.3.3.8 mod_userdirOn large, multiuser systems the average non-root user needs a mechanism for making web pages and displaying them. Apache offers this functionality through mod_userdir. A user can have a directory and files in a well-known location (a directory named public_html in her home directory by default), and Apache associates that directory with a URL based on her login name. For example, user jsmith might have a home directory /home/jsmith. The file /home/jsmith/public_html/index.html, then, would correspond to the URL http://www.example.com/~jsmith/. By itself, this module does not create any noteworthy security concerns. However, it can be combined with server-side includes, PHP, CGI, or suexec, for example, to create security risks. The primary risk is that it gives every user a place where he can install his own .htaccess file and bypass (inadvertently or intentionally) restrictions you placed in the system-wide httpd.conf file. This is where users can create their own PHP configuration options, for example, that may differ from your site-wide defaults and create more risks.
If you have users who need this style of web page access, be careful what other options you provide and what you allow them to override in their .htaccess files. 7.3.4. Apache Best PracticesThere are a few specific recommendations for running an Apache server that can help you run it more securely. Some of them are operating system tuning parameters, while others are configurations of Apache itself. If you consider applying these practices, be sure to consider your specific situation. It is not necessarily true that you should turn on every security option and every optimization possible. In general you should enable only the modules you need, and the optimizations that address specific problems you face. 7.3.4.1 Enable only modules you needAs mentioned previously, instead of disabling modules you do not think you need, disable all modules. Then enable only those you know you will need. If you run into problems, you should be able to figure out which additional modules you need to enable. Apache provides a small set of example configuration files. One of them, typically named highperformance.conf has a minimum number of modules enabled. Although it also has a variety of other options tuned for performance, the LoadModule commands are the most relevant to consider in terms of minimizing modules. Modules are enabled and disabled in the httpd.conf file by commenting out the corresponding LoadModule directive in the httpd.conf file. In Apache 1.3, there is an additional AddModule directive that must also be commented out. Failure to disable both lines in an Apache 1.3 will result in a syntax error. Furthermore, for Apache 1.3, the AddModule and LoadModule directives must list the modules in the same order. Apache must be restarted for these changes to take effect. 7.3.4.2 Minimize information leaksUnless Apache is configured otherwise, the web server will provide its version (e.g., Apache/2.0.52), which modules it has (e.g., mod_perl, mod_php), and even the module version numbers (e.g., PHP/4.3.2). It sends this information not only in the environment available to CGI programs and SSI pages, but also in the headers of every HTTP response. For example, a fully loaded web server with no special configuration might send the following in every HTTP response: Server: Apache/2.0.52 (UNIX) PHP/4.3.2 mod_perl/1.26 mod_ssl/2.8.16 OpenSSL/0.9.7b That is a wealth of information for an attacker. OpenSSL has had known exploits in the past, including a timing attack that could divulge the server's private key. By offering up version information so willingly, you only help potential attackers. You certainly do not benefit in any way from including this information.
By default, Apache will also append a tag line to the bottom of any pages it generates for you (such as those created by mod_autoindex and error documents). That tag line indicates that the web server is Apache and it often includes the version number. Again, this is information that you, as an administrator, have no need for; however, it may prove useful for attackers. Unlike BIND and Sendmail, there is no trivial way to cause Apache to report a fake version identifier. A little obfuscation to confuse the script kiddies never hurts. The most you can do, without modifying source code, is to make Apache simply report itself as "Apache." This is easy to configure, as shown in Example 7-8. Example 7-8. Disabling extraneous version information in httpd.confServerTokens ProductOnly ServerSignature Off 7.3.4.3 Always separate HTML and CGI locationsApache tries to protect the CGI directory from being browsed to prevent the programs from being downloaded instead of executed. However, if the CGI directory (almost always called /cgi-bin/) is within the DocumentRoot of a virtual server (or within a user's ~/public_html directory), then there is a chance that the programs can be downloaded. All too often programs such as Perl scripts will embed sensitive information like database usernames and passwords in the source code of the script. If the script is downloaded, an attacker learns something valuable (and perhaps directly exploitable) about your systems. On a related note, watch out for lingering artifacts from development and test. Developers and administrators frequently create scripts like test.sh or phpinfo.php within the DocumentRoot in the course of developing or debugging a web application. It is critical that these sorts of scripts be removed or made nonexecutable when they are not actively being used. Better yet, restrict these kinds of activities to a development or test environment that is not directly exposed to external visitors. Tools exist that crawl through web sites and check for long lists of commonly named debugging scripts. Use them, before they're used against you. 7.3.4.4 Protect sensitive configuration filesAnother way attackers probe system security is by trying to download .htaccess files. In order to have their desired effect, these files must live in web-accessible directories. However, they also give clues to the security of the system. For instance, they may identify resources that are protected, thereby giving an attacker a roadmap for future attacks. Rules such as the one in Example 7-9 are typical in the outermost scope of an httpd.conf file. Example 7-9. Protecting .htaccess files in httpd.conf<Files ~ "^\.ht"> Order allow,deny Deny from all Satisfy All </Files> This rule is provided in most example httpd.conf files. It protects any file beginning with .ht like password-based access files, commonly named .htpasswd and .htgroup. There is no reason that the files need to be named .htaccess, .htpasswd, or .htgroup. In fact, as a security precaution, you should probably choose other names for these files and don't store password and group files within the DocumentRoot. But just in case your system users fail to heed this advice, protect them from being downloaded by implementing a configuration similar to Example 7-9. 7.3.4.5 Run CGI programs as normal usersWeb server administrators often find themselves performing a variety of security gymnastics to make all the UIDs of all the processes match their requirements. The httpd process must run as root, initially, in order to listen for connections on ports less than 1024. Once a connection is made, the server process immediately switches to the unprivileged www user to minimize the risk of doing bad things as root. In addition to root and www, you have users who generally do not login to the web server either as root or as the www user: they must also be accommodated by the web server configuration. Since the script running as the www user cannot normally write files into directories owned by a normal user, novice users often create world-writable directories and files for their CGI program ouput and scratch space. Clearly this is not very desirable from a security point of view. Both suexec and cgiwrap allow users' CGI scripts to run under their individual UIDs. Their scripts can read and write files anywhere in their home directories, and damage from any poorly programmed scripts they might write will be contained. While undesirable, it is better to put one user's data at risk than many users' data. 7.3.4.5.1 cgiwrapOn FreeBSD, cgiwrap can be installed from ports/www/cgiwrap. It is not available in the OpenBSD ports tree, but it is not complicated and it has no dependencies. Retrieving the source, configuring, and installing it manually under OpenBSD is not difficult. In either case, the net result is a pair of setuid root binary files named cgiwrap and cgiwrapd, which may be placed in your CGI directory (e.g., /usr/local/www/cgi-bin). They should be executable, but not readable, by all users. There are no changes necessary to Apache's configuration. cgiwrap examines its PATH and execution environment, determines dynamically which user's permissions to adopt, and then invokes CGI programs with that user's permissions. Its purpose is to perform critical safety checks, and then switch users in a way that is safe and does not create new exploit possibilities. One advantage to cgiwrap is that it supports lots of different users, all using their own sets of CGI programs. You can install cgiwrap once, in one location, and then all users' web sites can take advantage of it. cgiwrap also includes a very useful debugging binary called cgiwrapd that can be installed in the CGI directory. When it is invoked, instead of cgiwrap, the output of the CGI program is turned into plain text and sent along with a report of the execution environment. Normally, when a CGI program exits prematurely and produces bad output or no output, the Apache server simply sends a generic Error 500: Internal Server Error web page to the browser. This makes debugging problems very difficult without access to error logs. With cgiwrapd, developers can point to a debugging URL like http://www.example.com/cgi-bin/cgiwrapd/user/myscript and get more useful output.
One of the primary disadvantages to cgiwrap is its complexity. Users put their scripts in an obvious filesystem location, such as /home/user/cgi-bin/myscript, but the URL for the script will be something unintuitive like http://www.example.com/cgi-bin/cgiwrap/user/myscript. If you download CGI programs that someone else wrote, you may find it difficult to configure them to run in a cgiwrap environment. 7.3.4.5.2 mod_suexecThe suexec module comes with Apache and uses a slightly different approach to running CGI programs under users' own IDs. The Apache httpd documentation describes 20 checks that suexec performs before actually executing code as a user other than the unprivileged www user. Although we can't cover all 20 checks, two of the most useful include making sure that the file to be executed is owned by the target user and is not writable by anyone else or setuid. Ultimately, however, these checks merely determine whether the program is allowed to run and if it may be run with the privileges of the designated user. The primary advantage of mod_suexec is its tight integration with the Apache web server. It can operate in ways cgiwrap cannot, because it can intercept requests for CGI programs before they are dispatched. With mod_suexec installed, two new directives, User and Group, can be used in VirtualHost definitions. These directives, as you may suspect, define the user and group under which CGIs must run. Additionally, mod_suexec can be used with mod_userdir style directories (e.g., http://www.example.com/~jsmith/), executing CGIs with the appropriate user's permissions. Example 7-10 is analogous to Example 7-7 where the CGI programs in this example server all execute as user jsmith. Example 7-10. Enabling mod_suexec in httpd.conf# This expands the configuration from Example 7-7 <VirtualHost www.example.com> DocumentRoot /data/www/www.example.com Options None AllowOverride IncludesNOEXEC User jsmith Group webusers </VirtualHost> There is one small disadvantage with mod_suexec. It is not as simple to enable or disable as cgiwrap. Enabling it, disabling it, or reconfiguring it, requires changing the Apache configuration file and restarting the server. It also does not offer the debugging aid that cgiwrapd offers. On the other hand, a mod_suexec-based server is slightly easier to delegate to a junior administrator than one that uses cgiwrap. While restarting the server is an unfortunate requirement, it is a task that can be easily done using apachectl(8) via sudo(8). Likewise, editing the httpd.conf file can also easily be delegated to junior administrators. cgiwrap, on the other hand, requires the authority to manipulate files that are setuid root. 7.3.4.6 SummaryRemember that no runtime environment can ensure that CGI programs have no errors or vulnerabilities. These two programs are simply privilege containment systems. They enable users' CGI programs to read and write into the filesystem safely, and they help control damage from poorly written programs. It is still vitally important that your CGI programs be well written. 7.3.5. Encrypting Web TrafficBy default, web traffic is sent in plain text, so if someone can eavesdrop anywhere in the network between a client and a server, she can see everything that goes by. Encryption helps to protect sensitive data when it is transmitted over the Internet. RFC 2246 defines a protocol called Transport Layer Security (TLS). This is the standardized version of a protocol originally developed by Netscape called the Secure Sockets Layer (SSL). Despite the fact that virtually all encrypted web traffic uses the modern TLS protocol, the vast majority of people still refer to encrypted web traffic as SSL. We follow this convention as well. SSL is a transport layer protocol, just above the HTTP level, encrypting what would normally be clear-text HTTP traffic. Figure 7-5 shows most of the OSI reference model network layers, with the ones relevant to our discussion in black. The web browser in this example transmits the password "mozart" to the transport layer. At the transport layer, the password is encrypted using a session key that has been pre-established between the web browser and web server. Figure 7-5. Network protocol stack showing SSL encryption SSL generally gives you two assurances: (1) the data is encrypted as it is transmitted over the Internet; (2) your browser really is communicating with the site you think it is. There are a variety of ways to undermine the fundamental assumptions that make these two assurances strong. Your operating system, however, can only do a little to prevent SSL from being subverted. We will mention what you can do, but some of the concepts required to fully discuss the risks (certificates, authority and trust, and DNS integrity) are too big to cover here. 7.3.5.1 SSL and certificatesBefore you can SSL-enable your web server, you must generate a private key and get a signed certificate as described previously. For detailed instructions and to purchase a certificate, visit either a low-end retailer like InstantSSL (http://www.instantssl.com/) or a high-end retailer like Verisign (http://www.verisign.com/). They have complete instructions on what you must do and can walk you through the process. You can also create your own certificate independent of any certificate authority. The problem with self-signed and issued certificates, however, is that your users will see many ugly warnings from their web browsers. You have to tell your users to dismiss these warnings about untrusted certificates. If they ever are the victim of a man-in-the-middle attack, though, they will blithely dismiss the warning that is their only clue that their session has been hijacked. For the sake of your users' trust, you should purchase a commercial certificate.
7.3.5.2 Enabling SSLAssuming you have gone through some process, commercial or otherwise, to obtain a signed certificate, you have two files: a public key certificate and a private key. We will call the public key certificate server.crt and the private key server.key. This naming largely follows the examples Apache has laid out. Example 7-11 shows a minimally configured SSL-enabled Apache VirtualHost. Example 7-11. Apache SSL configuration<VirtualHost *:443> DocumentRoot /usr/local/www/data/secure SSLEngine On SSLCertificateFile /usr/local/etc/apache2/ssl.crt/server.crt SSLCertificateKeyFile /usr/local/etc/apache2/ssl.key/server.key </VirtualHost> At this point, your web server will listen on port 443 (the officially designated port for HTTPS) and will communicate over SSL. 7.3.5.3 SSL, TLS, and cipher choiceAs an HTTPS connection is established, the two sides browser and server each send a list of their cryptographic capabilities. Each identifies which ciphers it understands and what parameters it supports with those ciphers. For example, a browser with export-grade cryptography might identify itself as supporting DES, but only with 56-bit keys. During this handshake, the strongest algorithm that both browser and server support will be chosen. If a web browser connects and only offers the weak encryption, your Apache server has two choices: continue the connection with weak protection over the data, or close the connection telling the browser that they have no satisfactory algorithms in common. There are a number of ciphers that are common and well-known, but are also cryptographically weak. RC2, RC4, and export-grade DES should be avoided if possible, especially by e-commerce and financial sites. 7.3.5.4 Restricting ciphers at the serverYou can restrict which ciphers your server is willing to use to ensure that only clients capable of high-grade cryptography can connect with the SSLCipherSuite directive. If you restrict which ciphers you are willing to use, realize that you will restrict which web browsers can connect. Older versions of Microsoft Internet Explorer and Netscape, especially those that shipped with export-grade cryptography, will have a limited set of ciphers available. The SSLCipherSuite directive in your httpd.conf file is a very complicated directive with a dense syntax. It controls which algorithms are accepted by your server and your server's order of preference. By default, Apache is configured with a pretty generous set of algorithms. The default SSLCipherSuite directive is: ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP The Apache mod_ssl documentation describes what this cipher suite includes quite clearly:
If you want to create a more secure configuration, consider the following cipher specification: TLSv1:!ADH:!EXP:!NULL:!MD5:!LOW:+HIGH:+MEDIUM This favors TLS ciphers, without any anonymous Diffie-Hellman, no export-grade ciphers, no NULL ciphers (i.e., those that don't actually encrypt), no algorithms that use MD5 for their hash, and none of the weak algorithms (such as RC2) that have been classified as "low" grade. It favors the "high" grade algorithms (such as AES with 256-bit keys) over the "medium" algorithms (such as RC4). You can find out what the aliases "high," "medium," and "low" refer to by looking at the manpage for ciphers(1) on FreeBSD or openssl(1) on OpenBSD. If you are too draconian in your selection of ciphers, you should be aware that some users will utterly fail to connect to your server, and you will have no opportunity to send a nice error message when that happens. The web browser will issue an error message that is probably opaque and incomprehensible to the user. Internet Explorer gives its general-purpose (and wrong) Cannot find server or DNS Error message. Mozilla Firefox says, Firefox and www.example.com cannot communicate securely because they have no common encryption algorithms. To make matters worse, since the browser and server never properly communicated, there will be no trace of this failed attempt in your server logs. An IDS system might be able to detect and log such failures, but Apache cannot. A good solution is to support one or two low-grade ciphers and, using some JavaScript, PHP, or SSI, redirect users to a page that handles their request. The page could recommend that they upgrade their browser, or warn them that they are using low-grade cryptography, or redirect them to a server where low-grade cryptography is acceptable. 7.3.5.5 CPU usageWhen enabling SSL, you will find that the computational load on your server increases. The cryptography involved in SSL is nontrivial. Busy sites will quickly discover that the CPU cannot keep up with nearly the same number of connections over SSL as it can over vanilla HTTP. There are two solutions to this problem: add more redundant servers or install hardware cryptographic accelerators. You might be tempted to add redundant servers to meet demand, but there is probably a more cost-effective method that more fully exploits the power of OpenBSD and FreeBSD. A hardware cryptographic accelerator can offload the computation involved in performing cryptography. They also often provide hardware random number generators, which are better than any software-based pseudorandom number generators, making your transactions more secure. This is an area where OpenBSD excels, and FreeBSD does almost as well. You only have to purchase and install a compatible hardware cryptographic accelerator card and OpenBSD will detect it and use it by default. The list of compatible cards is constantly growing, and can be found in the release notes for whichever version of OpenBSD or FreeBSD you install. What makes it so easy to use is the fact that the hooks for using acceleration are already built into the kernel and all devices that are supported register themselves at boot time. Simply by plugging a card into a PCI slot, the system will detect the card at boot and begin to perform hardware-accelerated cryptography. See Chapter 2 for more information on hardware-accelerated cryptography in the BSDs. |
| < Day Day Up > |
EAN: 2147483647
Pages: 142