John D. Mitchell's Blog

Piss Poor Web Security Approaches

Pete Freitag writes up 20 ways to Secure your Apache Configuration. Now, all 20 tips are useful to help make Apache less insecure but they certainly don't make an Apache installation actually "secure."

First off, note clearly how many things you have to go out of your way to turn off. That is, look at all of the extraneous, insecure junk that is installed and configured as part of a default Apache setup up. That's a big violation of the security dictum that we should be secure by default and have to explicitly take action to add in extra, insecure things. An example of why this is so important is that if you actually go through all of this tightening and then upgrade that server and forget to go back through and do all of the tightening again... Oops, not only will your system be insecure again but you'll probably be under the false assumption that your system is secure when it isn't. I've seen this happen way too many times to my clients and friends.

Second, if one really cares about security, why on earth would anyone consider Apache at all? There are many much better http server solutions out there for anyone needing serious security such as publicfile. Publicfile takes an arguably extreme approach and is fundamentally incapable of the vast majority of web server security problems. Therefore, other web servers such as the venerable, static-speed demon thttpd, the new, feature-rich kid on the block, LightTPD, or even the commercial king-of-the-hill Zeus Web Server can be a much better blend of increased security and increased performance.

Of course, if you're doing Java-based web server applications, Jetty and Resin are great solutions but they also tend to err by having way too much enabled by the default configurations.

Comments

• I ask: why would anyone NOT want to run Apache? It's byt far the dominant web server (see Netcraft), the best supported for third-party software like PHP and J2EE web containers, and has an excelent security track record. Some products you cited, like Zeus, are mere Apache budles, as is the IBM httpd server.

  No matter which software you do use, you'll have to tune a lot of parameters if you intent to expose it to the Internet. Personally I found the article a little bit lame, as many tips were too obvious (anyone who didn't found them obvious should not even try to configure any internet server) and most of them are default on apache installations on Linux. Whatever the server software you install, if you let defaults you'll have a very insecure server. No exceptions. Sad, but true.

  Apache has more security-related features than all those alternatives together. Administrators and developers should learn about how to securely configure their servers and how to write secure code, using advice such as the OWASP.org web site, not switch to another software expecting it to close all the security breaches.
  

  Posted by: flozano on December 07, 2005 at 04:21 AM

• 
  flozano, as I hope that I made clear enough, I'm not just picking on the Apache web server but on the fundamentally broken, "open by default" thinking. There are plenty of other examples of the same piss-poor thinking. Unfortunately they are too easy to find.

  That said, using popularity to justify anything other than popularity is just doesn't work. Popularity is driven by lots of things but security is not one of them.
  That you (and many, many others) use the popularity argument first (or at all) is a very clear example that choice, even among supposedly rationale developers, is heavily biased (i.e., irrational).

  The simple fact is that Apache's approach is "open by default" and that's just plain bad security. Other servers such as publicfile cannot have most of the problems that afflict e.g., apache because it doesn't support insecure operations at all. I.e., publicfile isn't just "closed by default", it doesn't even implement many insecure features. It makes many of the problems literally impossible.

  Your argument that "Apache has more security-related features than all those alternatives combined" is both fallacious and is, in and of itself, an example of the complicatedness of Apache. There's way too many knobs and settings to tweak in Apache and that makes it difficult for people to secure installations in the first place, very difficult to keep it secure over time, and misleads people into a false sense of security ("gee, Apache is so popular that it must be secure", "I set up one server securely so don't worry about it", etc.).

  Of course, there is no silver bullet for security or anything else. However, that's no excuse for taking an "open by default" approach.

  Posted by: johnm on December 07, 2005 at 09:00 AM

• I agree with the argument that popularity does not ensure code is secure (See Also: Web Browsers). On the other hand, "...it doesn't even implement many insecure features..." does point to one flaw in the argument ... you've compared apples to oranges in feature sets. But the closed-by-default, that I can get behind.

  Posted by: mzsanford on December 07, 2005 at 01:52 PM

• mzsanford, security doesn't require a so-called apples-to-apples comparison. A powerful solution to security is to remove functionality. If some piece of functionality isn't there, there's less security risk. As with bugs, adding more features adds more security risk.

  
  Of course, for a lot of people, they "need" more of those features that e.g., publicfile doesn't provide and so people have created complementary servers to publicfile which use the same basic philosophy but provide more of the features that some users need. Another example is Felix Leitner's fnord has great performance and security and is easy to setup.

  Posted by: johnm on December 07, 2005 at 11:03 PM

• I agree with that "open by default" is bad but looking at this alone is not enough to recomend not using Apache and switching to alternatives. The ASF is not there to deliver software to end users, and so comparisions on defaults with other products are not fair. Every web server I tried came with default management tools and sample applications that were insecure out-of-the box and in fact I did not found them easier to configure in a secure way than Apache.

  Actually, if you do use the customized Apache binaries provided by Linux distributions such as Debian and Red Hat, or the one provided by IBM, I found them to be easier to secure and with less holes open "out of the box" than alternatives. You should compare these too, to make a fair comparision with products like Zeus.

  The "most popular" argument is used a lot of times regarding client platforms and development tools, but for server-side software like Apache it deservers consideration. Check sites like CERT and you'll see that in spite of being used by more than 60% of all web sites Apache has fewer security exploits, and with lower severity, than most alternatives. If it's more exposed and had less bugs, it's more secure. And the popularity in this case means it's easier to get information about the security features and how to use them.

  Apache httpd is mantained by the people who better understand web server security: ISP network admins. It las more security features because it addresses a wider range of needs. So you could pick up a specific scenario and learn that for that scenario other web server may be more secure or easier to make secure than Apache, but not in the general case.

  So we agree on the fundamental point of "open by default is bad" but you used it to tell people not to use Apache httpd and to recomend other web server software. You presented the question as if Apache httpd had big security problems and the others you cited did not. You need to make a much deeper comparision to come to this conclusion.

  Posted by: flozano on December 08, 2005 at 06:01 AM

• 
  flozano, sorry but when it comes to security, life ain't anything even resembling "fair." That's just not how it works no matter how much people hope and believe.

  Next, you couldn't have tried e.g. publicfile because it doesn't have "insecure out-of-the-box" defaults on anything and is trivially easy to configure securely.

  Your point about CERT is nominally true but is misleading because the comparison is against other solutions where security is also an afterthought.

  As to the claim about "professional administration" of Apache installations, that's another partial truth. Yes, there are many apache installations administered by professional administrators. Good. Heck, I've done that too. But, so what? There are bajillions of sites using Apache that are run by non-professional non-administrators people and even many of the pros are, as always, overloaded with other work and so their dilligence is taxed by the reality that most businesses don't care much about security (until it's too late).

  Here's a personal example.... When I was working at one particular startup, the network used the "open by default" model for security. We had a great sys admin who locked down the financial department. Somebody made some minor change and suddenly all of that "secret" information was available to everybody in the company, including all of the compensation details. That led to a very tense month or so as people digested all of the cronyism, bad deals, etc. that the executives certainly wanted to remain hidden.

  Also, most people don't have any idea about the real liability cost of weak security. Here's a link to information on How much will it cost you to lose your customer's data?
  

  Posted by: johnm on December 08, 2005 at 09:14 AM

• InformationWeek is running an article on Security's Shaky State which talks about, among other things, how chronically underfunded and understaffed most IT security departments are.

  Posted by: johnm on December 13, 2005 at 07:16 AM

This work is licensed under a Creative Commons License.