Difference between revisions of "Hardening IIS"

From OWASP
Jump to: navigation, search
(Wildcard domains)
Line 22: Line 22:
  
 
=== Avoid wildcard host headers ===
 
=== Avoid wildcard host headers ===
 +
 +
IIS 10.0 has added wildcard host headers.  This means that if there is a website hosted for a domain, the server will handle requests for any subdomain, allowing the developer to make decisions based on the request as how to respond.
 +
 +
In general, this is a bad idea and shouldn't be used.  There are very specific reasons to use them, but it is almost guaranteed that your situation isn't one of them.
 +
 +
Certainly, do not use wildcard domains, like http://* for example.  But in general avoid using them at all.  Instead use site bindings to solve the same problem.
  
 
=== Ensure applicationPoolIdentity is configured for all application pools ===
 
=== Ensure applicationPoolIdentity is configured for all application pools ===

Revision as of 17:45, 16 August 2018

Draft - Work In Progress

Basic configuration

Common changes that should be part of all IIS installations.

Disable directoryBrowsing

Directory browsing gives the user the ability to just navigate to http://server/directory/ and get a list of all files in the directory. This was useful when web servers were primarily file servers, but is clearly a security problem now.

To disable directory browsing in IIS 10.0 (and several earlier versions, either:

1) Alter the web.config to set the directoryBrowse feature to false

  <configuration>
     <system.webServer>
        <directoryBrowse enabled="false" />
     </system.webServer>
  </configuration>

2) or Navigate to IIS in the Server Manager, and uncheck Directory Browsing under Common HTTP Features.

Avoid wildcard host headers

IIS 10.0 has added wildcard host headers. This means that if there is a website hosted for a domain, the server will handle requests for any subdomain, allowing the developer to make decisions based on the request as how to respond.

In general, this is a bad idea and shouldn't be used. There are very specific reasons to use them, but it is almost guaranteed that your situation isn't one of them.

Certainly, do not use wildcard domains, like http://* for example. But in general avoid using them at all. Instead use site bindings to solve the same problem.

Ensure applicationPoolIdentity is configured for all application pools

Use an unique applicationPool per site

Disable IIS detailed error page from displaying remotely

Request filtering

Configure maxAllowedContentLength

Configure maxURL request filter

Configure MaxQueryString request filter

Reject non-ASCII characters in URLs

Reject double-encoded requests

Disable HTTP trace requests

Disallow unlisted file extensions

Enable Dynamic IP Address Restrictions

Transport Encryption

SSL/TLS settings are controlled at the SChannel level. They are set machine wide and IIS respects these values.

A list of recommendations for IIS

Disable SSL v2/v3

Disable TLS 1.0

Disable TLS 1.1

Ensure TLS 1.2 is enabled

Disable weak cipher suites (NULL cipher suites, DES cipher suites, RC4 cipher suites, Triple DES, etc)

Ensure TLS cipher suites are correctly ordered

https://cloudblogs.microsoft.com/microsoftsecure/2017/09/07/new-iis-functionality-to-help-identify-weak-tls-usage/

HSTS support

IIS recently (Windows Server 1709) added turnkey support for HSTS

https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts

CORS support

If you choose not to handle CORS in your application, we ship an IIS an IIS module to help configure CORS

https://blogs.iis.net/iisteam/getting-started-with-the-iis-cors-module

Authors

Sourabh Shirhatti (Microsoft)

Bill Sempf (bill.sempf@owasp.org)