Hardened images, verified on a booted instance

ToTheNOC builds hardened Linux images for public clouds: AlmaLinux 10 and 9, Rocky Linux 10 and 9, and Debian 13, for x86_64 and arm64. They are hardened with the open-source ComplianceAsCode content, profile “CIS Level 1 Server”, the same content the distributions ship as scap-security-guide. Most hardened images are scanned once, on the build machine. We had images that passed that scan and then did not boot. So every release is launched as a new instance, checked, and scanned again while it runs. This page publishes the evidence for each release: what was checked, on what, and the raw results.

LIVEAWS Marketplace10 images: AlmaLinux 10 and 9, Rocky Linux 10 and 9, Debian 13, each for x86_64 and arm64 (Graviton).See the AWS images →IN REVIEWGoogle CloudAlmaLinux 9 for Compute Engine, submitted to Google Cloud Marketplace. The other images follow after it.See the Google Cloud image →

AWS Marketplace

Try Free with AWS  30-day free trial on AWS Marketplace, then $0.04/hr plus EC2. The button opens AlmaLinux 9; all ten images (x86_64 and arm64) are linked in the table below.

Status: live. Each image links to its listing; the evidence is for the release that is listed.

Default user: ec2-user on AlmaLinux, rocky on Rocky Linux, admin on Debian.

Google Cloud

Status: in review. AlmaLinux 9 is built for Compute Engine and submitted to Google Cloud Marketplace. It is not listed yet; this section will link to the listing and to the evidence of the listed release when it is.

The Compute Engine image goes through the same release steps as the AWS images. On the running test instance, the AlmaLinux 9 image gives the same result as on AWS: 265 automated checks pass, 0 fail, 30 not applicable. Google’s base image needed a few changes to get there: the network interface came up in the firewalld “trusted” zone (now “public”, SSH only), the guest agent wrote the SSH host keys with the wrong permissions, and the startup-script services pulled in rsyslog next to journald.

How to launch it, connect over SSH and check it: Getting started on Google Cloud.

How a release is verified

1. Build. Packer, starting from the distribution’s own image for that cloud, fully updated, then hardened with the ComplianceAsCode “CIS Level 1 Server” profile.
2. Boot. A new instance is launched from the final image. If it does not come up and answer on SSH, the release stops here.
3. Check. Boot checks over SSH: system running with no failed units, first-boot services done, GRUB password present, /tmp mounted noexec, SELinux enforcing (AppArmor on Debian), firewall with only SSH open, sshd with no root login, no password login and only the sshusers group allowed, new host keys and a new machine-id.
4. Scan. OpenSCAP on the running instance, with the same tool that ships in the image: sudo ttn-cis-audit.
5. Journal upload test. A log collector is started on the test instance, the image forwards its journal to it with ttn-journal-upload, and the scan runs again with the remote-journal rules included.
6. Publish. The report, the raw results, the tailoring, the boot checks, the journal upload test and their checksums go on this page. An image is listed only if every step passes.

What the result means, and what it does not

“0 fail” means every automated check of the profile, as tailored below, passes on the running instance. Some recommendations of the benchmark are manual and have no automated check in any tool; they are not counted. The results come from OpenSCAP with ComplianceAsCode content, not from CIS-CAT, and they are not a CIS certification. ToTheNOC is not affiliated with or endorsed by the Center for Internet Security. CIS and CIS Benchmarks are trademarks of the Center for Internet Security, Inc.

Tailoring: what is adjusted, and why

Every evidence folder contains the exact tailoring.xml used for that release. The adjustments:

• Remote journal upload (all images). The rules require the journal to be sent to a log collector, at a URL. That URL is yours; an image cannot ship it, and an image that sent your logs to us would be worse than one that sends them nowhere. The service is installed and off. Turn it on with sudo ttn-journal-upload https://your-collector:19532, or at launch in user data. From then on sudo ttn-cis-audit checks those rules too, against the URL you configured. Every release is tested this way: see upload-test.txt.
• Red Hat GPG key (Rocky Linux 10 only). The rule looks for Red Hat’s signing key; Rocky Linux signs with its own. The build checks instead that the Rocky Linux 10 release key is installed, and stops if it is not.
• One alternative per choice (Debian 13 only). The upstream Debian profile selects both alternatives in two places: chrony and systemd-timesyncd for time, journald and rsyslog for logs. The image uses chrony (with Amazon Time Sync on AWS), and journald only.

Check it yourself

On your instance: sudo ttn-cis-audit. It runs the same scan with the same tailoring and writes the report and the raw results to /var/tmp/ttn-audit. Exit code 0 means every rule passed, 2 means at least one failed.

What is in each evidence folder

• report.html: the OpenSCAP report, rule by rule.
• results.xml.gz: the raw OpenSCAP results, unmodified.
• tailoring.xml: the tailoring used for the scan.
• checks.txt: the boot checks, command by command, with their output.
• upload-test.txt: the journal upload test, command by command.
• summary.json: counts, scan time, the ID of the tested image, the deselected rules.
• SHA256SUMS: checksums for all of the above. Verify with sha256sum -c SHA256SUMS.

The test instance is terminated after the scan. In report.html its password hashes (generated for that instance only) are replaced with [redacted]. Nothing else is changed.

Passwords and access

There is no password in the image. On first boot every instance generates its own random GRUB password (and on AlmaLinux and Rocky Linux its own random root password), which is not stored anywhere. SSH accepts keys only, root cannot log in over SSH, and only members of the sshusers group can connect. The default user depends on the cloud: see the section of each provider above.

Support

Questions, findings, or a rule you need changed for your environment: support@tothenoc.com. You get an answer from the engineer who builds the images.