Securing Apache

HTTP, the protocol over which the Web travels, is probably the most visible service on the Internet today, and more and more sensitive information is being sent over the Web with each passing day. Secure HTTP is vitally important to e-commerce, because it protects clients' credit card numbers and billing informationconsiderably more critical, especially to home Internet users, than protecting login names and passwords. Secure HTTP is especially important if your business depends on your clients' confidence in the privacy with which you handle their information. FreeBSD's flagship HTTP server, Apache, must be secured if you intend to use it for any kind of commercial or privacy-sensitive purpose.

Securing HTTP was one of the earliest widespread uses for SSL. Until recently, integrating Apache with SSL was a matter for commercial software vendors who developed products based on Apache, and there were comparable but competing versions of SSL-enabled Apache available for free. However, since the release of Apache 2.0, SSL is integrated into the software in the default installation, and enabling it is a much simpler matter. However, for the benefit of users who might still be using Apache 1.3 or earlier, we will cover the SSL implementations designed for that version.

Note

Secure and clear-text HTTP are intended to operate side by side. It's not a good idea to serve all HTTP requests through SSL, and rarely is it done. High-traffic websites would suffer a speed impact from the processing overhead of encrypting every page and image regardless of whether it contains sensitive information, and convenience and convention discourage the practice. Most public web data has no need for encryptionafter all, it's public. But switching to secure mode when a customer enters an online purchasing page or information-gathering form helps to provide your web users with assurance that they're now in a more heavily protected area. Remember, you're serving the user's expectations and confidence as much as the user's data.

Apache-SSL

Apache-SSL is the "official" secure implementation of Apache prior to version 2.0. Apache-SSL has a more limited feature set than mod_ssl, being primarily concerned with stability and performance rather than with advanced features. Development on Apache-SSL is not very active these days, largely because of the tightly controlled feature set and the lack of known bugs.

The Apache-SSL binary is called httpsd rather than httpd; the idea is that you would run a regular httpd to serve regular HTTP requests on port 80, and httpsd to handle encrypted requests on port 443. Of course, this means you would have to have a version of Apache without SSL installed as well to accomplish this.

You can install Apache-SSL from the ports at /usr/ports/www/apache13-ssl, and the official website is http://www.apache-ssl.org.

Apache with mod_ssl

mod ssl is a more complete and active implementation of SSL on HTTP than Apache-SSL. mod_ssl is a standard Apache module that links OpenSSL into Apache, taking advantage of the modern modular architecture of the software. It's more streamlined than Apache-SSL, and it incorporates many more features and a more versatile configuration model. The apache13-modssl port installs a single httpd executable, for example, just like the regular apache13 port, except that the configuration files have special tuning to enable SSL connections when requested:

<IfDefine SSL> Listen 80 Listen 443 </IfDefine>

You can add further modules to Apache with mod_ssl; these include mod_perl, mod_php, and all the rest in /usr/ports/www. The focus of mod_ssl is a rich and complete feature set and easy configurability; it's not necessarily as fast or robust as Apache-SSL, but statistics on this are scarce.

In Apache 2.0, mod_ssl is compiled into the httpd binary by default, and the configuration options for it are given in the basic configuration file /usr/local/etc/apache2/ssl.conf, which you can incorporate into your httpd.conf as necessary.

Apache with mod_ssl can be installed from /usr/ports/www/apache13-modssl; the official website is http://www.modssl.org.

Running a Secure Web Server

Installing either Apache-SSL or Apache with mod_ssl makes maintaining your web server a little more complex. As mentioned earlier, Apache-SSL operates under the assumption that you will run a regular httpd to handle regular clear-text HTTP connections, and httpsd for encrypted requests on port 443. This means that a separate httpsdctl program controls Apache-SSL, operating the same way as apachectl with the regular Apache. Furthermore, an httpsd.conf program is added to /usr/local/etc/apache in parallel with httpd.conf. These separate programs aren't present if you install Apache with mod_sslthe functionality is rolled into a single set of files (you saw these files in Chapter 26, "Configuring a Web Server").

The ports (both apache13-ssl and apache13-modssl) install complete Apache directory treesincluding icons, sample HTML pages, dynamic modules, and configuration files. For this reason, you must take care when updating the parallel installations of Apache-SSL and regular Apache. The mod_ssl version only has a single installation, replacing the standard Apache installation, so the maintenance is potentially much simpler.

Managing Your OpenSSL Certificates

Create your OpenSSL certificates, again using the method you learned in "Enabling SSL Encryption" in Chapter 25. Note that mod_ssl expects to find its certificate in /usr/local/etc/apache2/ssl.crt/server.crt and its private key in /usr/local/etc/apache2/ssl.key/server.key. You can adjust the directives in your Apache configuration file, which specify those files to point to the location of your existing systemwide security certificates. Alternatively, be sure to place copies of those cert files into the locations that Apache expects.

