Learning AlmaLinux - Security Compliance & Hardening

#Introduction

In the previous episode, Episode 15, we built the encryption foundation with TLS and PKI. Now we go up a level: making sure the system isn't just secure by feeling, but compliant with auditable standards. For organizations handling sensitive data — finance, healthcare, government — this compliance isn't a choice, it's an obligation.

This episode introduces OpenSCAP and security baselines, audit tools, integrity monitoring, and antivirus for certain workloads.

#OpenSCAP and SCAP Profiles

OpenSCAP is a tool ecosystem for automating security compliance based on the SCAP (Security Content Automation Protocol) standard. AlmaLinux provides official security content you can use directly.

sudo dnf5 install -y openscap-scanner scap-security-guide

The scap-security-guide package ships industry-standard security profiles. See the profiles available for AlmaLinux:

oscap info /usr/share/xml/scap/ssg/content/ssg-almalinux9-ds.xml | head -40

The output shows the list of ready-to-use profiles, including CIS and STIG.

#Running a Scan

Run a compliance scan against one profile:

sudo oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis \
  --results-arf /tmp/scan-results.xml \
  /usr/share/xml/scap/ssg/content/ssg-almalinux9-ds.xml

The results are saved in ARF (Asset Reporting Format). For a human-readable report:

oscap xccdf generate report /tmp/scan-results.xml -o /tmp/scan-report.html

#Automatic Remediation

OpenSCAP can fix findings automatically, not just report them:

sudo oscap xccdf eval --remediate \
  --profile xccdf_org.ssgproject.content_profile_cis \
  /usr/share/xml/scap/ssg/content/ssg-almalinux9-ds.xml

#Baselines: CIS Benchmarks and STIG

Two frameworks you'll encounter most often:

The CIS profile in scap-security-guide covers password settings, auditing, SSH, and much more. STIG is stricter and mandatory for systems handling US government data.

#Ansible Playbook: almalinux-hardening

To apply hardening consistently across many servers, use Ansible. The almalinux-hardening playbook is a collection of automation that applies AlmaLinux best practices:

sudo dnf5 install -y ansible-core

Ansible playbooks use variables that can be tuned per environment, and run over SSH — the infrastructure we already secured in episode 14. This "hardening as code" approach makes your security policy reviewable, testable, and reproducible.

#Audit Tool: lynis

lynis is an open-source security audit tool that analyzes the system and gives a score:

sudo dnf5 install -y epel-release
sudo dnf5 install -y lynis
sudo lynis audit system

Lynis checks hundreds of security controls, then shows a score and recommendations. Although it's not a replacement for OpenSCAP in formal compliance, lynis is very useful as a quick check and an educational narrative for finding missed gaps.

#Integrity Monitoring with AIDE

AIDE (Advanced Intrusion Detection Environment) detects changes to important files by building a hash database:

sudo dnf5 install -y aide

Initialize the first database:

sudo aide --init
sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

After that, routine checks compare the current state against the database:

sudo aide --check

#Antivirus: ClamAV

For workloads that need malware scanning — such as mail servers or file sharing — install ClamAV:

sudo dnf5 install -y clamav clamav-update
sudo systemctl enable --now clamd@scan

Update the virus database periodically:

sudo freshclam
clamscan -r /srv/files

ClamAV is optional on pure Linux servers — but important when a server accepts files from external users. Combine it with AIDE: ClamAV detects incoming malware, AIDE detects unauthorized system changes.

#Firewall Baseline

Don't forget the foundation we built in episode 9:

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all

A firewall that only opens necessary services, uses the right zones, and has no rogue ports is the first item on the hardening checklist — and usually also the first item to fail an OpenSCAP scan.

#Common Pitfalls

1. Running --remediate without reading scan results. Remediation can disable services — test in staging first.
2. Assuming one scan is enough. Compliance is an ongoing process; schedule regular scans, not a one-off.
3. Forgetting to move aide.db.new.gz. A database in the wrong location makes aide --check fail with confusing results.
4. Relying on a single tool. Combine OpenSCAP (compliance), lynis (audit), AIDE (integrity), and firewalld (perimeter).
5. Ignoring audit logs. All these tools are useless if findings aren't followed up — build a periodic review loop.

#Conclusion

In this episode 16 you've built a standards-compliant, locked-down system: scanning and remediation with OpenSCAP, understanding the CIS and STIG baselines, hardening automation with Ansible, auditing with lynis, integrity monitoring with AIDE, and ClamAV for certain workloads.

Key takeaways:

• OpenSCAP evaluates the system against CIS and STIG profiles; reports are generated as HTML.
• --remediate fixes findings automatically — test in staging before production.
• Ansible and the almalinux-hardening playbook automate mass hardening.
• lynis provides a quick audit; AIDE detects file changes via a hash database.
• ClamAV scans malware for workloads that accept external files.
• Verify the firewall baseline before closing the checklist.

Compliance is a journey, not a one-time destination. In the next episode, Episode 17, we'll cover Performance Tuning & Resource Management — tuning profiles with tuned-adm, systemd resource limits with cgroups v2, and performance analysis with systemd-analyze. See you there!