Please create an account to participate in the Slashdot moderation system

 


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

Professional Apache Security 115

Posted by timothy from the patchy dept.
Gianluca writes "Web sites get defaced every day -- that's routine practice for aspiring crackers who want to gain popularity by proving their bravery. Too often their attacks are aimed at unprepared, defenceless servers which were improperly secured by clumsy administrators. Just reading a book won't save you from the next cracker attack. However, having a solid knowledge of the basics of web security and a list of effective checkpoints for configuring your server, will definitely help you to prevent at least the most trivial mistakes." Gianluca reviews here Wrox Press' Professional Apache Security to see how well it can provide that kind of knowledge -- read on below.
Professional Apache Security
author Tony Mobily et al.
pages 360
publisher Wrox Press
rating 8.0
reviewer Gianluca Insolvibile
ISBN 1861007760
summary A comprehensive overview of security related issues of interest for web admins, security analysts and web developers

The book walks through the most common tasks of an Apache administrator. It covers, for example, proper installation and maintenance, common practices in security and remote attacks. Some basic notions of system administration are also given, for those areas which affect the web server behaviour.

Topics of specific interest for security freaks include system hardening, intrusion detection mechanisms, monitoring and logging, server chroot()ing, session tracking, cryptography and SSL.

Throughout the book there are descriptions of common attacks like Cross-Site Scripting (XSS), CGI vulnerabilities, Denial of Service (DoS), Distributed DoS (DDoS), Reflection DDoS (RDDoS), cookie spoofing and session hijacking. Script kids be warned: there's no easily exploitable information on how to attack a web server inside the book.

What's to like
The book is well written, and an enjoyable read. It uses a very precise and yet friendly language to guide its readers through the covered subjects. Using this straightforward approach, it explains some thorny topics starting from basic notions and assuming no previous knowledge.

