Security Best Practices for IIS 8
Applies To: Windows Server 2012 R2, Windows Server 2012
This document contains a list of recommendations for improving the security of your IIS 8 web server. While following these recommendations does not guarantee freedom from security issues, these recommendations can significantly reduce your risk.
The recommendations are grouped I the following categories:
Installation and Configuration
Do not run IIS on a domain controller or a backup domain controller.
First, there are no local accounts on a domain controller. Local accounts are important to the security of many IIS server installations. Placing an IIS web server and domain controller on the same computer seriously limits your security account options. Second, any new exploit that compromises your web server could also compromise your entire network when the web server and the domain controller are on the same computer.
Install only the IIS modules you need.
IIS 8 is composed of more than 40 modules, which allow you to add modules you need and remove any modules you don’t need. If you install only the modules you need, you reduce the surface area that is exposed to potential attacks.
Periodically remove unused or unwanted modules and handlers.
Look for modules and handlers that you no longer use and remove them from your IIS installation. Strive to keep your IIS surface area as small as possible.
For high volume installations of IIS, run other resource-intensive products like SQL Server or Exchange on separate computers.
Keep you antivirus software up to date.
Install and run the latest version of antivirus software on the server.
Move the Inetpub folder from your system drive to a different drive.
By default IIS 8 sets up the Inetpub folder on your system drive (usually the C drive). If you move the folder to a different partition, you can save space on your system drive and improve security. For information about how to the Inetpub folder, see the following blog post: Moving the INETPUB directory to a different drive.
Web Application Isolation
Isolate web applications.
Separate different applications into different sites with different application pools.
Implement the principle of least privilege.
Run your worker process as a low privileged identity (virtual application pool identity) that is unique per site.
Isolate ASP.NET temp folders.
Set up a separate ASP.NET temp folder per site and only give access to appropriate process identity.
Isolate content.
Make sure to set an ACL (access control list) on each site root to allow only access to the appropriate process identity.
Authentication
If you use Windows authentication, turn on extended protection.
Extended protection protects against credential relaying and phishing attacks when using Windows authentication. For more information about extended protection and how to turn it on in IIS, see Configure Extended Protection in IIS 7.5.
Be aware that configuring Anonymous authentication along with another authentication type for the same website can cause authentication problems.
If you configure Anonymous authentication and another authentication type, the result is determined by the order in which the modules run. For example, if Anonymous authentication and Windows authentication are both configured and Anonymous authentication runs first, Windows authentication never runs.
Disable anonymous access to server directories and resources.
When you want to grant a user the access to server directories and resources, use an authentication method that is not anonymous.
Do not allow anonymous writes to the server.
Authenticate the user with a method that is not anonymous before allowing the user to upload anything to you website or FTP site.
Request Filtering
Ensure that request filtering rules are enabled.
Request filters restrict the types of HTTP requests that IIS 8 processes. By blocking specific HTTP requests, request filters help prevent potentially harmful requests from reaching the server. The request filter module scans incoming requests and rejects requests that are unwanted based upon the rules that you set up. Both websites and FTP sites should have the protection that request filter rules provide. For more information about request filtering, see Configure Request Filtering in IIS.
Ensure that request limits are set to reasonable values.
Think carefully about the values you assign to configuration parameters. For example, make sure that an upper limit value is higher than a lower limit value. Otherwise, the filter may never trigger.
Application Pool Identities
Don’t use the built-in service identities (such as Network Service, Local Service, or Local System).
For maximum security, application pools should run under the application pool identity that is generated when the application pool is created. The accounts that are built in to IIS are ApplicationPoolIdentity, NetworkService, LocalService, and LocalSystem. The default (recommended) and most secure is ApplicationPoolIdentity.
Using a custom identity account is acceptable, but be sure to use a different account for each application pool.
More Security Practices
Make periodic backups of the IIS server.
Do a complete system-state backup every day or two. Also do it before major software upgrades or configuration changes.
Limit permissions granted to non-administrators.
Look for folders that non-administrators have write permissions and script execution permissions to, and remove the permissions.
Turn on SSL and maintain SSL certificates.
Renew the certificate or choose a new certificate for the site. An expired certificate becomes invalid and can prevent users from accessing your site.
Use SSL when you use Basic authentication.
Use Basic authentication with an SSL binding, and make sure that the site or application is set to require SSL. Alternatively, use a different method of authentication. If you use Basic authentication without SSL, credentials are sent in plaintext that might be intercepted by malicious code. If you want to continue using Basic authentication, you need to check the site bindings to make sure that an HTTPS binding is available for the site, and then configure the site to require SSL.
When you set feature delegation rules, don’t make rules that are more permissive than the defaults.
For a classic ASP application, turn off debug mode.