AlmaLinux 9 STIG on AWS User Guide

Overview

This guide covers launching and verifying the AlmaLinux 9 STIG AMI from cloudimg on Amazon EC2. It is one version of the cloudimg AlmaLinux listing on AWS Marketplace; you pick it as the software version when you subscribe and launch. Every release and variant in the listing is described at /guides/almalinux-aws/.

AlmaLinux 9 is a free, community-built enterprise Linux distribution that is binary compatible with Red Hat Enterprise Linux 9, maintained until 2032. This image starts from AlmaLinux 9.8 for EC2 and adds four things:

• DISA STIG remediation. The image is remediated with the OpenSCAP DISA STIG profile for AlmaLinux OS 9 from SCAP Security Guide 0.1.82 (AlmaLinux's own signed scap-security-guide package), then rebooted and evaluated. On this build 392 of 404 scored rules pass (97.0%). 24 rules are waived because they cannot work on an EC2 image or would need a value only you can know, each with its reason, and the 12 rules that do not pass are explained below. The HTML report, the machine-readable results, the tailoring, the waiver list and a summary ship in /usr/share/doc/cloudimg/.
• The STIG's enforcement services, running. Application control (fapolicyd, deny by default), USB device control (USBGuard, with USB storage disabled), auditd with 74 audit rules, AIDE file integrity checking, a 10 minute shell timeout and account lockout after three failed passwords.
• EC2 defaults that keep you in control. Key-only SSH as ec2-user, root locked, no password on any account, SELinux enforcing, IMDSv2 required, a host firewall (firewalld) that allows SSH in and everything out, the current AWS Systems Manager agent, and time from the Amazon Time Sync Service.
• Fully patched at build time, with dnf-automatic applying security updates on your instance. The out-of-date AWS tools the base image carried outside any repository (an old CloudWatch agent and AWS CLI) are removed, and the Systems Manager agent is brought to its current release.

What is on the image: AlmaLinux 9.8 (the RHEL 9 compatible kernel), cloud-init, OpenSSH, firewalld, chrony, SELinux (targeted policy, enforcing), the AWS Systems Manager agent, auditd with the audit dispatcher plugins, rsyslog with TLS support, fapolicyd, USBGuard, AIDE, postfix (local mail only, not running), dnf-automatic, OpenSCAP and the pinned SCAP Security Guide content used for the evaluation.

Default user: ec2-user · Architecture: x86_64 · Root volume: 10 GiB gp3, XFS (grows to the size you choose at launch)

A STIG is a configuration standard published by the US Defense Information Systems Agency (DISA). This image is remediated with the OpenSCAP DISA STIG profile and ships its own evaluation report. The pass rate is a measurement made with the SCAP Security Guide content; it is not a DISA certification or an authorisation to operate (ATO), and DISA has not reviewed or certified this image. Step 15 lists what remains yours to do for your own authorisation.

Connecting to your instance

Version	SSH user	Root device
AlmaLinux 9 STIG	ec2-user	/dev/sda1 (10 GiB gp3)

Security posture

• No known credential. There is no default password and no baked in SSH key. The only key that works is the EC2 key pair you choose at launch, which cloud-init installs for ec2-user on first boot.
• Key-only SSH. PasswordAuthentication no, PermitRootLogin no, keyboard-interactive off. The root account has no password and is locked.
• Per-instance identity. SSH host keys and the machine ID are generated fresh on every instance, so no two instances share a host key.
• IMDSv2 required. The AMI is registered with ImdsSupport v2.0, so instances launched from it refuse token-less (IMDSv1) metadata requests by default.
• SELinux enforcing with the targeted policy, as AlmaLinux ships it.
• Application and device control. fapolicyd refuses to run executables that no RPM package installed; USBGuard blocks USB devices that are not in its policy.
• Host firewall. firewalld's public zone allows only SSH and the DHCPv6 client inbound and allows all outbound traffic, so the SSM agent, metadata service, DNS, time and package updates keep working.
• Only SSH listens on the network. Nothing else on the image listens on any address.

Prerequisites

1. An AWS account and permission to launch EC2 instances
2. An EC2 key pair in the Region you launch in
3. A security group that allows TCP 22 from your own address (not from the whole internet)

Recommended instance type: m5.large. The image runs on any current x86_64 instance type.

Step 1: Launch the instance

Option A: AWS Marketplace console

1. Open the cloudimg AlmaLinux listing on AWS Marketplace and choose View purchase options, then Subscribe. One subscription covers every version in the listing.
2. Once the subscription is active, choose Launch your software.
3. Choose One-click launch from AWS Marketplace (or Launch from EC2 Console for full control), then in Version choose AlmaLinux 9 STIG - YYYY-MM-DD (the date is when the version was added) and your Region.
4. Instance type: m5.large is recommended; any current x86_64 type works. The software charge is $0.04 per vCPU per hour.
5. 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).
6. Security group: allow inbound TCP 22 from your own IP address or network only.
7. Storage: the root volume is 10 GiB gp3 by default. Choose a larger size if you need one; 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).
8. Metadata: leave the defaults. The image already requires IMDSv2. Then choose Launch.

