AlmaLinux 9 STIG

Option A: Azure Portal

• Open the Azure Marketplace and search for "AlmaLinux 9 STIG-Hardened SecureAnyCloud".
• Select the image and click Create.
• On the basics page, set Subscription to your Azure subscription and Resource Group to a new or existing group.
• Enter a name under Virtual Machine Name and choose your preferred Region.
• Set Size to Standard_B2s (recommended).
• Under Administrator Account, select SSH public key and enter your key.
• Under Inbound Port Rules, allow SSH (port 22).
• Click Review + Create, then Create.

Option B: Azure CLI

az vm image terms accept --urn sac1647283583153:almalinux-9-stig:default:latest
az vm create \
  --resource-group myResourceGroup \
  --name my-almalinux-9-stig-vm \
  --image sac1647283583153:almalinux-9-stig:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Run these commands on your own workstation, not on the VM. Find the public IP, then connect:

az vm show --resource-group myResourceGroup --name my-almalinux-9-stig-vm --show-details --query publicIps -o tsv ssh azureuser@<vm-ip>

There is no password to enter. If SSH asks you for one, the key you supplied at create time is not the key your client is offering.

The STIG's sshd hardening tightens the ciphers, MACs and session timeouts shown below. The SSH connection model is the same as every other SecureAnyCloud image: key only, injected by Azure at first boot.

The raw DISA STIG profile includes a rule that removes the NOPASSWD tag from every sudoers entry, so that sudo always demands re-authentication. This build deliberately excludes that rule, and its two closest siblings, from automated remediation. Here is why.

This image, like every SecureAnyCloud image, has no password on any account. Access is entirely by SSH key. If the NOPASSWD-removal rule had been applied, sudo would have demanded a password that does not exist, on the very account Azure creates for you. That would permanently lock you out of root with no recovery path, not even a console password.

That is not "requiring re-authentication". It is removing administrative access outright, so the rule is excluded.

Confirm it for yourself:

sudo -n true && echo "sudo works, no password prompt" grep -A1 'User rules for azureuser' /etc/sudoers.d/90-cloud-init-users

Expected output:

sudo works, no password prompt
# User rules for azureuser azureuser ALL=(ALL) NOPASSWD:ALL

The full list of excluded rules, and the reasoning for each, ships on the image:

cat /usr/share/sac/stig/skip-rules.txt

Expected output:

xccdf_org.ssgproject.content_rule_aide_use_fips_hashes xccdf_org.ssgproject.content_rule_disallow_bypass_password_sudo xccdf_org.ssgproject.content_rule_fips_crypto_subpolicy xccdf_org.ssgproject.content_rule_fips_custom_stig_sub_policy xccdf_org.ssgproject.content_rule_grub2_password xccdf_org.ssgproject.content_rule_sudo_remove_no_authenticate xccdf_org.ssgproject.content_rule_sudo_remove_nopasswd xccdf_org.ssgproject.content_rule_sysctl_crypto_fips_enabled

There are three exclusion groups, eight rules in total. Each is explained here:

Rule group Why it is excluded

sudo_remove_nopasswd, sudo_remove_no_authenticate, disallow_bypass_password_sudo Would strip passwordless sudo from your SSH-key-authenticated account, as above. There is no password anywhere on this image to re-authenticate with.

grub2_password The upstream remediation script for this rule reads a boot loader password interactively from a terminal. Run non-interactively during an automated build, it would hang the build indefinitely rather than fail cleanly. It has no effect on normal boot either way: GRUB password protection guards editing boot entries at the console, not booting the default one. Set it yourself with grub2-setpassword if you want that protection (see Step 7).

fips_crypto_subpolicy, fips_custom_stig_sub_policy, sysctl_crypto_fips_enabled, aide_use_fips_hashes Full FIPS 140 mode. Enabling it correctly needs fips-mode-setup --enable, a dracut -f initramfs rebuild and a further reboot to prove that it boots that way. This build does not perform that cycle, so FIPS is not enabled on this image.

The build-time compliance report ships on the image. It is generated after a reboot, so it reflects a real running boot, not a snapshot taken mid-build:

cat /var/log/sac/stig/build-remediation-score.txt ls -la /var/log/sac/stig/ oscap info --profiles /usr/share/xml/scap/ssg/content/ssg-almalinux9-ds.xml | grep stig

Expected output. The exact score varies from build to build as the upstream STIG content and the base image evolve. This is the measurement from this build, not a fixed target:

94.4 build-remediation-report.html build-remediation-results.xml build-remediation-score.txt xccdf_org.ssgproject.content_profile_stig:DISA STIG for AlmaLinux OS 9

Copy the HTML report to your workstation to read it properly:

echo "from your workstation: scp azureuser@<vm-ip>:/var/log/sac/stig/build-remediation-report.html ."

This profile is AlmaLinux-native, not a RHEL 9 substitute. AlmaLinux's own scap-security-guide package ships ssg-almalinux9-ds.xml with a DISA STIG for AlmaLinux OS 9 profile built in. The image resolves and probes that datastream directly. It does not assume a particular filename or fall back to a different distribution's content.

What the remaining gap is made of. This build measures in the mid-90s percent, out of 428 evaluated rules. Every rule that does not pass falls into one of these buckets:

Bucket Example rules Why it does not pass

Single-disk architecture partition_for_tmp, partition_for_var, partition_for_var_log, partition_for_var_log_audit, partition_for_var_tmp, partition_for_home These require /tmp, /var, /var/log, /var/log/audit, /var/tmp and /home on their own separate partitions. This is a single OS disk cloud image; there is nowhere for a second partition to live. These rules are not applicable to this image, and they are not defects.

