Red Hat Security: Linux in Physical, Virtual, and Cloud

RH415

Welcome

Course Objectives and Structure

Schedule

Orientation to the Classroom Lab Environment

Internationalization

Chapter 1: Managing Security and Risk

Goal: Define strategies to manage security on Red Hat Enterprise Linux servers.

Objectives:

• Describe the fundamental concepts of security management for Red Hat Enterprise Linux servers, how to approach the security management process, and how Red Hat's development process and security response practices help.

• Review simple recommended practices to improve the security of a server system.

Quiz: Managing Security and Risk

Guided Exercise: Reviewing Recommended Security Practices

Lab: Managing Security and Risk

Summary

• Risk management is a continuous process of proactively discovering potential risk, assessing facts, and taking action based on the facts to resolve those risks.
• Red Hat analyzes threats and vulnerabilities against all Red Hat products every day, and provides relevant advice and updates through the Red Hat Customer Portal.
• Common Vulnerabilities and Exposures (CVE) entries provide a standardized format for reporting and tracking security-related software issues.
• You should base your servers on a standard operating environment (SOE) that provides a baseline of the minimum packages that all your systems require, and add only the additional packages that the server applications require.
• Every daemon that provides a network service increases the risk of a successful remote attack, so you should not run unnecessary services.
• You should not allow root to directly log in to the system using ssh. Instead, require initial login to an unprivileged account that can use sudo or su to become root.
• You should consider turning off password-based SSH access and require either key-based authentication or Kerberos for remote logins.

Chapter 2: Automating Configuration and Remediation with Ansible

Goal: Remediate configuration and security issues automatically with Ansible Playbooks.

Objectives:

• Describe the benefits of automation tools for managing security, install and configure an Ansible control node, and configure systems so that they can be managed by Ansible.

• Read and interpret an existing Ansible Playbook, and run it in order to apply its plays to hosts as specified by the plays and the current Ansible inventory.

• Run playbooks and manage access to authentication credentials using Red Hat Ansible Tower

Guided Exercise: Configuring Ansible for Security Automation

Guided Exercise: Remediating Issues with Ansible Playbooks

Guided Exercise: Managing Playbooks with Red Hat Ansible Tower

Lab: Automating Configuration and Remediation with Ansible

Summary

• Effective automation tools help you manage security by ensuring all machines are correctly and consistently configured and patched.
• Red Hat Ansible Automation is a good choice as an automation tool because it is simple to use, its automation instructions are easy to read, and a number of security tools provide Ansible Playbooks to help remediate issues.
• An Ansible Playbook consists of one or more plays. Each play targets a set of hosts with a list of tasks, executed in order, and checks to see whether the system is in a certain state. If it is not, it puts the system in that state.
• You use the ansible-playbook command to run an Ansible Playbook.
• An ad hoc command is a simple, one-task command that you can run using the ansible command without writing a playbook.
• An inventory file lists the hosts and groups that you can use in your playbook and with ad hoc commands.
• Red Hat Ansible Tower is a service that helps you control, secure, and centrally manage your Ansible automation at scale.
• You can use Red Hat Ansible Tower to protect the authentication credentials of hosts from users while still allowing them to use them to run playbooks.
• Red Hat Ansible Tower provides central logging and management so that you can track who ran playbooks from the Ansible Tower server, at what time, affecting what hosts, and what the results were of those runs.

Chapter 3: Protecting Data with LUKS and NBDE

Goal: Encrypt data on storage devices with LUKS, and use NBDE to manage automatic decryption when servers are booted.

Objectives:

• Create encrypted storage devices with LUKS, and manually open and mount storage on LUKS-encrypted devices.

• Manage decryption policy, and automatically decrypt storage when specified conditions are met, using NBDE.

Guided Exercise: Managing File System Encryption with LUKS

Guided Exercise: Controlling File System Decryption with NBDE

Lab: Protecting Data with LUKS and NBDE

Summary

• Red Hat Enterprise Linux supports block device encryption with Linux Unified Key Setup (LUKS).
• A passphrase is required at boot time to decrypt a LUKS-encrypted block device.
• Network Bound Disk Encryption (NBDE) automates the decryption of LUKS-encrypted disks without manually entering a passphrase at boot time.
• NBDE uses the Clevis framework on the client (decryption) side, and queries Tang servers to determine if the client is running on a secure network.
• The Clevis framework provides binding policies which support the use of multiple Tang servers.
• The signature and exchange keys for a Tang server should be rotated periodically.

Chapter 4: Restricting USB Device Access

Goal: Protect systems from rogue USB device access with USBGuard.

Objectives:

• Configure and use USBGuard in order to selectively control USB device access.

Guided Exercise: Controlling USB access with USBGuard

Lab: Restricting USB Device Access

Summary

• USBGuard protects your systems against rogue USB devices by implementing basic whitelisting and blacklisting capabilities based on device attributes.
• The usbguard-daemon service determines whether or not to authorize a USB device based on a policy defined by a set of rules.
• When a USB device is inserted into the system the daemon scans the existing rules sequentially, and when a matching rule is found it either allows, blocks or rejects the device, based on the rule target.
• The usbguard utility is used to manage the USB device authorization rules.

