By: Blane Warrene

November 3rd, 2004

Reader Rating: 7.5

Information security has become a standard function for system administrators of all stripes and in all sizes of environments. One of the most critical pieces of the security puzzle is to lock down production and development Web servers.

A new book from Apress by Tony Mobily, titled Hardening Apache [1], takes securing this most popular Web server to the next level, and brings users of all experience levels into the world of secure configuration.

The book walks intuitively through the setup process, from download and verification, to configuration and modifications, to running in production mode. Here's the Hardening Apache Table of Contents:

1. Secure installation and configuration


2. Common attacks


3. Logging


4. Cross-site scripting attacks


5. Apache security modules


6. Apache in jail


7. Automating security


8. App. A: Apache resources


9. App. B: HTTP and Apache


10. App. C: Chapter checkpoints

A Chat with The Author

Tony Mobily, who previously authored Professional Apache Security for the now defunct Wrox Press, knows his Apache. This resident of Western Australia started out to become a programmer, describing his early work as that of a 'wanna-be' hack.

"At the beginning, I guess I was a bit of a 'script kiddie' (I was young and I used pre-made exploits!); but then, thanks to my programming skills, I managed to dig in deeper into this amazing field, and I became more aware of the underlying techniques and problems. Maybe, it was then that I became a real 'hacker' -- if I can say I am one," Mobily told SitePoint.

However, he soon came to realize his strengths were in systems administration, and cut his teeth on IBM's AIX and Linux. As the Internet emerged, he jumped on for the ride and decided that 'Net security was his game.

When asked what inspired him to pen Hardening Apache, Mobily's answer reveals his passions about the subject.

"Somebody had to do it, but nobody seemed to be doing it right, nor did it look like they would in the near future. For example, if you look at PHP, you can probably find around 35 books. 15 of them are complete rubbish. 10 of them are quire readable. 8 of them are very well done. 2 of them are true gems -- well thought, written, edited, and published," he said.

"For Apache security, this wasn't going to happen, and my goal was to write -- well, a 'very well written book'. The first attempt, with [Wrox], wasn't a great success. I was only part of a team, and many people said that the book didn't work because it was too fragmented. With Hardening Apache, I wanted to get it right. And I believe I did."

Fundamentals

From the start, Mobily requests the patience of the reader as he covers an element of security that's not always foremost in an administrator's mind: the validity of a download and a lean, clean installation.

For some, this may not be a major issue; however, there are Website infrastructures that require the highest levels of security, be it for compliance reasons, or simply to appease a paranoid management.

Mobily goes beyond the usual MD5 checksum and delivers a primer on the use of GnuPG for the verification of a file even when it's downloaded from an authorized source (in consideration of the possible site and source file hack).

A very solid guide to building Apache from source is provided, which addresses both versions 1.3.x and 2.0.x.

Checking for Leaks

This book first introduced me to Nikto [2], a handy tool created by the folks at Cirt.Net [3] for the comprehensive scanning of your Web servers' security.

As described on the Cirt site,

It includes support for Unix systems (which would of course include Linux and Macintosh OS X) and Windows-based machines, and is the replacement for htmap from the same group.

This is an excellent starting point for those performing a thorough review of servers under their administration for security, vulnerability and the tightening of configurations.
Configuration

I particularly liked Mobily's review of configuring httpd.conf prior to the setup of virtual servers. It keeps the cart behind the horse, patiently ensuring that the system is ready to host those domains, with a run down on Apache modules from a security perspective, along with some tweaks.

These include excellent explanations for the use of third party modules like mod_security, mod_bandwidth, and mod_dosevasive to ramp up security.

Some of the author's tips include the modification of headers with 'ServerTokens Minimal' in httpd.conf -– this drops the Apache version number from a header sent as part of an HTTP request.

Another possibly controversial change is a suggestion for disabling HTTP TRACE either through a <Location /> container, or outside of all containers as a global directive using mod_rewrite. See the W3C's definition of HTTP TRACE [4] if you need more information on it.

RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .*  [F]

Note that all code samples provided in the book are available online for download at the Apress Website [5].

Key Factors in Apache Administration

The book covers two of the most often discussed functions within Apache, mod_rewrite and logging, at great length, and offers insightful methods by which both can be used efficiently for security. In particular, the complete plan for deploying an independent Web log server using encryption for data transfer is included in the book.

Mobily explains, "Logging is absolutely critical, and should be done on a remote server dedicated to logging. The log files should be transmitted on a TCP connection (rather than UDP), and should be encrypted to prevent people from tampering with their contents."

The chapter on logging concentrates exclusively on how to achieve this, and Mobily believes his solution is really quite inventive.

