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.
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.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
If security is not a concern, installing the Apache web server is a simple task even for an inexperienced system administrator Yet I still preffer IIS, according to research, it's more easy to install, and up to 70% more secure; according to research that is.
To Harden PHP while you're at it.
OpenBSD's Apache has a diff of 3 or 4 thousand lines over "stock" Apache. Why not just use that?
Comment removed based on user account deletion
You could also take the time to read about Hardening IIS. Come get me Mods =)
a cigar store wooden Indian? Sorry, I hadda say it...
To harden Apache, you just rub it the right way.
*I apologize*
How many of you so called admins do this:
%su
%httpd start
when we all know it should be
%su
#httpd start
- It's not the Macs I hate. It's Digg users. -
Picked up Maximum Apache Security at Apache-Con last year and it has proven very useful. But any Apache administrator worth his salt knows most of this already. I don't see why you say it's fragmented and hard to find.
This is my sig. There are many like it but this one is mine.
The creators of Apache Server came up with the name due to it being based on a series of patches for httpd. "A Patchy Server." Get it? The name itself suggests its fragmented beginnings.
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.
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.
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
The older I get, the less I like everyone else.
you're apache install will stay safe because they'll be too distracted
Simple. Dip it in tree resin and let it fossilize. It should harden into amber in . . . oh, a few million years or so. Don't be impatient, though, or all you'll get is copal.
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.
There is one thing that makes apache very unsecure. Suppose that you have few users each having it's own virtual host. Apache is running from exactly the same UID/GID for each virtual host! There is no way in pure apache to prevent user A from looking into user B vhost files (containing for example php scripts, password to sql databases etc).
:/
You would need to run multiple apaches running from different UIDs for each user
That's bad. suexec it's not a option - it doesn't work with mod_python and other apache modules.
perchild MPM module that should do it doesn't work and apache developers are not interested in fixing that. No idea why.
metuxmpm MPM module was written instead perchild by external developers but it also doesn't work well unfortunately (for me it doesn't work at all).
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.