The three excluded rule groups from Step 3, plus their crypto-policy cascades grub2_admin_username, selinux_context_elevation_for_sudo, configure_crypto_policy, harden_sshd_ciphers_openssh_conf_crypto_policy, harden_sshd_ciphers_opensshserver_conf_crypto_policy, harden_sshd_macs_openssh_conf_crypto_policy, harden_sshd_macs_opensshserver_conf_crypto_policy Deliberately excluded (grub2/sudo), or tied to the deferred FIPS crypto sub-policy. The system-wide crypto policy reaches its strictest FIPS-aligned state only once FIPS mode itself is enabled, which this build does not do (see Step 3).

The zero-password, key-only design require_singleuser_auth, accounts_password_all_shadowed_sha512 Rescue/single-user mode authentication and password-hash checks both assume an account has a password. No account on this image has one, because access is by SSH key only, by design.

Environment specific, no automated fix, or a package this image does not carry network_configure_name_resolution, chronyd_configure_local_socket, accounts_authorized_local_users, sysctl_user_max_user_namespaces_no_remediation, package_cron_installed, postfix_prevent_unrestricted_relay, sssd_enable_certmap, sssd_enable_smartcards, configure_usbguard_auditbackend These need a site-specific answer (your own DNS servers, your own authorized-user list), SSG itself ships no automated fix and expects manual review, or the rule hardens a package (cron, postfix, usbguard, domain-joined sssd) that is not installed on this lean base image at all.

Read the HTML report for the full rule-by-rule detail.

cat /etc/almalinux-release grep -E '^(NAME|VERSION|ID|PLATFORM_ID)=' /etc/os-release uname -rm sudo dnf check-update; echo "check-update exit code: $?"
sudo dnf needs-restarting -r; echo "needs-restarting exit code: $?"

Expected output:

AlmaLinux release 9.8 (Olive Jaguar) NAME="AlmaLinux" VERSION="9.8 (Olive Jaguar)" ID="almalinux" PLATFORM_ID="platform:el9" 5.14.0-687.36.1.el9_8.x86_64 x86_64 check-update exit code: 0 needs-restarting exit code: 0

dnf check-update returns exit code 100 when updates are pending and 0 when none are. needs-restarting -r returns 0 when nothing requires a restart.

systemctl is-enabled dnf-automatic.timer
systemctl is-active dnf-automatic.timer grep -E '^(upgrade_type|download_updates|apply_updates)' /etc/dnf/automatic.conf

Expected output:

enabled active upgrade_type = default download_updates = yes apply_updates = yes

upgrade_type is deliberately default rather than security. The security-only mode resolves against errata metadata. Where that metadata is not published, a security-only policy silently resolves to nothing and applies no updates at all. default applies every available update, so it cannot quietly do nothing.

Confirm SELinux, the root account, the SSH ciphers and the boot loader kernel arguments that the STIG requires:

getenforce grep -E '^[[:space:]]*SELINUX=' /etc/selinux/config
sudo passwd -S root
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|maxauthtries|clientaliveinterval)' grep -o 'init_on_free=1\|pti=on\|vsyscall=none\|page_poison=1\|audit=1\|audit_backlog_limit=[0-9]*' /proc/cmdline

Expected output:

Enforcing SELINUX=enforcing root LK 2009-12-22 -1 -1 -1 -1 (Alternate authentication scheme in use.) permitrootlogin no passwordauthentication no kbdinteractiveauthentication no maxauthtries 6 clientaliveinterval 600 init_on_free=1 pti=on vsyscall=none page_poison=1 audit=1 audit_backlog_limit=8192

Every one of these kernel arguments is also written into /etc/default/grub, not only applied to the current boot entry. They carry forward the next time a kernel update installs a new boot entry:

grep CMDLINE_LINUX /etc/default/grub

To add password protection for editing the GRUB boot menu, use the block below. Step 3 explains why this build does not set one automatically:

sudo grub2-setpassword
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Do not run that block blindly. It sets an interactive password, so review it first.

STIG hardening must not break the cloud-init and Azure agent paths that provision your VM. Confirm that they still work:

systemctl is-active waagent
systemctl is-enabled waagent cloud-init --version cloud-init status --long df -h / free -h

free -h reports 0B of swap, deliberately. Azure manages swap on the ephemeral resource disk through waagent rather than on the OS disk, and a swap file baked into a Marketplace image fails certification.

Unlike the plain AlmaLinux 9 image, STIG remediation installs and enables firewalld. Confirm what it allows before you rely on it:

firewall-cmd --state firewall-cmd --get-default-zone firewall-cmd --list-services ss -tlnu

Expected output:

running public cockpit dhcpv6-client ssh Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* tcp LISTEN 0 128 [::]:22 [::]:*

ssh is explicitly permitted in the default zone. The build asserts this every time rather than assuming it, because a default-deny firewall that did not keep SSH open would lock out every customer, as the sudo rule in Step 3 would have.

cockpit and dhcpv6-client are the stock public zone's other pre-authorised services. Neither is installed or listening, so they grant nothing extra.

The Azure Network Security Group is still the first boundary your traffic crosses. With firewalld also active, a port must be open in both the NSG and firewalld before traffic reaches your service. For example:

sudo firewall-cmd --permanent --add-port=443/tcp sudo firewall-cmd --reload

rpcbind is disabled on this image, exactly as on the plain AlmaLinux 9 build. NFSv4, the default in AlmaLinux 9, does not need it. If you specifically need NFSv3, re-enable it with sudo systemctl enable --now rpcbind.socket.

The STIG's package_nfs-utils_removed rule also removes the nfs-utils package outright to reduce attack surface. If you need any NFS client capability, install it again with sudo dnf install -y nfs-utils.

The scanner and policy content ship on the image, so you never depend on SecureAnyCloud's own report. Check what is installed:

oscap ds sds-validate /usr/share/xml/scap/ssg/content/ssg-almalinux9-ds.xml && echo "datastream valid" systemctl list-timers stig-verify.timer --no-legend test -f /var/lib/sac/data/stig-firstboot.done && echo "firstboot completed: $(stat -c %y /var/lib/sac/data/stig-firstboot.done)"

stig-verify.timer runs an audit-only re-scan of your own instance a few minutes after every boot, and weekly after that. It writes a fresh report to /var/log/sac/stig/verify-report.html, verify-results.xml and verify-score.txt. It never remediates, so a scheduled job never silently changes your running configuration.

To run a full scan by hand at any time:

sudo oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_stig \
  --results /tmp/my-scan-results.xml --report /tmp/my-scan-report.html \
  /usr/share/xml/scap/ssg/content/ssg-almalinux9-ds.xml echo "exit code: $? (0 = every rule passed, 2 = some rules failed -- normal, 1 = a genuine scanner error)"

The upstream bash and Ansible remediation content for every profile ships alongside the scanner. Remediation is never automatic, so you can review it and apply further hardening deliberately:

ls /usr/share/xml/scap/ssg/content/*.xml | head -3

Generating and applying additional fixes can be destructive, so review them first. They can disable services, tighten sshd further, or change mount options. The block below is a reference, not something to paste and run:

sudo oscap xccdf generate fix --profile xccdf_org.ssgproject.content_profile_stig \
  --fix-type bash /usr/share/xml/scap/ssg/content/ssg-almalinux9-ds.xml > /tmp/my-fixes.sh less /tmp/my-fixes.sh
# review every line before running anything

Option A: AWS Marketplace console

• Open the SecureAnyCloud AlmaLinux listing on AWS Marketplace. Choose View purchase options, then Subscribe. One subscription covers every version in the listing.
• When the subscription is active, choose Launch your software.
• Choose One-click launch from AWS Marketplace, or Launch from EC2 Console for full control. In Version, choose AlmaLinux 9 STIG - YYYY-MM-DD (the date is when the version was added), then choose your Region.
• Instance type: m5.large is recommended, and any current x86_64 type works. The software charge is $0.04 per vCPU per hour.
• Key pair: choose your EC2 key pair. It is the only way in. RSA and ED25519 keys both work (FIPS mode is not enabled, see Step 4).
• Security group: allow inbound TCP 22 from your own IP address or network only.
• Storage: the root volume is 10 GiB gp3 by default. Choose a larger size if you need one, and cloud-init grows the root partition and filesystem to fill it on first boot. If your policy requires encryption at rest, set encryption on the volume here (see encrypt_partitions in Step 15).
• Metadata: leave the defaults, because the image already requires IMDSv2. Then choose Launch.

Option B: AWS CLI

Run this on your workstation. Replace the AMI ID with the one shown for your Region on the Marketplace launch page. Replace the key pair, security group and subnet with your own. The root device of this AMI is /dev/sda1:

aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type m5.large \
  --key-name my-key-pair \
  --security-group-ids sg-0123456789abcdef0 \
  --subnet-id subnet-0123456789abcdef0 \
  --block-device-mappings 'DeviceName=/dev/sda1,Ebs={VolumeSize=20,VolumeType=gp3,Encrypted=true}' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=almalinux-9-stig}]'

You do not need --metadata-options, because the AMI already makes IMDSv2 required.

From your workstation, connect as ec2-user with the key pair you chose. Run:

ssh -i ~/.ssh/my-key-pair.pem ec2-user@<public-ip>

Before the login completes, SSH prints the Standard Mandatory DoD Notice and Consent Banner that the STIG requires. Step 11 shows how to replace it with your own organisation's notice. There is no password to enter. If SSH asks for one, or says Too many authentication failures, see Troubleshooting below.

You can also connect without opening port 22 through AWS Systems Manager Session Manager, if the instance has an instance profile that allows Systems Manager. The agent is installed and running on this image.

cat /etc/almalinux-release grep -E '^(NAME|VERSION|ID|VERSION_ID|PLATFORM_ID|PRETTY_NAME)=' /etc/os-release uname -srm head -3 /etc/issue

Expected output:

AlmaLinux release 9.8 (Olive Jaguar) NAME="AlmaLinux" VERSION="9.8 (Olive Jaguar)" ID="almalinux" VERSION_ID="9.8" PLATFORM_ID="platform:el9" PRETTY_NAME="AlmaLinux 9.8 (Olive Jaguar)" Linux 5.14.0-687.59.1.el9_8.x86_64 x86_64 You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions:

This version follows AlmaLinux 9. It receives every AlmaLinux 9 minor release (9.8 at build time) through normal dnf updates. Your kernel version may be newer if updates have installed since this image was built.

The evaluation the build ran after its reboot ships on the image:

ls -lh /usr/share/doc/sac/ python3 -c "import json; s=json.load(open('/usr/share/doc/sac/stig-summary.json')); print('profile: ', s['profileLabel'], '(SCAP Security Guide', s['ssgVersion'] + ')'); print('scored rules: ', s['scored'], ' pass:', s['pass'], ' fail:', s['fail'], ' errors:', s['error'], ' rate:', str(s['ratePct']) + '%'); print('waived: ', s['waived'], ' not applicable:', s['notapplicable'], ' not checked:', s['notchecked']); print('evaluated at: ', s['evaluatedAt'])"

Expected output:

total 42M -rw-r--r--. 1 root root 1.6K Oct 20 01:53 scap-security-guide-LICENSE.txt -rw-r--r--. 1 root root 37M Oct 20 01:59 stig-arf.xml -rw-r--r--. 1 root root 4.5M Oct 20 01:59 stig-report.html -rw-r--r--. 1 root root 1.7K Oct 20 01:59 stig-summary.json -rw-r--r--. 1 root root 4.1K Oct 20 01:59 stig-tailoring.xml -rw-r--r--. 1 root root 7.7K Oct 20 01:59 stig-waivers.txt profile: DISA STIG (SCAP Security Guide 0.1.82) scored rules: 404 pass: 392 fail: 12 errors: 0 rate: 97.0% waived: 24 not applicable: 39 not checked: 10 evaluated at: 2026-10-20T01:59:47Z

• stig-report.html is the full OpenSCAP report, rule by rule. Copy it to your workstation and open it in a browser.
• stig-arf.xml is the same evaluation in the machine-readable ARF format, for compliance tooling and for your own assessment records.
• stig-tailoring.xml is the exact tailoring used, so you can re-run the same evaluation (Step 5).
• The pass rate is pass / (pass + fail + error + unknown). Rules that are not applicable to this machine, not selected, waived, or that need a manual check (not checked) are not counted.

To copy the report to your workstation, run this on the workstation:

scp -i ~/.ssh/my-key-pair.pem ec2-user@<public-ip>:/usr/share/doc/sac/stig-report.html .

The 24 waived rules

grep -v '^#' /usr/share/doc/sac/stig-waivers.txt | cut -f1,2

Expected output:

sudo_remove_nopasswd [default-user-sudo] disallow_bypass_password_sudo [default-user-sudo] partition_for_tmp [single-volume-partitions] partition_for_home [single-volume-partitions] partition_for_var [single-volume-partitions] partition_for_var_log [single-volume-partitions] partition_for_var_log_audit [single-volume-partitions] partition_for_var_tmp [single-volume-partitions] grub2_password [serial-console-and-boot] accounts_maximum_age_login_defs [key-only-account-aging] account_disable_post_pw_expiration [key-only-account-aging] auditd_data_disk_full_action_stig [audit-sizing-8gb] auditd_data_disk_error_action_stig [audit-sizing-8gb] auditd_data_retention_admin_space_left_action [audit-sizing-8gb] auditd_data_retention_max_log_file_action_stig [audit-sizing-8gb] sysctl_crypto_fips_enabled [fips] fips_crypto_subpolicy [fips] fips_custom_stig_sub_policy [fips] configure_crypto_policy [fips] install_smartcard_packages [smartcard] package_opensc_installed [smartcard] sssd_enable_smartcards [smartcard] configure_opensc_card_drivers [smartcard] rsyslog_remote_loghost [syslog-remote-destination]

The full reason for each is the third column of the same file. In short:

• Passwordless sudo for ec2-user (default-user-sudo): ec2-user has no password, and cloud-init gives it password-free sudo. Removing NOPASSWD, or refusing it, would leave the only administrator unable to use sudo at all. Step 11 shows how to require a password for sudo safely once you have set one.
• Separate partitions (single-volume-partitions): this version boots from one EBS root volume, so /tmp, /var, /var/log, /var/log/audit, /var/tmp and /home live on the root filesystem. The LVM versions of this listing provide each of them as a separate volume.
• Boot loader password (serial-console-and-boot): a GRUB password would have to be baked into the image, giving every instance the same secret. Set your own if you need one (Step 15).
• Password ageing defaults (key-only-account-aging): the accounts cloud-init creates are key-only. A default ageing limit would expire them and lock the SSH key out, so PASS_MAX_DAYS stays unlimited. To set an age on accounts you give a password, run sudo chage -M 60 <user>.
• Halt or single-user mode on audit storage problems (audit-sizing-8gb): on a single small root volume the audit log shares the disk with the operating system, so halting when the disk fills would take the whole instance down. auditd rotates its log at 8 MB, keeps five files, mails root when space runs low and suspends logging if the disk fills (Step 11). If you need the STIG's actions, put /var/log/audit on its own volume or use an LVM version.
• FIPS mode (fips): FIPS mode is a separate, validated-module claim. It needs the FIPS kernel setting and a reboot to be real, and the FIPS crypto policy refuses the ED25519 SSH keys that EC2 key pairs may use. FIPS mode is not enabled or claimed, and the system crypto policy is DEFAULT. Step 15 shows how to enable FIPS mode on your own instance if your authorisation needs it.
• Smart cards (smartcard): EC2 instances have no smart-card readers, so the smart-card (CAC/PIV) packages and PAM settings would only add a login path nobody can use.
• Remote syslog server (syslog-remote-destination): the STIG forwards every syslog message to a remote log server, and the content fills in a stand-in host name (logcollector). An image cannot know your log server. That stand-in name would send every log message, authentication records included, to whichever host answers to that name in your network. rsyslog logs locally only. Step 11 shows how to forward to your own collector.

The 12 rules that do not pass

python3 -c "import json; [print(r) for r in json.load(open('/usr/share/doc/sac/stig-summary.json'))['failingRules']]"

Expected output:

accounts_authorized_local_users chronyd_configure_local_socket grub2_admin_username harden_sshd_ciphers_openssh_conf_crypto_policy harden_sshd_ciphers_opensshserver_conf_crypto_policy harden_sshd_macs_openssh_conf_crypto_policy harden_sshd_macs_opensshserver_conf_crypto_policy network_configure_name_resolution require_singleuser_auth selinux_context_elevation_for_sudo sssd_enable_certmap sysctl_user_max_user_namespaces_no_remediation

None of these is hidden or remediated away. What each one means on this image:

• accounts_authorized_local_users: the STIG wants every local account to be on a list your organisation approves. The list is yours to define, so SCAP Security Guide ships no automatic fix. The image has AlmaLinux's system accounts and ec2-user.
• chronyd_configure_local_socket: the STIG closes chrony's network command port (cmdport 0) and then wants chrony-wait.service rewritten to use chrony's local socket. That service is not enabled on this image, and SCAP Security Guide ships no automatic fix for it. Time sync itself is unaffected (Step 10).
• grub2_admin_username: this renames the GRUB superuser, which only has an effect together with a GRUB password, and the GRUB password is waived (above). Set both together if you need them (Step 15).
• harden_sshd_ciphers_openssh_conf_crypto_policy, harden_sshd_ciphers_opensshserver_conf_crypto_policy, harden_sshd_macs_openssh_conf_crypto_policy, harden_sshd_macs_opensshserver_conf_crypto_policy: these four want the SSH client and server limited to the FIPS 140 cipher and MAC lists in the system crypto policy files. They belong with FIPS mode, which is not enabled (above), and SCAP Security Guide ships no shell fix for them. SSH uses the AlmaLinux DEFAULT crypto policy: AES-GCM, ChaCha20-Poly1305 and AES-CTR ciphers with SHA-2 (and SHA-1) MACs (Step 11).
• network_configure_name_resolution: the STIG wants at least two DNS servers in /etc/resolv.conf. An EC2 instance gets one, the Amazon-provided resolver of its VPC, which is itself redundant. If you run your own resolvers, configure them in the VPC's DHCP options set.
• require_singleuser_auth: the check looks for an exact ExecStart line in a drop-in for rescue.service. In SCAP Security Guide 0.1.82 the automatic fix for this rule has a quoting fault and writes an empty drop-in, so the rule stays failed. The rescue target still runs systemd-sulogin-shell, which asks for the root password, and root is locked.
• selinux_context_elevation_for_sudo: the STIG wants sudo to switch administrators into the sysadm_r SELinux role. That needs administrators mapped to the staff_u SELinux user, which is a site decision. Done to ec2-user on an image, it could break sudo for the only administrator. SCAP Security Guide ships no automatic fix.
• sssd_enable_certmap: smart-card certificate mapping for SSSD against a directory. Smart cards are waived (above), and the mapping is specific to your directory and certificate authority.
• sysctl_user_max_user_namespaces_no_remediation: the STIG wants user namespaces off (user.max_user_namespaces = 0). Rootless containers, Podman and some browsers and build tools need them, so SCAP Security Guide deliberately ships no fix. Set it yourself if nothing on your instance needs them (Step 15).

You can repeat the evaluation at any time with the same content and tailoring. It takes about a minute. Run:

sudo oscap xccdf eval \
  --tailoring-file /usr/share/doc/sac/stig-tailoring.xml \
  --profile xccdf_co.sac_profile_stig_ec2_single \
  --results /tmp/stig-check-results.xml --report /tmp/stig-check-report.html \
  /usr/share/xml/scap/ssg/content/ssg-almalinux9-ds.xml > /tmp/stig-check.log 2>&1 echo "oscap exit code: $? (2 = at least one rule did not pass)"
sudo python3 -c "import re,collections; c=collections.Counter(re.findall(r'<result>(\w+)</result>', open('/tmp/stig-check-results.xml').read())); s=sum(c[k] for k in ('pass','fail','error','unknown')); print(dict(sorted(c.items()))); print('pass rate: %.1f%%' % (100.0*c['pass']/s))"

Expected output on a freshly launched instance:

oscap exit code: 2 (2 = at least one rule did not pass) {'fail': 12, 'notapplicable': 39, 'notchecked': 10, 'notselected': 1087, 'pass': 392} pass rate: 97.0%

Your own report is at /tmp/stig-check-report.html. As you install software and change settings, re-run the evaluation to see how your changes affect the result.

To evaluate against the complete, untailored DISA STIG profile (the waived rules included), run the same command with --profile xccdf_org.ssgproject.content_profile_stig and without --tailoring-file.

The STIG requires a deny-by-default application control policy. On this image it is enforced by fapolicyd: every time a program is executed, or a script in a language such as Python or Perl is opened, fapolicyd checks the file against its trust database. Files installed by RPM packages (the AlmaLinux repositories, and anything else you install with dnf) are trusted automatically. An executable that arrived any other way, such as a copied, downloaded or compiled binary, is refused, even for root.

systemctl is-active fapolicyd
sudo grep -E '^(permissive|trust|integrity) ' /etc/fapolicyd/fapolicyd.conf
sudo grep -v '^#' /etc/fapolicyd/rules.d/90-deny-execute.rules /etc/fapolicyd/rules.d/95-allow-open.rules /etc/fapolicyd/rules.d/99-deny-everything.rules | grep -v ':$' cp /usr/bin/date /tmp/my-date /tmp/my-date || echo "exit code $?: fapolicyd refused to run /tmp/my-date (an untrusted copy)" rm -f /tmp/my-date

Expected output:

active trust = rpmdb,file integrity = none permissive = 0 /etc/fapolicyd/rules.d/90-deny-execute.rules:deny_audit perm=execute all : all /etc/fapolicyd/rules.d/95-allow-open.rules:allow perm=open all : all /etc/fapolicyd/rules.d/99-deny-everything.rules:deny perm=any all : all bash: line 5: /tmp/my-date: Operation not permitted exit code 126: fapolicyd refused to run /tmp/my-date (an untrusted copy)

• permissive = 0 means fapolicyd enforces its rules. With 1 it would only log what it would have denied.
• trust = rpmdb,file: a file is trusted if the RPM database lists it, or if it is in a trust file under /etc/fapolicyd/trust.d/.
• The copy of /usr/bin/date is byte-for-byte the same program, but it is not where an RPM put it, so it is refused.
• The STIG adds 99-deny-everything.rules as the last rule, so anything the earlier AlmaLinux rules do not explicitly allow is denied. AlmaLinux's 72-shell.rules allows shell scripts, so cloud-init user data and Systems Manager Run Command scripts work as usual.

Running your own software. Install it from an RPM package where you can, because dnf updates the trust database for you. For software that arrives another way (a release tarball, a binary you build, an application under /opt), add it to a trust file and reload the trust database before you first run it:

sudo fapolicyd-cli --file add /opt/myapp/ --trust-file myapp
sudo fapolicyd-cli --update

If a program was already refused once, fapolicyd may still hold that decision. sudo systemctl restart fapolicyd clears it. After an upgrade of that software, run sudo fapolicyd-cli --file update /opt/myapp/ --trust-file myapp and sudo fapolicyd-cli --update again.

Denials are logged in the audit log (sudo ausearch -m FANOTIFY -ts recent).

systemctl is-active usbguard
sudo cat /etc/usbguard/rules.conf
sudo grep -E '^(ImplicitPolicyTarget|PresentDevicePolicy|AuditBackend)=' /etc/usbguard/usbguard-daemon.conf grep -rh usb-storage /etc/modprobe.d/
sudo sysctl kernel.kexec_load_disabled kernel.yama.ptrace_scope kernel.unprivileged_bpf_disabled kernel.dmesg_restrict kernel.kptr_restrict net.core.bpf_jit_harden grep -oE '(audit|audit_backlog_limit|init_on_free|page_poison|pti|vsyscall)=[^ ]*' /proc/cmdline

Expected output:

active
# No USB devices found ImplicitPolicyTarget=block PresentDevicePolicy=apply-policy AuditBackend=LinuxAudit install usb-storage /bin/false kernel.kexec_load_disabled = 1 kernel.yama.ptrace_scope = 1 kernel.unprivileged_bpf_disabled = 1 kernel.dmesg_restrict = 1 kernel.kptr_restrict = 1 net.core.bpf_jit_harden = 2 init_on_free=1 pti=on vsyscall=none page_poison=1 audit=1 audit_backlog_limit=8192

• USBGuard runs with a policy generated from the devices present at build time. An EC2 instance has no USB bus, so the policy is empty and any USB device that ever appeared would be blocked (ImplicitPolicyTarget=block). The usb-storage kernel module cannot be loaded at all.
• Kernel settings: kexec cannot load a new kernel at run time (so kdump is not available). Only a parent process can ptrace its children, unprivileged users cannot load BPF programs, and kernel addresses and the kernel log are hidden from unprivileged users.
• Boot options: memory is wiped when freed (init_on_free, page_poison), kernel page-table isolation is on, the legacy vsyscall page is off, and auditing starts at boot with a large backlog. Other kernel modules the STIG names (Bluetooth, FireWire, ATM, CAN, SCTP, TIPC, cramfs) are disabled the same way as USB storage.

curl -s -o /dev/null -w 'IMDSv1 request without a token: HTTP %{http_code}\n' http://169.254.169.254/latest/meta-data/instance-id
TOKEN=$(curl -s -X PUT -H 'X-aws-ec2-metadata-token-ttl-seconds: 60' http://169.254.169.254/latest/api/token)
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" -w '\n' http://169.254.169.254/latest/meta-data/placement/region

Expected output (your Region may differ):

IMDSv1 request without a token: HTTP 401 us-east-1

A request without a session token is refused with HTTP 401, and the same request with a token works. Scripts and SDKs on the instance must use IMDSv2. Every current AWS SDK and the AWS CLI do this automatically.

sudo firewall-cmd --state sudo firewall-cmd --list-all sudo ss -tlnp

Expected output:

running public (active) target: default icmp-block-inversion: no interfaces: eth0 sources: services: dhcpv6-client ssh ports: protocols: forward: yes masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=866,fd=7)) LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=866,fd=8))

• Only sshd listens, on port 22. Nothing else on the image opens a TCP port. postfix is installed for the STIG's local mail settings but is not running.
• The public zone allows ssh and dhcpv6-client (replies to the instance's IPv6 DHCP client, which is how an instance in an IPv6-enabled subnet gets its address). The AlmaLinux default cockpit service is removed from the zone, and Cockpit is not installed.

To open a port for your own service, take two steps. Allow it in the instance's security group, and allow it in firewalld. For example, for a web server on 443, run this on the instance:

sudo firewall-cmd --permanent --add-service=https sudo firewall-cmd --reload

If a port is open in the security group but not in firewalld, or the other way round, the traffic does not arrive.

systemctl is-active chronyd amazon-ssm-agent
sudo chronyc -n sources grep -E '^(server|port|cmdport)' /etc/chrony.conf rpm -q amazon-ssm-agent

Expected output (the pool servers and timings vary):

active active MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^- 23.186.168.132 2 6 377 53 +1079us[+1082us] +/- 55ms ^- 104.232.0.123 2 6 377 58 -1334us[-1332us] +/- 52ms ^- 144.86.176.3 2 6 377 55 -998us[ -996us] +/- 31ms ^- 192.231.84.118 2 6 377 55 +60us[ +62us] +/- 44ms ^* 169.254.169.123 3 6 377 21 +107us[ +109us] +/- 601us server 169.254.169.123 prefer iburst minpoll 4 maxpoll 16 port 0 cmdport 0 amazon-ssm-agent-3.3.5390.0-1.x86_64

The ^* marks the source chrony is using: 169.254.169.123, the Amazon Time Sync Service. It is reachable from every instance without internet access, so time stays correct in a private subnet too. The public AlmaLinux pool servers are fallbacks.

The STIG makes chrony a client only: port 0 (it serves time to nobody) and cmdport 0 (no network control port). chronyc therefore talks to chrony through its local socket, which needs root, so run it with sudo. Without sudo it reports 506 Cannot talk to daemon.

The AWS Systems Manager agent is installed from Amazon's own package at its current release. It is not in the AlmaLinux repositories, so dnf does not update it. Systems Manager can keep it current for you (the AWS-UpdateSSMAgent document, or the Auto update SSM Agent setting in Fleet Manager).

getenforce
sudo passwd -S root
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication|clientaliveinterval|clientalivecountmax|x11forwarding|banner|ciphers|macs) ' update-crypto-policies --show grep -h '^[^#]*TMOUT' /etc/profile.d/*.sh grep -vE '^\s*(#|$)' /etc/security/faillock.conf grep -E '^(minlen|minclass|difok|dictcheck|enforce_for_root)' /etc/security/pwquality.conf grep -E '^(UMASK|PASS_MIN_DAYS|PASS_MAX_DAYS|ENCRYPT_METHOD)' /etc/login.defs
sudo auditctl -s | grep -E '^(enabled|failure)'
sudo auditctl -l | wc -l sudo grep -E '^(max_log_file|num_logs|space_left_action|admin_space_left_action|disk_full_action) ' /etc/audit/auditd.conf

Expected output:

Enforcing root LK 2023-11-16 0 99999 7 -1 (Password locked.) clientaliveinterval 600 clientalivecountmax 1 permitrootlogin no pubkeyauthentication yes passwordauthentication no x11forwarding no ciphers aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr macs hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512 banner /etc/issue DEFAULT typeset -xr TMOUT=600 audit deny = 3 even_deny_root dir = /var/log/faillock fail_interval = 900 unlock_time = 0 dictcheck = 1 difok = 8 enforce_for_root minclass = 4 minlen = 15 UMASK 077 PASS_MAX_DAYS 99999 PASS_MIN_DAYS 1 ENCRYPT_METHOD SHA512 enabled 2 failure 2 74 max_log_file = 8 num_logs = 5 space_left_action = email admin_space_left_action = SUSPEND disk_full_action = SUSPEND

What these mean day to day:

• SELinux is enforcing the targeted policy. Keep it on. If your own software is denied, check sudo ausearch -m avc -ts recent rather than disabling SELinux.
• SSH. Root login, passwords and X11 forwarding are off. With clientaliveinterval 600 and clientalivecountmax 1, the server checks a silent connection after ten minutes and drops it if the client does not answer. The ciphers and MACs come from the AlmaLinux DEFAULT crypto policy (see the four SSH crypto-policy rules in Step 4).
• Shell timeout. TMOUT=600 is read-only, so an interactive shell left idle for 10 minutes exits. Run long jobs under tmux, screen, nohup or a systemd unit rather than in an open terminal.
• Account lockout. faillock locks an account, root included, after 3 wrong passwords within 15 minutes. unlock_time = 0 means it stays locked until an administrator unlocks it (see Troubleshooting). This only affects password logins and sudo prompts, because SSH is key-only.
• Passwords you set. New passwords need at least 15 characters from all four character classes, must differ from the old one in 8 characters, may not be a dictionary word, and may be changed at most once a day. The rules apply to root too.
• New files. The default umask for new accounts is 077, so new home directories and files are private to their owner.
• Audit. auditd runs with the STIG's 74 audit rules (privileged commands, identity files, module loading, permission changes, logins and more). enabled 2 means the rules are locked until the next reboot, so changing them needs a reboot, which is itself recorded. auditd rotates /var/log/audit/audit.log at 8 MB, keeps five files, mails root when space runs low and suspends logging if the disk fills (the halt actions are waived, Step 4).
• LK in the passwd -S root line means the root account is locked.

The login banner. /etc/issue (shown by SSH before login) carries the Standard Mandatory DoD Notice and Consent Banner, which the STIG requires word for word on US Department of Defense systems. If your organisation is not a DoD system or uses its own notice, replace the text. The evaluation's banner_etc_issue rule then reports fail, which is expected for a non-DoD notice:

sudo cp /etc/issue /etc/issue.dod echo "Authorized users only. All activity may be monitored and reported." | sudo tee /etc/issue

Sending logs off the instance. The STIG requires audit records and system logs to be kept off the machine. Where they go is your choice (CloudWatch Logs through the CloudWatch agent, a central syslog server, or audisp-remote), so the image sends nothing anywhere.

The STIG's TLS settings for rsyslog forwarding are already in /etc/rsyslog.d/encrypt.conf (gtls driver, TLS required, certificate name checked). To forward syslog to your own collector, add a file such as /etc/rsyslog.d/90-forward.conf containing *.* @@logs.example.internal:6514, put your collector's CA certificate path in $DefaultNetstreamDriverCAFile, then run sudo systemctl restart rsyslog.

To send audit records with audisp-remote, set remote_server = <your-log-server> in /etc/audit/audisp-remote.conf, set active = yes in /etc/audit/plugins.d/au-remote.conf, and reboot. The audit configuration is locked until then.

System mail. The STIG sets root's mail alias to the stand-in address change_me@localhost, and AIDE mails its daily report to root. postfix is installed but not running, so that mail is not delivered.

Set a real alias with sudo sed -i 's/^root:.*/root: ops@example.com/' /etc/aliases && sudo newaliases, then enable postfix with a relay host if you want the reports delivered.

