Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Books Media Software Book Reviews Apache

Hardening Apache 241

Posted by timothy from the crunchy dept.
Gianluca writes "If security is not a concern, installing the Apache web server is a simple task even for an inexperienced system administrator. The problem is that security should always be a concern, and in case of Apache the information about making it secure can be sparse and fragmented. This is probably the reason why many web administrators are pretty clueless when it comes to Apache security. Needless to say, this creates a worrisome situation (to say the least): many web servers are vulnerable and exposed to thousands of potential attackers." Read on for Gianluca's review of Hardening Apache, a book intended to consolidate and clarify that information.
Hardening Apache
author Tony Mobily
pages 270
publisher Apress
rating 9
reviewer Gianluca Insolvibile
ISBN 1590593782
summary A thorough guide through the intricacies and gotchas involved in securing an Apache installation

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.
This discussion has been archived. No new comments can be posted.

Hardening Apache More

Hardening Apache

Comments Filter:

  • One of the unfortunate things about Apache... (Score:4, Insightful)

    by Sheetrock ( 152993 ) on Wednesday September 01, 2004 @02:28PM (#10131485) Homepage Journal
    Its configuration is unusually complex for a webserver. 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 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.

    • Re:One of the unfortunate things about Apache... (Score:3, Interesting)

      by Anonymous Coward
      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.
    • > 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.

      • Re:One of the unfortunate things about Apache... (Score:5, Insightful)

        by Blue Lang ( 13117 ) on Wednesday September 01, 2004 @02:48PM (#10131717) Homepage
        you'll also have a gimpy, crapped-up config file that other admins have to wade through after you get fired.

        the best thing about the pre-built apache config files is the degree to which they are self-documenting. you can learn everything you need to know about apache just by reading through the comments. the second-best thing about them is that they're the same on all of your servers. the third best thing about them is that you don't have to read through a bunch of documentation to find out-of-date and non-working examples of config stanzas, because they're already there, commented out and waiting for some s/ action.
        • > a gimpy, crapped-up config file

          Hm. I find smaller configuration files to have both a lower gimp quotient and a reduced crapification level.

          > they are self-documenting.

          True, although there's a ton of stuff in there most folks won't use - content negotiation and such-like.

          > they're the same on all of your servers

          Hm. Most of my servers have different config files - different vhost names, different modules, etc. Perhaps if they were all fronting one application that might be different...
          • We use Include's to handle that. Include conf/vhosts.conf for example. Then the httpd.conf files are, almost always, identical.
            • 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 co
        • you'll also have a gimpy, crapped-up config file that other admins have to wade through after you get fired.

          C'mon, surely you know the difference between "learning exercise" and "what I leave behind for my successors"!

        • Yeah but if only editors (vi or emacs in my case) had a 'fold away the comments' mode; in many cases in order to find whats actually configured, its easier to just;

          grep -v "^#\|^$" /etc/apache/httpd.conf

          so that I can see the woods through the trees so to speak.

          Comments arn't always good.
      • That's a good suggestion. Once you get the barebones config the way you want, save it and use it for every server you deploy (with the necessary modifications/additions, of course).

        I spent about 3 hours years ago making my Apache config, and I haven't had to do it again. I have a second one I made last year for Apache 2, and I expect it to last me just as long.
      • >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.

        I'm not a sysadmin or worked with Apache, but doesn't this sound a bit crude to figure out a configuration of a system?

        Its like going through the Apache source code to see what strings in the config file they are looking for.

      • Re:One of the unfortunate things about Apache... (Score:5, Interesting)

        by tonymercmobily ( 658708 ) on Wednesday September 01, 2004 @03:04PM (#10131847) Homepage Journal
        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)

      • Re:One of the unfortunate things about Apache... (Score:5, Insightful)

        by Skjellifetti ( 561341 ) on Wednesday September 01, 2004 @03:15PM (#10131965) Journal
        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.

        No, its not add that. Its copy that and the associated comment from the original stock config file apache provides. Now your lean config file is documented, looks just like apache's and won't confuse your successor. I generally do this with any new daemon I install that requires a config file. Note that from a security standpoint this may not be good enough if the daemon's secure options are turned off by default since you may not see any warnings in the logs.

      • Why doesn't Apache just ship a leaner default config file?
      • 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.

        That is a good start, but also make sure you start from a completely blank file tree, delete all the default cgi scripts etc. A lot of exploits

    • Re:One of the unfortunate things about Apache... (Score:5, Interesting)

      by ThogScully ( 589935 ) <neilsd@neilschelly.com> on Wednesday September 01, 2004 @02:36PM (#10131576) Homepage
      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
    • 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.

  • secure (Score:4, Funny)

    by Anonymous Coward on Wednesday September 01, 2004 @02:29PM (#10131507)
    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.

  • Don't forget (Score:4, Informative)

    by Anonymous Coward on Wednesday September 01, 2004 @02:30PM (#10131510)
    To Harden PHP [hardened-php.net] while you're at it.

  • Umm. (Score:5, Interesting)

    by Anonymous Coward on Wednesday September 01, 2004 @02:31PM (#10131516)

    OpenBSD's [openbsd.org] Apache has a diff of 3 or 4 thousand lines over "stock" Apache. Why not just use that?

    • Re:Umm. (Score:5, Interesting)

      by Triumph The Insult C ( 586706 ) on Wednesday September 01, 2004 @02:42PM (#10131646) Homepage Journal
      here is a link [google.com] about just that

      and it's not that they haven't tried feeding the patches back, either. the ASF is being utterly retarded about accepting them. more [google.com] and more [google.com]
    • 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.

      • Re:it's specific to OpenBSD (Score:2, Informative)

        by Anonymous Coward
        wget the apache tarball from apache's website. Run the make on it under openbsd. It compiles but without the security niceties, chroot for one.

  • Comment removed (Score:4, Interesting)

    by account_deleted ( 4530225 ) on Wednesday September 01, 2004 @02:32PM (#10131536)
    Comment removed based on user account deletion

    • Re:Interesting (Score:4, Insightful)

      by bigbadunix ( 662724 ) on Wednesday September 01, 2004 @02:41PM (#10131634) Homepage Journal


      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
      • Roflmao I did that once -> used apache as a reverse proxy. I love the simplicity of it, and the increased security. You can block a tonne of attacks using mod_security, and keep them from hitting your real web server.

        Thing is, I forgot to lock down the allowable hosts.

        Soon, I was seeing scripting engines requesting ads from various web servers in my logs. Took over a year for those scripts to stop.

        Didn't take long for me to find it, but once you're on an open proxy list.... You're screwed.

    • Re:Interesting (Score:3, Insightful)

      by ctr2sprt ( 574731 )
      Basic security is not difficult. If you know the rule of "If you don't need it, turn it off," you know everything you need to about basic security. Hackers, like just about all criminals, go for the path of least resistance. If you take basic precautions, you'll defend yourself against everyone who isn't out to get you personally.

      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 w

    • Heh. I plan to serve my own site to gain the experience of log-reading, config-file twitching, and all that; I want to break into the Web field, and see this as a good opportunity to learn about webserver/OS hardening by fire, as well as being just plain fun :)

      I'll also ask a buddy of mine who's a security consultant to attack the server. Better to have a friend attack and tell me my mistakes than some pimply-faced kid 0wneR my machine.

    • Re:Interesting (Score:2, Interesting)

      by tonymercmobily ( 658708 )
      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)

  • Devil's Advocate (Score:5, Informative)

    by Anonymous Coward on Wednesday September 01, 2004 @02:33PM (#10131539)
    You could also take the time to read about Hardening IIS [microsoft.com]. Come get me Mods =)

  • Is that anything like... (Score:5, Funny)

    by gregarican ( 694358 ) on Wednesday September 01, 2004 @02:33PM (#10131543) Homepage
    a cigar store wooden Indian? Sorry, I hadda say it...

  • Well (Score:3, Funny)

    by Anonymous Coward on Wednesday September 01, 2004 @02:34PM (#10131552)
    To harden Apache, you just rub it the right way.

    *I apologize*

  • Maximum Apache Security (Score:4, Interesting)

    by Foofoobar ( 318279 ) on Wednesday September 01, 2004 @02:37PM (#10131586)
    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.
  • Does anyone know whether StrongHold [redhat.com] actually improves on Apache's security?
    • Stronghold began as a commerial SSL-enabled version of Apache, when zero-cost SSL modules were non-existant and/or crappy. At some point RH bought out Stronghold-Inc. Im supprised that RedHat still supports Stronghold at all, frankly. It is unclear if the latest version is still a sepearate product, or comes with RHEL 3 only. Beh.

      Short answer, likely not.

  • Don't advertise version number (Score:5, Insightful)

    by captaineo ( 87164 ) on Wednesday September 01, 2004 @02:39PM (#10131614)
    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.
    • 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.
    • ServerTokens Prod

      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.
      • This would not stop skilled bad guys, but would slow down those kiddies playing around.

        Not in the least. My logs show tons of IIS and ancient Apache exploit attempts. Kiddies just mindlessly launch every exploit they know against any server they can find and hope to get lucky.

    • Security by obscurity will not take you anywhere. Why not simply maintaing the server up to date?
    • Actually it won't. Debian will keep an Apache version constant while fixing security related bugs, so it is not that simple.

      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....

  • Great. Another Book of The Arcane. (Score:5, Insightful)

    by Thalia ( 42305 ) on Wednesday September 01, 2004 @02:40PM (#10131630)
    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.

  • just put an IIS server in front of it (Score:5, Funny)

    by seringen ( 670743 ) on Wednesday September 01, 2004 @02:42PM (#10131652)
    you're apache install will stay safe because they'll be too distracted

  • Hardening apache? (Score:3, Funny)

    by DrMrLordX ( 559371 ) on Wednesday September 01, 2004 @02:46PM (#10131699)
    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.

  • logging (Score:2, Informative)

    by MasTRE ( 588396 )
    For non-database logging, use mod_log_spread [backhand.org]. This also solves the problem of merging logs if you happen to run a web farm.
  • I do most of my work on a Domino server (say what you will, but its very secure and stable and I build customer apps really inexpensively) but Apache based servers (and they are myriad) keep intruding into my happy little world.

    A year ago I wanted to put one public but found information on hardening it extremely limited -- or perhaps extremely disconnected.

    If the book is indeed concise, it will be useful.

  • Apache is extremely complicated and therefore a potentail rats nest of potential security holes. Please don't get me wrong here: I like Apache very much for its great flexibility, yet I helped a lot of security aware companies to migrate to thttpd [acme.com] because they wanted a code base that could be scrutinized in a reasonable amount of time. Most web apps really don't need the flexibility of Apache anyway, and those who do, will have to be run in secure environments like, say, jails [freebsd.org] or other virtualized environme

  • If possible, use a different httpd (Score:3, Interesting)

    by Dr. Manhattan ( 29720 ) <(moc.liamg) (ta) (171rorecros)> on Wednesday September 01, 2004 @03:19PM (#10132014) Homepage
    Apache is nice, and Apache is popular, but the simple fact that it's popular means that it attracts attention. If you don't need a module that's specifically for Apache, you can use a different webserver package (take a look at Freshmeat, there's a bunch) and you gain some security through obscurity.

    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.

  • Lack of security between users/virtual hosts (Score:3, Insightful)

    by Cronq ( 169424 ) on Wednesday September 01, 2004 @03:39PM (#10132227) Homepage
    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.
  • 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 ed

Slashdot Top Deals

Nothing ever becomes real till it is experienced -- even a proverb is no proverb to you till your life has illustrated it. -- John Keats

Close