Option B: AWS CLI

Run this on your own workstation. Replace the AMI ID with the one shown for your Region on the Marketplace launch page, and 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: the AMI already makes IMDSv2 required.

Step 2: Connect via SSH

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

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 at all 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.

Step 3: Confirm the release

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.58.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.

Step 4: Read the compliance evidence

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

ls -lh /usr/share/doc/cloudimg/
python3 -c "import json; s=json.load(open('/usr/share/doc/cloudimg/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/cloudimg/stig-report.html .

The 24 waived rules

grep -v '^#' /usr/share/doc/cloudimg/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; 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. Set an age on accounts you give a password with 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). Put /var/log/audit on its own volume (or use an LVM version) if you need the STIG's actions.
• FIPS mode (fips): FIPS mode is a separate, validated-module claim that 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; 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 placeholder host name (logcollector). An image cannot know your log server, and the placeholder 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/cloudimg/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, 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).

Step 5: Re-run the evaluation yourself

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

sudo oscap xccdf eval \
  --tailoring-file /usr/share/doc/cloudimg/stig-tailoring.xml \
  --profile xccdf_co.cloudimg_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 this 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.

Step 6: Application control with fapolicyd

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. Shell scripts are allowed by AlmaLinux's 72-shell.rules, 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: 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).

Step 7: USB devices and kernel hardening

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.

Step 8: Confirm IMDSv2 is required

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.

Step 9: The host firewall and listening ports

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; Cockpit is not installed.

Opening a port for your own service takes two steps: allow it in the instance's security group, and allow it in firewalld. For example, for a web server on 443, run 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 will not arrive.

Step 10: Time sync and the Systems Manager agent

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: 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).

Step 11: STIG settings on the instance

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 and passwords are off and X11 forwarding is 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, and unlock_time = 0 means it stays locked until an administrator unlocks it (see Troubleshooting). This only affects password logins and sudo prompts; 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), and enabled 2 means the rules are locked until the next reboot: 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 placeholder 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, and enable postfix with a relay host if you want the reports delivered.

Requiring a password for sudo. If your policy requires sudo re-authentication, first give each administrator a password (sudo passwd ec2-user; SSH stays key-only, the password is only used by sudo), confirm sudo -k; sudo true asks for it and works, and 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; it must meet the rules above):

sudo passwd ec2-user

Step 12: Patch level and automatic updates

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.58.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

Step 13: Disk size, swap and file integrity

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, and the STIG schedules aide --check daily at 05:00, mailing 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.

Step 14: Install software and add users

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, and open its port in the security group and firewalld (Step 9). Software from RPM packages is trusted by fapolicyd automatically; 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 (and 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.

Step 15: What remains yours for an authorisation

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), and rename the GRUB superuser from root in /etc/grub.d/01_users followed by sudo grub2-mkconfig -o /boot/grub2/grub.cfg (the grub2_admin_username rule). Keep the password in your vault, as 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.

Common use cases

• A base for workloads that must show DISA STIG alignment on an enterprise Linux 9, with the evaluation report already on the machine
• Government, defence supply chain and regulated workloads that start from a STIG baseline instead of hardening by hand
• Software certified or packaged for RHEL 9 compatible systems, with SELinux, fapolicyd and USBGuard enforcing from the first boot
• Fleets managed through Systems Manager, with IMDSv2 required from the first boot
• A starting point for your own golden image: add your software, re-run Step 5, and keep the report with your build

