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.
How many of you so called admins do this:
%su
#httpd start
when we ALL know it should be
%su -
#httpd start
I am a viral sig. Please help me spread.
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
apache drops root privs on startup.
i browse at -1 because they're funnier than you are.
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.
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!
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!
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.
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.
In short, find a hosting company with a lot of Windows servers nearby IP-wise. This is, sadly, not a troll or flamebait, it's my experience. Apache is not what you have to worry about, it's scripts you run. Every single non-targeted exploit of a Unix machine I've seen (that is, compromises that don't target a particular site or person) has been the result of a buggy script. And usually a script that's installed on a ton of systems, so the hackers can compromise many machines with the same attack. Most of them are looking for warez dump sites or launching points for DDoSes. It's not worth their time to target individuals.
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.
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?
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).
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.
Any RFC standard that breaks because it looks just like the computer on the other end of the line is turned off... needs breaking any way.
If you have a specific need to know I am here... it should be a part of your protocol.
Because, other than those things I want to work... my machine does not exist.
In short: I don't need ping replies to work. So, my machine does not do it.
--Phillip
Can you say BIRTH TAX
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. -
Hows about you try something like Webmin great way to manage most aspects of your system.