Debian 12

Option A: Azure Portal

• Open the Azure Marketplace and search for "Debian 12 (Bookworm) on Azure SecureAnyCloud".
• Select the image and click Create.
• For Subscription, select your Azure subscription.
• For Resource Group, create a new one or select an existing one.
• For Virtual Machine Name, enter a name for your VM.
• For Region, select your preferred Azure region.
• For 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:debian-12:default:latest
az vm create \
  --resource-group myResourceGroup \
  --name my-debian-12-azure-vm \
  --image sac1647283583153:debian-12:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Once your VM is running, connect with SSH:

ssh azureuser@<public-ip-address>

To find your VM's public IP address, run:

az vm show --resource-group myResourceGroup --name my-debian-12-azure-vm --show-details --query publicIps -o tsv

After connecting, verify the operating system:

cat /etc/os-release uname -r

Check disk space and memory:

df -h free -h

Verify that the Azure Linux Agent is running. On Debian, its service is named walinuxagent:

systemctl status walinuxagent

Install the latest security patches to keep your system up to date:

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

The Azure network security group (NSG) controls inbound and outbound traffic. You can also configure the local firewall:

sudo firewall-cmd --list-all

To allow additional ports:

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

Option A: AWS Marketplace console

• Open the SecureAnyCloud Debian 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 Debian 12 - YYYY-MM-DD (the date is when the version was added), then choose your Region.
• Instance type: m5.large is recommended, and any current x86_64 type works. The software charge is $0.04 per vCPU per hour.
• Key pair: choose your EC2 key pair. It is the only way in. RSA and ED25519 keys both work.
• Security group: allow inbound TCP 22 from your own IP address or network only.
• Storage: the root volume is 8 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.
• Metadata: leave the defaults, because 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, and replace the key pair, security group and subnet with your own. The root device of this AMI is /dev/xvda:

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/xvda,Ebs={VolumeSize=20,VolumeType=gp3}' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=debian-12}]'

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

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

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

There is no password to enter. If SSH asks for one, or says Too many authentication failures, see Troubleshooting below. The SSH server shows the login banner (/etc/issue.net) before you sign in.

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

cat /etc/debian_version grep -E '^(PRETTY_NAME|NAME|VERSION_ID|VERSION|VERSION_CODENAME|ID)=' /etc/os-release uname -srm

Expected output:

12.15 PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" NAME="Debian GNU/Linux" VERSION_ID="12" VERSION="12 (bookworm)" VERSION_CODENAME=bookworm ID=debian Linux 6.1.0-54-cloud-amd64 x86_64

This version follows Debian 12. It receives every Debian 12 point release (12.15 at build time) through normal apt 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/cis-l1-summary.json')); print('profile: ', s['profileLabel'], '(SCAP Security Guide', s['ssgVersion'] + ')'); print('scored rules: ', s['scored'], ' pass:', s['pass'], ' fail:', s['fail'], ' rate:', str(s['ratePct']) + '%'); print('waived: ', s['waived'], ' not applicable:', s['notapplicable']); print('evaluated at: ', s['evaluatedAt'])"

Expected output:

total 24M -rw-r--r-- 1 root root 21M Oct 24 22:28 cis-l1-arf.xml -rw-r--r-- 1 root root 3.3M Oct 24 22:28 cis-l1-report.html -rw-r--r-- 1 root root 1.4K Oct 24 22:28 cis-l1-summary.json -rw-r--r-- 1 root root 2.1K Oct 24 22:28 cis-l1-tailoring.xml -rw-r--r-- 1 root root 2.3K Oct 24 22:28 cis-l1-waivers.txt -rw-r--r-- 1 root root 1.6K Oct 24 22:18 scap-security-guide-LICENSE.txt profile: CIS Level 1 Server (SCAP Security Guide 0.1.82) scored rules: 342 pass: 335 fail: 6 rate: 98.0% waived: 6 not applicable: 51 evaluated at: 2026-10-24T22:28:34Z

• cis-l1-report.html is the full OpenSCAP report, rule by rule. Copy it to your workstation and open it in a browser.
• cis-l1-arf.xml is the same evaluation in the machine-readable ARF format, for compliance tooling.
• cis-l1-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, or waived are not counted.

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

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

The six waived rules

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

Expected output:

partition_for_tmp [single-volume-partitions] 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] sshd_limit_user_access [ssh-access-list]

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

• Separate /tmp partition: this version boots from one EBS root volume. The LVM versions of this listing provide separate volumes for /tmp, /var, /var/log, /var/log/audit, /var/tmp and /home.
• Boot loader passwords: a GRUB password would have to be baked into the image, giving every instance the same secret. Root stays locked with no password. Set your own if you need serial console access (see Step 10).
• Password ageing defaults: the accounts cloud-init creates are key-only. An ageing limit would expire them and lock the SSH key out. Accounts that do have a password are still aged.
• SSH AllowUsers/AllowGroups: a list fixed at build time would refuse accounts you create later. Your security group restricts who can reach port 22.

