Rocky Linux 9 STIG

Option A: Azure Portal

• Open the Azure Marketplace and search for "Rocky Linux 9 STIG-Hardened SecureAnyCloud".
• Select the image and click Create.
• Configure the basics:
• Subscription: select your Azure subscription.
• Resource Group: create a new group or select an existing one.
• Virtual Machine Name: enter a name for your VM.
• Region: select your preferred Azure region.
• Size: Standard_B2s is 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:rocky-9-stig:default:latest
az vm create \
  --resource-group myResourceGroup \
  --name my-rocky-9-stig-vm \
  --image sac1647283583153:rocky-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-rocky-9-stig-vm --show-details --query publicIps -o tsv ssh azureuser@<vm-ip>

There is no password to enter. If SSH asks 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. The connection model is the same as on 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. The reason is as follows.

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. It would not require re-authentication. It would remove administrative access outright.

To confirm the configuration, run:

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

The eight excluded rules fall into three groups:

• sudo_remove_nopasswd, sudo_remove_no_authenticate, disallow_bypass_password_sudo: these would strip passwordless sudo from your SSH-key-authenticated account, as described 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. The rule has no effect on normal boot, because 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: these enable full FIPS 140 mode. Enabling it correctly needs fips-mode-setup --enable, a dracut -f initramfs rebuild and a further reboot to prove the system 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 was 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-rl9-ds.xml | grep stig

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

94.9 build-remediation-report.html build-remediation-results.xml build-remediation-score.txt xccdf_org.ssgproject.content_profile_stig:DISA STIG for Red Hat Enterprise Linux 9

To read the report properly, copy the HTML file to your workstation:

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

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:

• 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 rules 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, so there is nowhere for a second partition to live. The rules are not applicable here, and this is not a defect.
• The three excluded rule groups from Step 3 (the crypto and FIPS rules and the sudo-nopasswd rules): these are deliberately excluded. They cascade into a couple of closely related checks, such as grub2_admin_username (tied to the boot loader password) and selinux_context_elevation_for_sudo.
• Environment-specific rules with no automated fix (network_configure_name_resolution, chronyd_server_directive, sssd_enable_certmap, installed_OS_is_vendor_supported, accounts_authorized_local_users, sysctl_user_max_user_namespaces_no_remediation): these need a site-specific answer, such as your own DNS servers, your own NTP servers or your own authorized-user list. For the "no_remediation" rule, SSG itself ships no automated fix and expects manual review.

None of these rules is hidden or remediated away. Read the HTML report for the full rule-by-rule detail.

cat /etc/rocky-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:

Rocky Linux release 9.8 (Blue Onyx) NAME="Rocky Linux" VERSION="9.8 (Blue Onyx)" ID="rocky" 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. The default mode applies every available update, so it cannot quietly do nothing.

Confirm SELinux, root, the SSH settings 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 therefore carry forward when a kernel update installs a new boot entry:

grep CMDLINE_LINUX_DEFAULT /etc/default/grub

To add password protection for editing the GRUB boot menu, run the following. Step 3 explains why this build does not set a password automatically.

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

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

The most important property of this image is that STIG hardening does not break the cloud-init and Azure agent paths that provision your VM. Confirm it:

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, by design. 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 Rocky Linux 9 image, this image has STIG remediation install and enable 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. This is asserted on every build, not assumed, because a default-deny firewall that did not keep SSH open would lock out every customer, as the sudo issue in Step 3 would have. cockpit and dhcpv6-client are the other pre-authorised services in the stock public zone. 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:

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

rpcbind is disabled on this image, as on the plain Rocky Linux 9 build. NFSv4, the default in Rocky Linux 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:

oscap ds sds-validate /usr/share/xml/scap/ssg/content/ssg-rl9-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, writing a fresh report to /var/log/sac/stig/verify-report.html, verify-results.xml and verify-score.txt. It never remediates, because this image does not run a scheduled job that could silently change 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-rl9-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, so you can review and apply further hardening deliberately:

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

Applying additional fixes can be destructive, so review them first. They can disable services, tighten sshd further or change mount options. The next block 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-rl9-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 Rocky Linux listing on AWS Marketplace and choose View purchase options, then Subscribe. One subscription covers every version in the listing.
• Once the subscription is active, choose Launch your software.
• Choose One-click launch from AWS Marketplace (or Launch from EC2 Console for full control), then in Version choose Rocky Linux 9 STIG - YYYY-MM-DD HH:MM (the date and time are when the version was added) and your Region.
• Instance type: m5.large is recommended; 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 11 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 Step 15).
• 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=rocky-9-stig}]'

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

From your workstation, connect as rocky with the key pair you chose:

ssh -i ~/.ssh/my-key-pair.pem rocky@<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.

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

Expected output:

Rocky Linux release 9.8 (Blue Onyx) NAME="Rocky Linux" VERSION="9.8 (Blue Onyx)" ID="rocky" VERSION_ID="9.8" PLATFORM_ID="platform:el9" PRETTY_NAME="Rocky Linux 9.8 (Blue Onyx)" 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 Rocky Linux 9: it receives every Rocky Linux 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 21 16:44 scap-security-guide-LICENSE.txt -rw-r--r--. 1 root root 38M Oct 21 16:53 stig-arf.xml -rw-r--r--. 1 root root 4.4M Oct 21 16:53 stig-report.html -rw-r--r--. 1 root root 1.6K Oct 21 16:53 stig-summary.json -rw-r--r--. 1 root root 4.0K Oct 21 16:53 stig-tailoring.xml -rw-r--r--. 1 root root 7.7K Oct 21 16:53 stig-waivers.txt profile: DISA STIG (SCAP Security Guide 0.1.82) scored rules: 404 pass: 393 fail: 11 errors: 0 rate: 97.3% waived: 24 not applicable: 39 not checked: 10 evaluated at: 2026-10-21T16:53:33Z

