IT Monger: Part 3 - Install, STIG, and verify STIG'd Red Hat Enterprise Linux (RHEL) 9.x Server

Part 3 of a 3 part series on how to built a DISA STIG compliant RHEL 9 server.

In this part we will take a look at the individual findings from the DISA STIG based OpenSCAP Evaluation Report we generated in the previous article, and see what needs

to be done to correct the rule violations that were found.

☐ To streamline the iterative process of fixing and re-scanning the system to verify our corrections we will temporarily enable a web server on the RHEL 9.x server we are working on. Follow the commands below in bold.

$ sudo -i

[sudo] password for admin: ************

# yum install httpd
Updating Subscription Management repositories.
Red Hat Enterprise Linux 9 for x86_64 - AppStream (RPMs) 9.7 kB/s | 4.5 kB 00:00
Red Hat Enterprise Linux 9 for x86_64 - BaseOS (RPMs) 12 kB/s | 4.1 kB 00:00
Red Hat CodeReady Linux Builder for RHEL 9 x86_64 (RPMs) 14 kB/s | 4.5 kB 00:00
Dependencies resolved.
====================================================================================================
Package Arch Version Repository Size
====================================================================================================
Installing:
httpd x86_64 2.4.62-13.el9 rhel-9-for-x86_64-appstream-rpms 54 k
Installing dependencies:
apr x86_64 1.7.0-12.el9_3 rhel-9-for-x86_64-appstream-rpms 126 k
apr-util x86_64 1.6.1-23.el9 rhel-9-for-x86_64-appstream-rpms 97 k
apr-util-bdb x86_64 1.6.1-23.el9 rhel-9-for-x86_64-appstream-rpms 14 k
httpd-core x86_64 2.4.62-13.el9 rhel-9-for-x86_64-appstream-rpms 1.5 M
httpd-filesystem noarch 2.4.62-13.el9 rhel-9-for-x86_64-appstream-rpms 18 k
httpd-tools x86_64 2.4.62-13.el9 rhel-9-for-x86_64-appstream-rpms 88 k
redhat-logos-httpd noarch 90.6-1.el9 rhel-9-for-x86_64-appstream-rpms 15 k
Installing weak dependencies:
apr-util-openssl x86_64 1.6.1-23.el9 rhel-9-for-x86_64-appstream-rpms 17 k
mod_http2 x86_64 2.0.26-5.el9 rhel-9-for-x86_64-appstream-rpms 163 k
mod_lua x86_64 2.4.62-13.el9 rhel-9-for-x86_64-appstream-rpms 65 k

Transaction Summary
====================================================================================================
Install 11 Packages

Total download size: 2.2 M
Installed size: 6.0 M
Is this ok [y/N]: y

...

Installed:
apr-1.7.0-12.el9_3.x86_64 apr-util-1.6.1-23.el9.x86_64
apr-util-bdb-1.6.1-23.el9.x86_64 apr-util-openssl-1.6.1-23.el9.x86_64
httpd-2.4.62-13.el9.x86_64 httpd-core-2.4.62-13.el9.x86_64
httpd-filesystem-2.4.62-13.el9.noarch httpd-tools-2.4.62-13.el9.x86_64
mod_http2-2.0.26-5.el9.x86_64 mod_lua-2.4.62-13.el9.x86_64
redhat-logos-httpd-90.6-1.el9.noarch

Complete!

# firewall-cmd --permanent --zone=public --add-service=http
success
# systemctl reload firewalld

# systemctl enable --now httpd
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.

# mkdir /var/www/html/openscap

# ls -l /var/www/html
total 0
drwx------. 2 root root 6 May 25 10:43 openscap

# chmod 755 /var/www/html/openscap

# ls -l /var/www/html
total 0
drwxr-xr-x. 2 root root 6 May 25 10:43 openscap

☐ Re-run the DISA STIG OpenSCAP scan and specify the new web directory in the report output parameter using the commands below in bold.

# oscap xccdf eval --report /var/www/html/openscap/rhel98.html --profile stig /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

☐ Modify the file permissions of the report so it can be viewed via the web server

# chmod 755 /var/www/html/openscap/rhel98.html

☐ Access the DISA STIG web report using a browser and the URL below:

http://192.168.x.x/openscap/rhel98.html (use ifconfig command to find IP)