Your OpenSSL certificates are read much more interactively by a web browser than by other secure services, so you must take special care to be sure that the certificates match reality. If the hostname in the certificate doesn't match the server's hostname or if the certificate isn't signed by a recognized Certifying Authority (in other words, if it's selfsigned), the user gets a dialog showing all the information about your certificate and asking for confirmation on whether the browser should accept it. This dialog can bewilder your users and undermine their confidence in your site's security.

Even if your certificate matches your site's information properly, the user can view the certificate's contents through a web browser's Security Information feature, so all the fields you specify when generating the certificate request will be visible to any interested party. Bear this in mindit's fairly difficult to change the information on a certificate once it has been signed.

Poorly Written CGI Scripts

Clear-text traffic isn't the only potential security hole in an Apache installation. If your security model is one where you don't necessarily trust your local users, you should be equally concerned with the possibility of users' CGI scripts running amok on the system (whether intentionally or accidentally) and destroying files. Many files in Apache's document root are owned by the www or nobody user (especially files created dynamically by your own server-side programs); the same www user executes every user's CGI programs as well. Given those facts, it's a simple matter for a user CGI program to be able to delete or modify anything else on the server owned by www.

It's easier than you might think for this to happen. All it takes is for a user to design a CGI program to remove her own unneeded files, but to mistakenly code the program to prepend the wrong path to the filenames. The same might happen in a program that prints data out into a file, potentially corrupting other users' data. Even the most seasoned CGI veterans have fallen prey to this trap. The danger is naturally much higher if you have a malicious user on your system who decides intentionally to write a destructive script to be executed by Apache as www.

The solution to this problem is to run Apache within a "wrapper" program that intercepts user CGI programs, performs security checks on them (making sure the permissions are appropriate), and executes them as the users who own them rather than as www. This has traditionally been done with the suexec wrapper that comes with Apache, but an easierto-use and more flexible solution is CGIWrap, by Nathan Neulinger.

Making CGI Scripts Safer with CGIwrap

CGIWrap, available in the ports at /usr/ports/www/cgiwrap, provides two security advantages: It protects users and the server root from attack by poorly written CGI scripts, and it also enables users' CGI programs to write files that the users themselves can modify or delete in the shell.

In an ideal world, where programs are always written perfectly and nobody tries to sabotage others' files, a user CGI program would be executed by the user who owns it, rather than by the unprivileged www user. However, it's not an ideal worldpeople write buggy CGI scripts, and hackers abound. It's a fairly simple matter for a user to create a CGI program owned by root, put it in his directory, and wait for it to be executed as the owner (the super-user), unleashing its destructive payload against any files in your system.

CGIWrap protects your system against such problems. It's not a complete or ideal solution, but it reduces the security risks associated with user CGI scripts so that you can put your administrative efforts elsewhere. By running security checks against all user CGI programs before executing them, and by running each program as its owner, CGIWrap shifts the risks inherent in a badly written CGI from you onto the script's owner.

When you install CGIWrap from its port directory, the cgiwrap program (a precompiled binary) goes into your top-level cgi-bin directory, /usr/local/www/cgi-bin. Rather than operating as a wrapper around Apache itself as suexec does, CGIWrap has to be called explicitly by your users, with a URL of the following form:

http://www.example.com/cgi-bin/cgiwrap/frank/myscript.cgi

Or as a server-side include:

<!--#include virtual="/cgi-bin/cgiwrap/frank/myscript.cgi"-->

This executes the myscript.cgi program in /home/frank/public_html/cgi-bin. All of a user's CGI programs must go inside his or her public_html/cgi-bin directory, which the user needs to create if it doesn't exist already.

Tip

CGI programs outside the user's public_html/cgi-bin directory will not be run through CGIWrap, so it's important that you disable CGI execution outside the server DocumentRoot. To do so, make sure you don't have an Options +ExecCGI directive in a block that defines your users' directories, and make sure users can't override that setting with .htaccess files (make sure AllowOverride Options is not set for /home).

The official CGIWrap home page is at http://cgiwrap.UNIXtools.org/, for further reference.

Preventing SMTP Relaying

It can be construed as a security weakness for your Sendmail server to be open for anybody to send mail through it. These days, an open mail relay is almost synonymous with a mail server that's being used by spammers to broadcast junk mail, and that constitutes a theft of your services. Furthermore, you're subject to a form of denial of service if other mail service providers add your host to a "blackhole" lista list of banned remote addresses with which they refuse to exchange any mailas a result of your server being an open and unprotected mail relay.

It is critical to configure Sendmail so that your own legitimate users and their correspondents can continue to use your SMTP server, but unauthorized spammerswho want to send mail that neither originates on nor is destined for your servercannot. You can find a full description of how this can be achieved in the "Understanding Relaying" section of Chapter 25.