• 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 rocky@<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 rocky (default-user-sudo): rocky 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 generic host name (logcollector). An image cannot know your log server, and that name would send every log message, authentication records included, to whichever host answers to it in your network. rsyslog logs locally only; Step 11 shows how to forward to your own collector.

The 11 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 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 installed_OS_is_vendor_supported network_configure_name_resolution 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 Rocky Linux's system accounts and rocky.
• 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 Rocky Linux DEFAULT crypto policy: AES-GCM, ChaCha20-Poly1305 and AES-CTR ciphers with SHA-2 (and SHA-1) MACs (Step 11).
• installed_OS_is_vendor_supported: the check recognises only the commercially supported distributions it lists (Red Hat Enterprise Linux and a few others), so it reports Rocky Linux as unsupported. Rocky Linux 9 receives security updates from the Rocky Enterprise Software Foundation until 2032; whether your authorisation accepts a community-supported distribution is a decision for you and your assessor.
• 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.
• 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 rocky 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 a few minutes:

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-rl9-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': 11, 'notapplicable': 39, 'notchecked': 10, 'notselected': 1087, 'pass': 393} pass rate: 97.3%

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.

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 Rocky Linux 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 for every ordinary user. Root is the exception: Rocky Linux's own 20-dracut.rules lets any trusted program running as root (a root shell, sudo, dracut) execute or open any file, so fapolicyd does not stop an administrator.

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 ':$' install -m 0755 /usr/bin/date /tmp/my-date
sudo -u rocky /tmp/my-date || echo "exit code $?: fapolicyd refused to run /tmp/my-date for rocky (an untrusted copy)"
sudo /tmp/my-date > /dev/null && echo "root, through a trusted program, may still run it (20-dracut.rules)" 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 sudo: unable to execute /tmp/my-date: Operation not permitted exit code 1: fapolicyd refused to run /tmp/my-date for rocky (an untrusted copy) root, through a trusted program, may still run it (20-dracut.rules)

• 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 for rocky (and for any other non-root account).
• 20-dracut.rules (allow perm=any uid=0 trust=1 : all) is Rocky Linux's default and lets root, working through a trusted program, run the copy. Treat root access as fully trusted, and keep untrusted code away from root shells.
• The STIG adds 99-deny-everything.rules as the last rule, so anything the earlier Rocky Linux rules do not explicitly allow is denied. Shell scripts are allowed by Rocky Linux'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).

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 blacklist usb-storage 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. The same arguments are in GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub and in /etc/kernel/cmdline, so kernels installed later, and boot entries regenerated with grub2-mkconfig, keep them. 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 -tulnp echo "cockpit.socket: $(systemctl is-enabled cockpit.socket)"

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: Netid State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=935,fd=7)) tcp LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=935,fd=8)) cockpit.socket: disabled

• Only sshd listens, on port 22. Nothing else on the image opens a TCP or UDP port: postfix is installed for the STIG's local mail settings but is not running, chrony serves no time and has no network command port (Step 10), and the RPC port mapper (rpcbind, port 111) that the base Rocky Linux image runs is removed. If you install NFS client tools (nfs-utils), rpcbind comes back with them.
• 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 Rocky Linux default cockpit service is removed from the zone.
• The Cockpit web console is installed as in a standard Rocky Linux system, but its socket is disabled and a preset in /etc/systemd/system-preset/80-sac-cockpit.preset keeps it disabled. To use it, run sudo systemctl enable --now cockpit.socket and sudo firewall-cmd --permanent --add-service=cockpit && sudo firewall-cmd --reload, allow TCP 9090 from your own address in the security group (or use an SSH tunnel, ssh -L 9090:localhost:9090 ...), and give your user a password first (sudo passwd rocky; it must meet the rules in Step 11). SSH stays key-only.

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.

systemctl is-active chronyd amazon-ssm-agent
sudo chronyc -n sources grep -E '^(server|pool|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 =============================================================================== ^- 198.178.138.195 2 6 377 57 +3561us[+3573us] +/- 38ms ^- 173.71.69.149 1 6 377 57 +326us[ +338us] +/- 4502us ^- 158.51.99.19 2 6 377 122 -2185us[-2163us] +/- 12ms ^- 209.253.210.112 1 6 377 55 +1875us[+1887us] +/- 9255us ^* 169.254.169.123 3 6 377 41 +36us[ +48us] +/- 400us pool 2.rocky.pool.ntp.org iburst maxpoll 16 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 Rocky Linux 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 Rocky Linux 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 2026-06-24 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 76 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 Rocky Linux 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 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 76 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 default 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. Each instance creates its own postfix TLS key on first boot.

Requiring a password for sudo. If your policy requires sudo re-authentication, first give each administrator a password (sudo passwd rocky; 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 rocky

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); Rocky Linux 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 11 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.9G 1.6G 8.4G 16% / 2026-10-21 17:21:35,853 - 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 11 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 Rocky Linux 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.rocky.0.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 rocky, 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 11 failing and 24 waived rules (the reasons above are a starting point for your deviation records). DISA publishes its STIG for Red Hat Enterprise Linux 9, not for Rocky Linux; SCAP Security Guide's Rocky Linux content follows the RHEL 9 STIG, but rule-by-rule acceptance, and acceptance of the distribution itself (installed_OS_is_vendor_supported), 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. Whether Rocky Linux's cryptographic modules carry a FIPS 140 validation that your authorisation accepts is for you to confirm.
• 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.