By Keren Pollack, on March 6th, 2019

Security versus functionality is always the concern when approaching server hardening. Hardening your IIS server is one of the most crucial missions when trying to achieve a secured infrastructure.

There are numerous attack vectors against IIS server; from database loopholes, vulnerabilities in source code, social engineering etc. In most cases, attackers target the authentication, authorization, and auditing mechanism of the web system. After gaining access to the system and subsequently gaining access to restricted resources in devious ways, attackers usually eras their traces, performing a ‘passive’ attack. Passive hackers only observe existing activity. Hence, detecting, preventing, and combating them can be difficult.

Securing your IIS servers’ configurations is essential to prevent attack. Problems arise when hardening actions lead to server outages…and they often do. The following list contains a number of configuration benchmarks set by the CIS that need to get special attention when implemented on IIS servers. In this list you’ll find the desired value of the policy, according to the CIS benchmarks recommendations, a short explanation of what it is and how it can be leveraged for cyberattacks, and special considerations on IIS server production (bolded at the end of each benchmark).  

https://calcomsoftware.com/securing-configurations-cis-benchmarks/

D

1. Ensure ‘Impersonate a client after authentication’ is set to ‘Administrators, LOCAL SERVICE, NETWORK SERVICE, SERVICE’:

Description: This policy allows programs that run on behalf of a user to impersonate that user, so they can perform actions on behalf of that user.

Rationale: If the user right won’t be required for this impersonation, the unauthorized user (attacker) might be able to convince a client to connect to a service that the attacker has created to impersonate that client. If the client ends up being fooled, the attacker could elevate his user’s permissions to administrative or system levels.

IIS server special adjustment: In order to prevent a negative effect on the IIS server’s production, you’ll need to also assign the user rights to IIS_IUSRS.

2. Ensure ‘Replace a process level token’ is set to ‘LOCAL SERVICE, NETWORK SERVICE’:

Note! changing ‘Replace a process level token’ is not recommended (although established as a benchmark under CIS recommendations).

Description:  This policy allows a process or a service to start another process or service with an escalated security access token. The first process or service can use the second one’s security privileges to elevate its own security privileges.

Rationale:  An attacker that uses this ability is able to start processes like other users with elevated privileges. This way, attackers can hide their unauthorized actions on the system.

IIS server special adjustments: In order to prevent a negative effect on the IIS server’s production, you’ll need to allow the IIS application pool(s) to be granted this user rights assignment.

3. Ensure ‘Web Management Service (WMSvc)’ is set to ‘Disabled’ or ‘Not Installed’:

Description: The Web Management Service enables remote and delegated management capabilities of the web server, the site, as well as apps on the machine by the administrators.

Rationale: Remote web administration of IIS from a workstation can increase security risk. Enabling this remote control will greatly increase the attack surface.

Note that remote web-based management of IIS will not be available.


Figuring out what might break when hardening your IIS server is exactly what makes hardening so difficult. Information is spread and often doesn’t comply with your exact system’s structure.

4. Ensure ‘World Wide Web Publishing Service (W3SVC)’ is set to ‘Disabled’ or ‘Not Installed’:

Description: Provides web connectivity and administration through the IIS manager.

Rationale: Hosting a website from a workstation will increase attack surface and as a result, will increase the security risk. This security concern applies to any web server application installed on the workstation, not just the IIS alone.

IIS web service will not function due to this configuration. An organization may choose to selectively grant exception to web developers to allow IIS (or another web server) in their workstation. If it does, those workstations should be tracked to ensure that security controls and mitigations are kept up to date.

5. Ensure ‘Access this computer from network’ is set to ‘Administrators, Remote Desktop Users’

Description: This policy allows other users on the network to connect to the computer. This policy is required by various network protocols such as SMB, NetBIOS, CIFS and COM+.

Rationale: Users that can connect from their computer to the network can access resources on target computers for which they have permission.

IIS server special adjustment: When ASP.NET or IIS are installed, you might need to assign this user right to additional accounts that are required by those components.

6. Ensure ‘Adjust memory quotas for a process’ is set to ‘Administrators, LOCAL SERVICE, NETWORK SERVICE’:

Description: This policy allows a user to adjust the maximum amount of memory that is available to a process. This ability is useful for system tuning, but can also be abused.

Rationale: Mishandling of this ability will cause a reduction of the memory available for any process, which could lead to the slowing down or failure of critical applications. In the wrong hands, this privilege could be used to start a DoS attack.  

IIS server special adjustment: When ASP.NET or IIS are installed, you might need to assign this user right to additional accounts that are required by those components. If the user right is necessary for a specific user account, it can be assigned to a local computer account instead of a domain account.

7. Ensure ‘Log on as a batch job’ is set to ‘Administrators’:

Description: This policy allows accounts to log in using the task scheduler service.

Rationale: Task scheduler use should be restricted to high security environments to prevent misuse of the system resources, or to prevent attackers from using the right to launch malicious code after gaining user level access to a computer.

IIS server special adjustment: When ASP.NET or IIS are installed, you might need to assign this user right to additional accounts. For example, IIS requires assignment of this user right to the IIS_WPG group and the IUSR_, ASPNET and IWANM_ accounts. If this user right is not assigned to this group and those accounts, IIS will be unable to run some COM objects that are necessary for proper functionality.

8. Ensure ‘Log on as a service’ is set to ‘No One’:

Description: This policy allows accounts to launch network services or to register a process as a service running on the system. This user right should be restricted on any computer in a high security environment security wise, though production might require it to be enabled. As many applications may require this privilege, it should be carefully evaluated and tested before configuring it in production environment.

Rationale: Log on as service is a very powerful user right. It allows an account to launch network services or services that run on a computer even when no one is logged on to the console. When only users with administrative privileges can install and configure services, the risk is reduced. If an attacker attains that level of access, he can configure the service to run with the Local System account.

IIS server special adjustment: If ASP.NET or IIS are installed, you may need to assign the ‘Log on as service’ user right to additional accounts that need this user right. IIS requires that this user right be granted to the ASPNET user account.

Figuring out what might break when hardening your servers is exactly what makes hardening so difficult. Information is spread and often doesn’t comply with your exact system’s structure. Therefore, costly and very demanding lab tests are required before enforcing configuration changes on production.

But what if there is a tool that needs to be constantly updated with best practice recommendations, and synchronized with your ever-changing IT infrastructure? CHS by CalCom does exactly that. It saves you from the need to burrow in best practice benchmarks and to restart lab testing all over again for every change in your IT infrastructure. CalCom’s automated hardening tool ensures you are always in control and your servers remain hardened no matter what.

References:

https://www.cisecurity.org/benchmark/microsoft_iis/

https://techcommunity.microsoft.com/t5/ITOps-Talk-Blog/Windows-Server-101-Hardening-IIS-via-Security-Control/ba-p/329979

https://hostadvice.com/how-to/how-to-harden-windows-iis/

https://resources.infosecinstitute.com/hardening-iis-security/#gref