Ubuntu 22.04 STIG-Hardened

Option A: AWS Marketplace console

• Open the SecureAnyCloud Ubuntu listing on AWS Marketplace. 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). In Version, choose Ubuntu 22.04 LTS STIG-Hardened - YYYY-MM-DD (the date is when the version was added), and choose your Region.
• Pick an instance type (m5.large recommended; any current x86_64 type works) and your key pair.
• For the security group, allow SSH (TCP 22) from your own IP address or network only.
• For storage, set the root volume size you want (8 GiB minimum). The root filesystem grows to fill it on first boot. If your policy requires encryption at rest, set encryption on the volume here (see encrypt_partitions in Step 4).
• For metadata, leave the defaults. The image already requires IMDSv2. Then choose Launch.

Option B: AWS CLI

Run this command on your own workstation. Replace the AMI ID with the one shown for your Region on the Marketplace launch page. Replace the key pair, security group and subnet with your own:

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=ubuntu-2204-stig}]'

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

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

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

Before the login completes, SSH prints the Standard Mandatory DoD Notice and Consent Banner that the STIG requires. Step 9 shows how to replace it with your own organization'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. The instance needs an instance profile that allows Systems Manager. The agent is installed and running on this image.

grep -E '^(NAME|VERSION|ID|VERSION_ID|PRETTY_NAME)=' /etc/os-release uname -srm dpkg --print-architecture

Expected output:

PRETTY_NAME="Ubuntu 22.04.5 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04.5 LTS (Jammy Jellyfish)" ID=ubuntu Linux 6.8.0-1066-aws x86_64 amd64

The -aws kernel is Canonical's kernel flavor for EC2, with the Nitro network and NVMe drivers built in. 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 19M -rw-r--r-- 1 root root 1.6K Oct 19 08:30 scap-security-guide-LICENSE.txt -rw-r--r-- 1 root root 17M Oct 19 08:35 stig-arf.xml -rw-r--r-- 1 root root 2.1M Oct 19 08:35 stig-report.html -rw-r--r-- 1 root root 1.3K Oct 19 08:35 stig-summary.json -rw-r--r-- 1 root root 4.2K Oct 19 08:35 stig-tailoring.xml -rw-r--r-- 1 root root 8.9K Oct 19 08:35 stig-waivers.txt profile: DISA STIG (SCAP Security Guide 0.1.82) scored rules: 195 pass: 191 fail: 4 errors: 0 rate: 97.9% waived: 23 not applicable: 7 not checked: 5 evaluated at: 2026-10-19T08:35:11Z

• 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.
• stig-tailoring.xml is the exact tailoring used, so you can re-run the same evaluation (Step 6).
• 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 command on the workstation:

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

The 23 waived rules

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

Expected output:

sudo_remove_nopasswd [default-user-sudo] grub2_password [serial-console-and-boot] grub2_uefi_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 [audit-sizing-8gb] is_fips_mode_enabled [fips] install_smartcard_packages [smartcard] package_opensc_installed [smartcard] smartcard_configure_ca [smartcard] smartcard_configure_cert_checking [smartcard] smartcard_configure_crl [smartcard] smartcard_pam_enabled [smartcard] sssd_enable_smartcards [smartcard] package_sssd_installed [sssd-pki] package_nss_sss_installed [sssd-pki] package_pam_sss_installed [sssd-pki] service_sssd_enabled [sssd-pki] sssd_certification_path_trust_anchor [sssd-pki] sssd_enable_pam_services [sssd-pki] sssd_enable_user_cert [sssd-pki] sssd_offline_cred_expiration [sssd-pki] auditd_audispd_configure_remote_server [audit-remote-destination]

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

