The Microsoft Trustworthy Computing initiative promised customers security by default and security by design. However, Microsoft is a large company, and customers can wait a long time before seeing the effect of big changes. I was skeptical that Microsoft would deliver a locked-down Web server in Windows Server 2003 and Microsoft Internet Information Services (IIS) 6.0 and perhaps you were too, but the company appears to have done so. Let me share what I see as the top 10 security improvements in IIS 6.0 and assess the changes.
10. Windows 2003 disables IIS 6.0 when you upgrade to the new OS if you haven't run the IIS Lockdown tool on IIS 5.0. If you upgrade a Windows 2000 Server system that's running IIS 5.0 to Windows 2003 and you haven't first used IIS Lockdown to harden the server, the new OS will disable IIS 6.0 by default.
Because Win2K Server installs IIS 5.0 by default, a lot of IIS 5.0 servers that people don't know they have are sitting around out there. The CodeRed worm signatures you still see from time to time are evidence of these forgotten servers. For the most part, people have patched all the IIS 5.0 servers they want to patch; the other servers are in the care of operators who don't know or don't care that they're running infected servers. If these operators upgrade their unpatched servers to Windows 2003, they'll disable IIS and make the Internet a safer place for the rest of us.
If you plan to upgrade an IIS 5.0 server, haven't run IIS Lockdown on it, and want to enable IIS 6.0, you need to do one of the following:
- Run IIS Lockdown on the IIS 5.0 server.
- Enter the RetainW3SVCStatus registry subkey under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC registry subkey. The value of the added subkey doesn't matter—the subkey must just be present.
- Place the DisableWebServicesonUpgrade=False switch in the answer file for an unattended upgrade.
If you upgrade to Windows 2003 and find that IIS 6.0 is disabled, you can enable it by opening the Services console and setting IIS Admin Service to Automatic startup. Then reboot your computer or type
net start w3svc
at a command prompt.
9. IIS 6.0 enables pass-through authentication by default for virtual directories. Unlike IIS 5.0 and Internet Information Server (IIS) 4.0, in IIS 6.0, when you create a virtual directory to access remote content on a Universal Naming Convention (UNC) share, the Virtual Directory Creation Wizard has an Always use the authenticated user's credentials when validating access to the network directory option, which is selected by default.
Because IIS 6.0 passes along the user's credentials, you can now use NTFS permissions on the remote content in a much more granular way than in previous IIS versions. However, you need to use the right authentication method: Basic and properly configured Kerberos authentication result in logons that IIS 6.0 can delegate (i.e., pass through), but Windows NT LAN Manager (NTLM) and Anonymous authentication don't produce logons that the Web server can pass along. You must ensure that users are authenticated in such a way that pass-through authentication will work.
8. Windows 2003 supports conversion from one authentication protocol to another. Protocol transition is a Windows 2003 feature that IIS 6.0 can leverage with pass-through authentication. In a Windows 2003 Active Directory (AD) environment, an IIS 6.0 server can transition an authentication token to a Kerberos-style token, regardless of which method you use to authenticate the client. For example, Windows 2003 could use NTLMv2 authentication between the client and IIS 6.0, which could transform the logon into a Kerberos-style authentication token when it contacts other network resources on behalf of the client. Kerberos is the most secure means of deploying network authentication on Microsoft servers, and protocol transition lets you use it to authenticate users without concern for the kind of logon token they use to gain access to the IIS 6.0 server.
7. Windows 2003 lets you limit IIS server delegation. Constrained delegation is a Windows 2003 feature that fits in neatly with pass-through authentication and protocol transition. A computer that's trusted for delegation in a Win2K AD forest that uses Kerberos is trusted forestwide. However, you aren't likely to want your IIS server to forward credentials to every computer in the forest. On Windows 2003 servers, you can create computer-to-computer trusts for delegation, eliminating overly broad authority for the IIS server. For more details, see "Kerberos Protocol Transition and Constrained Delegation" (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/plan/constdel.asp).
6. IIS 6.0 supports an improved http.sys engine that provides better HTTP-request parsing and other cool stuff. An important part of the IIS 6.0 architecture is the http.sys kernel-mode listener. (See "IIS Core Components" at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/proddocs/standard/arc_core.asp for an overview.) The http.sys device driver receives all URL requests from users and parses them. Microsoft has learned a lot about URL parsing since the company released IIS 5.0; consequently, the http.sys parsing engine is much more rigorous about enforcing the rules that define what constitutes a properly formed URL. The engine processes far fewer malformed requests, which results in significantly improved security. When http.sys rejects a request because it violates the rules, http.sys sends a response as required and terminates the connection.
Table 1, page 14, lists the registry entries that affect http.sys's behavior in regard to URL parsing and accepting content from the client. If you don't see these entries under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters registry subkey, create them there. See the Microsoft article "INF: Http.sys Registry Settings for IIS" (http://support.microsoft.com/?kbid=820129) for the complete set of registry entries that Microsoft has released for http.sys.
Moving to the kernel the tasks of URL parsing, acceptance, and routing to the correct application raises the problem of how to log requests that http.sys rejects or can't hand off to the correct application. To solve this problem, IIS 6.0 adds a log file named httperr.log that you can use for troubleshooting and security-related purposes. This log file records entries for specific events and for errors resulting from connection timeouts. For information about this log, see the Microsoft article "INFO: Error Logging in HTTP API" (http://support.microsoft.com/?kbid=820729).
In addition to these improvements, the http.sys parser includes the functions that Internet Server API (ISAPI) filters such as compression.dll and sspifilt.dll provide in earlier versions of IIS. (Sspifilt.dll provides Secure Sockets Layer—SSL—capability.)
5. Worker processes don't run under the System account. In IIS 5.0 and IIS 4.0, in-process applications have the System account as their process identity because they run in-process with Inetinfo (the main IIS process), which is launched under that account. This situation presents significant security risks because an intruder can use buffer-overflow attacks or malicious applications that invoke the RevertToSelf function to obtain the elevated privileges of the System account.
IIS 6.0 can run in two modes: IIS 6.0 mode (which Microsoft calls worker process isolation mode) and IIS 5.0 emulation mode (which Microsoft calls IIS 5.0 isolation mode). When running in IIS 6.0 mode, applications don't run under the System account. Instead, they have the process identity of a new built-in account called Network Services. This account is a well-known SID on all Windows 2003 servers and can use resources on other systems, but it doesn't have administrative rights on the servers. Consequently, the IIS 6.0 default configuration has no known attack surfaces that offer up the System context.
4. The default Web site offers no openings for intruders. The default Web site still exists in IIS 6.0, but the IISAdmin, IISHelp, Scripts, MSADC, and Printers virtual directories are gone. As a result, locations such as http://servername/scripts aren't readily available in the default Web site.
Not only has the Web site structure been significantly streamlined in IIS 6.0—it contains only static content. In IIS 5.0, if you access the default Web site locally, you get the IIS Help files in an Active Server Pages (ASP) application. In IIS 6.0, the Help files are typical files (not a Web application) and the only files present in the default Web site—iisstart.htm and pagerror.gif—show an Under Construction page if you invoke them.
3. IIS 6.0 streamlines the Inetpub directory structure and improves the default permissions to folders. The complement to a streamlined and hardened default Web site configuration is a streamlined and hardened directory structure in IIS Manager. By default, IIS 6.0's Inetpub folder contains only two subfolders: wwwroot and Adminscripts.
Although the Adminscripts folder (which contains synciwam.vbs and adsutil.vbs) is present, IIS Manager has no associated virtual directory, so users don't have direct access to the folder. In addition, the NTFS permissions are limited to Full Control for System and Administrators.
The default permissions for the Inetpub folder are
- Administrators—Full Control
- System—Full Control
- IIS_WPG (which includes the new Network Services account)—List Folder Content, Read & Execute, Read
- Users—List Folder Content, Read & Execute, Read
- Internet Guest Account—Deny Write
These permissions are a fair representation of the minimum permissions for many installations. Clearly, the Execute permission is the biggest question mark here, but the Web Service Extensions default settings (see number 2 below) significantly mitigate the effect of this improper assignment of the Execute permission.
2. Web Service Extensions prevent all applications from running by default. If you choose to install IIS under Application Server from the Add/Remove Windows Components section of the Control Panel Add/Remove Programs applet and select no other Application Server components, IIS 6.0 will deliver only static content. The Web Service Extensions node is preconfigured to prevent any executables from running. You must specify the full path to any program that you want to run. For example, if you want to run ASP, you must specify that C:\winnt\system32\inetsrv\asp.dll can run. The same is true for WWW Distributed Authoring and Versioning (WebDAV), ASP.NET, Perl, or any other script engine or directly invoked executable. This restriction is very strong stuff from a security perspective. Even if you gave the Everyone group Full Control permission on the entire Web server file structure, an intruder wouldn't be able to launch an executable from the URL unless the Web Service Extensions list allows the full path to that specific binary.
Prohibiting executables would have prevented all the attacks against IIS 5.0 that were directed at the default script mappings and WebDAV. Although these script mappings are installed in IIS 6.0, they aren't accessible without your specific approval. Of course, along with this great new Web Service Extensions setting comes what I'm already seeing as the most frequently asked question about IIS 6.0: "Why don't my applications run?"
1. IIS 6.0 isn't installed by default. With the exception of Windows 2003, Web Edition, Windows 2003 products don't install IIS 6.0 by default. Microsoft's inclination when introducing Win2K was to install the server fully enabled. Although the developers had good intentions, installing on every server a doorway that allows anonymous access has proven catastrophic. Microsoft's image took a beating, but I think that IIS 6.0 is proof that the company has undergone big changes internally, resulting finally in tangible benefits for us all.
Perhaps the most important IIS 6.0 security improvement isn't on the list. I can name features and capabilities that Microsoft has definitely improved from a security perspective, but less visible are the internal practices that the company has put in place over the last couple of years to make its code more secure. Microsoft developers now run code through complex automated and manual testing processes, penetration tests, and outside audits. Of course, all this testing doesn't ensure that another CodeRed attack won't occur. The point is that Microsoft is significantly investing in the security of its products, which should result in better security. IIS 6.0 is still in the early stages of deployment, but so far, it's proving to be the most solid and secure platform Microsoft has produced to date.