☐ Note the last time we ran the oscap scan we tried using the '--remediate' option and in the meantime this test system has been rebooted. The report we just generated now has 8 medium (Cat 2) and 2 high (Cat 1) rule violations.

☐ Let's tackle the Cat 1 violations first. Scroll through the most recent OpenSCAP Evaluation Report and look for the two high severity failed rules.

☐ If you click on the red text it will expand to a detailed description of the problem and how to fix it. Here is a simplified solution to fix both of these Cat 1 findings:

☐ Edit the /etc/grub.d/01_users file as follows (csadm means cybersecurity admin):

# vi /etc/grub.d/01_users

#!/bin/sh -e

cat << EOF

if [ -f \${prefix}/user.cfg ]; then

source \${prefix}/user.cfg

if [ -n "\${GRUB2_PASSWORD}" ]; then

set superusers="csadm"

export superusers

password_pbkdf2 root \${GRUB2_PASSWORD}

EOF

:wq

☐ Set the UEFI Boot Loader Password

# grub2-setpassword

Enter password: **********

Confirm password: **********

☐ Generate a new GRUB configuration file

# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Adding boot menu entry for UEFI Firmware Settings ...
done

☐ Reboot the system, log back in and re-run the scan as the root user and view the new report and check to make sure the high (Cat 1) violations were taken care of.

# shutdown -r now

...

$ sudo -i

# oscap xccdf eval --report /var/www/html/openscap/rhel98.html --profile stig /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

SUCCESS! There are NO high (Cat 1) findings.

Now let's start looking at the medium severity violation.

☐ First red highlighted fail we come to is: "Configure SSH Client to Use FIPS 140-2 Validated

MACs: openssh.config" followed by "Configure SSH Server to Use FIPS 140-2 Validated

MACs: opensshserver.config". These are both related to the SSH server service. Click on each

and read through what the rule is looking for.

☐ These first two violations appear to be due to the order that the Message Authentication Codes

(MACs) are listed. So we will ssh into our server, sudo to root, backup and edit both files, comment

out the offending line, and paste in the line from the the OpenSCAP evaluation report into the file.

Make changes highlighted in bold below.

$ sudo -i

# cd /etc/crypto-policies/back-ends

# cp openssh.config openssh.config.orig

# vim openssh.config

...

Ciphers aes256-gcm@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512
GSSAPIKeyExchange no
...

<ESC>

:wq

# cp opensshserver.config opensshserver.config.orig

# vim

Ciphers aes256-gcm@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512
GSSAPIKeyExchange no
...

<ESC>

:wq

☐ Now restart the SSHd service and re-run the scan and examine the new report.

# systemctl restart sshd.service

☐ Re-run the oscap scan and examine the results.

# oscap xccdf eval --report /var/www/html/openscap/rhel98.html --profile stig /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

☐ The next red highlighted fail we come to is: "Configure Logind to terminate idle sessions after

certain time of inactivity". Click on the entry and read through what the rule is looking for.

☐ To fix the issue, we will backup and modify the logind.conf file as shown below.

# cd /etc/systemd

# cp logind.conf logind.conf.orig

# vim logind.conf (Modify the StopIdleSessionSec line to look like below)

StopIdleSessionSec=600

<ESC>

:wq

☐ Re-run the oscap scan and examine the results.

# oscap xccdf eval --report /var/www/html/openscap/rhel98.html --profile stig /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

AND THERE IS A BUG IN THE TEST CRITERIA

The test criteria is looking for logind.conf inside a directory named /etc/systemd/logind.conf.d. That directory does not exist and the logind.conf file is in the /etc/systemd directory.

☐ We will create a symbolic link to the file we just corrected in the location where

OpenSCAP is looking for it, and re-run the scan.

# cd /etc/systemd

# mkdir logind.conf.d

# ln -s /etc/systemd/logind.conf /etc/systemd/logind.conf.d/logind.conf

☐ Re-run the oscap scan and examine the results.

# oscap xccdf eval --report /var/www/html/openscap/rhel98.html --profile stig /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

☐ The next red highlighted fail we come to is: "Only Authorized Local User Accounts Exist

on Operating System". Click on the entry and read through what the rule is looking for.

☐ We can modify the test criteria inside the ssg-rhel9-ds.xml file to allow our admin

user and the other default accounts that were created during the install. On our test

system we will add the following as authorized accounts: fapolicyd, postfix,