Requiring a password for sudo. If your policy requires sudo re-authentication, give each administrator a password first (sudo passwd ec2-user). SSH stays key-only, and sudo is the only thing that uses the password.

Confirm that sudo -k; sudo true asks for the password and works. Only then change NOPASSWD:ALL to ALL with sudo visudo -f /etc/sudoers.d/90-cloud-init-users. Doing it the other way round locks you out of sudo.

EC2 Serial Console and recovery. No account on this image has a password, so the serial console cannot log in until you set one. If you want serial console access, set a password for your own user on your running instance. The password is yours and is not on the image, and it must meet the rules above:

sudo passwd ec2-user

The image is fully patched at build time. Check what is pending now:

sudo dnf -q check-update --refresh echo "dnf check-update exit code: $? (0 = nothing to update, 100 = updates available)" grep -E '^(upgrade_type|apply_updates)' /etc/dnf/automatic.conf systemctl is-enabled dnf-automatic.timer uname -r

Expected output on an instance launched soon after the image was built (later launches list the updates released since, with exit code 100):

dnf check-update exit code: 0 (0 = nothing to update, 100 = updates available) upgrade_type = security apply_updates = yes enabled 5.14.0-687.59.1.el9_8.x86_64

dnf-automatic runs daily and installs security updates automatically. Packages from the repositories stay trusted by fapolicyd after an update. The STIG profile also installs subscription-manager (a Red Hat requirement). AlmaLinux does not use it and needs no registration.

