Slashdot Mirror
Hardening Apache
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.
To Harden PHP while you're at it.
You could also take the time to read about Hardening IIS. Come get me Mods =)
> In the end it's all about knowing your product,
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.
This really doesn't take as long as it sounds - and after about 10 minutes of adding directives and restarting Apache, you'll have a lean configuration file that has just what you need in it - and you'll know how you got there, where the error logs are, and so on.
The Army reading list
Its configuration is unusually complex for a webserver.
Really? I never found it all that hard. Most of the complex stuff is inserted in the default file, but is not insecure in of itself. You just have to think about everything you do after that.
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 my experience, most Apache security issues are related to giving access to files that shouldn't be on the web. Doing things like symlinking directories is very powerful, but it's also very dangerous. Also keep in mind that if an attacker can upload a script, he already has access to your system. These sorts of problems (as well as undiscovered buffer overflow issues) can be mitigated by the use of Jails. When you jail Apache, you ensure that any attacker that does gain access, will only have access to Apache files.
A typical Apache security problem would be something like an FTP server that has an anonymous account with access to a web-sharable directory. An attacker uploads a PHP script to the web-share, and it's game over for your machine/network.
Javascript + Nintendo DSi = DSiCade
Sorry but IIS has more critical exploits in any given month than Apache has all YEAR! Why do you think Apache owns 70% of the web? Microsoft made a push in 2001 but could only get as high as 35%... at which point it tanked back to it's previous high of about 22%
This is my sig. There are many like it but this one is mine.
Ohh, and you do know that on unix you can remove a binary of a program that's running, put a new one in, and do a quick kill/start?
Actually, for most of the configuration changes (short of an actual version upgrade or SSL cert change), you can do an 'apachectl graceful' and it applies your changes to the _new_ sessions, while letting the existing sessions close in the natural flow of the users' use of your site. Nice for minor tweaks on the fly during the day, with zero downtime.