Debian Hardening: Securing Debian Servers

Debian servers are often hardened from generic Linux checklists that miss what is specific to Debian: its release and LTS lifecycle, the security archive and advisory feeds, APT keyring handling, AppArmor rather than SELinux, and the changes Debian 13 made to /tmp, sysctl and OpenSSH. This guide covers those Debian specifics for administrators, platform engineers and auditors running Debian 12 (bookworm) and Debian 13 (trixie) servers. It follows the account, privilege, service identity, logging and baseline structure of an identity-aware hardening review, maps controls to CIS Benchmarks and NIST SP 800-53, and lists the misconfigurations that recur on Debian estates. Release dates and support status were checked on debian.org on 8 November 2026. Distribution-neutral controls (SSH options, kernel parameters, auditd rules) are covered in the Linux Server Hardening Guide; this page does not repeat them.

This is an independent guide from NHI Mgmt Group, based on Debian's public documentation as of November 2026. It is not sponsored or reviewed by Debian. Product features change, so confirm settings against Debian's current documentation.

Key takeaways

Know which support phase you are in. Debian 13 is stable; Debian 12 left regular security support on 11 July 2026 and is now under LTS until 30 June 2028; Debian 11's LTS ended on 31 August 2026.
Patch from the security archive automatically. Keep trixie-security (or bookworm-security) in APT sources, subscribe to DSA and DLA feeds, and let unattended-upgrades apply security updates with logs you actually review.
Pin repository trust with Signed-By. Every APT source should name its own keyring in deb822 .sources files, so a third-party key cannot sign packages for the Debian archive.
Use the controls Debian ships. AppArmor is the default mandatory access control, the systemd journal is the default log store, and Debian 13 mounts /tmp as tmpfs and reads sysctl settings only from sysctl.d directories.
Audit against a Debian benchmark. CIS publishes Debian-specific benchmarks (Debian 13 v1.1.0 and Debian 12 v2.0.0 at the time of writing); generic RHEL-derived checks give false findings on Debian.

How identity and access work in Debian

Debian authenticates local users through PAM, with accounts in /etc/passwd and hashes in /etc/shadow, and optionally through SSSD for directory accounts. Remote access is almost always OpenSSH. Debian-specific points matter at install time and at upgrade time.

Root at install: if no root password is set in the installer, the root account is locked and the first user is placed in the sudo group. That is the better default for servers: decide it deliberately and record which model each build uses.
Directory accounts: join Active Directory or LDAP through SSSD and restrict logins with access_provider rules and group-based sudo. Debian 13's release notes state that sudo-ldap will be removed in Debian 14 (forky) and recommend libsss-sudo, so migrate sudo rules held in LDAP now. See the SSSD and Linux Active Directory Integration Guide.
OpenSSH versions: Debian 13 ships OpenSSH 10.0p1 (Debian 12 shipped 9.2p1). DSA keys are no longer supported at all, even with HostKeyAlgorithms or PubkeyAcceptedAlgorithms overrides; generate Ed25519 keys before upgrading. openssh-server also no longer reads ~/.pam_environment by default because of that file's security history.
Keys over passwords: treat authorized_keys files as credentials, because adding one is a common persistence step (ATT&CK T1098.004 SSH Authorized Keys). Prefer SSH certificates or centrally managed keys. See the SSH Key Management Guide.

Release	Codename	Released	Regular security support ends	LTS ends	Action now
Debian 13	trixie	9 August 2025	9 August 2028 (planned)	30 June 2030 (planned)	Standard target for new builds
Debian 12	bookworm	10 June 2023	11 July 2026 (passed)	30 June 2028	Running on LTS: plan the upgrade to 13
Debian 11	bullseye	14 August 2021	14 August 2024 (passed)	31 August 2026 (passed)	Out of community support: upgrade or obtain extended support

Debian's release page also lists Extended LTS end dates (2035 for 13, 2033 for 12, 2031 for 11); ELTS is a commercial offering outside the Debian project's own security support, so treat it as a contract decision. LTS covers a subset of architectures and packages: confirm your packages are included before relying on it.

Admin roles and privileged access

On Debian, administrative rights come from membership of the sudo group (granted by the default %sudo ALL=(ALL:ALL) ALL rule) and from other privileged groups that are easy to overlook.

Group or mechanism	Effective power	Hardening step
`sudo`	Full root through sudo	Keep membership to named admins; use drop-in files in `/etc/sudoers.d/` for narrower roles
`adm`	Read most logs in `/var/log`	Treat as sensitive; logs can contain tokens and personal data
`systemd-journal`	Read the full system journal	Grant only to log readers and agents
`docker` (if installed)	Root-equivalent through the Docker socket	Never add ordinary users; prefer rootless containers
`disk`	Raw access to block devices, so to all data	Should be empty of human users
Root SSH login	Direct root access	Set `PermitRootLogin no` in a file under `/etc/ssh/sshd_config.d/`