Chapter 5: Controlling Authentication with PAM

Goal: Manage authentication, authorization, session settings, and password controls by configuring Pluggable Authentication Modules (PAM).

Objectives:

• Explain how PAM works and interpret the effect of settings in existing PAM configuration files.

• Configure authentication by updating the PAM files, and explain recommended practices for modifying and managing PAM configuration files.

• Implement password quality requirements using pam_pwquality and authconfig.

• Implement account locking after a specified number of failed logins.

Guided Exercise: Auditing the PAM Configuration

Guided Exercise: Modifying the PAM Configuration

Guided Exercise: Configuring Password Quality Requirements

Guided Exercise: Limiting Access After Failed Logins

Lab: Controlling Authentication with PAM

Summary

• PAM stores most of its configuration files in /etc/pam.d/.
• A PAM-enabled application invokes the rules in each management group, auth, account, password, and session, at different times during the user authentication and authorization process.
• The authconfig command is the recommended way of updating the PAM configuration.
• Before any modification, back up the PAM configuration with authconfig --savebackup=backupdir and open an extra root session to recover from errors.
• The pam_pwquality module uses the /etc/security/pwquality.conf configuration file to enforce your organization password complexity requirements.
• The pam_faillock module locks accounts after too many consecutive failed attempts. You use the authconfig --enablefaillock --faillockargs="parameters" command to configure it.

Chapter 6: Recording System Events with Audit

Goal: Record and inspect system events relevant to security by using the Linux kernel's Audit subsystem and supporting tools.

Objectives:

• Ensure Audit is installed and configured to record system events, and forward audit messages to a central audit server.

• Search for events and generate reports from the audit log and interpret the results.

• Write your own audit rules to configure the system to collect information about particular events.

• Enable standard audit rule sets provided with Red Hat Enterprise Linux and identify potentially useful rule sets.

Guided Exercise: Configuring Audit to Record System Events

Guided Exercise: Inspecting Audit Logs

Guided Exercise: Writing Custom Audit Rules

Guided Exercise: Enabling Prepackaged Audit Rule Sets

Lab: Recording System Events with Audit

Summary

• Linux Audit is a system managed by the kernel to collect and log security-related events based on a list of audit rules.
• The kernel sends the audit messages it collects to a user-space daemon, auditd, which is responsible for recording them.
• auditd can save messages to a local log or relay them to a remote auditd or syslog service.
• You can use the ausearch and aureport commands to analyze the audit log.
• You can define audit rules persistently by editing files in /etc/audit/rules.d that have a .rules suffix.
• There are three types of rules: file system rules (watches), system call rules, and control rules.
• The auditctl command may be used to edit Audit rules temporarily.
• The audit package includes some prepackaged Audit rule files that can be used to help implement common security requirements.
• If a control rule has been set to make the audit rules immutable, they cannot be changed until the system is rebooted.

Chapter 7: Monitoring File System Changes

Goal: Detect and analyze changes to a server's file systems and their contents by using AIDE.

Objectives:

• Detect and identify changes to files on a system that has AIDE installed, and manage AIDE checks and the AIDE detection database.

• Investigate causes of file system changes reported by AIDE by using Linux Audit tools.

Guided Exercise: Detecting File System Changes with AIDE

Guided Exercise: Investigating File System Changes with AIDE

Lab: Monitoring File System Changes

Summary

• AIDE allows you to detect changes made to a machine's file systems.
• An AIDE check can be run manually or by scheduling it with a tool such as crontab, and detect changes using a database of baseline information.
• You use the /etc/aide.conf file to configure checks that AIDE performs against specific files and directories using group definitions, selection lines, and macros.
• You need to rebuild the AIDE database file to accept authorized changes to files and to apply new settings from the configuration file.
• You can use Audit in conjunction with AIDE to help you determine what process or user caused a change that AIDE is reporting.

Chapter 8: Mitigating Risk with SELinux

Goal: Improve security and confinement between processes by using SELinux and advanced SELinux techniques and analysis.

Objectives:

• Configure SELinux in Enforcing mode on a server that has been running with SELinux disabled.

• Limit user access to the system and the root account by configuring them as confined users.

• Examine a system's SELinux policy to evaluate the access it permits, and to troubleshoot and resolve issues.

Guided Exercise: Enabling SELinux from the Disabled State

Guided Exercise: Controlling Access with Confined Users

Guided Exercise: Auditing the SELinux Policy

Lab: Mitigating Risk with SELinux

Summary

• To migrate a system that has SELinux disabled to enforcing mode, switch to permissive mode, review the audit log, relabel files and resolve issues, and then switch to enforcing mode.
• Confined SELinux users can allow you to restrict users from using sudo or su to switch user, log in using ssh, or run some commands on the system.
• You can use the sesearch command to look up the access rules and transition rules that SELinux enforces.
• You can use the sepolicy transition command to analyze whether or not a process running in one domain can potentially use one or more domain transitions to run a process in another domain.
• You can use the matchpathcon command to determine the expected context of a file created in a particular location even if the file does not exist.

