Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
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
Applies to openSUSE Leap 15.6

10 Software management Edit source

10.1 Removing unnecessary software packages (RPMs) Edit source

An important step in securing a Linux system is to determine the primary functions or roles 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 of software packages and remove any unnecessary packages or packages that do not comply with your defined security policies.

Generally, an RPM software package consists of the following:

  • The package's metadata that is written to the RPM database upon installation.

  • The package's files and directories.

  • Scripts that are being executed before and after installation and removal.

Packages generally do not impose any security risk to the system unless they contain:

  1. setuid or setgid bits on any of the installed files

  2. group- or world-writable files or directories

  3. a service that is activated upon installation, or by default

Assuming that none of the three conditions above apply, a package is merely a collection of files. Neither installation nor uninstallation of such packages has any influence on the security value of the system.

Nevertheless, it is useful to restrict the installed packages in your system to a minimum. Doing this results in fewer packages that require updates and simplifies maintenance efforts when security alerts and patches are released. It is a best practice not to install, among others, development packages or desktop software packages (for example, an X Server) on production servers. If you do not need them, you should also not install, for example, the Apache Web server or Samba file sharing server.

Important: Requirements of third-party installers

Many third-party vendors like Oracle and IBM require a desktop environment and development libraries to run installers. To prevent this from having an impact on the security of their production servers, many organizations work around this by creating a silent installation (response file) in a development lab.

Also, other packages like FTP and Telnet daemons should not be installed unless there is a justified business reason for it. ssh, scp or sftp should be used as replacements.

One of the first action items should be to create a Linux image that only contains RPMs needed by the system and applications, and those needed for maintenance and troubleshooting purposes. A good approach is to start with a minimum list of RPMs and then add packages as needed.

To generate a list of all installed packages, use the following command:

# zypper packages -i

To retrieve details about a particular package, run:

# zypper info PACKAGE_NAME

To check for and report potential conflicts and dependencies when deleting a package, run:

# zypper rm -D PACKAGE_NAME

This can be useful, as running the removal command without a test can often yield a lot of complaints and require manual recursive dependency hunting.

Important: Removal of essential system packages

When removing packages, be careful not to remove any essential system packages. This could put your system into a broken state in which it can no longer be booted or repaired. If you are uncertain about this, then it is best to do a complete backup of your system before you start to remove any packages.

For the final removal of one or more packages use the following zypper command with the added -u switch, which removes any unused dependencies:

# zypper rm -u PACKAGE_NAME

10.2 Patching Linux systems Edit source

Building an infrastructure for patch management is another important part of a proactive and secure Linux production environment.

It is recommended to have a written security policy and procedure to handle Linux security updates and issues. For example, a security policy should detail the time frame for assessment, testing and roll out of patches. Network related security vulnerabilities should get the highest priority and should be addressed immediately within a short time frame. The assessment phase should occur within a testing lab, and initial rollout should occur on development systems first.

A separate security log file should contain details on which Linux security announcements have been received, which patches have been researched and assessed, when patches were applied, and so on.

SUSE releases patches in three categories: security, recommended and optional. There are a few options that can be used to keep systems patched, up to date, and secure. Each system can register and then retrieve updates via the SUSE Update Web site using the included YaST tool—YaST Online Update. SUSE has also created the Repository Mirroring Tool (RMT), an efficient way to maintain a local repository of available/released patches/updates/fixes that systems can then pull from (reducing Internet traffic). SUSE also offers SUSE Manager for the maintenance, patching, reporting and centralized management of Linux systems, not only SUSE, but other distributions as well.

10.2.1 YaST Online Update Edit source

On a per-server basis, installation of important updates and improvements is possible using the YaST Online Update tool. Current updates for openSUSE Leap are available from the product specific update catalogs containing patches. Installation of updates and improvements is accomplished using YaST and selecting Online Update in the Software group. All new patches (except the optional ones) that are currently available for your system are marked for installation. Clicking Accept automatically installs these patches.

10.2.2 Automatic Online Update Edit source

YaST also offers the possibility to set up an automatic update. Select Software ›  Automatic Online Update. Configure a Daily or a Weekly update. Some patches, such as kernel updates, require user interaction, which would cause the automatic update procedure to stop. Check Skip Interactive Patches for the update procedure to proceed automatically.

In this case, run a manual Online Update from time to install patches that require interaction.

When Only Download Patches is checked, the patches are downloaded at the specified time but not installed. They must be installed manually using rpmor zypper.

Print this page