Changes in RHEL 7 Security Technical Implementation Guide Version 1, Release 3

major@mhtx.net (Major Hayden) — Thu, 02 Nov 2017 15:00:25 +0000

The latest release of the Red Hat Enterprise Linux Security Technical Implementation Guide (STIG) was published last week. This release is Version 1, Release 3, and it contains four main changes:

V-77819 - Multifactor authentication is required for graphical logins
V-77821 - Datagram Congestion Control Protocol (DCCP) kernel module must be disabled
V-77823 - Single user mode must require user authentication
V-77825 - Address space layout randomization (ASLR) must be enabled

Deep dive

Let’s break down this list to understand what each one means.

V-77819 - Multifactor authentication is required for graphical logins

This requirement improves security for graphical logins and extends the existing requirements for multifactor authentication for logins (see V-71965, V-72417, and V-72427). The STIG recommends smartcards (since the US Government often uses CAC cards for multifactor authentication), and this is a good idea for high security systems.

I use Yubikey 4’s as smartcards in most situations and they work anywhere you have available USB slots.

V-77821 - Datagram Congestion Control Protocol (DCCP) kernel module must be disabled

DCCP is often used as a congestion control mechanism for UDP traffic, but it isn’t used that often in modern networks. There have been vulnerabilities in the past that are mitigated by disabling DCCP, so it’s a good idea to disable it unless you have a strong reason for keeping it enabled.

The ansible-hardening role has been updated to disable the DCCP kernel module by default.

V-77823 - Single user mode must require user authentication

Single user mode is often used in emergency situations where the server cannot boot properly or an issue must be repaired without a fully booted server. This mode can only be used at the server’s physical console, serial port, or via out-of-band management (DRAC, iLO, and IPMI). Allowing single-user mode access without authentication is a serious security risk.

Fortunately, every distribution supported by the ansible-hardening role already has authentication requirements for single user mode in place. The ansible-hardening role does not make any adjustments to the single user mode unit file since any untested adjustment could cause a system to have problems booting.

V-77825 - Address space layout randomization (ASLR) must be enabled

ASLR is a handy technology that makes it more difficult for attackers to guess where a particular program is storing data in memory. It’s not perfect, but it certainly raises the difficulty for an attacker. There are multiple settings for this variable and the kernel documentation for sysctl has some brief explanations for each setting (search for randomize_va_space on the page).

Every distribution supported by the ansible-hardening role is already setting kernel.randomize_va_space=2 by default, which applies randomization for the basic parts of process memory (such as shared libraries and the stack) as well as the heap. The ansible-hardening role will ensure that the default setting is maintained.

ansible-hardening is already up to date

If you’re already using the ansible-hardening role’s master branch, these changes are already in place! Try out the new updates and open a bug report if you find any problems.

Apply the STIG to even more operating systems with ansible-hardening

major@mhtx.net (Major Hayden) — Fri, 21 Jul 2017 17:38:46 +0000

Tons of improvements made their way into the ansible-hardening role in preparation for the OpenStack Pike release next month. The role has a new name, new documentation and extra tests.

The role uses the Security Technical Implementation Guide (STIG) produced by the Defense Information Systems Agency (DISA) and applies the guidelines to Linux hosts using Ansible. Every control is configurable via simple Ansible variables and each control is thoroughly documented.

These controls are now applied to an even wider variety of Linux distributions:

CentOS 7
Debian 8 Jessie (new for Pike)
Fedora 25 (new for Pike)
openSUSE Leap 42.2+ (new for Pike)
Red Hat Enterprise Linux 7
SUSE Linux Enterprise 12 (new for Pike)
Ubuntu 14.04 Trusty
Ubuntu 16.04 Xenial

Any patches to the ansible-hardening role are tested against all of these operating systems (except RHEL 7 and SUSE Linux Enterprise). Support for openSUSE testing landed this week.

Work is underway to put the finishing touches on the master branch before the Pike release and we need your help!

If you have any of these operating systems deployed, please test the role on your systems! This is pre-release software, so it’s best to apply it only to a new server. Read the “Getting Started” documentation to get started with ansible-galaxy or git.

Photo credit: Wikipedia

Suse on Major Hayden