"Maybe logging is not a security risk; rather, not having proper logging is an enormous security hazard," he said.

Running Apache in Jail

Many system administrators hesitate to carry out Chroot jails. Indeed, this can be a formidable task, particularly if you also have to jail a database and several scripting languages. Mobily explains the task in his book, including the details of getting Perl and PHP to work with Apache in jail.

Chroot jails create a quasi-root sector on a server, so, if they're compromised, the compromising attacker is exclusively jailed within a subset of directories and not the true root file system. This is due to the program's inclusion of a command shell, "believing '/', which refers to that particular sector of the file system -- not the true server root.

The challenge lies in getting all of the required library files in place in the jail, which is necessary even to run a simple bash shell. Mobily makes the process less painful with his coverage here.

"You may think it's weird to have a server where most of the files are in a 'cage'," Mobily commented. "People might wonder: what difference does it make? Why bother with the cage at all? Well, the point is that even though all the information in the cage may be compromised, you can still be fairly sure that the server itself hasn't been modified, doesn't contain a nasty root kit, and so on (not through Apache anyway)."

"If you realize that you were cracked, you can simply explode a tar file from backup (possibly a very big one!) with the content of the whole chroot jail (of course, you'd be creating a daily copy of this file), and then analyze your log files to find out who made the attack and how. The equivalent, at server level, is a complete reinstallation -- which is a much more painful and time-consuming process!"

Apache on Windows

While a large portion of the Apache universe runs on a Linux/Unix platform in production, there is an onslaught of newcomers to Apache who often put their first sites into production on a Windows desktop. We asked the author if he had any advice for those using Apache on Windows.

"The first rule is: know your system. If you really have to (or want to) run Apache on Windows, you must know Windows inside-out. Unfortunately, this is easier said than done. My advice, therefore, is: get to know Windows very well. Or, if you want to save some time and get some good results, install Linux and buy a good book to study it," Mobily advised.

Log Security and Log Analysis Tools

When tightening controls on log files or using non-traditional methods such as those described earlier, the interaction between raw logs and analysis applications can become complicated.

Tony feels that it's the usual problem -- you create a very safe system, but then it becomes a complete pain in the neck to get anything from. If you send your logs to a secure log server, you will most probably have some kind of system administration issues. The root of the problem is that a log machine should allow connections exclusively for logging and (most probably) for ssh connections.

"What can you do then? The trick in this case is simple: let the log server itself connect to a Web server, and upload the information in a "default" format every day. Then, extract and format all the statistics you need from the Web server, As usual, having a secure architecture implies more work and knowledge. That's probably why most companies seem to give up on it, and use the "cross your fingers" path," Mobily added.

Apache and SSL

Mobily suggests that the use of SSL improves Apache security somewhat -- and he offers a caveat on the use of self-signed certificates.

"A self-signed certificate will still allow companies to encrypt the connection; so, in a way, they are still good. What they don't do is tell the customer that the identity of the company is verified by a trusted institution or company," he said. "I'm not sure I'd use them in a production server, because you can obtain a certificate quite cheaply now, and (more importantly) because Web users shouldn't be trained to say "yes" to dialog boxes that appear in front of them while they browse."

Configuring on the Command Line

I shared the author's method of configuring Apache almost exclusively on the command line, having been taught administration from a terminal shell. However, in light of the rampant growth of control panels and graphical administration tools, I asked Tony for his input.

"I must be honest -- I have never used a GUI to configure Apache! So, I can't really say if there is a GUI that does the right job. However, as I said previously, you must know your system inside out in order to secure it," Mobily responded. "In my opinion, configuring Apache securely means getting your hands dirty on the httpd.conf file. In the book, I advise having a basic, short configuration file and enriching it slowly, whenever you discover that you need a new feature."

Multi-Platform Apache

Finally, knowing that Apache is one of those more unique open source solutions that runs across an endless number of platforms, including Linux, Macintosh, Netware, Unix and Windows, I queried Tony as to whether the Web server runs more securely out of the box on any particular platform.

"I don't think so. I wouldn't run a mission critical, high risk server on Windows, for example, because it's so much more difficult to harden than Linux. But as far as Apache is concerned, the rules stay more or less the same [form OS to OS]," Mobily said.

Hardening Apache
Author: Tony Mobily
Publisher: Apress
Price: $29.95
More information: http://apress.com/book/bookDisplay.html?bID=320 [6]

[1] http://apress.com/book/bookDisplay.html?bID=320
[2] http://www.cirt.net/code/nikto.shtml
[3] http://www.cirt.net/
[4] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
[5] http://www.apress.com
[6] http://apress.com/book/bookDisplay.html?bID=320