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...

Question:

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???

Answer:

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:

  1. By inserting Apache in front of IIS for every request, all you accomplish is execute more code (both Apache and IIS) per request from the Internet. All code has non-zero defect rate, so inserting more code simply increases your chance of encountering a defect per request, and some percentage of those defects are security related. Thus, by inserting Apache, you merely increase the risk of triggering a security defect for each request.
  2. By isolating IIS in the Intranet, away from direct Internet access except through Apache, all you accomplish is deny Internet-based access to all ports on the IIS machine except for those that are open on Apache. You can accomplish this same effect by placing a firewall, either a hardware device or software running on the IIS machine, that only allows the same open ports on Apache for clients to access. You do not need Apache to do this.

Thus, at best, your proposed network topology cannot improve security.

What? You mean Apache does not Improve Security? Blasphemy!

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. :-)

Basic Security Terminology and Theory

To talk about security, we must agree on a couple of terminologies and concepts:

  • Valuables - these are your worthy resources that you are trying to protect.
  • Threats - these are the bad guys that are trying to steal or otherwise compromise your Valuables.
  • Vulnerability - this is the means by which a Threat can compromise your Valuables.
  • Exploit - When a Threat is successful in utilizing a Vulnerability to compromise your Valuables.

Clearly, the basic problem in security rests on protecting one's Valuables. What are some of the ways to do this?

  1. Have no Valuables. If there is nothing worthy to take, then you are secure from having things taken from you.
  2. Eliminate Threats. Take care of the bad guys before they take care of you.
  3. Eliminate Vulnerabilities. Get rid of ways for bad guys to take things from you.
  4. Stop Exploits. Utopian world where there are no bad guys interested in being a Threat.

Most of the approaches are extreme and rare to accomplish. Most of this world tries to accomplish #3 - eliminate vulnerabilities.

About Security Vulnerabilities

When talking about security vulnerabilities, we are NOT just talking about the MS05-00XX bulletins. Software security is multi-faceted and consists of:

  • Software - this is the system under discussion that accesses the Valuables
  • Configuration - this is the configuration of the Software that accesses the Valuables
  • Policy - this is the human usage pattern of the Software and Configuration

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:

  • The most securely configured and tight security policied system can fall victim if the Software has a remote anonymous LocalSystem exploit.
  • The most securely written and tight security policied system can fall victim if IIS is Configured to allow anonymous user Write and Execute permissions on a virtual directory.
  • The most securely written and configured software system can fall victim if the user has a poor Policy of leaving the console unlocked (or have username/password on a Post-It note...).

What You can do

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.

All about the Attack Surface

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.

  • With firewalls, you can close off the remainder of the server from external contact and just have port 80 open and allowing HTTP Requests to reach your web server. Reducing the number of ports accessible via the Internet reduces the Attack Surface by reducing server code listening on ports from ever being accessible.
  • With tools like URLScan, which examine characteristics of the Request URL and Headers for "funny behavior", you can reject bogus or otherwise prevent functional code on the IIS server from ever executing, thus reducing the Attack Surface of the server.
  • By running IIS Lockdown, you tighten up various configurations on IIS to prevent unwanted or unknown functionality from ever executing, thus reducing the Attack Surface of the server.

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.

IIS5 vs IIS6

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:

  • IIS6 is not even installed on Windows Server 2003 by default, unless it is the Web Blade or Small Business Server SKU. User has to take explicit action to install IIS6. This is contrary to IIS5, which is installed and running by default under the assumption that user ease of use is key.
  • Once you install IIS6, it only serves static content that has a defined Content-Type. Thus, you can serve plain HTM/JPG/GIF as well as download EXE/ZIP files. Specifically, you cannot download ASP files to read its source code. On IIS5, everything can be served, which makes $DATA exploits for ASP possible.
  • If you want to run dynamic content on IIS6, you must explicitly enable dynamic content execution by IIS as well as enable dynamic code with a Web Service Extension. If you do not enable an ISAPI or CGI as a Web Service Extension, IIS6 will not run it to execute dynamic content. Period. On IIS5, everything can be run as soon as you enable IIS to do so, which makes virtual directories with Write and Execute permissions suicidal.
  • Even if you manage to run dynamic code on IIS6, it only has access to an unprivileged Network Service account by default. So, even if there is an exploit, the resulting damage scope is low. Contrary to IIS5, which can run code as Local System where damage from an exploit is high.

And the list of multi-pronged, multi-layer security approach of IIS6 goes on and on...

Conclusion

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.

//David