Linux Server Hardening: Checklist Based on CIS and BSI

Want to know how well your Linux servers are secured today? The server audit reviews hardening, patch level, access and backups and delivers a prioritised list of findings.

A freshly installed Linux server works, but it is not hardened. Distributions choose defaults that work on as many systems as possible. An internet-facing server is exposed to automated login attempts and scans. Hardening reduces the attack surface to what the server actually needs.

This checklist summarises the most important measures for Debian, Ubuntu and the RHEL family. Each measure has an audit command and a reference to the German BSI IT-Grundschutz. The CIS Benchmarks cover the same topics in detail and work well as an audit baseline.

Contents

• References: CIS Benchmarks and BSI IT-Grundschutz
• Checklist: hardening a Linux server
• Securing SSH
• Firewall and network services
• Accounts, privileges and kernel protection
• Logging, time and intrusion detection
• Verifying hardening: Lynis, OpenSCAP and Ubuntu Security Guide
• Common mistakes
• Our approach at WZ-IT
• Status and methodology

References: CIS Benchmarks and BSI IT-Grundschutz

Sources: CIS Benchmarks FAQ, CIS Ubuntu Linux, CIS Debian Linux, CIS Red Hat Enterprise Linux, BSI SYS.1.3 (German), BSI SYS.1.1 (German).

According to CIS, Level 1 is a base recommendation that can be implemented fairly promptly and has little performance impact. Level 2 is considered defense in depth for environments where security is paramount. For most business servers Level 1 is the realistic baseline, with individual Level 2 items added based on risk.

Checklist: hardening a Linux server

Securing SSH

SSH is reachable from the internet on almost every server and therefore a frequent target of automated login attempts. In SYS.1.3.A8 the BSI requires interactive remote access to use SSH exclusively and authentication to rely primarily on certificates rather than passwords.

The relevant options in /etc/ssh/sshd_config according to the OpenSSH manual:

• PasswordAuthentication no: the default is yes. Together with KbdInteractiveAuthentication no, login is restricted to keys. Test your own key access first.
• PermitRootLogin no: the default is prohibit-password, which still allows root to log in with a key. With no, administration runs through personal accounts and sudo, which makes actions attributable to a person.
• KbdInteractiveAuthentication no: prevents password prompts through keyboard-interactive; the default is yes.
• AllowGroups: restricts login to members of specific groups.

After every change, sshd -t checks the syntax and sshd -T shows the effective configuration. A second open session prevents a mistake from locking you out.

Firewall and network services

SYS.1.1.A19 requires incoming and outgoing communication to be restricted by a rule set to the necessary partners, protocols and ports. Debian and Ubuntu offer nftables or ufw, the RHEL family firewalld.

Proven approach:

1. List all listening services with ss -tulpn.
2. Bind services that are only needed locally, such as databases and caches, to 127.0.0.1.
3. Only allow inbound what must be reachable from outside, typically HTTP, HTTPS and SSH, with SSH ideally only from known networks or via VPN.
4. Set the default policy for incoming connections to drop.

fail2ban or CrowdSec help against repeated login attempts by blocking suspicious sources based on logs. They replace neither key-based login nor the firewall. For the network firewall in front of the servers there is managed OPNsense firewall operations.

Accounts, privileges and kernel protection

• Accounts: every person gets their own account; shared accounts are removed. Accounts of former staff and unused service accounts are deleted. SYS.1.3.A2 requires every UID and GID to occur only once.
• sudo: grant privileges as narrowly as possible and edit /etc/sudoers only with visudo. SYS.1.3.A6 recommends the administration tools instead of editing /etc/passwd, /etc/shadow, /etc/group and /etc/sudoers directly.
• Kernel protection: SYS.1.3.A4 requires ASLR and DEP/NX to be active. According to the kernel documentation, the value 2 for kernel.randomize_va_space additionally enables heap randomisation, i.e. full randomisation.
• Mandatory access control: SYS.1.3.A10 recommends AppArmor or SELinux with the default profiles enabled. Ubuntu and Debian use AppArmor, the RHEL family SELinux. Disabling it to work around an application problem is a common finding.
• File systems: separate partitions for /tmp or /var/log with options such as nodev, nosuid and noexec are among the CIS Benchmark recommendations and are easiest to implement during installation.

Logging, time and intrusion detection

SYS.1.1.A10 lists the minimum events: system starts and reboots, successful and failed logins, failed permission checks, blocked data flows (violations of ACLs or firewall rules), changes to users, groups and privileges, security-relevant error messages and warnings from security systems such as antivirus. Logs should additionally be sent to a central system so an attacker cannot delete them on the server itself.

Without synchronised time, events cannot be correlated across systems; timedatectl shows the status of systemd-timesyncd or chrony. For elevated protection requirements, SYS.1.1.A27 names host-based intrusion detection, for example with Wazuh for file integrity and event correlation.

Verifying hardening: Lynis, OpenSCAP and Ubuntu Security Guide

An automated report shows deviations. It does not decide which of them make sense in a given operation. Every deviation from the benchmark is therefore either implemented or documented with a justification, because SYS.1.1.A16 provides that decisions on security-relevant settings are documented and justified.

Common mistakes

• Hardening without repetition: a server hardened once drifts with every change. SYS.1.1.A24 requires regular security reviews.
• Level 2 everywhere: strict profiles without testing break applications. Level 1 as the base, Level 2 selectively.
• SELinux or AppArmor switched off instead of adjusting the profile.
• Database listening on all interfaces and reachable from the internet.
• Backup stored on the same server, lost together with it on encryption or disk failure.
• No more updates: hardening does not protect against known flaws in an unsupported release, see Linux end of life.

Our approach at WZ-IT

The server audit from 290 euros net one-time reviews security and hardening, backup configuration and system health and delivers a findings overview with prioritised measures. The audit works from the inside and is not a penetration test.

Implementation and ongoing maintenance are covered by Linux server management from 149.90 euros net per month for the first server: updates in maintenance windows, 24/7 monitoring, backup verification with up to 250 GB of backup storage per server and operations documentation of patches, alerts and backup status. We manage servers remotely at the existing provider or on-premises.

Further guides

• Linux patch management: process, deadlines and evidence
• Server monitoring: what needs to be monitored
• Proxmox hardening: checklist for virtualisation hosts
• Linux server takeover checklist: access and inventory before a change of operator

Status and methodology

• Collected: 26 October 2026.
• References: BSI IT-Grundschutz Compendium edition 2023, modules SYS.1.1, SYS.1.3 and OPS.1.1.3; CIS Benchmarks FAQ on profiles and distribution. The content of individual CIS Benchmarks is not reproduced, because the download requires registration.
• Defaults: OpenSSH according to the official manual, kernel according to the kernel documentation.
• Licenses: license files of the project repositories; Ubuntu Security Guide according to Canonical documentation.
• Not included: hardening of applications such as web servers and databases, Windows Server, container platforms.

Sources

• BSI IT-Grundschutz SYS.1.3 Linux and Unix servers (edition 2023, German)
• BSI IT-Grundschutz SYS.1.1 General server (edition 2023, German)
• BSI IT-Grundschutz OPS.1.1.3 Patch and change management (edition 2023, German)
• CIS Benchmarks FAQ
• CIS Benchmarks Ubuntu, Debian, Red Hat Enterprise Linux
• OpenSSH: sshd_config
• Linux kernel documentation: sysctl kernel
• Lynis
• OpenSCAP and ComplianceAsCode
• Ubuntu Security Guide