Hardening Apache

Gianluca writes "If security is not a concern, installing the Apache web server is a simple task even for an inexperienced system administrator. The problem is that security should always be a concern, and in case of Apache the information about making it secure can be sparse and fragmented. This is probably the reason why many web administrators are pretty clueless when it comes to Apache security. Needless to say, this creates a worrisome situation (to say the least): many web servers are vulnerable and exposed to thousands of potential attackers." Read on for Gianluca's review of Hardening Apache, a book intended to consolidate and clarify that information. Hardening Apache author Tony Mobily pages 270 publisher Apress rating 9 reviewer Gianluca Insolvibile ISBN 1590593782 summary A thorough guide through the intricacies and gotchas involved in securing an Apache installation

Hardening Apache fills a huge gap in this sense, providing web administrators with a complete and yet concise book aimed to guide them from the very beginning of the installation process to the final steps of the server configuration. The author, Tony Mobily, is also the mind behind Professional Apache Security, a book published by Wrox Press which I reviewed on Slashdot about 17 months ago. Since Wrox's unfortunate closure, some of the material from that book has been moved into Hardening Apache. More specifically:

• The excellent chapter on "jailing" Apache is exactly the same;
• The chapter on XSS attacks has been slightly improved;
• The chapter on logging, which was nothing remarkable, has been greatly improved. It now includes a complete architecture to log on a remote host using encryption and a TCP/IP connection.

The first chapter of the book deals with deploying a clean and safe base installation, which will then be the grounds for adding extra functionality. Unfortunately, this task is often underestimated. What I liked in this chapter is the step-by-step guide to correctly downloading the source distribution and verifying its integrity (by checking its digital signature), as well as the clean approach to the creation of a lean, easily readable configuration file, which grants a painless maintenance. A highlight of this section is the use of Nikto to analyse and explain common weaknesses and to show how to fix them.

Chapter 2 presents some vulnerabilities and explains how to exploit them. The chapter doesn't have any "pearls of wisdom" (but it's nevertheless important to show that Apache can be vulnerable), and presents some important reference sites every web administrator should be aware of.

Chapter 3 definitely deserves a special mention: after introducing the "common" ways of logging and syslogd's architecture, the author describes a rational approach to realizing a complete logging solution which entails remote log servers, encryption of logs, and the use of a MySQL database to better organize them.

Chapter 4 is the only one which deals with the "programming" side of web security. It is not a comprehensive guide on how to write safe programs for the web, as it focuses on cross-site scripting attacks; it shows how to secure a simple and vulnerable message board written in PHP.

The following chapter talks about security modules: it presents an interesting overview of the most useful modules related to security, which will help administrators understand the importance of third-party modules and explains how to install and use some of them. I also liked Chapter 6, which deals with the installation of Apache in a secure, chrooted environment: the chapter does a great job in guiding the reader through the non-trivial steps required to get Apache, Perl and PHP working correctly in such a restricted environment.

The last chapter presents a number of powerful and well-written scripts which anybody can use to automate security and keep an eye on their web server (monitoring log growth, Apache's responsiveness, and so on).

What's to like Information throughout the book is very well focused and presented with a clean and friendly writing style. The book provides a clear and detailed walkthrough of the process of securing an Apache installation, covering both versions 1.3.x and 2.x and thus providing long lasting information. The book has lots of references and pointers to resources on the web, and - what's more important - instructions on how to read them. I also liked the "checkpoints" at the end of each chapter.

What's to consider Apart from chapter 4 on cross-site scripting attacks, the book does not cover secure web programming at all. It doesn't cover OS hardening either, which is out of scope but part of the game anyway. Going through the book requires some familiarity with Unix and Apache; otherwise you will have to resort to other books for the very basic steps.

All in all, I found this sort of "new edition" of the book by Apress to be greatly enhanced, more homogeneous and better focused than the previous book: I had been happy with Wrox's version, but I am enthusiastic about this one. This is a book which should definitely be included in any serious Apache administrator's bookshelf.

You can purchase Hardening Apache from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

One of the unfortunate things about Apache...

[Sheetrock]

Its configuration is unusually complex for a webserver. I wouldn't be surprised if many of its so-called "security holes" actually came about because of misconfiguration by an administrator who was confused by the layout of the documentation or config files.

In a way, Internet Information Services provides a more secure environment because an administrator gets a wealth of help and a decent initial configuration. In the end it's all about knowing your product, but it helps if the product helps you.

Re:One of the unfortunate things about Apache...

[Blue Lang]

you'll also have a gimpy, crapped-up config file that other admins have to wade through after you get fired.

the best thing about the pre-built apache config files is the degree to which they are self-documenting. you can learn everything you need to know about apache just by reading through the comments. the second-best thing about them is that they're the same on all of your servers. the third best thing about them is that you don't have to read through a bunch of documentation to find out-of-date and non-working examples of config stanzas, because they're already there, commented out and waiting for some s/ action.

Re:One of the unfortunate things about Apache...

[tcopeland]

> a gimpy, crapped-up config file

Hm. I find smaller configuration files to have both a lower gimp quotient and a reduced crapification level.

> they are self-documenting.

True, although there's a ton of stuff in there most folks won't use - content negotiation and such-like.

> they're the same on all of your servers

Hm. Most of my servers have different config files - different vhost names, different modules, etc. Perhaps if they were all fronting one application that might be different...

Re:One of the unfortunate things about Apache...

[Skjellifetti]

In "Apache: The Definitive Guide", Ben and Peter Laurie suggest a way to learn how to build an Apache config file - start with a blank file, and start Apache. Oops, it won't start. OK, so what's it missing? Check the log files. It needs a User directive - OK, add that. Try to start. Hm, it started, but where do I put my HTML? Ah, add a DocumentRoot. And so forth.

No, its not add that. Its copy that and the associated comment from the original stock config file apache provides. Now your lean config file is documented, looks just like apache's and won't confuse your successor. I generally do this with any new daemon I install that requires a config file. Note that from a security standpoint this may not be good enough if the daemon's secure options are turned off by default since you may not see any warnings in the logs.

Re:One of the unfortunate things about Apache...

[jc42]

Of course, you could reinterpret "start with a blank file" to mean "Add a '#' to the start of every line in the sample httpd.conf file". That would give you a "blank" file, but with all the documentation and examples very easily available.

Don't advertise version number

[captaineo]

I wish web servers wouldn't advertise their version number be default (e.g. in directory listings or HTTP headers). It's like giving an attacker an exact list of the exploits that will work on your server.

Great. Another Book of The Arcane.

[Thalia]

There is a fundamental flaw with security hardening being in a separate book, sold by advertising and word of mouth, read separately and in a different medium than installation documentation, updated asynchronously, and expected to work. Would you accept a word processor with a separate book on "Master's Secrets on Keeping Your Word Processor From Crashing"?

With any luck, many hardening techniques will migrate towards the Apache installation process, or at least the Apache documentation.

Re:Interesting

[bigbadunix]

Don't let not knowing about security hold you back from hosting your own site. Experiment, learn, have fun. Put an apache box up on a DMZ, put stupid content on it, see what happens. Look at your logs, see what's going on, learn from any mistakes you make along the way.

If you're in this industry, and are afraid to be the "fall guy" who has do deal with the inevitable attacks, or the "fall guy" in general, you'd better fasten your seat belt...you're in for a bumpy ride.

He who makes no mistakes makes nothing at all