Why you should avoid manual ‘server hardening’
Sachin Kumar , a Premier Field Engineer from the India team, discusses a very important topic in this post. Many support incidents are actually triggered by non-standard (and sometimes unsupported) settings which are picked from outdated hardening guides. Read on for more details and for information on what NOT to tweak!
I was recently helping a customer with the deployment of a Windows 2012 failover cluster. We were able to configure a 3 node cluster in a matter of few hours but to my surprise, the final ‘litmus test’ of bringing the Network name up failed. Due to this, we could not bring the SQL Server Resource online. From both the cluster and the event log it was quite evident that we were hitting an Authentication issue:
Log Name: System
Source: Microsoft-Windows-FailoverClustering
Event ID: 1207
Task Category: Network Name Resource
Level: Error
Keywords:
User: SYSTEM
Computer: ********
Description:
Cluster network name resource 'Cluster Name' cannot be brought online. The computer object associated with the resource could not be updated in domain ********** for the following reason:
Unable to get Computer Object using GUID.
The text for the associated error code is: Logon failure: unknown user name or bad password
Root Cause
On investigation, it turned out to an issue with the security privilege ‘Access this computer over the network’. By default on Windows Server 2012 the following groups have rights to access this computer from network GPO:
- Administrators
- Backup Operators
- Users
- Everyone
On the problem server(s), the Everyone group was missing; and adding it back resolved the issue. Why was this needed? The Cluster Name Object (CNO), service accounts of applications that use cluster and the computer object of each node would need to have permission to access the computer from the network.
Windows testing does not include test cases where the default setting has been changed. Therefore we cannot predict of how cluster would behave after removing the default groups from the above GPO.
The ‘aha!’ moment
Relief implemented, over a cup of coffee, I asked the customer to share the reason behind this change. I was later informed of a “Hardening Document” implemented religiously before putting the servers into production. In our experiences, such documents tend to be dangerous because they were written in the late 1990’s and in many cases they have not been reviewed or updated for the modern OS versions.
Moment of truth
I personally do not recommend manual Server hardening, as it can cause the server to misbehave, result into breakdown of various operating system related components and failure of critical applications. I advice my customers to use Security Compliance Manager or Security Configuration Wizard for ‘hardening’ Windows Server 2012. Any other method to harden the server might result in unforeseen results.
Any single change in the environment (as a result of these manual hardening steps) might cause a failure. One cannot predict these failures, and therefore rigorous testing has to be carried out by someone who has is implementing manual hardening. Please ensure that the test environment are exactly similar to the production environment. Also, what is the duration of testing and testing coverage in order to verify that everything is still functional? Just because it has been tested for n number of days it does not mean that a problem will not occur on n+1 day.
To summarize:
- Use of Security compliance manager or Security Configuration Wizard is the only supported way for Windows server hardening.
- Have a layered security approach that disallows direct access to the servers.
- Monitor your servers using a centralized auditing system.
- Manual Hardening is not all recommended as detailed previously.
- Please ensure that Windows server 2003 hardening settings are not applied on newer operating system like Windows server 2008 R2, Windows server 2012
- Verify the source of the hardening document being followed in your organization
Popular ‘gotchas’
| Setting | Description | More information |
| “Do not allow storage of credentials or .NET Passports for network authentication ” | Task scheduler is widely in a lot of organizations and you should be aware that ENABLING the below GPO can cause scheduled tasks to fail in certain situations: | The new version of Task Scheduler uses Windows Credential Manager to store the credentials of the account that is specified to perform a task. If the Network access: Do not allow storage of passwords and credentials for network authentication policy is enabled and applied, Since Credential Manager cannot store the credentials you will end with Task Scheduler related issues. |
| Windows Firewall Service being kept in the disabled state | Keeping the Firewall service as disabled causes the WMI calls to fail resulting in the failure many application. Stopping the service associated with Windows Firewall with Advanced Security is not supported by Microsoft. | Please refer to this blog post and this TechNet article for more information. Also, a natural question then is
What is the right way to disable Firewall? You can either disable it from the Windows Firewall Control Panel (firewall.cpl), OR Run the below commands and disable firewall for all profiles Netsh.exe AdvFirewall Set CurrentProfile State Off Netsh firewall set opmode mode = disable profile = ALL |
Other security features
Further I would like share some of the in-the-box security features shipped with Windows Server 2008 and above which makes Windows operating System secure.
Address Space Layout Randomization
In older versions of Windows, core processes tended to be loaded into predictable memory locations upon system startup. Some exploits work by targeting memory locations known to be associated with particular processes. ASLR randomizes the memory locations used by system files and other programs, making it much harder for an attacker to correctly guess the location of a given process. The combination of ASLR and DEP creates a fairly formidable barrier for attackers to overcome in order to achieve reliable code execution when exploiting vulnerabilities. ASLR was introduced in Windows 2008 and has been included in all subsequent releases.
Protected processes
The Windows 2008 operating system introduces a new type of process, called a protected process. The protected process enhances support for digital rights management functionality in Windows Server 2008 and Windows Vista. These protected processes exist alongside typical processes.
The primary difference between a typical Windows process and a protected process is the level of access that other processes in the system can obtain to protected processes.
In versions of Windows operating systems earlier than Windows Vista, the process model allows a parent process to acquire a handle to and manipulate the state of any child process it creates. Similarly, processes that are created by users with sufficient privileges (that is, a system administrator) can access and manipulate the state of all processes on the system. This behavior remains unchanged for typical Windows processes. However, the level of access to protected processes and to threads within those processes is significantly more constrained in Windows Vista and Windows Server 2008
Mandatory Integrity Control
Windows defines four integrity levels: low, medium, high, and system. Standard users receive medium, elevated users receive high. Processes you start and objects you create receive your integrity level (medium or high) or low if the executable file’s level is low; system services receive system integrity. Objects that lack an integrity label are treated as medium by the operating system—this prevents low integrity code from modifying unlabeled objects. Consider a scenario. Say you receive an attachment in email. When you save it, it’s written with low integrity because it came from the Internet—an untrusted source. When you execute the attachment, its process runs at low integrity because the file object is labeled low; therefore, your data (labeled medium or high) is protected from malicious writes by the attachment.
Read more about Windows Integrity Mechanism at this link.
System Service Hardening
Earlier in Windows 2003, services running with elevated privileges in many cases. Now in windows 2008 with System Service Hardening, unnecessary services are not installed. If installed, they are turned off by default and if on they are isolated from users via privilege reduction.
Privilege reduction
Since Windows 2008 Services are not using the System Account anymore, the Service Control Manager (SCM) can give out a filtered token which contains only the necessary rights. SCM can add the Service SID to the Security Token which enables Admins to apply further restriction. Read more about Windows Service Hardening here.
File and Registry Virtualization
The transparency of file virtualization enables applications to perceive that they are writing and reading from the protected resource, when in fact they are accessing the virtualized version. Read more here.
Secure Boot
Secure Boot is a feature on UEFI-based PCs that helps increase the security of a PC by preventing unauthorized software from running on a PC during the boot sequence. It checks that each piece of software has a valid signature, including the operating system that will be loaded. It’s a good security measure against rootkits. Read more here and here.
Session 0 Isolation
In Windows Server 2003 and earlier versions, all services run in the same session as the first user who logs on to the console. This session is called Session 0. Running services and user applications together in Session 0 poses a security risk because services run at elevated privilege and therefore are targets for malicious agents who are looking for a means to elevate their own privilege level. The Windows Server 2008 and above isolate services in Session 0 and making Session 0 non-interactive. The user logs on to Session 1. Read more here.
‘Moral of the story’
Modern Windows OS versions (2008+) are far more secure out-of-the box than you might imagine. Provided patching is done regularly, the necessity to lock down even further by performing ‘hardening’ is quite limited these days. And in that event, we recommend you use only supported means like the Security Compliance Manager or Security Configuration Wizard.
Original content from Sachin Kumar ; posted by MSPFE editor Arvind Shyamsundar
Comments
- Anonymous
May 30, 2014
Pingback from Interesting things that i see on the internet, 30th May. | 503 5.0.0 polite people say HELO - Anonymous
May 30, 2014
Pingback from Interesting things that i see on the internet, 30th May. | 503 5.0.0 polite people say HELO - Anonymous
May 31, 2014
Pingback from Weekly IT Newsletter – May 26-30, 2014 | Just a Lync Guy - Anonymous
May 31, 2014
Pingback from Weekly IT Newsletter – May 26-30, 2014 | Just a Lync Guy - Anonymous
May 31, 2014
Pingback from NeWay Technologies – Weekly Newsletter #97 – May 29, 2014 | NeWay - Anonymous
May 31, 2014
Pingback from NeWay Technologies – Weekly Newsletter #97 – May 30, 2014 | NeWay - Anonymous
February 02, 2015
Great guidance! The two programs you recommend do not list Windows 2012 R2. Can these be used confidently with R2? - Anonymous
February 03, 2015
SCM provides a link internally to "update baselines", which gets you 2012 R2 support. - Anonymous
April 13, 2015
Very good guide. Thank you. - Anonymous
December 09, 2015
Sachin kumar is a Premier Field Engineer from India and will take us through the steps to create a manual - Anonymous
October 12, 2017
Any recommendations for tools to control hardening given Security Configuration Wizard was removed from Server 2016 and that Security Compliance Manager has been recently discontinued? Hardening docs from e.g. Center for Internet Security run to over 800 pages and was recommended by our PCI-DSS auditor to at least review it and implement the relevant parts to our environment, but it scarcely seems possible resource-wise - I'd much rather use a vendor-approved tool that minimises the admin work required and avoids the kind of gotchas you mention in this article.