The seven rules that do not pass

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

Expected output:

file_ownerships_var_log journald_forward_to_syslog package_iptables-persistent_installed package_ufw_removed permissions_local_var_log service_systemd-journal-upload_enabled systemd_journal_upload_url

Six of them fail, and one (file_ownerships_var_log) reports error. Each is the result of a deliberate choice, and each stays in the score rather than being hidden:

Log file ownership (file_ownerships_var_log) reports error, not fail. The check accepts only files owned by root or a syslog account, and Debian has no syslog account. The one file it trips on is /var/log/aide/aide.log, which belongs to the _aide account on purpose. Debian's daily AIDE check (dailyaidecheck.service) runs as _aide and has to rotate its own log. If that file belonged to root, the daily check would fail every day and the instance would report a failed service.

ufw against the nftables and iptables package rules (package_ufw_removed, package_iptables-persistent_installed). The Debian 12 content checks for the nftables and iptables firewall branches whatever firewall you select. ufw is the image's single host firewall, so these two always fail. Adding iptables-persistent would load a second, conflicting ruleset at boot.

Login accounting files (permissions_local_var_log). The Debian 12 check flags every file in /var/log wider than 0640 with no exceptions. That catches wtmp and lastlog (0664) and btmp (0660). Those are the modes login accounting needs, systemd restores them at every boot, and the CIS benchmark itself exempts them. Every other log file is 0640 or stricter.

journald forwarding (journald_forward_to_syslog). The profile selects both "forward the journal to syslog" and "do not forward the journal to syslog", so one of the pair always fails. The image keeps the journal as the log store (ForwardToSyslog=no). rsyslog is installed and running if you want to switch. Set ForwardToSyslog=yes in /etc/systemd/journald.conf and restart systemd-journald.

Remote journal upload (service_systemd-journal-upload_enabled, systemd_journal_upload_url). The benchmark wants the journal sent to a remote log server. The image cannot know yours, and with no address the upload service would fail at every boot, so it is installed but disabled. To use it, set URL= to your collector in /etc/systemd/journal-upload.conf, then run sudo systemctl enable --now systemd-journal-upload.

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/sac/cis-l1-tailoring.xml \
  --profile xccdf_co.sac_profile_cis-l1_ec2_single \
  --results /tmp/cis-check-results.xml --report /tmp/cis-check-report.html \
  /usr/share/xml/scap/ssg/content/ssg-debian12-ds.xml > /tmp/cis-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/cis-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:

oscap exit code: 2 (2 = at least one rule did not pass) {'error': 1, 'fail': 6, 'notapplicable': 51, 'notchecked': 4, 'notselected': 490, 'pass': 335} pass rate: 98.0%

Your own report is at /tmp/cis-check-report.html. The content file is ssg-debian12-ds.xml, the Debian 12 data stream from the SCAP Security Guide 0.1.82 release. Its sha256 is recorded in cis-l1-summary.json. 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 (process IDs vary):

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) 53 on lo ALLOW IN Anywhere
# systemd-resolved loopback stub 127.0.0.54:53 (lo only) Anywhere (v6) on lo ALLOW IN Anywhere (v6) 22/tcp (v6) ALLOW IN Anywhere (v6) 53 (v6) on lo ALLOW IN Anywhere (v6)
# systemd-resolved loopback stub 127.0.0.54:53 (lo only) 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=551,fd=3)) LISTEN 0 4096 127.0.0.54:53 0.0.0.0:* users:(("systemd-resolve",pid=341,fd=16)) LISTEN 0 20 127.0.0.1:25 0.0.0.0:* users:(("exim4",pid=1112,fd=4)) LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=341,fd=14)) LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=551,fd=4)) LISTEN 0 20 [::1]:25 [::]:* users:(("exim4",pid=1112,fd=5))

• Only sshd listens on a network address, on port 22. The DNS stub resolver (systemd-resolved, 127.0.0.53 and 127.0.0.54) and the local mail service (exim4, 127.0.0.1 and ::1 port 25) listen on loopback only. systemd-resolved's LLMNR and multicast DNS responders are switched off.
• The DHCP rule admits only replies from a DHCP server's port 67 to the instance's DHCP client, which is how the instance keeps its address. The port 53 rule applies to the loopback interface only.
• Outbound traffic is allowed, so the SSM agent, the metadata service, DNS, time sync and package updates work.

Opening a port for your own service takes two steps. Allow the port 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

Expected output (the pool servers and timings vary):

active active MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^- 40.160.22.251 3 6 37 13 +2740us[+2740us] +/- 25ms ^- 198.12.95.197 2 6 37 14 +430us[ +455us] +/- 62ms ^- 73.238.61.241 2 6 37 13 +5300us[+5300us] +/- 63ms ^- 23.142.248.8 2 6 37 13 +557us[ +557us] +/- 36ms ^* 169.254.169.123 3 4 377 14 +1038ns[ +26us] +/- 524us

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 Debian pool servers are fallbacks. chrony replaces Debian's default systemd-timesyncd, because the CIS profile wants exactly one time service and chrony can use the Amazon Time Sync Service as its preferred source.