• Passwordless sudo for ubuntu (default-user-sudo). ubuntu has no password, and cloud-init gives it password-free sudo. Removing NOPASSWD would leave the only administrator unable to use sudo at all. Accounts you create yourself still need their password for sudo (Step 12).
• Boot loader passwords (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.
• Password aging defaults (key-only-account-aging). The accounts cloud-init creates are key-only. A default aging limit would expire them and lock the SSH key out, so PASS_MAX_DAYS stays unlimited. To set an age on accounts you give a password, run sudo chage -M 60 <user>.
• Halt on a full audit disk (audit-sizing-8gb). On a single 8 GiB root volume, the audit log shares the disk with the operating system. Halting when the disk fills would take the whole instance down. auditd rotates its log at 8 MB, keeps five files, and suspends logging if the disk fills (Step 11). Put /var/log/audit on its own volume if you need the STIG's halt action.
• FIPS mode (fips). FIPS needs a FIPS-validated kernel and modules, which on Ubuntu come with an Ubuntu Pro subscription. FIPS is not enabled or claimed.
• 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 that nobody can use.
• SSSD for PKI logins (sssd-pki). The STIG uses SSSD only as the client for DoD PKI smart-card logins against a directory. The content installs SSSD, its PAM and NSS modules and a configuration for a dummy domain. SSSD refuses to start without a real domain, so the service failed on every boot. SSSD is therefore not installed. If you join a directory, install SSSD and configure it for your own domain and certificate authority.
• Remote audit server (audit-remote-destination). The STIG sends audit records to a remote log server through audisp-remote, and the content fills in a dummy host name (logcollector). An image cannot know your log server. The dummy name would send every audit record to whichever host answers to that name in your network, or queue and drop them when none does. audisp-remote is installed but inactive. Step 9 shows how to point it at your own collector.

The four 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:

auditd_offload_logs encrypt_partitions ufw_rate_limit verify_use_mappers

What each one means on this image:

• auditd_offload_logs: the STIG requires audit records to be copied off the machine regularly. Where they go is your choice (CloudWatch Logs through the CloudWatch agent, a central syslog server, or audisp-remote), so an image cannot set it. The remote audit server is waived for the same reason, above. The audit rules are loaded and auditd is running (Step 9).
• encrypt_partitions: the STIG wants the disks encrypted inside the operating system (LUKS). This image boots from a plain EBS volume. Encryption at rest on EC2 is done by EBS. Set Encrypted on the volume when you launch (Step 1), or turn on EBS encryption by default for your account. EBS encryption is invisible to the operating system, so this check still reports fail on an encrypted volume.
• ufw_rate_limit: the STIG wants ufw to rate-limit incoming connections (ufw limit). That allows a source six new connections in 30 seconds. It breaks tools that open several SSH sessions in a row (Ansible, CI pipelines, scp loops), so it is not switched on. Your security group already restricts who can reach port 22. To apply it, run sudo ufw limit 22/tcp.
• verify_use_mappers: this checks the smart-card certificate mapping in pam_pkcs11. The smart-card packages are not installed (see the waived rules), so there is no pam_pkcs11 configuration to set.

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

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-ubuntu2204-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': 4, 'notapplicable': 7, 'notchecked': 5, 'notselected': 432, 'pass': 191} pass rate: 97.9%

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

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 ufw status verbose
sudo ss -tlnp

Expected output:

Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), disabled (routed) New profiles: skip To Action From -- ------ ---- Anywhere on lo ALLOW IN Anywhere 22/tcp ALLOW IN Anywhere 68/udp ALLOW IN 67/udp
# DHCP client: replies from a DHCP server (port 67) Anywhere (v6) on lo ALLOW IN Anywhere (v6) 22/tcp (v6) ALLOW IN Anywhere (v6) 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=649,fd=3)) LISTEN 0 100 127.0.0.1:25 0.0.0.0:* users:(("master",pid=1184,fd=13)) LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=423,fd=14)) LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=649,fd=4)) LISTEN 0 100 [::1]:25 [::]:* users:(("master",pid=1184,fd=14))

Only sshd listens on the network. The DNS stub resolver (53) and the local mail relay (25, for system mail) listen on loopback only. The 68/udp rule admits only the replies of the VPC's DHCP server to the instance's own DHCP client, which keeps the instance's private address. It opens no service.

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

sudo ufw allow 443/tcp

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

systemctl is-active chrony amazon-ssm-agent chronyc -n sources dpkg -s snapd >/dev/null 2>&1 && echo "snapd: installed" || echo "snapd: not installed"

Expected output (the pool servers and timings vary):

active active MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^* 169.254.169.123 3 6 377 24 -3675ns[-6580ns] +/- 551us ^- 91.189.91.157 2 6 377 118 +516us[ +512us] +/- 29ms ^- 185.125.190.56 2 6 377 57 +4312us[+4310us] +/- 46ms ^- 185.125.190.58 2 6 377 57 +2640us[+2637us] +/- 43ms ^- 185.125.190.57 2 6 377 57 +5301us[+5299us] +/- 47ms ^- 23.186.168.123 2 6 377 56 +1455us[+1452us] +/- 56ms ^- 172.233.189.68 2 6 377 57 -1823us[-1826us] +/- 78ms ^- 5.78.139.245 3 6 377 122 -2966us[-2971us] +/- 109ms ^- 85.239.235.13 2 6 377 59 +9385us[+9382us] +/- 72ms snapd: not installed

The ^* marks the source that 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 Ubuntu pool servers are fallbacks.

