One of the most common services to be running is Web servers. Microsoft's built-in Web server, Internet Information Services (IIS), comprises a substantial portion of the Web servers on the Internet today. A few years ago, IIS garnered a not entirely undeserved reputation as being horribly insecure . Much of this was due to additional functionality and samples jammed into the Web server that were not directly relevant to the core function of serving Web pages. For instance, some rocket scientist actually thought it was a good idea to not only install IIS by default on Windows 2000, but also to include a component called the Internet Print Provider (IPP) that allows users on the Internet to print to internal printers, through IIS. Now, in spite of the fact that this is probably not functionality that 99 percent of Web servers ought to have, it probably would have gone relatively unnoticed had there not been a buffer overflow in the component that handled print requests . A few weeks later, a similar problem was discovered in the indexing services component, which was also installed by default in spite of the fact that the vast majority of Web servers do not need it. This problem overshadowed the complaints about the IPP, particularly a couple of weeks after it was discovered , once Code Red, which exploited the Index Server component flaw, came out.
Clearly, IIS 5.0 leaves a lot to be desired in the realm of security. Does that mean it is fundamentally unsafe? No. We have personally run Web servers on IIS 5.0 for many years without getting them hacked, because we took the pains to protect them. The most important step you can take is to run the IIS Lockdown Tool (http://www.microsoft.com/technet/security/tools/locktool.mspx). The Lockdown Tool is the single-most important thing you can do to protect IIS 5.0. Beyond that, we refer the interested reader to the white paper titled "From Blue print to Fortress" (http://www.microsoft.com/serviceproviders/security/iis_security_P73766.asp).
IIS 6.0 is an entirely different story. The code base for IIS 6.0 is completely new. Basically, the product was rewritten from the ground up. To date, this has been very successful. As of this writing, there has not been a single security bulletin issued for IIS 6.0 itself. There have been several, however, that affect an IIS 6.0 Web server, but largely because it uses operating systems components that have problems. In the rest of this chapter, we cover how to protect an IIS 6.0 Web server.
The first thing you have to realize is that IIS is much more than a Web server. It is an application platform. Therefore, the hardening you can do depends on what applications you are running. If all you are doing is serving plain Web pages, you can lock the system down pretty tight. However, if you are using more advanced application functionality, you must unlock some things. Yes, unlock. By default, IIS 6.0 installs only as a file server. All the functionality of the Lockdown Tool from IIS 5.0 is already built in. The key thing here is to only unlock exactly what you need. If you do not need the .NET Framework, do not install it. If you do not need Active Server Pages, do not enable them.
IIS uses application pools to execute Web applications. A Web application is basically a set of Web pages underneath one directory structure that are considered a single application. Whereas in IIS 5.0 Web apps by default executed within a single process, by default in IIS 6.0 you can much more easily manage each application, the account it executes under, and which process context it executes under. Although a complete discussion about how to run IIS 6.0 is the subject of several books, we will state that you should use this functionality to isolate applications from each other to make sure that if one gets compromised it happens in a low-privileged context, away from other applications.
One of the most frequently asked questions about IIS is how to make it connect to a database server for processing requests from anonymous users on the Internet. One of the most common approaches is that taken in Chapter 2, where we created a text file defining the database connection and specified a set of SQL Server credentials in there. This approach is very flawed. First, it requires us to use SQL Server authentication, which is highly undesirable. Second, it requires us to maintain cleartext credentials as well as cleartext connection information somewhere in the Web application. A much better approach is to use Windows authentication and a Data Source Name (DSN). It is actually really easy to do this. First, create an account to use for the connection. We will call it Webuser, for simplicity. If both systems are in the same domain, use a domain account. Otherwise, create two identical accounts on the Web server and the SQL Server. Then, set IIS to use that account for authentication, as shown in Figure 14-7.
As Figure 14-7 shows, configure anonymous access in IIS 6.0 to use the Webuser account. This account is known as the impersonation account in IIS 6.0. It is the account that the worker process impersonates when accessing files and processing identity those files. This is distinguished from the process identity , which the process identity of the worker process doing the impersonation. The process identity is the account configured in the Application Pools portion of the Internet Information Services Manager. After you have configured the impersonation, you need to grant this account execute permission on the stored procedures you use. First, add Webuser as a database login, and then map it as a user in the required database, ensuring that it has the proper permissions, as shown in Figure 14-8.
Next, grant it execute permissions on the stored procedures, as shown in Figure 14-9. You do not need to grant it any access to the underlying database.
All access in SQL Server happens inside the SQL Server process, which means that the actual access check happens only on the stored procedure, as long as the same user owns both the stored procedure and the tables. In most Web applications, you probably have a finite set of stored procedures, making this a viable way to grant access to the application. Finally, make sure you have revoked Public access, as shown earlier. Otherwise, the Web user account has access to a large number of other objects that it does not need.
We want to leave you with one of our favorite tools for protecting IIS: URL Scan. URL Scan enables you to scan requests before they are processed by IIS and throw away illegal ones before the server even processes them. It can control the verbs you permit, the lengths of requests, and many other things. To entice you to look further, we provide two examples here.
Microsoft Security Bulletin MS03-007 announced a vulnerability in WebDav. The problem was an integer overflow in a string-length variable. The string length was stored in an unsigned short, which is a 16-bit value. If the string was longer than 64K, this value would wrap, so that a 64K+11 character string would actually show as having a length of 10 characters . WebDav relied on this value to allocate the buffer into which it copied the string, with the net result that we had a 64K buffer overflowenough to install a decent operating system kernel. To exploit the issue, an attacker would need to send a 64K string to the server, however. URL Scan on the Web servers on Microsoft.com were configured to drop all requests larger than 16K. Without the patch even installed, they were immune to this issue.
When URL Scan was configured on Microsoft.com>, performance increased significantly. This seems counterintuitive, because security checks usually reduce performance. However, Microsoft.com is a very heavily attacked site. Allowing URL Scan to drop obviously illegitimate requests allowed the servers to focus on the ones that were more likely to be legitimate , increasing performance.
Some of the features of URL Scan are already included in IIS 6.0. Nevertheless, you get significant additional control by using URL Scan even on IIS 6.0. We highly encourage you to download and evaluate it. The best part is that it is free, so other than your time, there is no cost. You can get it at http://www.microsoft.com/technet/security/tools/urlscan.mspx.