To update everything now, run:

sudo dnf -y upgrade

Reboot if a new kernel was installed:

sudo systemctl reboot

df -hT /
sudo grep -E 'cc_growpart.*(resized|NOCHANGE)' /var/log/cloud-init.log | tail -1 swapon --noheadings --show | wc -l sudo grep -h aide /etc/crontab

Expected output with the default 10 GiB root volume (on a larger volume, Size is larger and the cloud-init line says resized):

Filesystem Type Size Used Avail Use% Mounted on /dev/nvme0n1p4 xfs 9.3G 1.7G 7.7G 18% / 2026-10-20 02:20:57,725 - cc_growpart.py[DEBUG]: '/' NOCHANGE: no change necessary (/dev/nvme0n1, 4) 0 0 5 * * * root /usr/sbin/aide --check | /bin/mail -s "$(hostname) - AIDE Integrity Check" root@localhost

• Disk layout. The root filesystem is XFS on partition 4 of the root volume. /boot (XFS) and /boot/efi are separate small partitions.
• Disk growth. cloud-init grows the root partition and filesystem to the volume size on first boot. To grow later, increase the EBS volume size in the console or with aws ec2 modify-volume, then run sudo growpart /dev/nvme0n1 4 && sudo xfs_growfs / (or reboot).
• Swap. The image has no swap. Add a swap file yourself if your workload needs one.
• AIDE. The file integrity database is built from the image's own files. The STIG schedules aide --check daily at 05:00 and mails the result to root (see System mail in Step 11).
• Audit log space. On the 10 GiB default, the audit log shares the root filesystem, so local audit history is short on a busy machine. Forward the logs (Step 11), and launch with a larger root volume or use an LVM version if you keep more locally.

