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

10 Physical security Edit source

10.1 System locks
10.2 Locking down the BIOS
10.3 Security via the boot loaders
10.4 Retiring Linux servers with sensitive data
10.5 Restricting access to removable media

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.

10.1 System locks Edit source

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.

10.2 Locking down the BIOS Edit source

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

10.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 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!

10.4 Retiring Linux servers with sensitive data Edit source

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

10.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, 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).

10.5 Restricting access to removable media Edit source

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.

  1. Create a user group whose users will be 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 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.

  4. Restart udisks2: 

    # systemctl restart udisks2

  5. Restart polkit 

    # systemctl restart polkit
→Chapter 11 Software management←Part II Local security
Print this page

© 2022 SUSE