The AWS Systems Manager agent is installed from Amazon's own package at its current release (3.3.5538.0 on this build). It is not in the Debian archive, so apt does not update it. Systems Manager can keep it current for you, through the AWS-UpdateSSMAgent document or the Auto update SSM Agent setting in Fleet Manager.

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

sudo apt-get update -qq apt list --upgradable 2>/dev/null cat /etc/apt/apt.conf.d/20auto-upgrades systemctl is-enabled unattended-upgrades apt-daily-upgrade.timer uname -r

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

Listing... APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1"; enabled enabled 6.1.0-54-cloud-amd64

unattended-upgrades runs daily and installs updates from the Debian and Debian-Security archives automatically. To update everything now, run:

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

Reboot if a new kernel was installed:

sudo systemctl reboot

sudo passwd -S root
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication|x11forwarding|maxauthtries|clientaliveinterval|banner) '
sudo aa-status --enabled && echo "AppArmor: enabled"
sudo aa-status | grep -E '^[0-9]+ profiles are (loaded|in enforce mode|in complain mode)' grep -c nullok /etc/pam.d/common-auth || true systemctl is-system-running

Expected output:

root L 2026-10-21 0 99999 7 -1 maxauthtries 4 clientaliveinterval 300 permitrootlogin no pubkeyauthentication yes passwordauthentication no kbdinteractiveauthentication no x11forwarding no banner /etc/issue.net AppArmor: enabled 12 profiles are loaded. 12 profiles are in enforce mode. 0 profiles are in complain mode. 0 running

• L means the root account is locked.
• maxauthtries 4 and clientaliveinterval 300 come from the CIS profile. SSH allows four authentication attempts per connection and checks idle sessions every five minutes.
• AppArmor is enabled, with every loaded profile in enforce mode (12 of 12 on this build) and none in complain mode. Profiles you add with new software report here too.
• 0 means PAM no longer accepts an empty password (nullok removed from pam_unix).
• running means no service failed during boot.

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:

sudo passwd admin

df -hT /
sudo grep -E 'cc_growpart.*(resized|NOCHANGE)' /var/log/cloud-init.log | tail -1 sudo swapon --noheadings --show | wc -l systemctl is-enabled aidecheck.timer grep -E '^(ExecStart|SuccessExitStatus)=' /etc/systemd/system/aidecheck.service

Expected output with the default 8 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/nvme0n1p1 ext4 7.7G 1.4G 6.0G 19% / 2026-10-24 22:43:23,788 - cc_growpart.py[DEBUG]: '/' NOCHANGE: no change necessary (/dev/nvme0n1, 1) 0 enabled ExecStart=/usr/bin/aide --config /etc/aide/aide.conf --check SuccessExitStatus=1 2 3 4 5 6 7

• Disk layout. The root filesystem is ext4 on partition 1 of the root volume. /boot/efi is a separate small partition.
• 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 1 && sudo resize2fs /dev/nvme0n1p1, or reboot.
• Swap. The image has no swap. Add a swap file yourself if your workload needs one.
• AIDE. The file integrity database is built from the image's own files. The CIS profile runs aide --check at boot and daily at 05:00 (aidecheck.timer). Differences are reported in the journal (journalctl -u aidecheck), and a real AIDE error marks the unit failed. On a new instance, a check may report files that cloud-init creates for that instance, such as its hostname. After you have reviewed the report, refresh the database with sudo aide --config /etc/aide/aide.conf --init and move the new database into place with sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db. Debian's own daily check (dailyaidecheck.timer) also runs, as the _aide account, and writes /var/log/aide/aide.log. That is why the AIDE log files belong to _aide.

The instance uses Debian's own archive: bookworm, bookworm-updates, bookworm-backports and bookworm-security. It reaches them through the mirror list that Debian's cloud images ship in /etc/apt/mirrors/:

apt-cache policy nginx | sed -n 1,3p

Expected output (the version changes over time):

nginx: Installed: (none) Candidate: 1.22.1-9+deb12u10

Install and start software in the usual way, for example sudo apt-get -y install nginx then sudo systemctl enable --now nginx. Open its port in the security group and ufw (Step 7).

The AWS CLI version 2 is on the image as Debian's own awscli package (aws --version reports aws-cli/2.9.19). It uses IMDSv2 and the instance profile automatically, and apt keeps it at Debian 12's release of the package. If you need a newer release, install it from AWS (AWS CLI install guide). That places it in /usr/local/bin, ahead of /usr/bin on the PATH.

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

sudo useradd -m -s /bin/bash -G 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

Because SSH is key-only, a new account needs its key in authorized_keys. The new account has no password, so sudo cannot authenticate it until you give it one with sudo passwd alice. SSH stays key-only, and sudo uses the password.

Password-free sudo is granted only to admin, which cloud-init creates, and to ssm-user, the account Session Manager creates for its sessions.