Debian 12 CIS Hardening Guide: A Step-by-Step Server Baseline

What changed for Debian 12 and its CIS baseline

Debian 12 “Bookworm” entered the Debian LTS phase on July 12, 2026. Security support is scheduled through June 30, 2028, while Debian 13 is now the current stable release. Debian recommends upgrading to Debian 13 where practical. If you must keep Bookworm, confirm your CPU architecture and installed packages remain covered by LTS, keep the Bookworm security sources configured, and plan a tested migration before the support window closes.

The current CIS listing includes the CIS Debian Linux 12 Benchmark v2.0.0. CIS announced this as a substantial update in 2026: it added, removed, moved, and revised recommendations. Older Debian 12 checklists and automation may therefore target a different baseline. This guide uses the v2.0.0 benchmark as the assessment reference, but it does not reproduce every control or claim a passing result. Use the exact benchmark and profile accepted by your organization.

References: Debian’s Bookworm LTS handover announcement, the CIS Debian Benchmark listing, and CIS’s June 2026 benchmark update.

Before hardening: select a profile and recovery path

CIS hardening is not a one-size-fits-all shell script. A Level 1 profile is a practical starting point for many production servers; Level 2 adds defense in depth and can have a stronger effect on compatibility and operations. CIS recommends testing the chosen recommendations in a non-production environment first. If a regulator, customer contract, or internal policy names a profile, follow that specific requirement.

• Record the target as Debian 12 Bookworm, the CIS benchmark version, and the applicable server profile.
• Take a tested backup or VM snapshot and confirm console or out-of-band access before changing remote-login or firewall settings.
• Write down required services, ports, users, scheduled jobs, mount points, and application dependencies.
• Define who can approve exceptions and where scan reports and change records will be retained.

CIS describes Level 1 as a baseline profile and Level 2 as a more restrictive defense-in-depth profile. See the official CIS profile FAQ before choosing between them.

1. Confirm the Debian release and LTS coverage

Capture the host’s release, architecture, kernel, active services, and listening sockets before making changes:

cat /etc/os-release
dpkg --print-architecture
uname -r
systemctl --failed
sudo ss -tulpn

Bookworm’s LTS coverage is limited to listed architectures and excludes some packages. Check Debian’s Bookworm LTS package information, especially if the machine runs software outside the main Debian archive. A CIS score does not expand Debian’s security-support scope.

2. Bring the system up to date safely

Confirm the APT sources use the bookworm codename and include the current Debian security/LTS sources for this installation. Avoid changing a production server’s sources from bookworm to stable as a shortcut; the stable alias now points to Debian 13 and can turn a security update into a distribution upgrade.

sudo apt update
sudo apt upgrade

Review the proposed package changes before confirming them. Schedule a maintenance window for upgrades that replace a kernel or restart a critical service. Do not use full-upgrade without reviewing package removals and dependency changes. For unattended patching, Debian’s unattended-upgrades package can automate installation from configured APT sources; decide whether automatic reboots and application restarts fit the host’s change policy before enabling them.

3. Inventory software and remove only what the role does not need

Use your service inventory and listening-port list to identify unexpected network exposure. Check package ownership before removing a daemon, and confirm whether a service is required by the application, monitoring agent, backup software, or local automation. Disabling a service can break a dependency that is not obvious from its name.

systemctl --type=service --state=running
sudo ss -lntup
apt-mark showmanual

Remove unused packages through APT only after an owner has confirmed they are not needed. For services that must remain installed but should not start, document the reason and use the exact CIS recommendation for the selected profile. Avoid commands that disable every service in a category or purge packages in bulk.

4. Tighten SSH without locking yourself out

For an SSH-managed server, create and test a named administrator account with sudo before restricting root or password login. Confirm that key-based login works from a second terminal session and that you can reach the console. Then apply only the SSH settings required by your profile and operational model. Common controls include preventing direct root login and limiting password authentication, but these are unsafe to apply before another working authentication method exists.

After editing /etc/ssh/sshd_config or an included configuration file, validate syntax and effective values, then reload SSH:

sudo sshd -t
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
sudo systemctl reload ssh