The instance uses the standard AlmaLinux 9 repositories (BaseOS, AppStream and Extras):

sudo dnf -q list --available nginx

Expected output (the version changes over time):

Available Packages nginx.x86_64 2:1.20.1-28.el9_8.6.alma.1 appstream

Install and start software in the usual way, for example sudo dnf -y install nginx then sudo systemctl enable --now nginx. Open its port in the security group and firewalld (Step 9). fapolicyd trusts software from RPM packages automatically, and anything else needs a trust entry (Step 6). Re-run the evaluation (Step 5) afterwards to see whether the new software changed the result.

The AWS CLI is not on the image. Install the current version from AWS (the AWS CLI install guide) and add it to fapolicyd's trust (sudo fapolicyd-cli --file add /usr/local/aws-cli/ --trust-file awscli, then sudo fapolicyd-cli --update).

To add another administrator, create the account, add it to the wheel group and give it an SSH key and a password:

sudo useradd -m -G wheel alice
sudo install -d -m 700 -o alice -g alice /home/alice/.ssh echo "ssh-ed25519 AAAA... alice@laptop" | sudo tee /home/alice/.ssh/authorized_keys
sudo chown alice:alice /home/alice/.ssh/authorized_keys && sudo chmod 600 /home/alice/.ssh/authorized_keys
sudo restorecon -R /home/alice/.ssh
sudo passwd alice