Least privilege in sudo: avoid NOPASSWD: ALL, avoid commands that spawn shells or editors, and log sudo input with Defaults log_input,log_output where your logging can hold it. Abuse of sudo caching and rules is ATT&CK T1548.003. See the sudo and sudoers Security Guide.
Break-glass: keep one local admin account with a vaulted password for when the directory is down, and alert on its use.
Recertify: review getent group sudo adm systemd-journal docker disk output each quarter against your access records.

Integrations, API tokens and service accounts

Servers carry non-human identities: service users, automation SSH keys, configuration management agents, backup agents and APT repository credentials. Each needs an owner and the narrowest access.

Service users: Debian packages create system users with no login shell. For your own services, use systemd's DynamicUser=yes or a dedicated system user created with adduser --system, never root or a human account. Add sandboxing such as ProtectSystem=strict, ProtectHome=yes, NoNewPrivileges=yes and PrivateTmp=yes, and check exposure with systemd-analyze security <unit>. Unexpected new units are a persistence signal (T1543.002 Systemd Service). See the Linux Service Accounts and Keytab Management Guide.
Automation keys: restrict deployment keys with from=, command= and no-port-forwarding options in authorized_keys, or move to short-lived SSH certificates.
Secrets on disk: keep tokens out of world-readable unit files and environment files. Use systemd credentials (LoadCredential=) or a secrets manager agent. See the Secrets Management Guide.
Repository trust: Debian 13's upgrade notes move APT to deb822 .sources files in /etc/apt/sources.list.d/. The documented security archive entry is:

Types: deb
URIs: https://security.debian.org/debian-security
Suites: trixie-security
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Give every third-party repository its own Signed-By keyring rather than a key trusted for all sources, and remove keys of repositories you no longer use. The trixie upgrade notes say the .gpg keyring paths are compatibility symlinks to .pgp paths that will eventually disappear, and recommend changing Signed-By to the .pgp path. See the Linux Package Signing and Repository Trust Guide.

Logging and detection

On current Debian the systemd journal is the primary log store; a minimal install does not include a traditional syslog daemon, so /var/log/auth.log may not exist unless you install rsyslog. Decide which pipeline you use and make it persistent: set Storage=persistent in a journald.conf.d drop-in (or create /var/log/journal), then forward to your SIEM.

What to watch	Debian source	Why
SSH logins, failures and source IPs	`journalctl -u ssh`	Brute force (T1110) and use of stolen keys
sudo use and denials	journal (`_COMM=sudo`), sudo I/O logs	Privilege escalation
Package installs and removals	`/var/log/dpkg.log`, `/var/log/apt/history.log`	Unauthorised software, tampering
Automatic updates	`/var/log/unattended-upgrades/unattended-upgrades.log` and `-dpkg.log`	Proof that patching ran, and failures
AppArmor denials	Kernel audit messages in the journal or `audit.log`	Confined services attempting unexpected access
New systemd units, timers and cron entries	auditd watches on `/etc/systemd/system` and `/etc/cron*`	Persistence (T1543.002, T1053.003)

Install auditd for kernel audit records; rules are distribution-neutral and covered in the Linux Logging and auditd for Defenders Guide.

Measure: percentage of servers on a release in regular security support; median days from DSA publication to installation; percentage of hosts where the last unattended-upgrades run succeeded in the past 48 hours; number of APT sources without Signed-By; members of sudo per host; percentage of internet-facing services running under an AppArmor profile in enforce mode; CIS benchmark score trend.

Hardening baseline

Patching and lifecycle

Track advisories. Debian publishes DSAs for the stable release and DLAs for LTS, both CVE-compatible, through the debian-security-announce and debian-lts-announce lists, RSS and the Security Tracker, which Debian calls the primary source for security information. Debian also publishes OVAL data for scanners.
Automate security updates. Install unattended-upgrades, which runs via apt-daily-upgrade.service and reads /etc/apt/apt.conf.d/50unattended-upgrades. Test with unattended-upgrade --dry-run --debug, then monitor its logs.
Handle restarts. Library updates do not protect running processes until they restart. Use needrestart or schedule reboots for kernel updates, and track hosts with pending reboots.
Check support coverage. Debian 13's release notes state that qtwebengine is not covered by security support and that Go and Rust packages get limited security support. The debian-security-support package reports installed packages with limited or ended support.
Upgrade on time. Plan major upgrades well before LTS ends. On Debian 13, i386 is no longer a regular architecture, and Debian recommends reinstalling such systems as amd64.

Debian 13 changes that affect a baseline