The explanation of essential topics like the HTTP protocol and server architecture, forms and CGI mechanisms, system configuration, etc. are nicely integrated with more tangled and scarcely documented issues. It is worth mentioning:

  • the chapter on "jailing" the web server (which explains in detail how to correctly prepare a complete yet secure chroot'ed "sandbox" for Apache);
  • the chapter on prevention of XSS attacks (explaining these types of attacks, and how to write CGI scripts to avoid them);
  • the appendix dealing with usage and configuration of mod_rewrite.

Everything is supplemented with hands-on examples, information and tricks valuable to the intermediate reader; the clear explanations of basic topics will provide complete instructions for the beginners.

Further pro's of the book include updated information (issues related to Netscape 7, IE 6, Mozilla 1.0, Apache series 1.3 and 2.0), coverage of less known topics (e.g.: P3P) and a wealth of references to the relevant sources of information like RFCs, W3C specifications and CERT Advisories.

What's to consider
The downside of writing for both beginners and intermediate readers in just 360 pages is that the depth of the information provided is necessarily limited. The book is clearly targeted to less experienced system administrators, who will be able to quickly grasp the most important concepts revolving around Apache security and secure administration. Intermediate users are likely to find some paragraphs quite trivial, however they will be rewarded by the many pearls of wisdom offered in the more detailed sections. Expert system administrators might be disappointed by the lack of more in-depth and hard-core technical explanations.

The summary
The best aspect of the book is that it assembles basic notions, rarely available information and hints derived from the authors' experience to produce a neat, clearly written and comprehensive guide to Apache security. This will enable beginning web admins to understand the key points in managing and securing a web server, while providing experienced ones with a quick reference to the most important security practices.

Table of Contents
Introduction
Chapter 1: Installation
Chapter 2: Secure administration
Chapter 3: HTTP Security and Cross-Site Scripting Attacks
Chapter 4: Authentication and authorization
Chapter 5: System security
Chapter 6: Apache in jail
Chapter 7: Denial of service attacks
Chapter 8: Cookies
Chapter 9: CGI security
Chapter 10: Logging
Chapter 11: Session tracking
Chapter 12: Apache and cryptography
Chapter 13: SSL and Apache
Appendix A: Security resources
Appendix B: Apache with mod_rewrite
Appendix C: Sample SSL Accelerator implementations

You can purchase Professional Apache Security 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.

Professional Apache Security More

Professional Apache Security

Comments Filter:

  • Whuh? (Score:3, Interesting)

    by MarsBar ( 6605 ) <geoff.geoff@dj> on Wednesday March 12, 2003 @12:24PM (#5494458) Homepage

    If it's that easy to make stuff insecure without realising it, then the httpd.conf file needs more obvious comments.

    If it's not actually that easy and it's down to the stupidity of the admin, then a book is unlikely to help: just read the various HOWTOs and follow them step by step, you can't really go wrong.

    Of course there will be ways around security models but you'll defeat the average script kiddy just by following word-for-word instructions and installing the latest patches.

    • Re:Whuh? (Score:5, Interesting)

      by dirkx ( 540136 ) <dirkx@vangulik.org> on Wednesday March 12, 2003 @12:37PM (#5494567) Homepage
      If it's that easy to make stuff insecure without realising it, then the httpd.conf file needs more obvious comments.

      Hey - toss me a bone here :-) this is open source, tell me/us [apache.org] what annotations should be added to httpd.conf.. and we'll make apache a beter product.

      Action >> Reaction ;-)

      Dw.

      • Heh. I didn't say it is that easy - I said if it's that easy.

        As far as I know I've never managed to do it - no-one's hacked any of the sites I've built. But there may be a first time :)

      • A little off-topic, but I'm quite impressed with the HTTPD.CONF file.... I think is is VERY well documented.

  • XSS (Score:2, Interesting)

    by RedWolves2 ( 84305 )
    I guess I need to learn more about Cross-site Scripting. I have heard of it before and am not real sure of what it is and how it works. I think this book [mediagab.com] would be good just for that topic alone.

    Anyone have any links on this topic?

  • Justifying your time and budget (Score:4, Insightful)

    by dsplat ( 73054 ) on Wednesday March 12, 2003 @12:28PM (#5494487)
    Just reading a book won't save you from the next cracker attack. However, having a solid knowledge of the basics of web security and a list of effective checkpoints for configuring your server, will definitely help you to prevent at least the most trivial mistakes.


    And having a published authority to refer to can help in justifying the time to a boss or a client. If they already trust you, they'll believe that the web server needs to be secured. But I find that the bulleted list of actions to take and the benefits of those actions goes a long way towards maintaining real world credibility.
  • Just reading a book won't save you from the next cracker attack.

    The saltines can be particularly nasty. Don't even get me started on the TownHouse.

    *shudders*

    I always thought that "crackers" were people who remove the copy protection from programs.

    Maybe a matter of symantecs... whatever.

    • Re:When crackers attack!! (Score:4, Funny)

      by josh crawley ( 537561 ) on Wednesday March 12, 2003 @12:36PM (#5494559)
      >Maybe a matter of symantecs... whatever.

      Nope, them's the virus people.

    • Re:When crackers attack!! (Score:2, Informative)

      by t0c ( 658568 )
      Actually... hackers are people who use clever techniques to improve code (or modify it for whichever purpose. The meaning of the word is usually a good one till society today dirtied it and made it "malicious people who break into servers") and programs in general. Now crackers are not the people who remove copyright protection...although the "cracking" of the program can be referred to as hacking code or whichever variation of the expression... Cracking is breaking into servers without prior consent from the owner or administrator. So the problem is not with semantics it's with what you (or should I say what most people) think a cracker and what a hacker or such things. A good knowledge of these things is never a bad thing.
      • yes but most good crackers are also good hackers which is to say that crackers for the most part are a subset of hackers so the media should get partial credit for their generalization.

        an over-generalization would be (for example) saying that arabs are people who commit terrorist acts, which wouldn't be an over-generalization if there weren't non-arabs who were also terrorists. as it is the hacker thing is merely a generalization.
        • Subset of hackers...I doubt that...I've recently seen a discussion about this whole thing (I am sorry but i am unable to give you an URL) where a "hacker" a white hat, was interviewed and he discussed this (or somewhere on that topic). So I don't really know if they are necessarily a subset I believe that they are their own set of people, of course crackers and hackers have a lot of skills in common given. I guess it's all a matter of opinion as to where you stand on all of this. For one I like to think tha
    • I always thought that "crackers" were people who remove the copy protection from programs.

      Noticing a hint of irony in the other sections of your post, there is a distinct possibility that this comment was meant to be ironic as well, but I'm gonna ignore that possibility and be informative instead.

      Anywho, according to the New Hacker's Dictionary (http://www.jargon.8hz.com/jargon_toc.html):

      " cracker /n./

      One who breaks security on a system. Coined ca. 1985 by hackers in defense against journalistic misuse of hacker (q.v., sense 8). An earlier attempt to establish `worm' in this sense around 1981--82 on Usenet was largely a failure.

      Use of both these neologisms reflects a strong revulsion against the theft and vandalism perpetrated by cracking rings. While it is expected that any real hacker will have done some playful cracking and knows many of the basic techniques, anyone past larval stage is expected to have outgrown the desire to do so except for immediate, benign, practical reasons (for example, if it's necessary to get around some security in order to get some work done).

      Thus, there is far less overlap between hackerdom and crackerdom than the mundane reader misled by sensationalistic journalism might expect. Crackers tend to gather in small, tight-knit, very secretive groups that have little overlap with the huge, open poly-culture this lexicon describes; though crackers often like to describe themselves as hackers, most true hackers consider them a separate and lower form of life.

      Ethical considerations aside, hackers figure that anyone who can't imagine a more interesting way to play with their computers than breaking into someone else's has to be pretty losing. Some other reasons crackers are looked down on are discussed in the entries on cracking and phreaking.      "

  • Professional? argh!! (Score:4, Interesting)

    by Eponymous Coward ( 6097 ) on Wednesday March 12, 2003 @12:30PM (#5494505)
    This is a pet peeve of mine. What is professional about it? Why not just name the book Apache Security? What does the word "Professional" add?

  • Not good enough. (Score:4, Interesting)

    by gpinzone ( 531794 ) on Wednesday March 12, 2003 @12:30PM (#5494511) Homepage Journal
    Just reading a book won't save you from the next cracker attack. However, having a solid knowledge of the basics of web security and a list of effective checkpoints for configuring your server, will definitely help you to prevent at least the most trivial mistakes.

    That's not good enough. I want a detailed list of exploits and how to configure my web server not to be vulnerable. I want to know what patches fix what. I want to know what vulnerabilities exist. Since we're not talking about Apache and not IIS, I'll assume this information isn't being kept a secret to prevent script kiddies from using an exploit on my box. So, where the heck can I get a definitive answer? Is there some kind of tool I can run (for free) that checks my system for vulnerabilities?

    • Re:Not good enough. (Score:5, Informative)

      by caferace ( 442 ) on Wednesday March 12, 2003 @12:56PM (#5494735) Homepage
      Is there some kind of tool I can run (for free) that checks my system for vulnerabilities?

      Try FreeScan [qualys.com] from Qualys. Nice web based tool.

    • Go visit Packet Storm [packetstormsecurity.org]. It's a pretty good site to grab admin tools. And a good place to read about what exploits you need to keep your eyes open for.
      Not sure how much you'll pick up for just your webserver, but it's a good starting point to pick up from.

      Malk

    • **Sigh** was Re:Not good enough. (Score:4, Insightful)

      by Phoukka ( 83589 ) on Wednesday March 12, 2003 @12:59PM (#5494757)
      Um, you may want to consider that the tool is yer brain and yer hands.

      Somewhat more seriously, go check out the BugTraq mailing list at securityfocus.com. You will find there just about everything you so obnoxiously demand. Also, get on the main and developer mailing lists for whatever software you use, Apache httpd, mod_perl, whatever. Third, read, read, READ!!!! Read ALL the fine manuals, how-tos, etc, etc. Read the Source, Luke.

      This book (at least from the review, haven't seen it myself) will clue you in as to what CATEGORIES of exploits exist, and how to prevent them from being used against you. If you "need a detailed list of exploits" after that, if you really truly NEED a set of cookie-cutter recipes, then please do your employer a favor, and quit now.

      It is possible to make lists of every KNOWN exploit. It is nearly pointless to do this, though, since for every known exploit, there are inevitably going to be unknown exploits and unknown variations. However, learning about the KINDS of exploits and preventing them is much more efficient, intelligent, and effective.
      • Exactly :)

        And, the thing is, the best reason to use the web for up to date exploit information instead of a book (if you must know of all the exploits as this person wants to) is that by the time a book actually hits a shelf at a bookstore on "current" exploits, it is already extremely out of date.

        I agree, understanding how your server software works will help you understand what can potentially be exploited on it! It is infinitely more useful to understand how Apache works than to *only* get a list of currently known exploits. Both should be intelligently employed together.

        I think also important is, following strict policies of enabling functionality only when it is necessary *and* securable. If new features are not currently securable, they are potentially dangerous and probably not worth the risk they pose to data on an otherwise secure system in exchange for their benefits.
      • Let's see...your solution is to go on bugtraq, and check every known exploit, become well versed on them all, and figure out how to protect yourself against each one manually. Considering most (if not all) of these exploits have a "proof of concept" test, why not bundle all these tests into a package and run it against your server. Wouldn't THAT be easier?
        • I shouldn't answer, but I will anyway... more fool me. Yes, a package of tests would be easy. But it isn't enough, and it never WILL be. Because there are always variations that the tests won't cover. On the other hand, educating oneself as to what broad categories of vulnerabilities exist, and making sure that one's server is not vulnerable (or at least minimally vulnerable) to the entire category, is a much more efficient and realistic way of going about it. Even so, having run the package, you will have security information regarding that one point in time -- NOT a security blanket for always and ever. As soon as you are finished running it, or even concurrently, some cracker somewhere could be testing his new exploit code on YOU.

          If you want *easy*, I can't help you. Humans write code, and humans are prone to error. If you want the most secure server possible, you will need to learn buckets about system administration. A starting point is to use an OS that is built for security: OpenBSD comes to mind, and maybe something like SELinux, I don't know enough about it to say. Then, run only the minimum of services you need, and make sure that the software providing those services is the most secure possible. Check out Bastille, the Linux hardening system. As others have pointed out, there are simpler, easier, more secure web servers available than Apache. Apache is stable, reliable, reasonably (though not the best) performant, and HIGHLY configurable. It is the kitchen sink of web servers -- everything gets thrown into it, and it does a darn good job of it all. But having lots of options means there is a good chance that some of those options will allow you to leave your system unsecured in some way.

          Use intrusion detection systems, keep your system up to date at all times (and THIS is where the BugTraq mailing list is optimally useful, as a notification method for newly discovered problems), go to insane lengths and go bald, blind, and crazy trying to keep up with it all. Because, while a black hat only has to come up with ONE new exploit, YOU have to stay on top of ALL of them.

          So, easy is nice, and I'll very likely check out the suggestions others have posted. But security isn't easy on the whole, you're either uber-paranoid or too complacent. You just have to figure out where your level of complacency lies. In all truth and honesty, on my own server I make sure that I'm fully patched, and aren't using anything too obviously open for intrusion, and that's about it. But then, I don't have any massively important data on my server anyway, and as a result, I don't NEED to be uber-paranoid. So, I know where my level of complacency is and I'm not unhappy about it. At the same time, I realize that I'm not on the cutting edge of security, and I also realize that easy isn't really an option to obtain true security. What you seek will give you something that you shouldn't have, and that's a false sense of security. You need to be aware, deep down in your heart, that as long as there are people out there who care enough to spend enough time at it, nothing -- say it with me, now -- NOTHING is truly secure.

          And, oh yeah, people who become well-versed with everything that comes out on BugTraq to the point where they start contributing are called security experts, and are typically very well paid for that expertise. If you want to have security to that level, that's what you have to do. And by that time you are too paranoid to ever feel secure again... ;)
    • Is there some kind of tool I can run (for free) that checks my system for vulnerabilities?

      So you aren't willing to pay anything to secure your site? I guess you'll get what you pay for.

    • I looked at WebInspect [spidynamics.com], and it does a decent job at vuln scanning. It also inspects the web pages, forms and parameters. Found an SQL injection bug in one site, which could of lead to session hijacking. The downside - it costs about $5000, but does some cool stuff.
    • [I wrote the book, so my comments might be a little biased :p) ]

      I totally understand what you mean.

      I must say that the point of the book is to give solid knowledge in order to understand *why* such exploits exist, and how to prevent them. A raw list will help you for the current version of Apache, where a deeper understanding will help you prevent and help you prevent any kind of vulnerability...

  • Clumsy Admins (Score:4, Interesting)

    by SirLantos ( 559182 ) on Wednesday March 12, 2003 @12:31PM (#5494516) Homepage
    Too often their attacks are aimed at unprepared, defenceless servers which were improperly secured by clumsy administrators.

    Now if we can just get those admins that are clumsy, to admit to it and force them to read the book.

    But seriously, I am glad that books like this are being printed, it makes it that much harder for crackers to play immature -and sometimes harmful- pranks and give the rest of us bad names.

    Just my humble opinion,
    SirLantos

  • I might read this (Score:5, Insightful)

    by The Tyro ( 247333 ) on Wednesday March 12, 2003 @12:32PM (#5494520)
    Unlike a lot of people on Slashdot, I'm a hobbyist/amateur sysadmin (or is that term even appropriate?), and this book is probably just what I need.

    I've been using/programming computers all my life, but have never taken a single Comp Sci or MSI course; I end up going to books and HowTo's very frequently. I run several servers at home, including an apache webserver, a samba server, etc... For a guy like me who's not 3l337, these kinds of things are a godsend.

    I've spent 11years in higher education... NO WAY I'm going back for another degree; keep those understandable, non-arcane books coming.
    • that's the 1st time I see someone actually sounding a bit shy of RTFM. It's the other sort of folks, those who never read the docs/HOWTO/FAQs/mans that should be ashamed, not you. And education b/g doesn't matter here at all - I know a lot of folks with master or doctor degree in CS that just suck at their jobs, and are never able to learn something from technical documentation, no matter how well written.

      Now personally I prefer the Apache docs, FAQs and mod_perl mailing list to cover anything I don't understand in it, and go to source code when in doubt, so I don't think I'll be tempted to buy this book...

      • Re:never be ashamed of RTFM (Score:4, Interesting)

        by stratjakt ( 596332 ) on Wednesday March 12, 2003 @01:22PM (#5494940) Journal
        I spent 3 years chasing a CS degree, when I realized it was an absolute waste of my time. Everything I know about computers I learned on my own, by doing.

        The straw that broke my back was the OpenGL course I took, where we spent the whole semester revisiting high school algebra, matrices and projections and normal vectors and whatnot. Not one line of friggen code written, not one technique learned (I wanted to learn a bit about bsp trees, gourad shading, environment mapping, you know.. the cool stuff). We didnt even learn the differences between gl.h, glu.h, glut.h.. It was a huge crock of crap.

        So I just switched to a pure math degree.

        Comp sci, and IT in particular, is something you learn by doing.
        • Comp sci, and IT in particular, is something you learn by doing.

          I think you're wrong. Computer Science is highly theoretical (hence "Science") and you should expect a great deal of algebra, matrices, etc. You sound like my friend who started majoring in Engineering and complained that he wasn't learning how to fix circuits! That's a technician's job, not an engineer's. If you want to learn programming, program. If you want to learn the theory behind computing, major in Computer Science. If people don't want to learn the theory, why do they take curricula which is highly theoretical?

          And, why on earth would you switch to pure Math if you weren't learning anything practical in Computer Science??? Was that a joke?

        • CS is applied math, that's all. If you want to learn how to program in X, Y or Z language, then go to a junior college or a trade school. Computers are to CS what telescopes are to astronomy.
          • Yes, CS is applied math, which is why I was better served switching to the pure math program.

            The CS program was full of .com wannabes which is why it revolved around reteaching high school algebra to them, instead of letting them flunk out or transfer to a less trendy program.

            I love and appreciate mathematics, and how it relates to CS. But spending two weeks discussing dot products in a 3rd year CS course? It was a joke.
        • The question you should be asking yourself is, 'Am I obtaining education for a job or higher learning?'. Computing science is science - the quest for knowledge. Tech. College and a ton of certifications in every app and/or framework you use is the way to go if you have/want a non-research job.

          Things come easier when you understand the underlying technologies/science, although not necessary to know. Books, like this one, targeting beginners to intermediates will help ease the learning curve and that's always welcome. Besides, how many IT folks are really going to cruise the source. If they're from a Microsoft background... nil (there's no source in Bill's world).

          Why know matrices and vectors if all you're going to use is someones rendering engine? Why know sorting algorthims and trees if all you're going to do is drag and drop in access? Why understand tcp if all you're going to do is turn-on/off properties on tabs of win2k? .... Because whenever things go seriously wrong the deeper low-level knowledges saves the day.

          BTW: I gots two tech diplomas, plethora of certs, and 2 1/2 years on my CS degree. Overkill for the day to day MS monkey stuff but that's okay I'm NOT a monkey.

    • no amateurs allowed (Score:4, Funny)

      by sczimme ( 603413 ) on Wednesday March 12, 2003 @02:47PM (#5495722)

      Unlike a lot of people on Slashdot, I'm a hobbyist/amateur sysadmin (or is that term even appropriate?), and this book is probably just what I need.

      No, I'm sorry - this book is only for professionals. "Professional Apache Security" - see? Move along... :-)

  • webapp side of the equation (Score:5, Informative)

    by StandardDeviant ( 122674 ) on Wednesday March 12, 2003 @12:35PM (#5494553) Homepage Journal
    The webapp side of the security equation is often sadly neglected by people focusing on the network and host levels of the system. (Which, don't get me wrong, are very important in their own rights.) It's nice to see a book that addresses "programmer-level" holes as well as "administrator-level" holes.

    A very good site for (free) information on this area is http://www.owasp.org/ [owasp.org]. OWASP seems to mainly focus on webapp level security, which is ok given the wealth of informative resources out there for the host and network layer. (OWASP = Open Web Application Security Project)

  • It's a start (Score:5, Informative)

    by Kneht ( 218314 ) <kneht@abcdefghij ... cdefghijklmnopqr> on Wednesday March 12, 2003 @12:40PM (#5494591)
    There's never gonna be a single source for all things security--even for a single item such as Apache. Those looking for a good start can go with this book, or google for how-to's, but another place is www.securityspace.com [securityspace.com].

    If you're running a web server, use my painfully-earned experience and never trust a single source to tell you you're secure. (This includes you. Get someone else to double-check your servers for you. Otherwise, you will never know what you missed until it's too late.)

    kneht

    • You're also better off realizing that no amount of 'locking down' or 'securing' your servers will eliminate the need for a sound backup and restore plan.

      Usually when I see a server get pooched, it's the admin that did it.

      Ie, they mean to type "DELETE FROM customers WHERE last_name = 'malda'", but forget the where clause.

      Or wiping the current directory with rm -rf ./*, but the . key is sticky and doesnt register.

      It happens to the best of em.
      • Or wiping the current directory with rm -rf ./*, but the . key is sticky and doesnt register.
        ITYM if the / key is sticky and doesn't register. Jaysus, I'm so scared of that I can't even click submit when I see rm -rf .*.
    • [I wrote the book, so my comments might be a little biased :p) ]

      >There's never gonna be a single source for all
      >things security--even for a single item such as
      >Apache. Those looking for a good start can go
      >with this book, or google for how-to's, but
      >another place is www.securityspace.com
      >[securityspace.com].

      I coulnd't agree more. For this reason, tis book is *full* of references to web sites, CERT pages, RFCs, etc.
      As I wrote in the introduction, this book is a start, a way of finding your way through the great deal of documentation available for Apache (and concerning security).

      Merc.

  • Secure Web Sites... (Score:5, Interesting)

    by xchino ( 591175 ) on Wednesday March 12, 2003 @12:41PM (#5494600)
    Don't want your web site defaced? Stick it on a CD and serve it from there. I know this isn't always feasible, but 99% of the time it is. Of course, this won't protect you from a rooting, as they can simply change the web directory to serve the defaced html. This is still a bit easier to remedy than having your customers files wiped out and having to notify them to re upload their webpage, as "hacked by chinese" doesn't seem to sell products/services well.

    As far as securing Apache itself, don't load modules you don't need, and keep it patched. That's about all you'll need to do to shun a majority of exploits. There's plenty of other security hardening modes and methods for Apache out there, Google them up and you'll probably get more than out of this book.
    • Agreed. However, if this is too drastic, you can have the same level of security by having a /readonly mount. If someone got root, they could remount that as read-write, just as they could screw with your DocumentRoot w/ the CD method, but it gives you the flexibility to do the same.

      Of course, under some OSs you can make it so filesystem mounts can't be changed without a reboot. It all comes down to how much convenience you need for yourself, and perhaps your end-users. (I know many companies that are not in a position to audit all customer CGI scripts for security holes, DOS holes, etc).
    • Yeah, well that'll work for all sites except ones with dynamic content. Which is like, er, every major site (and a lot of the minor ones) out there.

      Hmm....
      • " Yeah, well that'll work for all sites except ones with dynamic content"

        It seems you misunderstand the nature of dynamic content. Dynamic content comes from SSI languages and database backends. The content is derived from static code, such as a PHP script. The PHP script doesn't change, only the values it displays.
    • http://cr.yp.to/publicfile.html
    • You can also mount readonly for /usr, /bin, sbin.
      Most intrusions AFAIK are done by replacing common commands with a new one.

      If the commands are read-only they can't do that.
      I imagine the commands could be bypassed by altering your path, but that's another level of complexity that would need to be done.

      Oscar

  • Alternatives to reading this book: (Score:4, Insightful)

    by zaqattack911 ( 532040 ) on Wednesday March 12, 2003 @12:44PM (#5494628) Journal
    "Apache Security" is probably easy to get the latest information on. Probably for free, and without having to cut down trees.

    For example, assuming you have the latest patched apache, the left-over security issues that are CGI/web app/scripting related fall under the web applications category of security.

    In this case, have a look at some of the guidlines over at The Open Web Application Security Project (OWASP) [owasp.org] .

    Way better than paying too much for a book that wastes paper, and will likely be out of date in no time.

    --noodles
    • Way better than paying too much for a book that wastes paper, and will likely be out of date in no time.

      the beautiful thing about books, especially if they have an underlying message, is that they will not be dated......

      if this book is what it promises to be, it could teach young sysadmins where-to and how-to check for web abnormalities, and web server security risks.

      just my 2cents.

  • Hah! (Score:1)

    by BJH ( 11355 )
    Bravery?!
    So, what's next on the crackers' list of challenges to prove their bravery - stuffing kittens into sacks and throwing them off bridges?

    • Re:Hah! (Score:3, Funny)

      by stratjakt ( 596332 )
      >> So, what's next on the crackers' list of challenges to prove their bravery

      Posting something like 'linux is gay' as AC on slashdot.

  • Need HTTPD Security? (Score:3, Funny)

    by kc8ioy ( 640909 ) on Wednesday March 12, 2003 @01:21PM (#5494931) Journal
    Just close port 80 for all traffic. It works everytime (except when the firewall blows up).

    Computers and air conditioners are both the same.
  • I was always under the impression that an insecure server was more responsible for web defacing then an incorrectly configured/secured apache installation. I can understand misconfigured or poorly written cgi programs, but that aside how typical is this compared to a system compromised by other means?

  • web server security documentation (Score:1, Informative)

    by Anonymous Coward

    www.cgisecurity.com/lib [cgisecurity.com]
  • tinyhttpd, publicfile, etc.
  • Here's a real world security example I am researching. Let's see whatcha think... I usually program in mod_* (whatever). I've been away from CGI since.. oh, 1997 or so. The security issue is a big reason why.

    But.. I want to install a blog package on my own (as in my own box in a colo) server.

    I'm strongly considering Moveable Type. I like its features.

    Apache + suEXEC + Moveable Type, properly configured.. thumbs up or thumbs down? Would you stay away from CGI-based packages on principle, or is suEXEC really that good? I would restrict suEXEC to the one vhost running the blog package.

    And if not Moveable Type, then what blog package securely [1] runs with Apache under some mod_* setup?

    [1] "securely" meaning "reasonable amount of security that would frustrate all casual attempts"

  • why... (Score:2, Funny)

    by Alpha_Nerd ( 565637 )
    Just reading a book won't save you from the next cracker attack.

    Wait a sec... Then why are you showing us this book??
  • I've always wondered why RedHat doesn't chroot jail things like apache, bind, etc.

Slashdot Top Deals

1 + 1 = 3, for large values of 1.

Close