Slashdot Mirror
Professional Apache Security
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.
Most of the time, having the latest release of apache and all the modules in the default settings without changing anything you don't know, IMHO will prevent defacing.
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.
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 would be good just for that topic alone.
Anyone have any links on this topic?
It's not flamebait. There are many alternative servers available whos primary goal is security. They're easier to configure, secure, and maintain. Besides, most people don't need all the bells and wistles Apache offers.
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.
The net will not be what we demand, but what we make it. Build it well.
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.
Just reading a book won't save you from the next cracker attack.
Based on this sentence, I didn't bother to read the rest of your book review. Thanks for saving me time!
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?
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?
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
The flying hamster of DOOM rains coconuts on your pitiful city.
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.
Even if a man chops off your hand with a sword, you still have two nice, sharp bones to stick in his eyes.
I'd be interested to check some out.
freshmeat.net is your friend. My favorite is fnord from http://fefe.de/fnord/
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 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)
News for Geeks in Austin, TX
I'm waiting for the "unprofessional" edition to come out, complete with ketchup stains.
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
"Are you on some kind of medication?"
"No"
"Well, you should be."
--Bean
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.
Everyone is entitled to their own opinion. It's just that yours is stupid.
But many people want some of the bells and whistles. They also having changing needs. That's where an application like Apache can make sense, though as always you should spend time choosing something that meets your needs.
Which takes time. But if it's important you should be taking time, I'd suggest.
I think Apache is a decent example of an application that's mature enough to provide useful flexibility, useful performance, and still be managable. Finally, it's unlikely to disappear which will be important for anything other than very short term projects or those where you just install and forget.
"we demand rigidly defined areas of doubt and uncertainty!"
"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) .
Way better than paying too much for a book that wastes paper, and will likely be out of date in no time.
--noodles
Bravery?!
So, what's next on the crackers' list of challenges to prove their bravery - stuffing kittens into sacks and throwing them off bridges?
Why bother, when other servers are several times simpler to set up, smaller and faster? Pheh!
Let me add something here.
It will help prevent defacing, if the webserver and/or the modules are used to do it.
Flexibility is important. However, flexibility does not equal unnecessary bloat. History has shown bloat leads to security problems and support overhead.
About $8.00 to the cover price :)
Outside of a dog, a book is man's best friend. Inside a dog it's too dark to read. - Groucho Marx
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.
Ultimately though, that tactic failed to protect them against the inexorable tide white men. These days we call it a slashdotting, and there is still no known defence.
Modest doubt is called the beacon of the wise. - William Shakespeare
Slashdot Gets Hacked
Monday September 14, 02:52PM
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...
VKh
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?
This book sounds very useful and as an inexperienced admin I plan to pick it up... but I think it's important to stress that the software makers of the world (open source or otherwise) should have their installers default to the most secure possible configuration, THEN provide config tools to selectively open it up where necessary, warning what vulnerabilities may occur with the change.
I think it's better and safer that from a clean install an admin has to proceed to unlock things as needed, rather than learning (too late) what s/he should have closed.
most of the sites that have dynamic content don't need it. at all. it should be an absolute LAST resort to use php/perl/mysql/oracle/postgres backends to produce content, when you can generate static HTML on a regular basis.
i am continually surprised when people who run database-backend sites are puzzled when their site is down because of traffic.
www.cgisecurity.com/lib
Hacking Exposed Linux Second Edition has an excellent apache/web/dynamic content generation chapter, and it falls into the "walks you through the problems and gives you the solutions" category. Their website's "links" section is somewhat out of date unfortunately.
Well, putting PROFESSIONNAL is a guarantee that the thing is solid, serious, efficient. You know, like MCP, Microsoft Certified Professionnal, are sol...
Oh wait.
Yeah, as opposed to what, "Amateurish Apache Security"? From the same series as "Half-assed Programming in 10 minutes a day"?
-Andrei
About US$20, I'd wager.
!#@%*)anks for hanging up the phone, dear.
Closed Minded Apache Zealot Moderators Unite!
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...
I want to drag this out as long as possible. Bring me my protractor.
http://cr.yp.to/publicfile.html
tinyhttpd, publicfile, etc.
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
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"
Just reading a book won't save you from the next cracker attack.
Wait a sec... Then why are you showing us this book??
knowledge is power. Intelligence is recognizing this and yet acknowledging the simple limits of how much acurate and updated knowledge one can possess in one particular field (specialization) yet still be able to function proficiently in other areas and how this is so very rare. What helps are useful tools that make use of the knowledge, much like you buy a car that was designed and built by others who are knowledgeable about such things instead of yourself building one from scratch. Vulnerability assessment tools that are kept up do date help alot. However, like with cosmetic surgery vs. curing cancer it seems there is a lot of interest and funding for updated databases and tools for music cd's more than security. Or I should say, "Why is it so hard to find well designed (researcher friendly) information and support sites for these security tools outside of massively expensive "enterprise" suites?
You guys should take a look at InterDo by KavaDo, another Israeli startup..
http://www.kavado.com/
Put it between your firewall and your web server, your firewall obviously protecting the network layer, and Interdo protecting the application layer by acting sort of like a reverse proxy.
Tis good. As for ScanDo, I've not found a website yet that ScanDo hasn't penetrated!
I've always wondered why RedHat doesn't chroot jail things like apache, bind, etc.
Nothing to see here; Move along.
Well as an ME/EE I can tell you that hands-on is more a how than a what. Theoretical can be taught in a more hands on manner instead of being limited to a room full of students with a professor. In other words teaching is as much imagination as it is methodology.