Change in Debian 13	Effect on hardening
`/tmp` is a tmpfs by default (up to 50% of RAM) on new and upgraded systems after reboot	CIS "separate /tmp partition" checks are met by `tmp.mount`; add `nosuid,nodev,noexec` options with `systemctl edit tmp.mount` where workloads allow
New installs clean `/tmp` after 10 days and `/var/tmp` after 30	Do not stage forensic or build artefacts there
`/etc/sysctl.conf` is no longer read	Move kernel hardening settings to `/etc/sysctl.d/*.conf`, or they silently stop applying after upgrade
`ping` no longer has `CAP_NET_RAW`; it uses ICMP sockets gated by `net.ipv4.ping_group_range`	Fewer privileged binaries; check the setting is present after upgrade
OpenSSH 10.0p1, no DSA support	Replace DSA keys before upgrading
arm64 PAC and BTI enabled automatically where hardware supports them	Additional control-flow protection at no configuration cost
dm-crypt plain mode defaults changed; LUKS unaffected	Use LUKS for encrypted volumes, and install `systemd-cryptsetup` before rebooting into 13

Mandatory access control, firewall and minimal build

AppArmor: enabled by default on Debian. Check with aa-status, install apparmor-utils and apparmor-profiles, and move profiles from complain to enforce with aa-enforce after testing. See the AppArmor Guide.
Firewall: nftables is the default framework; define a default-drop input policy in /etc/nftables.conf and enable nftables.service. See the Linux Firewall Guide.
Minimal install: deselect desktop and "standard system utilities" tasks in the installer, then review systemctl list-units --type=service --state=running and listening sockets with ss -tulpn.
Secure Boot: Debian boots with a signed shim on amd64 and arm64. Keep it enabled. See the Linux Secure Boot and Shim Guide.

Rolling out the baseline

Pick the CIS Debian benchmark for your release and decide Level 1 or Level 2 per server role, documenting exceptions.
Scan a pilot group without remediation to get a baseline score. See the OpenSCAP and Linux Compliance Scanning Guide.
Encode settings in configuration management (drop-in files under sshd_config.d, sysctl.d, sudoers.d), so rollback is removing a file.
Apply to a canary ring, then widen. Keep a console path (out-of-band or cloud serial console) before changing SSH or firewall settings.
Rescan on a schedule and alert on drift.

Small versus large estates: a handful of servers can be hardened with the benchmark and unattended-upgrades alone; at scale, build golden images, enforce settings through configuration management, and feed Debian's OVAL data to your vulnerability scanner so findings reflect Debian's backported fixes rather than upstream version numbers.

Framework mapping

Control area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	CIS Controls v8.1
Benchmark baseline, drop-in configuration	CM-6 Configuration Settings	PR.PS-01	Control 4
Minimal packages and services	CM-7 Least Functionality	PR.PS-01	Control 4
Security archive, unattended-upgrades, lifecycle	SI-2 Flaw Remediation	PR.PS-02	Control 7
sudo groups, root login, service users	AC-6 Least Privilege, IA-2	PR.AA-05	Controls 5 and 6
Persistent journal, auditd, forwarding	AU-2 Event Logging	DE.CM-09	Control 8

Common misconfigurations

Running past regular support without noticing. Debian 12 hosts moved to LTS in July 2026 and Debian 11 hosts lost LTS in August 2026; scanners may not flag this if they only compare package versions.
Kernel settings in /etc/sysctl.conf after upgrading to 13. The file is no longer read, so hardening silently disappears.
Third-party repositories trusted globally. Keys added without Signed-By scoping let that key sign packages for any source.
Unattended-upgrades installed but never checked. Held packages, dpkg prompts or full disks stop updates; only the log shows it.
AppArmor profiles left in complain mode, which logs but does not block.
Checking for /var/log/auth.log on a journald-only host. Detection rules and audit scripts that expect syslog files report clean when nothing is being collected.

Practitioner checklist

Inventory every Debian host by release and support phase, and schedule upgrades for anything on LTS or beyond it.
Confirm the security archive is configured in deb822 format with a Signed-By keyring, and scope every third-party key.
Enable unattended-upgrades for security updates, monitor its logs and track pending reboots.
Subscribe the operations team to debian-security-announce and debian-lts-announce and feed Debian OVAL data to scanners.
Lock root SSH login, keep the sudo group small, and review adm, systemd-journal, docker and disk membership quarterly.
Migrate sudo rules from sudo-ldap to libsss-sudo before Debian 14.
Run custom services under dedicated or dynamic users with systemd sandboxing and no secrets in unit files.
Move sysctl settings to /etc/sysctl.d/, replace DSA SSH keys and harden tmp.mount options as part of the Debian 13 upgrade.
Enforce AppArmor profiles for exposed services and apply a default-drop nftables policy.
Make the journal persistent, forward it with dpkg and audit logs to the SIEM, and scan against the CIS Debian benchmark on a schedule.

Standards and references

Related NHI Mgmt Group resources: Linux Server Hardening Guide · CIS Benchmarks Guide · Patch Management Guide · Unix and Linux Privileged Access Guide