An obvious fan of open source, an anonymous author chimes in on the security of open source Web Servers, particularly Apache, versus other options. Interesting and informative despite an apparent bias, Anonymous's answers to Web Server security issues should be a help to any shop that is pondering a move to open source. Read the rest of this interview at InformIT.
Question: Web server security is obviously of critical importance to corporations and government agencies. With that in mind, what advice would you give someone considering open source versus a proprietary Web server solution?
Answer: Open source's modular design offers rapid, decentralized deployment and response. For example, suppose that an Apache security module you're using proves vulnerable to attack. You can instantly (or very near instantly) disable that module's support. And typically, within a week or so, that module's author will issue a fix or a patched version. Conversely, when new modules emerge that offer desirable services, you can plug them in with minimal effort.
To understand how valuable this is, contrast this against Apache's strongest competitor, Microsoft's IIS. IIS is a centralized application, maintained by a single entity. It therefore not only evolves on a slower development curve, but also offers comparatively limited flexibility. And because new attack methodologies (and new security technologies) emerge daily, flexibility, rapid deployment and turnaround are all essential issues. Apache is more malleable, adaptable and decentralized. It allows you to pick and choose which security features they want or need. Because modules are independent entities -- entities that Apache is neither tied to nor needs to operate effectively -- Webmasters needn't accept unwanted, irrelevant or extraneous modular components. Instead, they can include only those modules that provide services critical to their enterprise. Think in terms of warfare. Who fares better: the military that has rapid deployment and decentralized support, or the military that doesn't? The military that's informed regarding its technology (and how it works) or the military that isn't?
I've had long experience in that area (proprietary versus Apache). In 2000/2001, I managed a team that built one of Earth's largest databases (it uses the International Address Element Code for addressing, for example, which uses 152 fields for physical addresses, breaking down addresses so granularly that you can enable two machines in different nations that use disparate addressing structures to automatically exchange addresses without human intervention -- and the address component was merely one component out of hundreds). We used Solaris, Oracle, Pro*C/PL/SQL, PHP (through OCI, ugh) and Apache. We also had a parallel development effort (in case Apache folded under the strain) using IPlanet and also OracleAppServer/JSP, yada, yada. Apache smoked -- and we're talking tests that simulated 100 million records (and which stored one personal, unique identifier for every human being on this planet). We stayed with Apache except for the internationalization issues, which came later (and then, these were limited issues, for which we used JSP to OracleAppServer, where each JSP ran in its own, miniature JVM). Short of that, though, which has since been addressed, Apache outperformed any Web server we threw in the mix.
In short, Apache is gnarly. And, whereas it was once "Well, Apache doesn't have the hard copy documentation to support this enterprise" it's now "Well, there's Ben Laurie's book, twenty-dozen-other admin titles exist, we have Maximum Apache Security [shameless plug alert], and so on." Unless yours is a totally platform-centric solution (where you must use IIS or another Web server because your contracts dictate it), choose Apache. Benchmark it and see for yourself. Apache + MySQL + PHP, for example, outperformed (in our tests) commensurate commercial configs by a factor of at least 1:50 (and in some cases, 1:250). The proof's in the pudding, and Apache's pudding rocks.
Question: What are your predictions for the future of Apache and Web server security in general? Will better publicity help Web server administrators keep their servers more secure, or will hackers always be a step ahead of even the most disciplined administrator?
Answer: Well, that's a loaded question. Apache just saw some problems (chunking, etc.) Better publicity helps, for certain, but developers, hackers and crackers will always have a tiny edge. Even efforts like OpenBSD (traversing every line, looking for common holes and even enabling the compiler to watch bad constructs) still suffer holes. However, you have a much better chance with open source. Open source has no place to run or hide; people bang on that code 24/7 and they frequently trash it. But it's tighter than closed source, no question.
The stats speak for themselves. Microsoft's closed products were responsible for more than 60% of the holes from 1997 to today. Open source competitors had a much lower ratio. The best protection you can realize is to know your application (in this case, your Web server) inside and out. By knowing how it operates (and where, in its source, security facilities exist), you can at least understand, in a general way, where problems might arise. Hence, when you see an attack emerge, you understand why and how it emerged.
That's why I wrote an entire book on Apache security. A chapter or two won't do it. You must know how Apache handles authentication, for example. When you understand the phases it traverses in that process, you have a concept of how someone can get inside or in between those phases and cause unintended results. But hackers will always expose more problems. Hackers (regular users) now have staggering technology at their disposal and they understand the applications they attack. For an administrator to survive, she's got to own the same technology and understand it with the same depth. More than that, though, she must understand (with the same depth) every technology she grafts to Apache.
For example, modules now exist that support open C/C++ directives inside HTML. That's wonderful (and more than a tad amazing), but equally, before deploying such modules, a sysadmin must first understand the security issues inherent in C/C++ constructs. Basically, we have so much technology available, a gap exists between WHAT we can do and understanding HOW we do it. New languages and modules crop up every day. Some survive and take hold and some don't. In the balance, new technology (until it receives adequate bandwidth play) remains a crapshoot. Few enterprises can afford to engage in crapshoots anymore. It pays, therefore, to know your baseline technology well. That and remaining diligent and current on security issues and patches; these are your front lines of defense.
Read the rest of this interview at InformIT. Registration is required, but it's free.
