Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
ContentsContents
Security and Hardening Guide
  1. About This Guide
  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 The Polkit authentication framework
    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 Improving Network Security with sysctl Variables
    6. 27 Enabling compliance with FIPS 140-2
  7. IV Confining Privileges with AppArmor
    1. 28 Introducing AppArmor
    2. 29 Getting Started
    3. 30 Immunizing Programs
    4. 31 Profile Components and Syntax
    5. 32 AppArmor Profile Repositories
    6. 33 Building and Managing Profiles with YaST
    7. 34 Building Profiles from the Command Line
    8. 35 Profiling Your Web Applications Using ChangeHat
    9. 36 Confining Users with pam_apparmor
    10. 37 Managing Profiled Applications
    11. 38 Support
    12. 39 AppArmor Glossary
  8. V SELinux
    1. 40 Configuring SELinux
  9. VI The Linux Audit Framework
    1. 41 Understanding Linux Audit
    2. 42 Setting Up the Linux Audit Framework
    3. 43 Introducing an Audit Rule Set
    4. 44 Useful Resources
  10. A Payment Card Industry Data Security Standard (PCI DSS)
  11. B GNU-Lizenzen
Navigation
Applies to SUSE Linux Enterprise Server 15 SP2

Part II Local Security

10 Physical Security

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

11 Software Management

A very important step in securing a Linux system is to determine the primary function(s) or role(s) of the Linux server. Otherwise, it can be difficult to understand what needs to be secured and securing these Linux systems can prove ineffective. Therefore, it is critical to look at the default list…

12 File Management

Servers should have separate file systems for at least /, /boot, /usr, /var, /tmp, and /home. This prevents, for example, that logging space and temporary space under /var and /tmp fill up the root partition. Third-party applications should be on separate file systems as well, for example under /opt…

13 Encrypting Partitions and Files

Encrypting files, partitions, and entire disks prevents unauthorized access to your data and protects your confidential files and documents.

14 Storage Encryption for Hosted Applications with cryptctl

Databases and similar applications are often hosted on external servers that are serviced by third-party staff. Certain data center maintenance tasks require third-party staff to directly access affected systems. In such cases, privacy requirements necessitate disk encryption.

15 User Management

It is important that all system and vendor accounts that are not used for logins are locked. To get a list of unlocked accounts on your system, you can check for accounts that do not have an encrypted password string starting with ! or * in the /etc/shadow file. If you lock an account using passwd -…

16 Restricting cron and at

This chapter explains how to restrict access to the cron and at daemons to improve the security of a system.

17 Spectre/Meltdown Checker

spectre-meltdown-checker is a shell script to test if your system is vulnerable to the several speculative execution vulnerabilities that are in nearly all CPUs manufactured in the past 20 years. This is a hardware flaw that potentially allows an attacker to read all data on the system. On cloud computing services, where multiple virtual machines are on a single physical host, an attacker can gain access to all virtual machines. Fixing these vulnerabilities requires redesigning and replacing CPUs. Until this happens, there are several software patches that mitigate these vulnerabilities. If you have kept your SUSE systems updated, all of these patches should already be installed.

spectre-meltdown-checker generates a detailed report. It is impossible to guarantee that your system is secure, but it shows you which mitigations are in place, and potential vulnerabilities.

18 Configuring Security Settings with YaST

The YaST module Security Center and Hardening offers a central clearinghouse to configure security-related settings for SUSE Linux Enterprise Server. Use it to configure security aspects such as settings for the login procedure and for password creation, for boot permissions, user creation or for default file permissions. Launch it from the YaST control center by Security and Users › Security Center and Hardening. The Security Center dialog always starts with the Security Overview, and other configuration dialogs are available from the right pane.

19 The Polkit authentication framework

Polkit is an authentication framework used in graphical Linux desktop environments, for fine-grained management of access rights on the system. Traditionally, there is a strong separation of privileges on Linux between the root user as the fully-authorized administrator account, and all other accounts and groups on the system. These non-administrator accounts may have certain additional privileges, like accessing sound hardware through an audio group. This kind of privilege is fixed, however, and cannot be granted only in certain specific situations, or for a certain duration of time.

Instead of fully switching to the root user (using programs such as sudo) for gaining higher privileges, Polkit grants specific privileges to a user or group on an as-needed basis. This is controlled by configuration files that describe individual actions that need to be authorized in a dynamic context.

20 Access Control Lists in Linux

POSIX ACLs (access control lists) can be used as an expansion of the traditional permission concept for file system objects. With ACLs, permissions can be defined more flexibly than with the traditional permission concept.

21 Intrusion Detection with AIDE

Securing your systems is a mandatory task for any mission-critical system administrator. Because it is impossible to always guarantee that the system is not compromised, it is very important to do extra checks regularly (for example with cron) to ensure that the system is still under your control. This is where AIDE, the Advanced Intrusion Detection Environment, comes into play.

Print this page