Applies to SUSE Linux Enterprise Server 15 SP4

9 Physical security #

Physical security should be one of the utmost concerns. Linux production servers should be in locked data centers accessible only to people that have passed security checks. Depending on the environment and circumstances, you can also consider boot loader passwords.

Additionally, consider questions like:

Who has direct physical access to the host?
Of those that do, should they?
Can the host be protected from tampering and should it be?

The amount of physical security needed on a particular system depends on the situation, and can also vary widely depending on available funds.

9.1 System locks #

Most server racks in data centers include a locking feature. Usually this will be a hasp/cylinder lock on the front of the rack that allows you to turn an included key to a locked or unlocked position—granting or denying entry. Cage locks can help prevent someone from tampering or stealing devices/media from the servers, or opening the cases and directly manipulating/sabotaging the hardware. Preventing system reboots or the booting from alternate devices is also important (for example CD, DVDs, flash disks, etc.).

Some servers also have case locks. These locks can do different things according to the designs of the system vendor and construction. Many systems are designed to self-disable if attempts are made to open the system without unlocking. Others have device covers that will not let you plug in or unplug keyboards or mice. While locks are sometimes a useful feature, they are usually lower quality and easily defeated by attackers with ill intent.

9.2 Locking down the BIOS #

Tip: Secure boot

This section describes only basic methods to secure the boot process. To find out about more advanced boot protection using UEFI and the secure boot feature, see Section 17.1, “Secure boot”.

The BIOS (Basic Input/Output System) or its successor UEFI (Unified Extensible Firmware Interface) is the lowest level of software/firmware on PC class systems. Other hardware types (POWER, IBM Z) that run Linux also have low-level firmware that performs similar functions as the PC BIOS. When this document references the BIOS, it usually means BIOS and/or UEFI. The BIOS dictates system configuration, puts the system into a well defined state and provides routines for accessing low-level hardware. The BIOS executes the configured Linux boot loader (like GRUB 2) to boot the host.

Most BIOS implementations can be configured to prevent unauthorized users from manipulating system and boot settings. This is typically done by setting a BIOS admin or boot password. The admin password only needs to be entered for changing the system configuration but the boot password will be required during every normal boot. For most use cases it is enough to set an admin password and restrict booting to the built-in hard disk. This way an attacker will not be able to simply boot a Linux live CD or flash drive, for example. Although this does not provide a high level of security (a BIOS can be reset, removed or modified—assuming case access), it can be another deterrent.

Many BIOS firmware implementations have various other security-related settings. Check with the system vendor, the system documentation, or examine the BIOS during a system boot to find out more.

Important: Booting when a BIOS boot password is set

If a system has been set up with a boot password, the host will not boot up unattended (for example, in case of a system reboot or power failure). This is a trade-off.

Important: Losing the BIOS admin password

Once a system is set up for the first time, the BIOS admin password will not be required often. Do not forget the password or you will need to clear the BIOS memory via hardware manipulation to get access again.

9.3 Security via the boot loaders #

The Linux boot loader GRUB 2, which is used by default in SUSE Linux Enterprise Server, can have a boot password set. It also provides a password feature, so that only administrators can start the interactive operations (for example editing menu entries and entering the command line interface). If a password is specified, GRUB 2 will disallow any interactive control until you press the key C and E and enter a correct password.

You can refer to the GRUB 2 man page for examples.

It is very important to keep in mind that when setting these passwords they will need to be remembered! Also, enabling these passwords might merely slow an intrusion, not necessarily prevent it. Again, someone could boot from a removable device, and mount your root partition. If you are using BIOS-level security and a boot loader, it is a good practice to disable the ability to boot from removable devices in your computer's BIOS, and then password-protect the BIOS itself.

Also keep in mind that the boot loader configuration files will need to be protected by changing their mode to 600 (read/write for root only), or others will be able to read your passwords or hashes!

9.4 Retiring Linux servers with sensitive data #

