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.
so why is it IIS exploit attempts always fill logs and not apache exploit attempts? Can't use the usual MS deployment numbers with this one.
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
IF it's so secure, why are my apache logs filled with IIS buffer overflow attacks? The only actual direct attacks I have ever seen on my servers are sorry attempts at dictionary attacks.
When I've used Apache2, it's configuration setup seems a lot more organized and structured. It's still text files, but they make more sense and they are modularized better.
;-)
Granted, that's just the in the distribution, not the server version... but at least it shows it's getting better at that. Now if only more people used Apache2, things would just fix themselves
-N
I've nothing to say here...
only a farking moron disable's ping and BREAKS many RFC standards.
idiots disable ping. It there for a reason, just because asshat's use it to find targets does not make it something you dont need.
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 guess I can see how you would come to this.
/etc/conf.d I've been using the gentoo build ever since then.
I started using solely linux around 4 years ago. One of the first things I did was install apache and play around with that. I got it working with a little effort. After that I always built it from scratch. I eventually decided to try using apache out of the portage tree and it was set up as soon as I ran emerge and setup the configs in
Anyways I had to develop some webapp and my boss wanted me to do it in php on IIS. We had a hell of a time getting all of the authentication and settings, we couldn't quite get it all working. We had trouble with ssl and a few other things. so my co-worker and I dropped apache on it and got it working with SSL in about 10 minutes.
I guess the short version of the story is: Hire MS sys admins for MS systems and here Linux sys admins for Linux systems. Rather than saying one is easier than the other, it might be better to say that one comes more naturally to a given user. And since I'm at a school with a bunch of nerds and almost all of the people I know prefer to run linux, there's a good chance that we can probably get something like apache setup more easily than IIS.
i could not think of anything clever.
I coulnd't agree more with you.
The point is that if you write your config file by hand, then you HAVE TO know each directive (well, sort of).
That's part of the reason why I wrote the first chapter that way...
Merc.
(The book's author)
I wrote the book, so my input is biased...
I think the book would be great for you. If you do buy it, let me know what you think of it!
Merc.
(The book's author)
Now, you still have to learn how to set up that package right, and keep up on updates, but diversity is a nice thing. Even if you just move some files (e.g. static content like images) off onto a side server, there's less to secure on the Apache box, so it's usually simpler.
PHEM - party like it's 1997-2003!
That whole thread on "no more apache updates" had nothing to do with security. It had everything to do with the OpenBSD team deciding not to keep using Apache HTTPD because of the new ASL 2.0 license. Personally I think the OpenBSD team is completely wrong on this issue and their attitude is incredibly offensive. Moreover, if you read the whole thread you'd find this response that the apache group has been responsive to the patches but that many of them are BSD specific and that's why they were not put into the main source tree.
Who said Freedom was Fair?
Yep and I can still name 7 for every one of yours. How about Microsoft huh? Everytime a DDOS attack comes, gues who they duck and cover behind? LINUX and APACHE!!! :)
:)
Do a check on Netcraft for *.microsoft.com sometimes and check the first couple hundred servers for what they are running. If IIS is so damn good, how come Microsoft is always duck and covering behind open source?
This is my sig. There are many like it but this one is mine.
Gee - you get this massive file to edit to get Apache up and running which is fine for some of geeky land (like the slash-dot crowd) but it creates a hurdle for your basic person who wants to have a running web site.
So why not create a smart program to generate the config file either as a script or as a GUI application that will have enough smarts to get your normal site up and running but with the possible security holes turned OFF and massive warnings written into the file so that when someone goes to edit it they have some clue provided.
Same for PHP.
Oh sure - it's soooo kewl to just edit the text file - and for the clued-in that's great. But something which can make a new safe file for you, AND check an existing file - seems like that's just smart.
Otherwise it's safety through obscurity - or insecurity through obscurity and neither of those make sense.
I actually like ping, I leave it on since my cablemodem isn't all that reliable and it's a nice easy way to check if it's up when I'm at work. If port 23456 stops responding, I can ping to see if it's just the application or the connection.
I also use it as a monitor from another location so I can redirect certian traffic if it stops responding.
Sure, I could go firewall nazi and only allow ping from certain locations, but hell, it's only ping.
Not to say you MUST use it, but I find nothing particularly evil about it that it MUST be blocked.
- It's not the Macs I hate. It's Digg users. -
Microsofts autoupdate was ever so recently running on Linux as well http://uptime.netcraft.com/up/graph/?host=autoupda te.microsoft.com
This is my sig. There are many like it but this one is mine.
Include conf/vhosts.conf for example.
This guy should get more + moderation! That method is one of the best ways to keep your apache configs sane, especially if you've got a whole bunch of servers that aren't part of a cluster or whatever (i.e. identical configs for all).
We actually take it a step further and do "Include conf.d/" from the httpd.conf, where conf.d is a subdirectory with configuration "containers" that are automatically included on startup/reload. That way we just drop individual vhost configs into their own files. No parsing/rewriting required for automation!
I got that trick from the way Debian does things in Sarge and started using it on our stable web servers. Dunno if other distros do it that way, but it's a great idea.
A host is a host from coast to coast...
Unless it's down, or slow, or fails to POST!