Keep the existing session open and test a new login before closing it. If centralized identity or emergency password access is required, do not disable that path until the replacement has been tested. Debian’s Bookworm OpenSSH server manual documents supported settings; the benchmark provides the applicable target values.

5. Configure one host firewall with the required traffic

Choose a firewall management method that fits the host—such as nftables or an existing orchestration-managed firewall—and use one authoritative ruleset. Before enforcing a default-deny inbound policy, allow the management path and every service the server must provide. An incorrect rule can disconnect a remote host or interrupt a health check without changing the application itself.

sudo nft list ruleset

Compare the live rules with your approved network design, then test from an authorized external host. If your organization uses a firewall manager such as UFW, inspect its rules through that manager rather than layering an independent ruleset on top. Debian’s nftables manual describes the command syntax; the right allowlist depends on the server role and network segmentation.

6. Verify AppArmor and avoid weakening application confinement

AppArmor is Debian’s supported Mandatory Access Control framework. Check whether it is installed, enabled, and enforcing profiles for the services that matter:

sudo aa-status
systemctl status apparmor

If AppArmor is absent, first determine whether the host image or security policy intentionally uses another Linux Security Module. Do not install or enforce new profiles in production without testing application behavior. A profile in complain mode records policy violations but does not block them; enforcing mode can stop unauthorized file or network access, and a poorly tested profile can also break a legitimate service.

Debian’s Bookworm AppArmor package documentation describes the userspace components. Apply the exact benchmark recommendation for profile status and exceptions rather than assuming that package installation alone satisfies it.

7. Add audit and log retention that you can actually monitor

If required by the selected CIS profile, install and enable Debian’s audit daemon, then apply the rules from the current benchmark and your change-control process:

sudo apt install auditd
sudo systemctl enable --now auditd
sudo systemctl status auditd
sudo auditctl -l

Verify that the expected rules load after reboot and that audit records are collected, retained, and protected from routine users. Audit rules can increase storage and event volume, so size retention and alerting for the host’s workload. If logs are forwarded centrally, confirm delivery and access controls there as well. Debian’s Bookworm auditd package page explains that it provides utilities for storing and searching kernel audit records; installing it does not automatically configure the full CIS rule set.

8. Review kernel, filesystem, and account controls against the exact checklist

Work through the benchmark’s controls for kernel parameters, file permissions, password policy, login banners, scheduled tasks, and filesystem mount options. These settings depend on the host’s role. For example, noexec on a temporary filesystem may conflict with an installer or application that executes files there; disabling IPv6 can break a network that uses it; and restrictive account aging can conflict with centrally managed identities.

For each recommendation, capture the audit result, the required value, the actual value, and whether the change is applicable. Apply related settings in a managed configuration file or configuration-management system, then verify the effective runtime state. Avoid broad recursive chmod or chown commands: they can silently damage package ownership, application access, and system recovery.

9. Assess, remediate, and document exceptions

Run an assessment tool that explicitly supports CIS Debian Linux 12 Benchmark v2.0.0 and the profile selected in step 1. CIS lists assessment and automation resources on its Debian benchmark page; some are available only to CIS SecureSuite members. A PDF checklist can support manual review, but do not infer compliance from a generic Linux scanner or from a CIS benchmark for Debian 13.

Remediate findings in small batches. After each batch, verify access, application health, required ports, scheduled backups, log collection, and monitoring. Re-run the assessment and compare the result with the prior report. For every accepted deviation, record the control, reason, compensating measure, owner, and review date. “Not applicable” should be supported by evidence, not used to make a score look better.

Operational checklist

• Use the current Debian 12 v2.0.0 benchmark and the correct server profile.
• Keep Bookworm’s security sources current and confirm LTS coverage for this host’s architecture and packages.
• Preserve a recovery path before changing SSH, firewall, boot, or filesystem behavior.
• Test Level 2 and application-impacting changes outside production first.
• Record assessment results, exceptions, package updates, and reboot status.
• Plan migration to Debian 13 before Debian 12 LTS ends on June 30, 2028, where the workload permits.

Hardening can reduce exposure, but CIS alignment is established by assessing the specific benchmark version and profile, applying the required controls, validating the result, and documenting authorized exceptions. It is not a guarantee that a host is secure or a substitute for the organization’s compliance assessment.