On this page
Debian 12 hardening begins with knowing what the server actually runs and who can administer it. A checklist is useful only when each control has an owner and a validation step. A hardened image that cannot receive updates, produce usable logs, or be restored after failure is not ready for production.
These steps target Debian 12 (Bookworm) on a systemd host. Package names, SSH policy, and firewall ownership vary by installation. Commands are illustrative. Confirm console access and a tested administrative login before changing SSH or packet filtering on a remote server.
1. Record packages, users and listening services
Start with a snapshot of the installed release, active listeners, failed units, and authorized accounts. Investigate unfamiliar processes; do not disable a service simply because its name is unfamiliar.
cat /etc/debian_version
sudo ss -ltnup
sudo systemctl --failed --no-pager
getent group sudo
Separate customer-facing services from management-only ports. Check provider firewall rules, IPv4 and IPv6, and whether a container runtime adds its own network rules.
2. Use named administrative accounts
Avoid sharing a root password among operators. Create an account for each administrator and grant only the required sudo rights. On Debian, adduser and the sudo group are common, but verify the local policy before granting access.
sudo adduser operator
sudo usermod -aG sudo operator
sudo -l -U operator
Replace operator with the real approved account. Add the administrator's public SSH key using an approved channel. Test a second session as that user before changing direct root or password login. Keep provider console access available for recovery.
3. Review effective SSH policy
Configuration can live in the main file and drop-ins. Validate it before a reload, then inspect effective settings. A line in one file does not prove it wins after all includes are processed.
sudo sshd -t
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) '
sudo systemctl status ssh --no-pager
Only after key-based access is verified should you consider disabling password authentication and direct root login. A mistake here can lock out every remote administrator.
4. Keep security repositories and updates working
Confirm configured package sources correspond to Debian 12 and its security updates. Inspect pending upgrades and plan restarts or reboot where required. Do not add an unverified third-party repository to “get a newer package” without checking its trust and support policy.
sudo apt update
apt list --upgradable
sudo apt upgrade
apt upgrade changes installed software; schedule it with awareness of production services. Afterward, verify critical daemons and whether a restart is needed for patched libraries. Automated updates can help but still need monitoring and a change policy.
5. Set a clear firewall owner
Debian can use nftables or a frontend such as UFW. Choose one mechanism the team understands. Document required SSH, web, monitoring, backup, and internal database traffic. Review both inbound and outbound needs. Test firewall changes from a new SSH session and an external website check; local curl alone is not enough.
sudo nft list ruleset
sudo ss -ltnup
Do not run nft flush ruleset as a quick reset. It can remove rules used by containers or a VPN and leave services exposed or unreachable. Review the current ruleset before editing it.
6. Monitor and restore-test the baseline
Collect service, disk, memory, CPU, and network signals; alert when an agent goes silent. Ensure logs have sensible access control and retention. Back up databases and media off-host with encryption, then restore in an isolated environment. Record the exact Debian version and package set so a recovery host can be built consistently.
Troubleshooting and common errors
- SSH access fails after a change: use the provider console, inspect effective SSH configuration and firewall rules, and restore the last known-good settings.
- Security updates do not appear: inspect Debian sources and package pinning, then compare against official security advisories.
- Service fails after upgrade: read its journal and configuration validation before restarting repeatedly.
- Firewall allows IPv4 but not IPv6: test both address families; don't assume one rule covers both.
- Backups exist but restore fails: rehearse on a test host and document missing dependencies.
Security considerations
Use least privilege, reviewed repositories, SSH keys, network restrictions, and a monitored backup path together. Do not publish full host inventories, secret-bearing logs, or private network topology. Preserve an auditable record of who changed a hardening setting and how it was verified.
FAQ
Is Debian 12 secure without extra tools?
It provides a supported security-update process and strong defaults, but operational security still depends on patching, access control, firewall scope, logging, and recovery.
Should every service run behind a firewall?
Each service should be reachable only by the clients that need it. Host and provider firewalls can help enforce that policy, alongside service-level authentication.
Is a VPS snapshot sufficient disaster recovery?
Not necessarily. Verify consistency, retention, failure domain, and independent restore procedures.
Continue reading
Compare Ubuntu 24.04 post-installation security, then set up Linux firewall controls. Contact East4Serv for a reviewed Debian operations baseline.
References: Debian Reference and Debian security information.