If you’re working with IIS then you know that preventing configuration drift is as important as it is time consuming. In the best case scenario you’re monitoring configs daily to keep development, testing, and deployment running smoothly. In the worst case—well, all-nighters make good war stories but aren’t much fun.
A proactive approach is much better. UpGuard automates configuration testing at scale, to find out if your IIS servers are hardened and as expected. We'll look at how UpGuard can help with these five major problems as an example of what we do. Here are the top five critical configuration problems we see on IIS servers and how we fix them.
1. IIS should be moved from its default location.
IIS should be moved from its default location, preferably oﬀ the system drive to prevent system collapse due to the application exhausting disk capacity.
With UpGuard, you can track file location and other information easily, and only for the files you care about. For example, we can track the web.config file in the web root to determine if it's on the E: drive, like we expect, or if the default C: drive configuration was left on it. Here we can see an example of it still being on the system disk, causing our policy to fail:
2. Web applications should not be stored on the system drive.
Isolating web content from system ﬁles reduces the probability of file IO vulnerability in the web site/application from aﬀecting the conﬁdentiality and/or integrity of system files.
UpGuard can also monitor your web content files and check that they are in the right location, with the right permissions. This helps prevent resource contention and also improves security for web applications. Here we can see that our Contoso test application is living on C, the system disk:
3. Application pools should run as the application pool identity.
Conﬁguring the anonymous user identity to use the application pool identity will help ensure site isolation. Failure to do this can greatly extend the damage if a web app is compromised and violates the principle of least privilege you should be following in all cases.
UpGuard tracks IIS configurations and how services are authenticating to minimize the risk your web servers face on the internet. Tracking and standardizing IIS configs with UpGuard makes your environment more reliable and your web applications more resilient.
4. TLS 1.2 security should be enabled.
SSL-based services should not offer the possibility to utilize weak encryption protocols or ciphers. Weak encryption protocols SSL 2.0 and PCT 1.0 should be disabled, as well as the Poodle-sensitive SSL 3.0. TLS 1.0 and 1.2 have no discovered flaws, but only 1.2 supports modern encryption ciphers. Therefore, all website should be encrypted using the TLS 1.2 protocol with strong, 2048-bit cipher suites and other SSL best practices.
UpGuard monitors your IIS servers from the inside, as we've seen, and from the outside. An external view of a website in UpGuard will analyze and track encryption details, and policies can be created to ensure all websites follow best practices and are using secure protocols.
5. Directory browsing should be disabled.
Directory browsing allows the contents of a directory to be displayed upon request from a web client. You don't want that. This seems simple, but many production websites accidentally leave this on from a bad default config, or accidentally turn it on without realizing the implications.
UpGuard can tell you which of your IIS servers have directory browsing disabled in seconds, and should any of them be enabled at a later date, you'll know right away, because UpGuard will notify you of the unauthorized change.
Along with the five critical tests listed above, UpGuard can track and compare any IIS or Windows settings. We also include built-in policies from the Center for Internet Security (CIS) to harden servers even further. Try UpGuard now to see how we can help your organization trust its technology.