Photo by Adi Goldstein on Unsplash
To prevent outside interference and tampering with the physical hardware several measures should be taken into consideration. By taking the correct measures ensures that you can trust your deployed computing platform, and it adds security to server hardware and operating systems from the moment you turn them on or reboot.
Best practices:
- Prevent injection of shady boot code
- Run with UEFI Native mode
- Use UEFI with Secure Boot Standard Mode
- Combine Secure Boot with a TPM
- Deploy a TPM 2.0 on Hypervisor Hosts and Veeam Repositories
- Protect against unauthorized access to Data
- BitLocker
- TPM+PIN for Pre-boot authentication
- Linux Unified Key System (LUKS)
- Place locks on the hardware
Prevent Code Injection
The most vulnerable moment of a server is before it boots up the operating system and its applications. This is because shady code in the form of soft- and/or hardware can be added to the system and can hide itself from security applications that will start later on top of the operating system to scan for malicious code. This is often called a rootkit.
When a computer boots, it has no software in its main memory. So, some process must load software into the memory before it can be executed. This may be done by hardware or firmware in the CPU, or by a separate process in the computer system.
In previous servers a legacy boot mode called Basic Input/Output System (BIOS) mode or Compatibility Support Module (CSM) is used. Legacy boot modes are intended to be used with older peripherals, hardware, and software lacking support for Unified Extensible Firmware Interface (UEFI) standards.
Current servers are using UEFI for the booting process, because UEFI provides a common, vendor and architecture-neutral foundation that accelerates the development of new products and patches. Binaries are arranged in the form of modules. Modules can be patched, replaced, added, removed, or otherwise altered individually as needed.
Some modules can execute in parallel to accelerate boot time. Some modules can fail or enter error states without affecting a device’s ability to boot. Patches can be created by different vendors in parallel to accelerate delivery of new versions. Environment variables and services allow the firmware boot environment to pass data to the operating system, and vice versa.
Boot Security Modes
Current computing platforms provide a variety of boot options. You can choose from legacy BIOS or the new standard UEFI in native or compatibility modus. When looking for a secure starting process you will have to abandon BIOS and UEFI in compatibility modus. While running with UEFI in Native mode is a good starting point it does not provide any validation or protection at all. You will have to combine the UEFI in Native mode with Secure Boot or vendor-specific boot protection solutions.
With Secure Boot you get the option to run in Standard or Custom mode. Where Standard mode relies upon Microsoft and system vendors to validate hardware and software – a solution that minimizes overhead for system owners. Custom mode relies fully on the choices the system owners made which hardware components, firmware images, boot loaders, kernels, and drivers are acceptable at boot. The signing and hashing of the different trusted content are a full responsibility of the system owners!
UEFI with Secure Boot
Just choosing UEFI over legacy mode does not give any validation or protection of the boot process. To protect the boot process UEFI relies on Secure Boot or vendor-specific boot protection solutions. Secure Boot is a signature and hash-checking mechanism added to the UEFI boot process.
Each firmware and software executable at boot time must have an associated signature or hash. Secure boot validates signatures using RSA-2048 public key certificates. Hashes are listed in SHA-256 format. Secure Boot has multiple data stores for storing certificates and hashes. Most new computing devices are loaded with system vendor and Microsoft values focused on compatibility with mainstream computing solutions.
Untrusted values are checked first. Any signature or hash that validates against an untrusted value is blocked from execution at boot time. Trusted values are checked second. A signature or hash match validated to a trusted value may execute at boot time. Any binaries that cannot be validated as untrusted or trusted – also known as unknown binaries – are treated as untrusted and blocked. However, denial of execution privileges does not necessarily stop the boot process.
This way system firmware, component firmware, bootloaders, kernels, and other boot-time executables are validated by Secure Boot to provide a boot-time anti-malware solution.
IMPORTANT: Secure Boot is not active from the moment of power application (SEC phase of the UEFI boot order) meaning an early-boot blind spot exists! The Security (SEC) phase is the first phase in the Platform Initialization (PI) architecture and is responsible for handling all platform restart events, creating a temporary memory store, serving as the root of trust in the system and passing handoff information to the PEI Foundation.
Secure Boot and the Trusted Platform Module (TPM) complement each other. TPM provides the ability to cover the early-boot blind spot that exists in Secure Boot. Secure Boot allows the flexibility to handle multiple trusted system images, devices and configurations when necessary. Think about when you are updating versions of components, devices or operating systems. Use a TPM-aware solution to monitor PCR 0 firmware images, PCR 1 firmware configuration, and PCR 7 Secure Boot data stores- all system integrity indicators that rarely change.
UEFI Secure Boot for ESXi hosts
Starting with vSphere 6.5, ESXi supports Secure Boot if it is enabled in the hardware. The ESXi bootloader contains a VMware public key, which is being used to verify the signature (1) of the kernel and a small subset of the system that includes a secure boot VIB verifier. The VIB verifier (2) verifies every VIB package that is installed on the system. The entire system boots with the root of trust in certificates (3) that are part of the UEFI firmware.
TPM 2.0
Hardware tampering can expose encryption keys. The purpose of the Trusted Platform Module (TPM) is to implement a hardware controller on the server motherboard. This acts as a repository for keys, passwords and digital certificates, which are all protected through the TPMs subsystem. In effect, the physical TPM becomes an integral part of the encryption keys. As a hardware device, the TPM is immune to malware and forgery.
The TPM is secured with a unique key created by taking a baseline “fingerprint” of the server and its components as it boots up and comparing that baseline against periodic measurements of the system’s parameters. If the boot characteristics change and the fingerprint no longer matches the actual system parameters, hardware tampering may be indicated, and system access will be denied!
Platform Configuration Registers (PCRs) are one of the essential features of a TPM. Their prime use case is to provide a method to cryptographically record (measure) software state: both the software running on a platform and configuration data used by that software. The PCR update calculation, called an extend, is a one-way hash so that measurements can’t be removed. These PCRs can then be read to report their state. They can also be signed to return a more secure report, called an attestation (or quote). PCRs can also be used in an extended authorization policy to restrict the use of other objects.
The TPM never passes judgment on the measurements. Internally, it doesn’t know which measurements are good or bad, or more or less secure or trusted. At the time of measurement, TPM PCRs just record values. Security or trust comes later, when an application uses PCR values in an authorization policy, or a remote party asks for a signed attestation (quote) of the values and judges their trustworthiness.
IMPORTANT: TPM technology protects sensitive data, but it also requires specific hardware components. And hardware can and will fail. Enable TPMs only where most appropriate, manage passwords vigilantly and be sure to test TPM behaviors thoroughly and regularly.
What’s great about TPM is that its functionality is tied to the server hardware itself. That is, its security “travels” with the host hardware, and is much more difficult to bypass than a software-based control. TPM secures the PIN, helps encrypt passwords, and enables security as a critical pillar. Using Windows on a system with a TPM enables a deeper and broader level of security coverage.
Secure Boot and TPM redundant?
By smartly combining Secure Boot and TPM Auditing you can overcome the early mentioned boot blind spot when a server is powered on or restarted. UEFI Secure Boot in Standard Mode with TPM Support is the best balance of protection and overhead for most organizations. Enable the thorough- or full-boot options to ensure comprehensive Secure Boot checks!
Protecting Critical Servers with a TPM 2.0
While looking through your infrastructure think about leveraging and combining UEFI, Secure Boot and a TPM 2.0 for critical servers. Looking from a Veeam focus perspective towards the infrastructure you should equip the following critical servers with a UEFI (Native Mode), Secure Boot (Standard Mode) and TPM 2.0 combo:
- Hypervisor Hosts – which will run Veeam components like the Veeam Backup & Replication Server (VBR), Veeam Enterprise Manager (EM), Veeam Proxy servers and the Microsoft SQL Server running the databases for the VBR and EM server.
- Veeam All-in-one – especially when you combine all roles on a single server make sure it is protected to the max!
- Veeam Backup Repository – the Veeam Backup Repository holds vital and critical information and often a full copy of the whole infrastructure in backup files which are autonomous.
- Physical Server with Veeam Components – any physical deployed server which houses a Veeam component should be considered a critical server in the Veeam Availability infrastructure.
Protect against unauthorized access
After boot, TPM supports additional security features such as BitLocker drive encryption. Help protect your files and folders from unauthorized access by protecting your drives with BitLocker. Microsoft BitLocker encryption is a Windows feature that was launched with the Windows Vista operating system in early 2007.
Microsoft continues to develop BitLocker as a full-volume drive encryption platform. BitLocker uses the AES encryption algorithm, in either cipher block chaining or XTS mode – with a 128-bit or 256-bit key. The platform is commonly available in Windows 10 and Windows Server 2016/2019
Without the unique key used to encrypt the data, nobody can, easily, decrypt the data. In the event of a cyber security incident the data remains private and inaccessible. If you are running with Linux instead think about leveraging Linux Unified Key System (LUKS).
BitLocker
BitLocker Drive Encryption can be configured to use a number of authentication methods called protectors. It’s possible to leverage TPM security and BitLocker Drive Encryption without any additional protectors. In this case, the server starts normally and (at the surface) appears to offer no security benefit to the administrator, but if we look deeper into it you will see that the TPM protects the server against offline attacks by validating the startup environment. Users can access the encrypted drive as long as it is connected to the system board that hosts the TPM and the system boot integrity is intact!
The following protectors can be chosen in combination with BitLocker:
- Trusted Platform Module (TPM)
- TPM and Personal Identification Number (PIN)
- TPM, PIN and startup key
- Startup key (Stored on an USB memory device that is read by BitLocker)
- Password
- Recovery key (Stored on an USB memory device that is read by BitLocker)
- Recovery Password
- Active Directory Domain Services (AD DS) – Network Unlock
IMPORTANT: You can only add one of these methods or combinations at a time.
BitLocker with TPM+PIN protector
Pre-boot authentication with a PIN can mitigate an attack vector for devices that use a bootable eDrive because an exposed eDrive bus can allow an attacker to capture the BitLocker encryption key during startup. Pre-boot authentication with a PIN can also mitigate DMA port attacks during the window of time between when BitLocker unlocks the drive and Windows boots to the point that Windows can set any port-related policies that have been configured.
BitLocker uses a combination of the TPM and a user-supplied PIN. A PIN is four to twenty digits or, if you allow enhanced PINs, four to twenty letters, symbols, spaces, or numbers.
If you do not want to have user interaction, by typing in a PIN, at boot time leverage BitLocker Network Unlock which allows systems within the physical enterprise security perimeter that meet the hardware requirements and have BitLocker enabled with TPM+PIN to boot into Windows without user intervention. It requires direct ethernet connectivity to an enterprise Windows Deployment Services (WDS) server.
For secure administrative servers and workstations, I recommend using TPM with PIN protector and disable Standby power management and shut down or hibernate the device.
Group Policies to set
Before enabling BitLocker, you should set the correct group policy settings how you wish to run it in your environment. The default protector will be set to TPM when the TPM is available during the setup of the operating system. To choose different settings you should modify the correct policies through Group Policy editor (gpedit.msc) on the machine involved.
Browse to Local Computer Policy > Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drive
You can now go through the available policies and configure them to meet the requirements of your environment. Some useful policy setting that you may wish to adjust include:
- Choose drive encryption method and cipher strength: By default for Windows 10 this will set XTS-AES 128-bit encryption, this can be modified to XTS-AES 256-bit instead for higher protection.
- Require additional authentication at startup: Rather than only using one authentication method such as TPM, this policy can be enabled to instead require both TPM and a PIN, TPM and a startup key, or TPM with a startup key and PIN.
- Allow enhanced PINs for startup: Enhanced PINs allow you to use additional characters such as uppercase, lowercase, numbers and symbols and should be turned on by default. It allows for stronger PINs to be set.
- Configure minimum PIN length for startup: This allows you to configure the minimum PIN length, which can ensure that your users are forced to set strong BitLocker PINs. By default, it is 6-20 characters.
- (Optional) Store BitLocker recovery information in Active Directory: With this policy enabled it will only be possible to enable BitLocker if an Active Directory domain controller is available so that the recovery key can be stored there. If a domain controller is not available, BitLocker will not enable. This allows you to centrally manage BitLocker recovery keys as they will be stored in Active Directory.
For all critical servers’ best practice is to use: XTS-AES 256 bit, require TPM + PIN and allow enhanced PINs for startup. Optional you can Store BitLocker keys in Active Directory but for Veeam Servers and especially Veeam Repositories this is not recommended, because you will always need an active AD Domain Controller to startup and decrypt a server before you can start restoring your whole environment when it gets hit!
When setting the Require additional authentication at startup policy, remember that you can only have one authentication method working at a time. In order for the TPM with PIN option to work, you have to selected:
- Do not allow TPM – (TPM Only protector)
- Require startup PIN with TPM – (TPM with PIN protector)
- Do not allow startup key with TPM – (TPM with KEY protector)
- Do not allow startup key and PIN with TPM – (TPM with KEY and PIN protector)
This looks unnatural, because you do not allow TPM but remember this is the TPM Only protector option! Otherwise you will see an error that the BitLocker startup options are in conflict and cannot be applied.
IMPORTANT: Using BitLocker to encrypt operating system drives is a best practice, do not encrypt the drives where you store your Veeam Backups. This may result in backup jobs failing because they cannot access the drive. Even with the function auto unlock enabled in BitLocker from time to time access to those encrypted drives will be denied. A better solution to protect the backup data is by encrypting them through Veeam.
Activating BitLocker on Windows servers
By default, on a Microsoft Windows server the BitLocker feature is not installed. You will have to add the BitLocker Drive Encryption feature together with the Enhanced Storage Feature.
To encrypt an entire drive, simply right-click on the drive and select Turn on BitLocker from the context menu. Or open the BitLocker interface by searching for it through the magnifier glass. You will need administrative access to Turn on BitLocker.
Next you’ll need to choose a PIN that will be used to access the drive.
You’re prompted to store the recovery key which is used in the event you lose your PIN code. If you store it as a file make sure that it’s not on the same drive that you’re encrypting. Make sure this recovery key is stored in a physical vault!
You cannot continue until you save or print the recovery key.
In the next step you have to choose how much of your drive should be encrypted.
With the new Windows 10+ and Windows Server 2016+ you get an extra option to choose which encryption mode you want to use to encrypt the drive. Choose the New encryption mode.
Confirm you want the drive to be encrypted then wait until the process is complete. The amount of time it takes will vary based on the size and amount of data on the drive. To access the encrypted drive you’ll need to enter the PIN to unlock it during boot process.
The drive icon will change to show it’s encrypted with BitLocker, where the gold lock indicates it’s locked up and the gray lock is displayed after you have unlocked it.
Place Locks
Your server’s UEFI setup program should allow you to set one or more startup passwords that prevent the system from unauthorized startup. Because the UEFI/BIOS firmware settings are saved by battery power from the motherboard, you need to add physical locks to the server chassis.
IMPORTANT: Many attacks on sensitive data and resources reported by organizations occur from within the organization itself.
Resources:
