This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Hardening IIS
- 1 Draft - Work In Progress
- 1.1 Basic configuration
- 1.2 Request filtering
- 1.2.1 Configure maxAllowedContentLength
- 1.2.2 Configure maxURL request filter
- 1.2.3 Configure MaxQueryString request filter
- 1.2.4 Reject non-ASCII characters in URLs
- 1.2.5 Reject double-encoded requests
- 1.2.6 Disable HTTP trace requests
- 1.2.7 Disallow unlisted file extensions
- 1.2.8 Enable Dynamic IP Address Restrictions
- 1.3 Transport Encryption
- 1.4 HSTS support
- 1.5 CORS support
- 1.6 Authors
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
Application bools are designed to create a collection of sites that can be restarted together, and have a common max memory limit, and some other features. With today's applications, it is best if there is a unique application pool for each site. Perhaps if there is a separate project for services and the front end of an application, then they could go together in one pool but for the majority of applications, one pool per app.=
There are two ways to configure application pools for IIS.
1)In IIS Manager, expand Sites in the Connections pane. Then click Advanced Settings, then the ellipsis button next to Application Pool. Select a unique pool there.
2) Using the command prompt, run appcmd to set up new command pools.
appcmd.exe set config -section:system.applicationHost/applicationPools /+"[name='NewCommandPool',autoStart='True',managedPipelineMode='Integrated']" /commit:apphost
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
HSTS support
IIS recently (Windows Server 1709) added turnkey support for 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 ([email protected])