Troubleshooting

SSH says "Too many authentication failures"

If your SSH agent holds several keys, it can use up the server's attempts before it offers the right one. Tell SSH to offer only the key you name:

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

SSH or the shell disconnects when idle

That is the STIG's shell timeout: an interactive shell left idle for 10 minutes exits (TMOUT=600, read-only). Run long jobs under tmux, screen or nohup, or as a systemd unit. If the connection itself drops while you are idle, a network device between you and the instance is closing quiet connections; a client-side keep-alive helps (ssh -o ServerAliveInterval=60 ...).

A program fails with "Operation not permitted"

That is fapolicyd refusing an executable that no RPM package installed, even as root. Check the audit log:

sudo ausearch -m FANOTIFY -ts recent

Install the software from a package, or add it to a trust file and restart fapolicyd (Step 6). Do not disable fapolicyd to work around it: application control is a STIG requirement, and turning it off fails the evaluation.

Cannot connect via SSH

1. Check the instance is running and has passed its status checks.
2. Check the security group allows TCP 22 from your current public address.
3. Use the user name ec2-user and the key pair chosen at launch. Password login is disabled, so a wrong key never falls back to a password prompt.
4. If you enabled FIPS mode, ED25519 keys are refused; use an RSA or ECDSA key.
5. If you changed firewalld, make sure the ssh service is still allowed. Session Manager (Step 2) still works if SSH is blocked, provided the instance has a Systems Manager instance profile.

An account is locked after wrong passwords

faillock keeps an account locked after three failures until an administrator clears it. From ec2-user (or Session Manager), check and reset it:

sudo faillock --user alice
sudo faillock --user alice --reset

chronyc says "506 Cannot talk to daemon"

The STIG closes chrony's network command port. Run chronyc with sudo so it uses the local socket (Step 10).

My service is running but not reachable

Allow the port in both the security group and firewalld (Step 9). sudo firewall-cmd --list-all shows the firewalld rules; sudo ss -tlnp shows whether the service listens on all addresses or only on loopback. If the service runs on a non-standard port, SELinux may also need to allow it, for example sudo semanage port -a -t http_port_t -p tcp 8080 for a web server on 8080.

A tool that uses instance metadata fails

The image requires IMDSv2. Old scripts that call http://169.254.169.254/ without a token get HTTP 401. Update them to request a token first (Step 8), or use the AWS CLI or a current SDK.

Package manager issues

Refresh the metadata first:

sudo dnf -q makecache --refresh && echo "repository metadata refreshed"

If the repositories are unreachable, check that the instance has outbound internet access (a public IP or a NAT gateway) and that DNS resolves:

getent hosts repo.almalinux.org

Important notes

AlmaLinux is free and open source software. It is a distribution of thousands of packages, each under its own licence (GPL, LGPL, MIT, BSD, Apache 2.0 and others); rpm -qi <package> shows each package's licence. No subscription or licence key is needed to run this image. The compliance tooling is OpenSCAP (LGPL 2.1 or later) and SCAP Security Guide content (BSD 3-Clause, licence text in /usr/share/doc/cloudimg/scap-security-guide-LICENSE.txt).

AlmaLinux 9 is maintained by the AlmaLinux OS Foundation until 2032. This version tracks the AlmaLinux 9 release stream, so new minor releases arrive as ordinary updates.

The DISA STIG profile used here is the OpenSCAP profile for AlmaLinux OS 9 published in SCAP Security Guide. A pass rate measures this image as built; your own changes affect it, which is why the evaluation can be re-run (Step 5). It is not a DISA certification or an authorisation to operate, and some STIG requirements are about how you operate the system (Step 15).

AlmaLinux is a trademark of the AlmaLinux OS Foundation. Red Hat Enterprise Linux is a trademark of Red Hat, Inc. These names are used only to identify the software, its compatibility and the profile. cloudimg is not affiliated with or endorsed by the AlmaLinux OS Foundation, Red Hat, the Defense Information Systems Agency or the US Department of Defense.

Support

For help with this image, contact cloudimg support:

• Website: www.cloudimg.co.uk
• User Guides: www.cloudimg.co.uk/guides
• AlmaLinux on AWS hub: www.cloudimg.co.uk/guides/almalinux-aws