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.
You're all wrong:
%sudo apachectl start
apache drops root privs on startup.
i browse at -1 because they're funnier than you are.
For non-database logging, use mod_log_spread. This also solves the problem of merging logs if you happen to run a web farm.
Must-not-watch TV!
You can turn this off when you compile apache, it's just a matter of editting a .h file, I believe, and putting in whatever you want. You could, for instance, create a "Joe Schmoe's webserver version 11000!" or something of that ilk.
However, when it comes to exploits that deal with knowing version numbers, most of it is script kiddy stuff, so it's [ the script ] is going ot just run default exploit attempts against the webserver regardless of what is returned about the webserver.
I designed the backend of www.babiesfirstchoice.com and we used apache 2. Its been hugely stable for us (the downtime we've seen was not due to apache problems) and lets us do everything we need to do on it. An IIS box would of cost thousands more due to licensing and the extra hardware needed to push M$ solutions (BFC currently runs on a athlon 1700xp with 512 megs of ddr and a basic ide hard drive, nothing fancy).
Lawyers, MBA's, RIAA? A jedi fears not these things!
Might help a little bit. As I saw so eloquently stated somewhere...
This would not stop skilled bad guys, but would slow down those kiddies playing around.
Should this perhaps be the default? Maybe. But the bottom line is, you don't have the right to put a machine online without knowing about the details.
The older I get, the less I like everyone else.
step 1: groups.google.com
/.
step 2: search on 'no more apache updates group:lucky.openbsd.misc' (no quotes)
read that. this one in particular to answer your question. it was also covered here on
vodka, straight up, thank you!
Or at least a good chunk of it is. Some of the patch is necessary just to take into account how OpenBSD handles various calls.
There seemed to be little in the way of practical material that gave specific and step-by-step instructions for installing and running Apache on Linux.
Maybe you missed the "documentation" section at the apache.org website? Or, do a google search for "linux apache howto". Tons of good stuff out there.
Apache on Linux requires you to spend 8 hours per day just to keep it up and running,
On what planet is this true? There's about 4 things to change from one webserver to another; you build one config file for your environment, and for the next one modify the listen, the user if you want, the document_root, and maybe servlet mapping if you're using that. Trivial and one-time.
and while its performance and security is fine if you have the time and staff for it, there is no way to just set it up and let it sit while installing patches when needed.
Our experience differs profoundly. Perhaps someone like you needs to hire someone like me to help you get set up. It's a trivial setup, configuration is well documented, and once it's up and running a webserver doesn't need any attention whatsoever until the next version comes out or you decide you want to change what it does. Arguing against Apache on actual factual grounds would be one thing, but "it's hard to set up and lots of work to keep running" is demonstrably false.
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.
http://www.bastille-linux.org/jay/Talks/slides-def con-securing-apache.pdf
This helped me with a few extra ideas.
Sigh, there are several ways to approach setting up an Apache server. All of them are easy.
First one is to start with an empty configuration file and then cut and past in portions of the standard file until you get a minimally working server.
The good part about this approach is that you get the least amount of bells and whistles added. Security via a small footprint is a good thing. The bad part about this approach is that you end up with a minimal server that may need more tweaking to get everything working as you need it.
The second approach is to take the original configuration file and start chopping things out of it. Test each deletion to make sure that everything you need still works. Use something as simple as RCS to keep track of your changes.
The good part about this approach is that you'll have a server until you break it. You will also have a nice record of every configuration change you've made. The bad part about this approach is that you may end up with a fatter server than you need. This violates a security maxim of making the least footprint on the net necessary to accomplish the task.
The third way to configure Apache is from scratch. This is somewhat more complex than the other two, and can lead to unmaintainable configuration files.
The bonuses for creating your own configuration file include understanding what goes on in the Apache configuration, and making a nice, modular configuration file. The bad part about this is that if you don't comment your file, you'll get an unmaintainable mess. Unfortunately some consultants think this is a good thing.
As for chrooting Apache, it took me less than 15 seconds via Google to find a step by step procedure http://www.faqs.org/docs/securing/chap29sec254.htm l to chroot Apache on a Redhat Linux.
We use Include's to handle that. Include conf/vhosts.conf for example. Then the httpd.conf files are, almost always, identical.
Perhaps I'm mistaken here, but the apache daemon itself still maintains root priveleges, it's the children it spawns which do not. If someone managed to stick their own module and load it in the config, I believe it still runs with root priveleges on startup.
I've seen removing the version number being advocated by the Nessus folks, but I haven't done it.... It feels somewhat like security by obscurity....
Employee of Inrupt, Project Release Manager and Community Manager for Solid
Hows about you try something like Webmin great way to manage most aspects of your system.