I got the following interesting question about IIS security and whether it was better to "protect" IIS with an Apache server in front of it. Hmm, let's take a step back and look at what is security...
Hey, I really like your blog. I was wondering if you could give me your quick thoughts on this: A guy at my office is concerned about us having an IIS web server that is exposed to the internet. He wants to "front" the IIS server with an Apache server and have the Apache server redirect to the IIS server for "better" security. Thoughts???
Oh, hey, a juicy topic... IIS and security. :-) Please let the guy at your office voice his concerns and rationales as comments on this blog entry - I am very interested to hear and discuss it.
I presume the proposed network topology would have Apache facing the Internet, and it transparently forwards requests (using something like mod_rewrite and mod_proxy) to the IIS server on your Intranet (i.e. IIS server is otherwise not accessible via the Internet). IIS then processes the request, sends a response back to Apache, which then relays it back to the client in the Internet.
In general, I do not believe that simply fronting IIS with an Apache server results in "better" security. I find the statement to be a bit vague to base any sort of decision. Mind you, I do not wish to engage in any zealous or emotional behavior; I am simply stating impartial facts and drawing logical conclusions. :-)
Here is what I think of the proposed network topology and security in general:
Thus, at best, your proposed network topology cannot improve security.
Now, I know that you have heard all those reports saying how IIS5 is insecure and that Apache 1.x is solid and runs 70% of the worlds websites, so you wager that "since IIS5 is insecure, blanketing it with Apache should improve its security, right?" However, such a statement is based on emotions and a warm, fuzzy feeling and not the cold, hard facts. So, sorry for busting up your fairy tales about Apache and introducing some real-world concepts that qualify and quantify security to a point where you can logically determine whether a given action increases or decreases security. Only then can you make decisions that result in measurably "better" security. :-)
To talk about security, we must agree on a couple of terminologies and concepts:
Clearly, the basic problem in security rests on protecting one's Valuables. What are some of the ways to do this?
Most of the approaches are extreme and rare to accomplish. Most of this world tries to accomplish #3 - eliminate vulnerabilities.
When talking about security vulnerabilities, we are NOT just talking about the MS05-00XX bulletins. Software security is multi-faceted and consists of:
Unfortunately, the media and most of the world simply focus on the "Software" aspect of security and try to pin Microsoft as solely responsible when the truth is far from it:
Now, from a user perspective, you can rarely affect Software defect rates (Open/Closed Source does not matter - most users do not compile their own Software anyway). For a perspective on Software defect rates, read this URL.
For insights on how Microsoft is proactive reducing Software defects in security, just read Michael Howard's blog. He is one of the key folks driving security at Microsoft and incidentally has a long history with the IIS team.
What a user CAN control is Software Configuration and System usage Policy. I am going to assume that you can come up with a reasonably secure System usage Policy since that is strictly your computer and your responsibility.
Thus, at the end of the day, what we have left to discuss is just Software Configuration and how to eliminate Vulnerabilities in it. To deal with this issue conceptually, it is useful to think about the concept of "Attack Surface" (i.e. these are the avenues opened by Configuration through which Threats can attempt to Exploit your Valuables) and focus on reducing the Attack Surface, thereby limiting the number of exposed vulnerabilities that can be exploited.
Here are some thoughts on how to reduce the Attack Surface of web servers like IIS or Apache.
The Attack Surface of a web server like IIS or Apache is basically the HTTP Request itself and the code that runs to process that request.
By now, the theme should be clear. Reducing the Attack Surface of the server by restricting it to only exposing the set of behaviors and necessary support code for a given functionality is a real way to reduce security vulnerability due to Configuration.
Unfortunately with IIS5, non-security assumptions and ideas were the norm, but with IIS6, security is front and center. This results in the multi-pronged security approach of IIS6, which goes something like this:
And the list of multi-pronged, multi-layer security approach of IIS6 goes on and on...
Hopefully, it is now clear why simply fronting IIS with Apache does not improve security. You simply increase the amount of code that processes the request, which increases the Attack Surface of the server and thus increases the chance of encountering a Vulnerability which raises the possibility that a Threat can take advantage of the Vulnerability to successfully Exploit your Valuables.
And how to improve security? By reducing the Attack Surface of the web server and reducing number of features exposed by the web server to the minimum necessary to accomplish its task. This has nothing to do with placing Apache in front of IIS since that does not reduce the Attack Surface. Instead, it has to do with configuring IIS5 with URLScan and IIS Lockdown as well as other common security practices to lock down the server, or just run IIS6 and turn on the Windows Firewall of SP1. Then, you can directly run IIS6 on the Internet without fear because you know what is open and enabled on the server and how securely you configured it.
Security is not an absolute goal; it is a journey.