Chapter 9: Managing Compliance with OpenSCAP

Goal: Evaluate and remediate a server's compliance with security policies by using OpenSCAP.

Objectives:

• Explain what OpenSCAP is and how it works, and install OpenSCAP tools and SCAP Security Guide content on a server.

• Evaluate a server's compliance with the requirements specified by a policy from the SCAP Security Guide using OpenSCAP tools.

• Create a tailoring file to adjust the policy's security checks so that they are relevant and correct for a specific system and its use case.

• Run Ansible Playbooks, provided with the SCAP Security Guide's content, to remediate compliance checks that failed an OpenSCAP scan.

Guided Exercise: Installing OpenSCAP

Guided Exercise: Scanning and Analyzing Compliance

Guided Exercise: Customizing OpenSCAP Policy

Guided Exercise: Remediating OpenSCAP Issues with Ansible

Lab: Managing Compliance with OpenSCAP

Summary

• The openscap-scanner and scap-security-guide packages must be installed on the system to scan for compliance.
• You use SCAP Workbench to explore and customize the policies provided by the SCAP Security Guide.
• The oscap xccdf eval command is used to scan systems for compliance, using a data stream file, a profile, and optionally a tailoring file containing local customizations.
• The oscap generate fix command can be used to generate an Ansible Playbook from a profile or a scan result XML file, which can be used to apply remediations.

Chapter 10: Automating Compliance with Red Hat Satellite

Goal: Automate and scale your ability to perform OpenSCAP compliance checks and remediate compliance issues using Red Hat Satellite.

Objectives:

• Configure an existing Red Hat Satellite to perform OpenSCAP scans of registered servers.

• Perform OpenSCAP scans of registered systems from the Red Hat Satellite interface and evaluate the results of those scans.

• Apply a tailoring file to a SCAP profile in Red Hat Satellite and use the customized SCAP policy to scan registered servers.

Guided Exercise: Configuring Red Hat Satellite for OpenSCAP

Guided Exercise: Scan OpenSCAP Compliance with Red Hat Satellite

Guided Exercise: Customize OpenSCAP Policy in Red Hat Satellite

Lab: Automating Compliance with Red Hat Satellite

Summary

• Red Hat Satellite 6 compliance policies can be used to centrally manage and review the results of OpenSCAP scans on its registered clients.
• A Red Hat Satellite 6 compliance policy is a named, scheduled task that scans specific hosts for compliance with an OpenSCAP XCCDF profile.
• OpenSCAP content must be uploaded to the Red Hat Satellite Server before it can be used in a compliance policy.
• Clients update their compliance policy configuration using Puppet, run OpenSCAP scans locally, and upload the results to Red Hat Satellite.
• The compliance policy dashboard in the Satellite Server's web UI provides an overview of compliant and noncompliant hosts, and links to detailed OpenSCAP compliance reports for each host.
• A compliance policy can be customized with an OpenSCAP tailoring file, which may be created in SCAP Workbench.

Chapter 11: Analyzing and Remediating Issues with Red Hat Insights

Goal: Identify, detect, and correct common issues and security vulnerabilities with Red Hat Enterprise Linux systems by using Red Hat Insights.

Objectives:

• Explain what Red Hat Insights is and how it complements OpenSCAP, and register a Red Hat Enterprise Linux server with Red Hat Insights.

• Review and interpret issue reports provided by Red Hat Insights in your Red Hat Satellite web interface.

• Remediate issues reported by Red Hat Insights using Red Hat Ansible Engine and Red Hat Ansible Tower integration with Red Hat Satellite.

Quiz: Registering Systems with Red Hat Insights

Quiz: Reviewing Red Hat Insights Reports

Quiz: Automating Issue Remediation

Summary

• Red Hat Insights is designed to help you identify and remediate threats to the security, performance, availability, and stability of systems running Red Hat products.
• Red Hat Insights is provided as Software-as-a-service (SaaS) through the Red Hat Customer Portal.
• You can directly register clients for Red Hat Insights analysis through the Customer Portal, or indirectly by using your Red Hat Satellite Server as a proxy.
• You can configure the Insights client on each of your hosts to restrict or obscure the data sent to Red Hat Insights for analysis, although this may make its analysis less comprehensive.
• You can review Red Hat Insights reports on the Customer Portal or through your Red Hat Satellite Server.
• The risk and impact of issues are graded by Likelihood, Impact, Total Risk, and Risk of change to help you understand and prioritize the actions to take to address detected issues.
• You can create Ansible Playbooks to address issues with your systems by configuring a maintenance plan in Red Hat Insights.
• Integrating Red Hat Ansible Tower with Red Hat Insights allows you to automate the remediation of issues reported by Red Hat Insights on your registered systems.

Chapter 12: Comprehensive Review

Lab: Automating Configuration and Remediation with Ansible

Lab: Protecting Data with LUKS and NBDE

Lab: Restricting USB Device Access and Mitigating Risk with SELinux

Lab: Recording Events, Monitoring File System Changes and Managing Compliance with OpenSCAP