Because SSH is key-only, a new account needs its key in authorized_keys. restorecon gives the file the SELinux label sshd expects.

The password you set with sudo passwd alice is what sudo asks for. The STIG sets timestamp_timeout=0, so sudo asks every time. If your policy ages passwords, set it per account, for example sudo chage -M 60 alice. Only ec2-user, created by cloud-init, has password-free sudo.

The image gives you a remediated, evaluated starting point and the evidence for it. An authorisation to operate covers your whole system, so some STIG requirements can only be met by you, on your instance and in your AWS account:

• Assess it yourself. Re-run the evaluation after your software is installed (Step 5). Keep /tmp/stig-check-results.xml and the HTML report with your system documentation, and record your own decisions on the 12 failing and 24 waived rules. The reasons above are a starting point for your deviation records. For the full DISA checklist, compare against the current DISA STIG for RHEL 9. SCAP Security Guide's AlmaLinux content follows it, but rule-by-rule acceptance is your assessor's call.
• FIPS mode, if your authorisation needs FIPS 140 validated cryptography: run sudo fips-mode-setup --enable and reboot, then confirm with fips-mode-setup --check. This switches the crypto policy to FIPS, which refuses ED25519 SSH keys. Make sure every account that logs in has an RSA or ECDSA key in authorized_keys before you reboot, or you will lock yourself out.
• Encryption at rest: set Encrypted on the EBS volumes at launch, or turn on EBS encryption by default for your account. EBS encryption is invisible to the operating system, so the in-guest disk-encryption check still reports its own result.
• Boot loader password, if required: set one with sudo grub2-setpassword (the grub2_password rule). Rename the GRUB superuser from root in /etc/grub.d/01_users, then run sudo grub2-mkconfig -o /boot/grub2/grub.cfg (the grub2_admin_username rule). Keep the password in your vault, because it is needed to edit boot entries from the serial console.
• Log and audit offloading to your collector (Step 11), and a monitored mail alias for root.
• The login banner your organisation requires (Step 11), the list of authorised local accounts, and directory or smart-card authentication if you use them.
• User namespaces: if nothing on the instance needs them, echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/90-userns.conf && sudo sysctl --system.
• Separate volumes for /var, /var/log, /var/log/audit, /tmp, /var/tmp and /home, if your assessor requires them. Use the LVM versions of this listing as the starting point instead.