IIS hardening: 6 configurations changes to harden IIS 10 web server

IIS server, Microsoft’s Windows web server is one of the most used web server platforms on the internet. IIS 10 hardening according to the IIS CIS benchmarks is essential for preventing cyber-attacks and achieving CIS compliance. Common breaches happen by using IIS unsecured server protocols and configurations, such as SMB and TLS/SSL. The IIS default configurations is not recommended to use and should be changed to meet the IIS CIS benchmarks requirements.

Microsoft IIS integrates into the server's security model and operating systems services such as file system and directory. Since Microsoft IIS uses the server's user database and the same Access Control Lists as all other Windows services, it is important to make sure it is properly configured. Otherwise, it can be leveraged to be used as the gate to the server's OS and your network.

The Center for Internet Security (CIS) Benchmarks are considered the industry standard when it comes to hardening guidelines. The CIS IIS 10 Benchmark includes all of the configuration settings recommended to achieve a secured hardened and compliant IIS server. IIS CIS benchmarks for Microsoft IIS 10 v1.2.0 was updated on November 2022 and is a 178 page file. Configuration settings are divided into 7 groups:

1. Basic Configurations
2. Configure Authentication and Authorization
3. ASP.NET Configuration Recommendations
4. Request Filtering and Other Restriction Modules
5. IIS Logging Recommendations
6. FTP Requests
7. Transport Encryption

IIS 10 has some out-of-the-box configurations that may be used as attack vectors and require Microsoft IIS hardening.

Ensuring your IIS web server acts as a secure guardian for your data requires vigilance beyond just locking the front door. It’s time to delve into the fortress itself, configuring its internal defenses through strategic IIS security settings. This list contains the most common Microsoft IIS hardening actions required to successfully pass an audit and secure your IIS server, and how to perform them:

1. Securing cookies
2. preventing non-HTTPS connection
3. Removing IIS's branded response headers
4. Using a referrer policy
5. Using HSTS
6. Fixing IIS cryptography settings
7. Doing it all without breaking anything
8. IIS CIS Benchmarks 10 v1.2.0 Change History

1. Secure your cookies:

Cookies are a common tool, especially for authentication. In cases that the application running on the site doesn't need to access them with client-side JavaScript, you should secure them by setting them as httpOnly.

If your application does need to have access to the cookie, you should set a secure flag. Setting a secure flag will mean that cookies can only be accessed using SSL.

How?

Add to your site's system.web element of the web.config file the following:

<httpCookies domain="String" 
httpOnlyCookies="true" 
requireSSL="true" />

Learn how you this action impacts your server's functionality.

2. Prevent non-HTTPS connections:

Every site should be using SSL. Most sites also use port 80 for users who don't type https in the URL. Those users need to be directed to the SSL version of the site, and you must make sure they can't access any non-SSL resource on your site.

How?

Use the IIS URL Rewrite module. In the URL Rewrite, add the relevant rule. In the 'Conditions' section insert under Input: {HTTPS}, under Type: Matches the Pattern, and under 'Pattern': off.

In the 'Action' section insert under 'Action Type': Redirect, under 'Redirect URL': https://{HTTP_HOST}/{R:1} . Mark the 'Append query string' and choose 'Permanent (301)' under 'Redirected type'.

3. Remove IIS's branded response headers:

One of the most valuable steps of network reconnaissance is discovering the software and version you are using. Different versions suffer from specific vulnerabilities. Once the attacker has these details, he can search for specific attacks to compromise the system, or use relevant information to perform social engineering-based attacks. Your branded response headers can be easily located using developers' tools and will be held under the 'Server' and 'X-Powered-By' headlines. You must remove them to avoid this information being discovered.

How?

In order to get rid of the 'X-Powered-By' header add the following lines in each site's web.config file:

<httpProtocol>
  <costumHeaders>
    <remove name= "X-Powered-By"/>
  </costumHeaders>
</httpProtocol>

In order to get rid of the 'Server' header, you'll need to use PowerShell and add the following:

Set-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST' -filter 
"system.webServer/security/requestFiltering" -name "removeServerHeader" -value "True"
(in one line)

How to Automate IIS Hardening with PowerShell

4. Use a referrer policy:

When a web browser follows a link from one site to another, it sends a 'referrer' header that the next website can read. This can be leveraged by attackers and use to hijack your website. If the URL of one of your pages contains sensitive information, it shouldn't be sent to an external site. A referrer-policy is the way to prevent it.

How?

Using 'origin-when-cross-origin' value ensures that whenever a referrer information is sent outside your site, it'll only contain the domain name and not the specific page URL. In order to do it add in the site web.config file the following:

<httpProtocol>
  <customHeaders>
    <remove name= "X-Powered-By"/>
    <add name="Referrer-Policy" value="origin-when-cross-origin"/>
  </customHeaders>
</httpProtocol>

Learn how you can know what will be the impact of this action on your server's functionality.

5. Use HSTS:

HSTS stands for Http Strict Transport Security. Enforcing SSL using Rewrite rules is not enough. Attackers can use packet sniffers to redirect traffic that relies on 301 redirects alone to enforce SSL. When your web server insist that web browsers connect only via SSL, attempts to intercept traffic between users and your site will fail.

How?

Add the system.webServer section in your web.config file the following:

<httpProtocol>
  <customHeaders>
    <remove name="X-Powered-By"/>
    <add name="Referrer-Policy" value="origin-when-cross-origin"/>
    <add name="Strict-Transport-Security" value="max-age-31536000"/>
  </customHeaders>
</httpProtocol>

6. Fix IIS cryptography settings:

Using veteran versions of IIS cryptography, such as TLS 1.0 and different cipher suits, holds huge risks to your web site. Some sites require stricter cryptography than others, but default IIS cryptography in all cases are vulnerable. Take into consideration that changing these values may affect the functionality of your site.

How?

One useful free tool to do this is 'IISCrypto'. Make sure that its best practices really suit your needs.

7. How can you make sure nothing will break when hardening?

While hardening your IIS server is important, overly restrictive settings, particularly at the application level, can have disastrous consequences. Securing configurations can unintentionally break essential services and functions within your hosted applications. In order to prevent outages, you have two options:

1. Manually check the impact before implementing- establish a test environment where you can accurately measure the impact of every change on the rest of the IIS server functionalities. The test environment should be an exact copy of your production IIS, and each change must be tested before implemented.
2. Use CalCom Security Solution for IIS- this tool will do the entire testing process for you directly in your production environment. CalCom Security Solution for IIS (CSS for IIS) will produce an impact report for your policy, so you can decide your decide course of action. Once you'll make a decision, CalCom IIS Hardening Solution will implement the configuration change on your entire production from a centralized point of control. Once you hardened your IIS, CSS for IIS will monitor your IIS server and remediate any configuration drifts.

8. IIS CIS Benchmarks 10 v1.2.0 Change History