The AWS Systems Manager agent is installed from Amazon's Debian package rather than as a snap, and snapd is removed.

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication|clientaliveinterval|clientalivecountmax|x11forwarding|banner|ciphers|macs|kexalgorithms) '
sudo passwd -S root grep -h '^TMOUT' /etc/profile.d/*.sh grep -vE '^\s*(#|$)' /etc/security/faillock.conf grep -vE '^\s*(#|$)' /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 aa-status --enabled && echo "apparmor: enabled" for p in sssd libpam-sss libnss-sss; do dpkg -s "$p" >/dev/null 2>&1 && echo "$p: installed" || echo "$p: not installed"; done

Expected output:

clientaliveinterval 600 clientalivecountmax 1 permitrootlogin no pubkeyauthentication yes passwordauthentication no x11forwarding no ciphers aes256-ctr,aes256-gcm@openssh.com,aes128-ctr,aes128-gcm@openssh.com macs hmac-sha2-512,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-256-etm@openssh.com banner /etc/issue.net kexalgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256 root L 10/14/2026 0 99999 7 -1 TMOUT=900 audit deny = 3 fail_interval = 900 silent unlock_time = 0 dcredit = -1 dictcheck = 1 difok = 8 enforcing = 1 lcredit = -1 minlen = 15 ocredit = -1 ucredit = -1 UMASK 077 PASS_MAX_DAYS 99999 PASS_MIN_DAYS 1 ENCRYPT_METHOD SHA512 enabled 1 failure 1 60 apparmor: enabled sssd: not installed libpam-sss: not installed libnss-sss: not installed

What these settings mean day to day:

• SSH. Root login and passwords are off. The ciphers, MACs and key exchange are the STIG's approved set (AES ciphers, SHA-2 MACs, NIST elliptic-curve and group-exchange Diffie-Hellman key exchange), which current SSH clients support. With clientaliveinterval 600 and clientalivecountmax 1, the server checks a silent connection every ten minutes and drops it if the client does not answer.
• Shell timeout. TMOUT=900 is read-only, so an interactive shell left idle for 15 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 after 3 wrong passwords within 15 minutes. unlock_time = 0 means the account stays locked until an administrator unlocks it (see Troubleshooting). This only affects accounts that have a password, because SSH is key-only.
• Passwords you set. New passwords need at least 15 characters, with an upper-case letter, a lower-case letter, a digit and a symbol. They may not be a dictionary word, and may be changed at most once a day.
• New files. The default umask for new accounts is 077, so new home directories and files are private to their owner.
• Audit. auditd is running with the STIG's 60 audit rules (privileged commands, identity files, module loading, permission changes and more). The audit log is /var/log/audit/audit.log. To also send the records to your own log server 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, then run sudo systemctl restart auditd. The default port is TCP 60, which your collector must accept.
• L in the passwd -S root line means the root account is locked.

The login banner. /etc/issue.net (shown by SSH) carries the Standard Mandatory DoD Notice and Consent Banner. The STIG requires it word for word on US Department of Defense systems. If your organization is not a DoD system or uses its own notice, replace the text in both banner files, for example:

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

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

sudo passwd ubuntu

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

sudo apt-get update -qq apt-get -s -o APT::Get::Always-Include-Phased-Updates=true dist-upgrade | awk '/^Inst /{n++} END{print "pending upgrades: " n+0}' apt-mark showhold uname -r

Expected output on an instance launched soon after the image was built. Later launches show the updates released since:

pending upgrades: 0 6.8.0-1066-aws

unattended-upgrades is on, so security updates install automatically every day. To update everything now, run:

sudo apt-get update && sudo apt-get -y dist-upgrade

Reboot if a new kernel was installed:

sudo systemctl reboot

df -h / swapon --noheadings --show | wc -l sudo ls -l /etc/cron.daily/aide

Expected output with the default 8 GiB root volume (on a larger volume, Size is larger):

Filesystem Size Used Avail Use% Mounted on /dev/root 7.6G 1.9G 5.7G 25% / 0 -rwxr-xr-x 1 root root 34194 Dec 30 2021 /etc/cron.daily/aide

• 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 reboot, or run sudo growpart /dev/nvme0n1 1 && sudo resize2fs /dev/nvme0n1p1.
• 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. Ubuntu 22.04's AIDE package runs its daily check from /etc/cron.daily/aide.
• Audit log space. On the 8 GiB default, the audit log shares the root filesystem. auditd rotates /var/log/audit/audit.log at 8 MB and keeps five files, so local audit history is short on a busy machine. Offload the logs (see auditd_offload_logs in Step 4). If you keep more locally, launch with a larger root volume or put /var/log/audit on its own EBS volume.

The instance uses the standard Ubuntu archives:

sudo apt-get update -qq apt-cache policy nginx | sed -n '1,3p'

Expected output (the version changes over time):

nginx: Installed: (none) Candidate: 1.18.0-6ubuntu14.21

Install and start software in the usual way, for example sudo apt-get install -y nginx then sudo systemctl enable --now nginx. Open its port in the security group and ufw (Step 7). Re-run the evaluation (Step 5) afterwards to see whether the new software changed the result.

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

sudo adduser --disabled-password --gecos "" alice
sudo usermod -aG sudo 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 passwd alice

Because SSH is key-only, a new account needs its key in authorized_keys. The password you set with sudo passwd alice is what sudo asks for, and it must meet the password rules in Step 9. If your policy ages passwords, set the age per account, for example sudo chage -M 60 alice. Only ubuntu, created by cloud-init, has password-free sudo.