Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Security and Hardening Guide › Local security › Physical security
ContentsContents
Security and Hardening Guide
  1. Preface
  2. 1 Security and confidentiality
  3. I Authentication
    1. 2 Authentication with PAM
    2. 3 Using NIS
    3. 4 Setting up authentication clients using YaST
    4. 5 LDAP with 389 Directory Server
    5. 6 Network authentication with Kerberos
    6. 7 Active Directory support
    7. 8 Setting up a freeRADIUS server
  4. II Local security
    1. 9 Physical security
    2. 10 Software management
    3. 11 File management
    4. 12 Encrypting partitions and files
    5. 13 Storage encryption for hosted applications with cryptctl
    6. 14 User management
    7. 15 Restricting cron and at
    8. 16 Spectre/Meltdown checker
    9. 17 Configuring security settings with YaST
    10. 18 The Polkit authentication framework
    11. 19 Access control lists in Linux
    12. 20 Intrusion detection with AIDE
  5. III Network security
    1. 21 X Window System and X authentication
    2. 22 Securing network operations with OpenSSH
    3. 23 Masquerading and firewalls
    4. 24 Configuring a VPN server
    5. 25 Managing a PKI with XCA, X certificate and key manager
    6. 26 Improving network security with sysctl variables
  6. IV Confining privileges with AppArmor
    1. 27 Introducing AppArmor
    2. 28 Getting started
    3. 29 Immunizing programs
    4. 30 Profile components and syntax
    5. 31 AppArmor profile repositories
    6. 32 Building and managing profiles with YaST
    7. 33 Building profiles from the command line
    8. 34 Profiling your Web applications using ChangeHat
    9. 35 Confining users with pam_apparmor
    10. 36 Managing profiled applications
    11. 37 Support
    12. 38 AppArmor glossary
  7. V SELinux
    1. 39 Configuring SELinux
  8. VI The Linux Audit Framework
    1. 40 Understanding Linux audit
    2. 41 Setting up the Linux audit framework
    3. 42 Introducing an audit rule set
    4. 43 Useful resources
  9. A GNU licenses
Navigation←→
Security and Hardening Guide › Local security › Physical security
Top
←→
Applies to openSUSE Leap 15.6

9 Physical security Edit source

9.1 System locks
9.2 Locking down the BIOS
9.3 Security via the boot loaders
9.4 Retiring Linux servers with sensitive data
9.5 Restricting access to removable media
9.6 System protection with enforced USB device authorization via USBGuard

Physical security is important. Linux production servers should be in locked data centers accessible 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 Edit source

Most server racks in data centers include a locking feature. This is 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 do not let you plug in or unplug keyboards or mice. While locks are sometimes a useful feature, they are lower quality and easily defeated by attackers with ill intent.

9.2 Locking down the BIOS Edit source

Tip
Tip: Secure boot

This section describes basic methods to secure the boot process. To find out about more advanced boot protection using UEFI and the secure boot feature, see Book “Reference”, Chapter 14 “UEFI (Unified Extensible Firmware Interface)”, Section 14.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 have low-level firmware that performs similar functions as the PC BIOS. When this document references the BIOS, it 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 administrator or boot password. The administrator password needs to be entered for changing the system configuration but the boot password is required during every normal boot. For most use cases, it is enough to set an administrator password and restrict booting to the built-in hard disk. This way an attacker is not 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 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
Important: Booting when a BIOS boot password is set

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

Important
Important: Losing the BIOS administrator password

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

9.3 Security via the boot loaders Edit source

The Linux boot loader GRUB 2, which is used by default in openSUSE Leap 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 disallows 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 important to keep in mind that when setting these passwords they need to be remembered. Also, enabling these passwords can 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 need to be protected by changing their mode to 600 (read/write for root only), or others can read your passwords or hashes.

9.4 Retiring Linux servers with sensitive data Edit source

Security policies contain certain 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” yields 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. Many government agencies specify their own standards for data security. Some standards are stronger than others, yet may require more time to implement.

Important
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 provide their own erasing functionality.

9.4.1 scrub: disk overwrite utility Edit source

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. This requires overwriting all addressable locations with a character, its complement, a random character and 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 (https://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 and 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 Edit source

In certain 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.

  1. Create a user group whose users are allowed to mount and eject removable devices, for example mmedia_all: 

    > sudo groupadd mmedia_all

  2. Add a specific user tux to the new group: 

    > sudo usermod -a -G mmedia_all tux

  3. 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
    Important: Naming of the rules file

    The name of a rules file must start with a digit, otherwise it is 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.

  4. Restart udisks2: 

    # systemctl restart udisks2

  5. Restart polkit 

    # systemctl restart polkit

9.6 System protection with enforced USB device authorization via USBGuard Edit source

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 Edit source

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:

  1. 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.

  2. To generate a rule set based on currently connected USB devices, switch to root: 

    # usbguard generate-policy > /etc/usbguard/rules.conf
    Note
    Note

    You can customize USBGuard by editing the /etc/usbguard/rules.conf file.

  3. You can start the USBGuard daemon or ensure automatic enablement at system start by switching to root:

    # systemctl enable --now usbguard.service

  4. You can either authorize or deauthorize a device from interacting with the system. 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
    Note

    Use the usbguard --help command to see all the options.

9.6.2 How to use USBGuard Edit source

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 Edit source

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 Edit source

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

→Chapter 10 Software management←Part II Local security
Print this page

© 2024 SUSE