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
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:
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.
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.
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.
What is the right way to disable Firewall? You can either disable it from the Windows Firewall Control Panel (firewall.cpl),
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
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.
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.
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
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.
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.
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 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.
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.
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
Great guidance! The two programs you recommend do not list Windows 2012 R2. Can these be used confidently with R2?
SCM provides a link internally to "update baselines", which gets you 2012 R2 support.