Microsoft’s Internet Information Services (IIS), while one of the most popularly deployed web servers, has long been considered to be a weak point on any server on which it is installed, when it comes to security. Web servers, by their very nature, are generally open to the Internet (unless they are used only for intranet access) and this makes them a natural target for hackers and attackers. IIS exploits abound, and Microsoft has had to hustle to keep up with security patches for the web service software.
It’s no surprise, then, that tightening security was one of the company’s primary design goals with the new version of IIS (v6) that comes with Windows Server 2003. Have they accomplished that? In this article, we’ll cover some of the changes to IIS that are intended to make it less vulnerable to attackers, and let you decide.
No IIS Installed by Default
Microsoft decided to begin at the beginning, and make IIS an optional component that is not installed by default when you install the Windows Server 2003 operating system. The only exception is the Web Server Edition of the OS, which by definition is designed to be used only for web services and does not include many of the components (such as the ability to be a domain controller) built into the other three editions.
A common problem with earlier versions was the discovery of a “rogue” IIS server that was running web services without administrators realizing it, presenting attackers with an attractive point of entry to the server and the network. To prevent this from happening, when you install Windows Server 2003 Standard, Enterprise or Datacenter edition, IIS 6.0 will not be installed by default. You can add it either from the Configure your Server wizard that displays the first time you boot up (and is available later from the Administrative Tools menu) or from the Add or Remove Programs applet in Control Panel.
When you do choose to install IIS, it starts out in “highly secure” or “lockdown” mode. This means many of the more sophisticated web service features, such as Active Server Pages (ASP), ASP.NET, Web Distributed Authoring and Versioning (WebDAV) and server-side includes (SSI) are not functional. That’s because all of these features, used for serving dynamic content, present vulnerabilities of their own. In this lockdown mode, FrontPage server extensions don’t work, and only static content can be served. Any attempt to use these features causes a 404 error (file not found).
An administrator must enable dynamic content features in the IIS Manager to be able to use these features. To do so, you can individually enable ASP.NET, ASP pages and other web service extensions by following these steps:
In the left pane of the IIS Manager MMC, expand the node for the web server on which you want to enable dynamic content and click Web Service Extensions.
In the right pane, you will see a list of web service extensions and the status (Prohibited or Allowed) for each.
- You can right click on the extension name and select Allow to enable it individually.
- If you want to allow all extensions for a specific application, you can select the Allow all Web service extensions for a particular application icon in the Tasks section, as shown in Figure A. You can then select the application from a dropdown box (choices are: Active Server Pages, Internet Data Connector, Server-side Includes and WebDAV).
You can also choose to prohibit all web service extensions from the Task list, for greater security, if you have no applications that require ISAPI, CGI, ASP, WebDAV or other extensions.
New Authentication Method
IIS 6.0 includes a new authentication mechanism called Advanced Digest Authentication. When you use this authentication method, user credentials are stored in the Active Directory on the domain controller, as an MD5 message digest. This is a type of hash that relies on HTTP 1.1, so it’s not supported by all browsers. However, it provides for enhanced security over Digest authentication, so if all clients that will be accessing the pages are using IE 5 or later, or another browser that supports HTTP 1.1 and your domain controller is running Windows Server 2003, it can provide better security.
You don’t have to install any software on the clients to use Advanced Digest Authentication; you only have to ensure that they use an HTTP 1.1 compatible web browser. Users need to have valid user accounts in the Active Directory domain.
To enable Advanced Digest Authentication on the IIS server, you need to configure the properties of the Web Sites folder, specific web site, directory (or virtual directory) or file in the IIS Manager. To do so, follow these steps:
1. Right click the object on which you want to use this type of authentication, and click the Security tab (it will be labeled either Directory Security or File Security, depending on the object on which you’re setting the authentication method).
2. Click the Edit button in the Authentication and Access Control section.
3. In the Authentication Methods dialog box, check the Digest authentication for Windows domain servers checkbox in the Authenticated access section, as shown in Figure B.
4. A message window will inform you that Digest authentication works with Active Directory domain accounts and asks if you wish to continue. Click Yes.
5. In the Realm box, you’ll need to configure a realm name. Then click OK.
A realm is basically a security boundary. When a user has been authenticated within a realm and then accesses resources in a different realm, her/she will have to be re-authenticated, even though the user has already been authenticated to the server. This provides for greater security.
To use Advanced Digest Authentication, you’ll also need to set the UseDigestSSP metabase key to a value of 1 (TRUE). This is the value that switches between Digest and Advanced Digest methods. If this key is not set to TRUE, IIS will use Digest Authentication instead of Advanced Digest.
Another new security feature in IIS 6.0 is URL authorization. This feature relies on the Windows Server 2003 Authorization Manager (discussed on my two-part article on this site entitled Authorization Manager and Role-Based Administration in Windows Server 2003). The Authorization Manager tool is a new feature that allows you to use role-based security with IIS, providing authorization to a particular URL based on the user’s role as defined in LDAP queries, Authorization Manager scripts, and custom-created user roles.
You have to enable the ISAPI interceptor before you can use URL authorization, and set several required metabase properties on the application, virtual directory or web site. You also must associate the URL with an Authorization Manager store in which the authorization policy for the URL is contained. The details of performing these tasks will be the subject of a future article.
Using URL authorization makes it simpler for administrators to manage user access to the URLs that make up a web application, instead of having to deal with multiple ACLs and keep track of what permissions every user needs for every resource. URL authorization is in addition to ACL permissions, and provides an extra layer of security. Role-based authorization also gives you extremely granular control, so that you could allow users to access specified web pages only on a certain day of the week or time of day, or you could create roles that are defined through LDAP queries, which can check your database for information such as a user’s age.