Microsoft Internet Information Server (IIS) is widely used in the enterprise, despite a less-than-stellar reputation for security. In fact, for many “IIS security” is a contradiction of terms—though in all fairness, Microsoft's web server solution has improved significantly over the years. IIS 8.5 for server 2012 R2 and IIS 10 for 2016 have been hardened and no longer present the dangerous default configurations of older IIS iterations, but can still be further tightened. By following these 10 steps, you can greatly increase security for your IIS web apps and servers.
1. Analyze dependencies and uninstall unneeded IIS modules after upgrading.
If you plan on upgrading from a previous version of IIS, be forewarned that your previous installation’s state information and metabase will be carried over to the new install. Be sure to disable and/or uninstall any unused IIS components and features to minimize the web server’s attack surface. Even if you haven't upgraded, ensure that only required modules are present.
UpGuard ensures IIS modules are correct across any number of servers by transforming a known good configuration on one of the servers into executable documentation against which the others can be tested regularly.
2. Properly configure web server user/group accounts
IIS features built-in user and group accounts dedicated to the web server. So for example, separate system and application administrator accounts can be created for more granular-level access. System administrators can therefore give application administrators the rights to make application-level configuration changes without the need to grant them administrative access to the server. These accounts should be audited on a ongoing basis to ensure they are configured securely.
UpGuard tracks and visualizes which users are running which services, and tests servers against your standards to surface any user configurations that could be potential security problems. Oops, looks like this one is running as Local System, a highly privileged account:
3. Use IIS 7’s CGI/ISAPI Restrictions
CGI and ISAPI are two common ways to build upon IIS—either for generating dynamic content or for extending IIS’ native capabilities. Unfortunately, CGI files (.exe) and ISAPI extensions (.dll) are also commonly exploited in web attacks and should be restricted if not in use. For example, if you’re using PHP or ColdFusion to create dynamic content with IIS, use of CGI and other ISAPI extensions may not be needed. Like IIS modules, these configurations should be uninstalled unless they are being specifically used.
UpGuard handles IIS modules and configurations the same way, allowing you to quickly diff a set of IIS servers and see which modules are installed correctly. Use policies to keep IIS modules consistent over time by immediately surfacing any changes that violate your expected configurations.
4. Configure HTTP Request Filtering Options
UrlScan was an extension that functioned as a security tool for restricting HTTP requests. UrlScan functionality is now built right into IIS, and should be configured appropriately. Potentially harmful HTTP requests are prevented from reaching the server through rule-based filtering. These options are critical for mitigating threats like SQL injections, among others, and should be used in conjunction with your IIS-based web application.
UpGuard finds out which of your servers have the request filtering module installed and verifies that it's configured properly. No more guesswork about whether IIS servers between production and development are the same.
5. Use Dynamic IP Restrictions
Dynamic IP address restrictions use a requestor’s IP addresses and domain name to determine whether or not to restrict access. This is essentially a whitelist—"allowUnlisted"—that IIS uses to prevent unauthorized access. So in the event of Denial of Service (DoS) and brute force attacks, IIS’ Dynamic IP Restrictions (DIPR) module can temporarily block IP addresses making unusual requests.
Dynamic IPs are just another module within IIS. UpGuard helps you keep track of where it's installed and can proactively notify you if it's changed. If a production server is deployed without this module, web requests become a serious vector for attack, depending on what kind of code you have out there.
6. Incorporate URL Authorization In Your Application
URL authorization grants access to URLs within an IIS application based on user names and roles, as opposed to server or system accounts. This makes it easier to restrict content based on group membership. URL authorization rules can be associated with a server, site, or application.
Group membership is another important aspect of the system state that UpGuard manages. For example, if you wanted to monitor your administrators group, UpGuard could alert you when a new user was added, or an expected user removed.
7. Use Encrypted Forms-Based Authentication
Forms-based authentication allows for the management of client registration and authentication at the application level, as opposed to on the Windows account level. Because this authentication mechanism passes form values as clear text, SSL must be installed to encrypt sensitive data.
IIS treats authentication mechanisms as features, so tracking them with UpGuard is easy. Make sure that only the auth mechanisms you're using are installed, and make sure they're installed everywhere with just a few clicks.
8. Use Application Pool Identities
This feature of IIS enables more granular security by running application pools under unique accounts, bypassing domain or local account creation/management. By using a low-privileged account—namely, ApplicationPoolIdentity—multiple distinct sets of anonymous website content can be isolated without having to create a unique account for each website.
This is a key operation, as an exploited web application will only have the rights the user running the application pool has, so limiting and segregating that can drastically reduce damage.
9. Isolate/Segregate Web Applications
By using a combination of the above IIS features, you can achieve more secure isolation and segregation for your web applications. In general, the following security recommendations should be taken into consideration:
- Each application pool should be assigned to a single website.
- The application pool should be assigned to a dedicated user.
- Anonymous user identities should be set up to use the application pool.
10. Fix Critical IIS Vulnerabilities
Last but not least, critical IIS vulnerabilities should be patched or remediated. Like any Microsoft updates, staying on top of patches and service packs helps ensure that your server is as protected as possible. Most exploits target vulnerabilities that are over a year old and have patches released, so a little regular maintenance goes a long way. Patches should first be deployed in a test environment before production, and each update should be considered and approved if possible before being authorized in the organization.
UpGuard helps ensure that patch levels are the same across your IIS servers. By building an UpGuard policy from a server with a proper patch level, other servers can be compared against it to find any outliers. Remediation can then be tracked as servers become compliant within UpGuard.
In short, the modular nature of IIS allows for more granular control over web server resources and security. However, this can either make your web applications more or less secure—depending on the person or group responsible for security. Deeper, fine-grained security mechanisms require more careful management of said resources; fortunately, these arduous processes can be managed automatically with UpGuard's platform for vulnerability detected and monitoring. Our Windows and IIS security policies can automatically scan your environment for critical vulnerabilities and security gaps.