Security policies usually contain some procedures for the treatment of storage media that is going to be retired or disposed of. Disk and media wipe procedures are frequently prescribed, as is complete destruction of the media. You can find several free tools on the Internet. A search for “dod disk wipe utility” will yield several variants. To retire servers with sensitive data, it is important to ensure that data cannot be recovered from the hard disks. To ensure that all traces of data are removed, a wipe utility—such as scrub—can be used. Many wipe utilities overwrite the data several times. This assures that even sophisticated methods are not able to retrieve any parts of the wiped data. Some tools can even be operated from a bootable removable device and remove data according to the U.S. Department of Defense (DoD) standards. Note that many government agencies specify their own standards for data security. Some standards are stronger than others, yet may require more time to implement.

Important: Wiping wear leveling devices

Some devices, like SSDs, use wear leveling and do not necessarily write new data in the same physical locations. Such devices usually provide their own erasing functionality.

9.4.1 scrub: disk overwrite utility #

scrub overwrites hard disks, files, and other devices with repeating patterns intended to make recovering data from these devices more difficult. It operates in three basic modes: on a character or block device, on a file, or on a specified directory. For more information, see the manual page man 1 scrub.

Supported scrub methods #

nnsa: 4-pass NNSA Policy Letter NAP-14.1-C (XVI-8) for sanitizing removable and non-removable hard disks, which requires overwriting all locations with a pseudo-random pattern twice and then with a known pattern: random (x2), 0x00, verify.
dod: 4-pass DoD 5220.22-M section 8-306 procedure (d) for sanitizing removable and non-removable rigid disks, which requires overwriting all addressable locations with a character, its complement, a random character, then verifying. Note: scrub performs the random pass first to make verification easier: random, 0x00, 0xff, verify.
bsi: 9-pass method recommended by the German Center of Security in Information Technologies (http://www.bsi.bund.de): 0xff, 0xfe, 0xfd, 0xfb, 0xf7, 0xef, 0xdf, 0xbf, 0x7f.
gutmann: The canonical 35-pass sequence described in Gutmann's paper cited below.
schneier: 7-pass method described by Bruce Schneier in "Applied Cryptography" (1996): 0x00, 0xff, random (x5)
pfitzner7: Roy Pfitzner's 7-random-pass method: random (x7).
pfitzner33: Roy Pfitzner's 33-random-pass method: random (x33).
usarmy: US Army AR380-19 method: 0x00, 0xff, random. (Note: identical to DoD 522.22-M section 8-306 procedure (e) for sanitizing magnetic core memory).
fillzero: 1-pass pattern: 0x00.
fillff: 1-pass pattern: 0xff.
random: 1-pass pattern: random (x1).
random2: 2-pass pattern: random (x2).
old: 6-pass pre-version 1.7 scrub method: 0x00, 0xff, 0xaa, 0x00, 0x55, verify.
fastold: 5-pass pattern: 0x00, 0xff, 0xaa, 0x55, verify.
custom=string: 1-pass custom pattern. String may contain C-style numerical escapes: \nnn (octal) or \xnn (hex).

9.5 Restricting access to removable media #

In some environments, it is required to restrict access to removable media such as USB storage or optical devices. The tools included with the udisks2 package help with such a configuration.

Create a user group whose users will be allowed to mount and eject removable devices, for example mmedia_all:
```
> sudo groupadd mmedia_all
```
Add a specific user tux to the new group:
```
> sudo usermod -a -G mmedia_all tux
```
Create the /etc/polkit-1/rules.d/10-mount.rules file with the following content:
```
> cat /etc/polkit-1/rules.d/10-mount.rules
polkit.addRule(function(action, subject) {
 if (action.id =="org.freedesktop.udisks2.eject-media"
  && subject.isInGroup("mmedia_all")) {
   return polkit.Result.YES;
  }
});

polkit.addRule(function(action, subject) {
 if (action.id =="org.freedesktop.udisks2.filesystem-mount"
  && subject.isInGroup("mmedia_all")) {
   return polkit.Result.YES;
  }
});
```
Important: Naming of the rules file
The name of a rules file must start with a digit, otherwise it will be ignored.
Rules files are processed in alphabetical order. Functions are called in the order they were added until one of the functions returns a value. Therefore, to add an authorization rule that is processed before other rules, put it in a file in /etc/polkit-1/rules.d with a name that sorts before other rules files, for example /etc/polkit-1/rules.d/10-mount.rules. Each function should return a value from polkit.Result.
Restart udisks2:
```
# systemctl restart udisks2
```
Restart polkit
```
# systemctl restart polkit
```

9.6 System protection with enforced USB device authorization via USBGuard #

The USBGuard software framework helps to protect your system with enforced USB device authorization. It implements allowlist and blocklist capabilities based on the device attributes.

The USBGuard provides the following features:

A command-line interface to interact with a running USBGuard daemon
The daemon component with an inter-process communication (IPC) interface for dynamic interaction and policy enforcement
The rule language for writing USB device authorization policies
The C++ API for interacting with the daemon component implemented in a shared library

9.6.1 Installing USBGuard #

The USBGuard daemon decides which USB device to authorize based on a set of rules defined in the policy. To install and configure USBGuard, use the following commands:

To install USBGuard:
```
> sudo  zypper install usbguard
```
USBGuard and the required dependencies are installed. If you want to interact with the USBGuard service, you can install usbguard-tools.
To generate a rule set based on currently connected USB devices, switch to root:
```
# usbguard generate-policy > /etc/usbguard/rules.conf
```
Note
You can customize USBGuard by editing the /etc/usbguard/rules.conf file.
You can start the USBGuard daemon or ensure automatic enablement at system start by switching to root:
```
# systemctl enable --now usbguard.service
```
You can either authorize or deauthorize a device from interacting with the system. Note that this depends on the value of the ImplicitPolicyTarget option in the usbguard-daemon.conf file. This option is used to treat devices that do not match any rule in the policy.
```
usbguard allow-device 6
```
```
usbguard block-device 6
```
You can also use the reject-deviceoption to deauthorize and remove a device from the system.
Note
Use the usbguard --help command to see all the options.

9.6.2 How to use USBGuard #

You can configure a security policy to protect your system with enforced USB device authorization by implementing allow and block lists based on the device attributes.

9.6.2.1 The USBGuard configuration file #

The USBGuard daemon loads the usbguard-daemon.conf file after the command-line options are parsed and are used to configure the runtime parameters of the daemon. The file is by default, located at /etc/usbguard/usbguard-daemon.conf. Some options in the file include:

Options #

RuleFile=PATH

The USBGuard daemon uses this file to load the policy rule set from it and to write new rules received through the IPC (inter-process communication) interface. The default is %sysconfdir%/usbguard/rules.conf.

ImplicitPolicyTarget= TARGET

How to treat devices that do not match any rule in the policy, for example:

allow - authorize every present device
block - deauthorize every present device
reject - logically remove the device node from the system

PresentDevicePolicy= POLICY

How to treat devices that are already connected when the daemon starts.

allow - authorize every present device
block - deauthorize every present device
reject - remove every present device
keep - sync the internal state
apply-policy - evaluate the rule set for all present devices

IPCAllowedUsers= USERNAME

A space-delimited list of user names that the daemon accepts IPC connections from.

IPCAllowedGroups= GROUPNAME

A space-delimited list of group names that the daemon accepts IPC connections from.

IPCAccessControlFiles= PATH

Path to files that are interpreted by the daemon as IPC access control definition files.

Example 9.1: Configuration #

IPCAllowedUsers=root joe
IPCAllowedGroups=wheel

The example allows full IPC access to the users root,joe and to the members of the group wheel.

9.6.3 More information #

To know more about USBGuard, see:

The upstream documentation at https://usbguard.github.io/
man usbguard
man usbguard-rules.conf
man usbguard-daemon
man usbguard-daemon.conf