Implement server hardening solutions
In Skill 1.1 from Exam Ref 70-744 Securing Windows Server 2016, learn about whole-disk and file encryption in Windows Server 2016.
Server hardening refers to the process of improving the security configuration of a server. A Windows server is a soft target for attackers if:
Operating system files are installed from a non-trusted source
System is not current with patches and security updates
Administrator accounts have weak passwords
File systems don’t use NTFS and are unencrypted
Of course, the previous list is incomplete and is meant only to get you thinking on the right track. In this chapter we’ll examine a number of techniques intended to raise the security posture of your Windows Server 2016 infrastructure computers.
Skill 1.1: Configure disk and file encryption
Our first 70-744 order of business is to review disk and file encryption in Windows Server 2016. The idea of whole-disk encryption is pretty simple—we want to scramble all disk contents to the sector level, such that only authorized parties can read the data.
To be effective, BitLocker Drive Encryption must be deployed alongside the IT security principle of least privilege. This means that server operators should be able to access only those resources that they need to do their jobs. After all, a local administrator can easily disable BitLocker and thereby circumvent its protections.
Determine hardware and firmware requirements for Secure Boot and encryption key functionality
In this section we’ll tackle a host (pun intended) of hardware security features that aren’t all specific to Microsoft Windows Server operating systems, but are fully supported. We’ll cover UEFI, BitLocker Drive Encryption with and without the TPM chip, how Network Unlock works, and how we configure BitLocker Drive Encryption through Group Policy.
Unified Extensible Firmware Interface (UEFI) is the successor to the older Basic Input Output System (BIOS) firmware interface we’ve had since the first PCs; any new server hardware you purchase nowadays uses UEFI firmware. Windows Server 2016 fully supports all UEFI features, especially Secure Boot.
The method for starting your server into UEFI setup depends entirely on the original equipment manufacturer (OEM). Consult your documentation or visit the vendor’s website to find out which keystroke to use. Figure 1-1 shows the appropriate UEFI setup screen from a Lenovo notebook computer.
FIGURE 1-1 Configure Secure Boot and startup passwords from within UEFI setup
Secure Boot is a UEFI feature that protects the server’s startup environment. The UEFI firmware stores a database of trusted hardware, drivers, operating systems, and option ROMs. This database is structured by the server’s OEM. In short, your server starts up only if its operating system boot loader files and device drivers are digitally signed and trusted by the Secure Boot database.
Secure boot can be disabled by starting the server into UEFI/BIOS setup. This may be necessary when some server hardware isn’t recognized by the UEFI. You can also enable the UEFI’s compatibility support module (CSM) to configure the server to boot using legacy BIOS mode, although this defeats the purpose of UEFI startup security.
A Trusted Platform Module (TPM) is a microchip that is installed on current-generation servers and desktop-class motherboards. The TPM’s main function is protecting security-related data, particularly encryption and decryption keys.
What’s great about TPM is that its functionality is tied to your server hardware itself. That is, its security “travels” with the host hardware, and is much more difficult to bypass than a software-based control.
Windows Server 2016 supports both the current-generation TPM v1.2 as well as the original TPM 1.0 specification. An often-confused point about TPM is its relationship to Secure Boot. Technically, TPM can provide the same type of boot-time protection that UEFI Secure Boot can. However, the two systems are separate and rely upon separate trust stores.
Enable BitLocker to use Secure Boot and BCD integrity verification
BitLocker Drive Encryption (BDE) is Microsoft’s native disk encryption solution for operating system and data drives. BitLocker, along with the Boot Configuration Database (BCD), was introduced originally in Windows Vista.
Specifically, the BCD is a firmware-independent database that stores Windows startup configuration data. In Windows Server 2016, the BCD is located on the unlettered, 500 MB System Reserved partition on your startup disk.
To prepare BitLocker to use Secure Boot for vplatform and BCD database integrity validation, enable the Allow Secure Boot For Integrity alidation policy found in the Group Policy path: Computer Configuration\Policies\Administrative Templates\Windows Components\BitLocker Drive Encryption\Operating System Drives.
You may get better performance and reliability configuring your Windows Server 2016 servers to use Secure Boot for BCD verification because, at least in my experience, benign changes to the BCD can sometimes trigger BitLocker Recovery, as discussed later in this section.
Deploy BitLocker Drive Encryption
Thus far, you’ve probably noticed the themes of (a) physical security; (b) least privilege; (c) Secure Boot; and (d) the TPM chip as essential elements of any contemporary Windows Server 2016 infrastructure server.
Having accomplished that, let’s turn our attention to how to deploy BitLocker Drive Encryption. The deployment workflow is similar for Windows Server and Windows Client computers; however, the 70-744 exam objectives constrain our discussions only to protecting Windows Server 2016-based servers.
The first step is to install the BitLocker Drive Encryption feature. Fire up an administrative Windows PowerShell prompt and run the following command:
Install-WindowsFeature -Name BitLocker -IncludeAllSubFeature -IncludeManagementTools -Restart
Enable-WindowsOptionalFeature -Online -FeatureName BitLocker, BitLocker-Utilities -All
Configure BitLocker with or without TPM
BitLocker Drive Encryption can be configured to use a number of authentication methods called protectors. Table 1-1 sums up the options and their startup behaviors.
TABLE 1-1 BitLocker protectors and their startup behaviors
Requires a BitLocker password or a startup key on a USB flash drive
TPM + startup PIN
Requires the presence of a TPM chip as well as a personal identification number (PIN)
TPM +startup key
Requires a TPM chip and a USB flash drive-based startup key
TPM + startup PIN + startup key
Requires TPM, PIN, and startup key
As you probably expect, we use Group Policy to specify our server BitLocker Drive Encryption policy. The policy in question is called Require Additional Authentication At Startup, and it’s located in the same GPO path we used earlier: Computer Configuration\Policies\Administrative Templates\Windows Components\BitLocker Drive Encryption\Operating System Drives. You can see this policy in Figure 1-2.
FIGURE 1-2 Establishing BitLocker Drive Encryption policy in Windows Server 2016
Although it’s certainly not recommended, you can configure Windows Server 2016 to use BitLocker without TPM protection by selecting the Allow BitLocker Without A Compatible TPM (Requires A Password Or A Startup Key On A USB Flash Drive) Group Policy setting.
After your new Group Policy settings have taken effect, it’s time to actually encrypt our server’s operating system volume. Follow these steps to get that job done:
Open Control Panel and start the BitLocker Drive Encryption item.
In the BitLocker Drive Encryption Control Panel interface beneath Operating System Drive, and click Turn On BitLocker.
Depending on how you’ve configured BitLocker policy in your domain, the specific options vary. As shown in Figure 1-3, our test server offers us the choice of using a USB startup key or using a password. Choose Enter A Password to continue.
FIGURE 1-3 Choosing a BitLocker authentication protector
Type and reenter a strong password in the Create A Password To Unlock This Drive dialog box and click Next to continue. A strong password is at least eight characters long and consists of a combination of (a) uppercase and lowercase characters; (b) non-alphanumeric characters; (c) numbers; and (d) absence in any dictionary in any language.
Back up your recovery key by choosing to save it in one of the following locations:
USB flash drive Note that this is not the same USB flash drive that you’d use as a startup key.
File Make sure to remove the file from the local server’s file system!
Printout Once again, keep the printed key in a safe place, far away from its associated server.
Choose how much of your operating system drive to encrypt. By the way, you can (and should) encrypt your server’s data drives as well; we’re concerned with the operating system drive here for simplicity. Your choices here are to encrypt only used disk space or to encrypt the entire drive. For an existing server, choose the latter option and click Next to continue.
Choose which encryption algorithm to use. Windows Server 2016 supports the following four options:
AES-128 This is the default algorithm and cipher length.
AES-256 Same as AES-128, but with a double-sized cipher length.
XTS-AES-128 Provides Federal Information Processing Standard (FIPS) compliancy and additional features, but is incompatible with previous Windows Server versions.
XTS-AES-256 Same as XTS-AES128, but with a double-size cipher length.
The trade-off with encryption algorithms is the inversely proportional relationship between cipher strength and performance.
In the BitLocker Drive Encryption Control Panel interface, you’re asked to choose either New Encryption mode (which uses XTS-AES-128) or Compatible mode (which uses XTS-AES-128).
Ensure that the Run BitLocker system check option is selected and click Continue to proceed. After being prompted to restart, BitLocker Drive Encryption proceeds to encrypt the operating system volume.
You can see the BitLocker Drive Encryption startup password prompt in Figure 1-4.
FIGURE 1-4 An example screen shot
$SecureString = ConvertTo-SecureString ‘$tr0ngP@$$w0rd!!’ -AsPlainText -Force Enable-BitLocker -MountPoint ‘C:’ -EncryptionMethod Aes256 –UsedSpaceOnly -Pin $SecureString -TPMandPinProtector
Alternatively, you can run the legacy manage-bde command line executable to encrypt, manage, and decrypt BitLocker on operating system and data volumes.
Implement BitLocker on Hyper-V virtual machines
Hyper-V in Windows Server 2016 allows both Secure Boot and virtualized TPM (vTPM) for virtual machine (VM) guests. As you can see in Figure 1-5, these capabilities are now “baked into” the Hyper-V VM properties sheet.
FIGURE 1-5 Enabling both Secure Boot and vTPM in a Hyper-V VM
Of course, this now means that you can deploy BitLocker Drive Encryption in local VMs the very same way you do in host hardware, including requiring TPM!
Implement BitLocker on CSVs and SANs
Windows Server 2012 introduced the ability to apply BitLocker Drive Encryption on cluster shared volumes (CSVs) based in storage area network (SAN) shared storage; this capability is known as CSV v2. Volumes can be encrypted either before you add them to a cluster or afterward. Use either Windows PowerShell or managzbde.exe to perform the task.
Configure Network Unlock
Windows Server 2016 supports the BitLocker Network Unlock feature that was introduced in Windows Server 2012. Network Unlock allows automatic access to BitLocker decryption keys, which means that you can start, restart, or remotely manage (perhaps via Wake on LAN) your Windows Server 2016 servers without the manual intervention required by the PIN protector method.
Besides having servers that use UEFI firmware and have TPM chips installed, there are a number of other infrastructure requirements for implementing Network Unlock:
UEFI DHCP This UEFI feature has historically been known as Preboot Execution Environment (PXE). In other words, the server can startup and obtain a TCP/IP configuration from a DHCP server directly from UEFI and the installed network interface card (NIC).
No CSM Your servers’ UEFI firmware must have legacy mode disabled completely (that is, no Compatibility Support Modules (CSMs).
Separate WDS and DHCP servers You’ll need separate servers running the Windows Deployment Service (WDS) and Dynamic Host Configuration Protocol (DHCP) server roles.
PKI You’ll need a public key infrastructure (PKI) in order to generate the X.509 digital certificates required for Network Unlock. Active Directory Certificate Services (AD CS) works perfectly fine for this purpose.
Network Unlock Group Policy settings You’ll configure the previously mentioned Group Policy settings to specify the TPM+PIN protectors. For the Network Unlock certificate policy, navigate to Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies\BitLocker Drive Encryption Network Unlock Certificate and upload the .cer file.
The Network Unlock sequence
Let’s walk through how BitLocker Network Unlock works from a bird’s eye perspective.
Upon server startup, the Windows boot manager detects the presence of the Network Unlock protector. This protector is realized by the Allow Network Unlock At Startup Group Policy setting.
The server uses its UEFI DHCP driver to obtain a valid IPv4 address from a DHCP server.
The server broadcasts a vendor-specific DHCP request that’s encrypted with the WDS server’s Network Unlock certificate (which the local server has thanks to Group Policy configuration).
The WDS provider processes the request and produces an AES-256 key that unlocks the local server’s operating system volume.
The server continues the boot process with no administrator intervention required.