your admin user, apache, and unbound.

# cd /usr/share/xml/scap/ssg/content

# cp ssg-rhel9-ds.xml ssg-rhel9-ds.xml.orig

# vim ssg-rhel9-ds.xml

/libstoragemgmt (search for the first approved user account in the test criteria)

n (use 'n' to jump to the next instance and find the one under 'selector="rhel9"')

(look for the end of the line "|tcpdump|admin)" and add the additional accounts

after the "admin" user separated by "|" symbol)

<ESC>

:wq

☐ Re-run the oscap scan and examine the results.

# oscap xccdf eval --report /var/www/html/openscap/rhel98.html --profile stig /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

☐ The next red highlighted fail we come to is: "Configure Multiple DNS Servers in

/etc/resolve.conf". Click on the entry and read through what the rule is looking for.

☐ In a production environment these should be internal DNS server entries, for our test system

we can just add google's DNS server (8.8.8.8) or Cloud flare's (1.1.1.1) using the Network Manager

Command Line Interface (nmcli).

# nmcli connection show --active

NAME UUID TYPE DEVICE
enp1s0 d5a2ae35-dd87-35f4-a340-af32cf78bdf1 ethernet enp1s0
lo 58a4c38b-d1ea-4747-9708-c88633ecad84 loopback lo

# nmcli connection show enp1s0|grep -i ip4.dns
IP4.DNS[1]: 192.168.122.1
# nmcli connection modify enp1s0 +ipv4.dns "8.8.8.8"

# nmcli connection up enp1s0
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3)
# nmcli connection show enp1s0|grep -i ip4.dns
IP4.DNS[1]: 8.8.8.8
IP4.DNS[2]: 192.168.122.1

☐ Re-run the oscap scan and examine the results.

# oscap xccdf eval --report /var/www/html/openscap/rhel98.html --profile stig /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

☐ Next is "Disable the use of user namespaces", click on the entry and read through

what the rule is looking for.

☐ To see what the current user.max_user_namespaces value is (if you are curious).

# sysctl -a|grep user.max_user_name
user.max_user_namespaces = 14361

☐ Set the current runtime value for user.max_user_namespaces to 0.

# sysctl -w user.max_user_namespaces=0

☐ Make this setting persistent.

# vim /etc/sysctl.d/max_user_namespaces.conf

user.max_user_namespaces = 0

<ESC>

:wq

☐ Re-run the oscap scan and examine the results.

# oscap xccdf eval --report /var/www/html/openscap/rhel98.html --profile stig /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

☐ Next is "Elivate The SELinux Context When An Administrator Calls The Sudo Command", click on the entry and read through what the rule is looking for.

# cd /etc/sudoers.d

# visudo -f selinux.conf
%wheel ALL=(ALL) TYPE=sysadm_t ROLE=sysadm_r ALL

<ESC>
:wq

# chmod 755 selinux.conf
(note this can break your ability to sudo if it is wrong, and you will need to login as root from the console and delete the file and start over, ask me how I know)

☐ Re-run the oscap scan and examine the results.

# oscap xccdf eval --report /var/www/html/openscap/rhel98.html --profile stig /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

☐ The last one is "Enable Certmap in SSSD", click on the entry and read through what the rule is looking for.

☐ Backup the /etc/sssd/sssd.conf file and edit it as highlighted below.

# cd /etc/sssd

# cp sssd.conf sssd.conf.orig

# vim sssd.conf

[pam]
pam_cert_auth=True

[certmap/testing.test/rule_name]
matchrule =<SAN>.*EDIPI@mil
maprule = (userCertificate;binary={cert!bin})
domains = testing.test

<ESC>

:wq

(The above settings should be tailored for your specific production environment. How

to figure out what that looks like is beyond the scope of this series of articles)

☐ Re-run the oscap scan and examine the results.

# oscap xccdf eval --report /var/www/html/openscap/rhel98.html --profile stig /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

SUCCESS! There are NO medium (Cat 2) findings.

☐ READ ALL of the notchecked elements in the report, these are security best practices kinds

of things you should know.

☐ Shutdown your virtual test server.

# shutdown -h now

END.

IT Monger

Monday, May 25, 2026

Part 3 - Install, STIG, and verify STIG'd Red Hat Enterprise Linux (RHEL) 9.x Server

Now let's start looking at the medium severity violation.

No comments:

Post a Comment