Microsoft's IIS 7 Web server is a capable piece of software with numerous features for developers and administrators alike. As with any server, IIS is often brought online without careful consideration of security needed for authentication, site details and numerous other aspects of these systems. This can happen anytime a new application is developed or purchased, new Web-based services need to be offered, or during testing of applications or Web-based products. By carefully
Mike Chapple reviews how to secure a website with HTTPS encryption
By default, IIS 7.0 has completely locked down delegation, meaning only the server or domain administrator can make configuration changes to the IIS 7 instance. As most organizations will want to allow various development teams and other users to manage aspects of the system for developing or publishing content, the server should be set up to allow server, site or application-specific delegation by system or domain users. This is easily accomplished by selecting a site or application within the IIS Manager window, then selecting IIS Manager Permissions in the right-hand pane. From here, individual users and groups can be explicitly permitted or denied access. This is shown in Figure 1:
See larger image
Figure 1: Managing Site Delegation
Delegation and site/application access control can be taken to a much more granular level by setting up locking, or lockdown of individual configuration settings within XML-based configuration files. The need to lockdown specific tasks and configuration items will vary from one organization to another, but any configuration lockdown efforts are generally focused on the security principle of "separation of duties" -- limiting what one specific role or group can do within the IIS application. For example, to lockdown major role services such as security administration (which controls the configuration of security settings like basic or digest authentication, digital certificates, etc.), the "%windir%\System32\Inetsrv\config\applicationHost.config" file can be edited as shown in Figure 2:
See larger image
Figure 2: Editing the applicationHost.config file
The "overrideModeDefault" parameter is set to either "Allow" (unlocked) or "Deny" (locked). These are considered global parameters, meaning they cannot be overridden at a lower level in a site or application hierarchy. It's also possible to lock individual elements and attributes (or configuration values and sub-settings) this way.
By default, IIS 7 allows access to all sites and applications. Before deploying IIS 7 into production, it's a good idea to limit the access to only those that need it -- this is particularly useful for sites and applications that have a more limited user base, such as partner or specific customer applications. To limit access, select a site or application tier in the IIS Manager console, and then select IPv4 Address and Domain Restrictions in the "Features" view. You will then have the option to add simple single-IP or IP range "Allow" and "Deny" rules to limit access, which could be used effectively to only allow access to a specific group of customers or partners, as well as internal users connecting via VPN clients. This is shown in Figure 3:
See larger image
Figure 3: IP Address and Domain Restrictions
More granularIIS authorization and access controls can be configured using a feature called URL Authorization. With these "Allow" and "Deny" rules, an administrator can choose to control access by user, group or role, and can even choose specific HTTP methods as rule components ( GET, POST, etc). As an example, this could prevent attempts to use the GET method for form submission, which could expose parameters on the URL line and in log files. To configure these authorization rules, highlight a site or application component in IIS Manager and then select Authorization Rules in the "Features" pane. In the feature pane that comes up, select "Add Allow Rule" or "Add Deny Rule" to open a simple form that can be filled out to generate the rule, as shown in Figure 4:
See larger image
Figure 4: Adding Authorization Rules
In previous versions of IIS, filtering certain HTTP request types required an add-on tool called URLscan. With IIS 7, this functionality has now been built in, and can be configured from the command line. There are many possible options for configuring these request filters, but here are several common examples.
To deny unlisted file name extensions, type the following:
appcmd set config /section:requestfiltering /fileExtensions.allowunlisted:false
To deny a specific sequence of characters in a URL from being parsed, type the following:
appcmd set config /section:requestfiltering /+denyurlsequences.[sequence=' string ']
This would effectively limit certain known malicious strings of characters or encoding types. Many well-known attacks against Web servers and services have involved Unicode and other coding of characters to bypass intrusion detection and other filtering systems.
These are but a few of the security-specific configuration actions that should be considered before putting a Windows IIS 7 system into production. There are many more, ranging from authentication options to shared configuration settings for Web server farms and ISAPI and CGI restrictions. In general, the best approach to installing and securely configuring IIS 7 is to start with only the components you need, and then lock them down to only allow the minimum level of access required for business.
About the Author:
Dave Shackleford is director of risk, compliance and security assessments at Sword and Shield Enterprise Security Inc., and is a certified SANS instructor. He was formerly CSO at Configuresoft Inc. and CTO at the Center for Internet Security, and has worked as a security architect, analyst, and manager for several Fortune 500 companies. In addition to these roles, he has consulted with hundreds of organizations for regulatory compliance, as well as security and network architecture and engineering.
This was first published in April 2010