Linux-Server absichern: Basishärtung für den Produktivbetrieb

Ein frisch installierter Debian- oder Ubuntu-Server ist nicht kaputt konfiguriert, aber er ist offen konfiguriert. Sobald eine öffentliche IPv4-Adresse erreichbar ist, treffen die ersten automatisierten Verbindungsversuche auf Port 22 ein – in der Praxis innerhalb von Minuten, nicht Tagen. Die Angreifer sind keine Menschen, sondern Scanner, die Adressbereiche durchgehen, Banner einsammeln und Zugangsdaten aus Leak-Listen durchprobieren. Wer nichts unternimmt, verlässt sich darauf, dass niemand ein schwaches Passwort gesetzt und niemand eine veraltete Bibliothek installiert hat.

Die Kernantwort ist unspektakulär: Basishärtung ist kein Produkt, sondern eine Handvoll Konfigurationsentscheidungen. Angriffsfläche reduzieren (nur installieren und lauschen lassen, was gebraucht wird), SSH auf Public-Key-Authentifizierung umstellen und Passwörter abschalten, einen Paketfilter mit Default-Policy drop betreiben, Sicherheitsupdates automatisch einspielen, Dienste unter eigenen Systemnutzern mit systemd-Sandboxing laufen lassen, Logs zentral und lesbar halten und Backups mit einem tatsächlich geprobten Restore vorhalten. Diese sieben Punkte zielen nicht auf einzelne Angreifer, sondern auf die Voraussetzungen automatisierter Massenangriffe: erratbare Passwörter, vergessene offene Dienste, ungepatchte Pakete – und Masse ist das Geschäftsmodell.

Dieser Artikel zeigt die dazugehörigen Kommandos und Konfigurationsausschnitte und erklärt bei jeder Maßnahme, warum sie wirkt. Geprüft auf Debian 13 (Trixie) und Ubuntu Server 24.04 LTS mit OpenSSH 10.x und nftables 1.1.x. Am Ende steht eine Checkliste, die sich als Abnahmekriterium für neue Systeme verwenden lässt.

Angriffsfläche

Die Summe aller Punkte, an denen ein System Eingaben von außen annimmt: offene Ports, installierte Dienste mit Netzwerkzugriff, ausgelieferte Endpunkte, Cron-Jobs, die fremde Daten verarbeiten, sowie jedes Paket, dessen Code im Prozessraum eines dieser Dienste landet. Härtung verkleinert diese Menge, statt sie nur zu überwachen.

Angriffsfläche reduzieren, bevor Sie irgendetwas härten

Jede Zeile Code, die nicht installiert ist, hat keine Sicherheitslücke. Deshalb beginnt Härtung nicht mit Firewall-Regeln, sondern mit einer Bestandsaufnahme. Ein Cloud-Image bringt regelmäßig Cloud-Agenten, Mailtransport-Agenten, Monitoring-Reste und Entwicklungswerkzeuge mit, die auf einem Produktivsystem nichts zu tun haben.

Installierte Pakete und laufende Dienste inventarisieren

# Manuell installierte Pakete auflisten – die Kandidaten für den Rückbau
apt-mark showmanual | sort

# Alle aktiven Units mit ihrem Startgrund
systemctl list-units --type=service --state=running

# Nicht mehr benötigte Abhängigkeiten und alte Kernel entfernen
apt-get autoremove --purge

Anschließend prüfen, wer tatsächlich auf einem Socket lauscht. ss zeigt anders als ältere Werkzeuge direkt den Prozess:

ss -tulpnH | awk '{print $1, $5, $7}'

Interessant ist die Spalte mit der lokalen Adresse. Ein Dienst auf 0.0.0.0:5432 ist aus dem Internet erreichbar, ein Dienst auf 127.0.0.1:5432 nicht. Datenbanken, Caches, Metrik-Exporter und Admin-Oberflächen gehören auf das Loopback-Interface oder in ein privates Netz und werden bei Bedarf über SSH-Portweiterleitung oder einen Reverse Proxy erreicht. Das ist wirksamer als jede Firewall-Regel, weil der Socket gar nicht erst extern existiert – ein falsch geladenes Regelwerk kann ihn dann auch nicht versehentlich freigeben.

Für HTTP-Dienste vor einem Reverse Proxy lohnt derselbe Gedanke auf Anwendungsebene: nach außen nur TLS, keine Versionsbanner, keine Verzeichnislisten.

server {
    listen 443 ssl;
    http2 on;
    server_name beispiel.tld;

    server_tokens off;
    add_header Strict-Transport-Security "max-age=63072000" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server_tokens off verhindert nicht den Angriff, aber es entfernt die Information, mit der ein Scanner entscheidet, ob ein Exploit für diese Minor-Version lohnt. Ungezielte Angreifer sortieren nach Trefferwahrscheinlichkeit.

SSH härten: der Dienst, der am häufigsten angegriffen wird

SSH ist auf den meisten Servern der einzige interaktive Zugang und damit das lohnendste Ziel. Die Härtung besteht aus drei Entscheidungen, die zusammen wirken: Authentifizierung ausschließlich über Schlüssel, kein direkter Root-Login, und eine explizite Liste zugelassener Konten.

Public-Key-Authentifizierung und das Abschalten von Passwörtern

Ein Passwort ist ein Geheimnis, das bei jeder Anmeldung übertragen und geraten werden kann. Ein Ed25519-Schlüsselpaar verlässt die Arbeitsmaschine nie: der Server kennt nur den öffentlichen Teil, die Anmeldung ist eine Signatur über einen Zufallswert. Damit sind Brute-Force- und Credential-Stuffing-Angriffe nicht erschwert, sondern strukturell wirkungslos.

# Auf der Arbeitsmaschine
ssh-keygen -t ed25519 -C "arbeitsplatz-2026"
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@server.beispiel.tld

Die Serverkonfiguration gehört nicht in /etc/ssh/sshd_config, sondern in eine eigene Datei unter /etc/ssh/sshd_config.d/. Debian und Ubuntu laden dieses Verzeichnis per Include am Dateianfang; eigene Dateien überleben so ein Paketupdate ohne Merge-Konflikt.

# /etc/ssh/sshd_config.d/10-hardening.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AllowUsers deploy admin
AllowTcpForwarding no
X11Forwarding no
MaxAuthTries 3
MaxSessions 4
LoginGraceTime 20
ClientAliveInterval 300
ClientAliveCountMax 2

PermitRootLogin no erzwingt den Zwischenschritt über ein benanntes Konto und sudo. Der Gewinn ist nicht nur Zugriffskontrolle, sondern Nachvollziehbarkeit: im Audit-Log steht, welcher Mensch welche privilegierte Aktion ausgelöst hat. AllowUsers dreht die Logik von „alles außer“ auf „nur diese“ – neu angelegte Systemnutzer bekommen dadurch nicht versehentlich Fernzugriff. KbdInteractiveAuthentication no ist wichtig, weil sonst über PAM ein zweiter, passwortbasierter Pfad offen bleibt, obwohl PasswordAuthentication bereits no ist. AllowTcpForwarding no schließt Portweiterleitungen; wer eine Datenbank auf dem Loopback-Interface über einen SSH-Tunnel administriert, gibt die Direktive gezielt für dieses Konto per Match User wieder frei, statt sie global auf yes zu setzen.

Die Port-Frage ehrlich bewertet

Das Verschieben von SSH auf Port 2222 ist keine Sicherheitsmaßnahme im eigentlichen Sinn. Ein vollständiger Portscan findet den Dienst in Sekunden, und OpenSSH gibt sein Banner unabhängig vom Port aus. Der reale Effekt ist quantitativ: die Logs werden ruhig, weil ungezielte Massenscanner nur Port 22 prüfen. Wer Log-Rauschen reduzieren will, gewinnt hier etwas. Wer glaubt, damit einen gezielten Angreifer aufzuhalten, irrt. Gegen das Verschieben spricht, dass Standardports Firewall-Regeln, Monitoring und Fehlersuche einfacher halten. Die Entscheidung ist eine Abwägung zwischen Log-Hygiene und Betriebssimplizität, kein Sicherheitsgewinn.

Paketfilter: nftables oder ufw

Ein Paketfilter mit der Standardregel „verwerfen“ schützt vor dem Dienst, den Sie vergessen haben. Genau das ist sein Wert: nicht die bekannten Ports zu schließen, sondern unbekannte nicht zu öffnen. Debian 13 und Ubuntu 24.04 verwenden nftables als Backend; ufw ist eine Bedienoberfläche darauf.

Kriterium	nftables direkt	ufw
Regelwerk	eine deklarative Datei, versionierbar	Einzelkommandos, Zustand in /etc/ufw
Lesbarkeit im Review	vollständiges Regelwerk auf einen Blick	erfordert ufw status numbered
Ratenbegrenzung, Sets, IPv6	vollständig und explizit	vereinfacht, teils implizit
Einstiegshürde	Syntax muss gelernt werden	zwei Kommandos genügen
Eignung	Konfigurationsmanagement, Server-Flotten	Einzelserver, schnelle Absicherung

Für Systeme, die aus einem Repository heraus verwaltet werden, ist ein einziges Regelwerk in /etc/nftables.conf die bessere Wahl, weil sich Änderungen im Diff prüfen lassen:

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority filter; policy drop;

        iif lo accept
        ct state established,related accept
        ct state invalid drop

        icmp type { echo-request, destination-unreachable, time-exceeded } accept
        icmpv6 type { echo-request, packet-too-big, destination-unreachable, time-exceeded, nd-neighbor-solicit, nd-neighbor-advert, nd-router-advert } accept

        tcp dport 22 ct state new limit rate 10/minute burst 5 packets accept
        tcp dport { 80, 443 } accept

        counter comment "verworfene Pakete"
    }

    chain forward {
        type filter hook forward priority filter; policy drop;
    }

    chain output {
        type filter hook output priority filter; policy accept;
    }
}

Zwei Details verdienen Aufmerksamkeit. Die ICMPv6-Ausnahmen sind nicht optional: ohne Neighbor Discovery funktioniert IPv6 nicht, und ohne packet-too-big bricht die Pfad-MTU-Erkennung, was sich später als sporadisch hängende TLS-Verbindung zeigt. Und limit rate auf neue SSH-Verbindungen begrenzt die Rate, mit der ein Scanner überhaupt Versuche starten kann – eine Verteidigung in der Tiefe, die auch dann greift, wenn eine Anwendung später doch Passwörter akzeptiert. Aktiviert wird das Regelwerk mit nft -c -f /etc/nftables.conf zur Syntaxprüfung und anschließend systemctl enable --now nftables.

Wer Container betreibt, muss wissen, dass Docker eigene Regeln in die Filterkette einfügt und veröffentlichte Ports damit an einem naiv geschriebenen Regelwerk vorbei erreichbar macht. Details dazu stehen in unserem Artikel zum produktiven Einsatz von Docker.

Sicherheitsupdates automatisch einspielen

Der praktisch relevante Angriffsweg ist selten eine unbekannte Lücke, sondern eine öffentlich dokumentierte, für die längst ein Paket bereitliegt: Zwischen der Veröffentlichung eines Sicherheitsupdates und seiner Installation liegt ein Zeitfenster, in dem Schwachstelle und Exploit bekannt, das System aber noch alt ist. Automatische Sicherheitsupdates schließen dieses Zeitfenster ohne Personalaufwand.

apt-get install unattended-upgrades apt-listchanges
dpkg-reconfigure -plow unattended-upgrades

# /etc/apt/apt.conf.d/52unattended-upgrades-local
Unattended-Upgrade::Origins-Pattern {
        "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
};
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";
Unattended-Upgrade::Mail "ops@beispiel.tld";

Die Beschränkung auf das Security-Repository ist bewusst: Sicherheitsaktualisierungen in einem Debian-Stable-Zweig sind auf minimale Backports ausgelegt und ändern das Verhalten in der Regel nicht; wo ein Fix doch eine Änderung erzwingt, steht sie im Debian Security Advisory zum Paket. Vollständige Distributions-Upgrades gehören dagegen in ein geplantes Fenster. Ob automatisch neu gestartet wird, ist eine Verfügbarkeitsentscheidung – ein Kernel-Update wirkt erst nach dem Reboot, und /var/run/reboot-required sollte deshalb überwacht werden.

fail2ban und die Grenzen von Log-basierter Abwehr

fail2ban liest Logdateien, erkennt Muster wiederholter Fehlversuche und trägt die Quell-IP für eine Zeit in eine Sperrliste ein. Das reduziert Log-Rauschen und bremst einfache Angriffe.

# /etc/fail2ban/jail.d/sshd.local
[sshd]
enabled = true
backend = systemd
maxretry = 4
findtime = 10m
bantime = 1h
bantime.increment = true

Rechtetrennung und systemd-Sandboxing

Härtung endet nicht am Netzwerkrand. Die zweite Frage ist, was ein kompromittierter Dienst anrichten kann. Ein Anwendungsprozess, der als root läuft und Schreibrechte auf das gesamte Dateisystem hat, verwandelt eine Deserialisierungslücke direkt in eine Systemübernahme.

Dedizierte Dienstnutzer ohne Login-Shell

adduser --system --group --no-create-home --shell /usr/sbin/nologin appsvc
install -d -o appsvc -g appsvc -m 0750 /var/lib/appsvc

Ein Systemnutzer ohne Home-Verzeichnis und ohne Shell kann sich nicht anmelden und hat keinen Ort, an dem ein Angreifer bequem Dateien ablegt. Die Datenverzeichnisse gehören diesem Nutzer, das Anwendungsverzeichnis gehört root und ist für den Dienst nur lesbar. Damit kann der Prozess seinen eigenen Code nicht überschreiben – die Grundlage dafür, dass ein Einbruch nicht persistent wird.

Die wirksamsten Sandboxing-Direktiven

systemd bringt eine Sandbox mit, die ohne zusätzliche Software auskommt. Sie wird als Drop-in gesetzt, damit Paketupdates die Unit ersetzen dürfen:

# /etc/systemd/system/appsvc.service.d/hardening.conf
[Service]
User=appsvc
Group=appsvc
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
PrivateDevices=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
RestrictSUIDSGID=true
LockPersonality=true
MemoryDenyWriteExecute=true
CapabilityBoundingSet=
SystemCallFilter=@system-service
StateDirectory=appsvc
ReadWritePaths=/var/lib/appsvc

Direktive	Wirkung	Verhinderte Eskalation
NoNewPrivileges=true	setuid-Bits wirken im Prozessbaum nicht mehr	Rechteausweitung über sudo, pkexec, setuid-Binaries
ProtectSystem=strict	gesamtes Dateisystem nur lesbar, außer freigegebenen Pfaden	Manipulation von Binaries, Units, Cron-Einträgen
PrivateTmp=true	eigener /tmp-Namespace	Symlink- und Race-Angriffe über gemeinsame Temp-Dateien
CapabilityBoundingSet=	alle Capabilities entzogen	Zugriff auf Raw Sockets, Kernel-Module, chroot
MemoryDenyWriteExecute=true	keine Speicherseiten schreib- und ausführbar	Nachladen von Shellcode im Prozess

Prüfen lässt sich das Ergebnis mit systemd-analyze security appsvc.service. Das Werkzeug vergibt eine Bewertung pro Direktive und macht sichtbar, welche Lockerungen ein Dienst tatsächlich braucht. Braucht der Prozess einen privilegierten Port, ist AmbientCapabilities=CAP_NET_BIND_SERVICE die schmale Ausnahme – zusammen mit demselben Eintrag in CapabilityBoundingSet=, weil eine Ambient-Capability sonst wieder entzogen wird, und nicht als Start unter root. Diese Muster gehören in die Deployment-Automatisierung, damit sie auf jedem System identisch ankommen; wie das mit Pipelines zusammenspielt, beschreiben wir in den Grundlagen zu CI/CD.

Kernel- und Netzwerkparameter über sysctl

sysctl-Einstellungen sind kein Ersatz für die vorherigen Maßnahmen, aber sie kosten nichts und schließen einige alte Fußangeln im Netzwerkstack.

# /etc/sysctl.d/60-hardening.conf
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.tcp_syncookies = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
fs.protected_hardlinks = 1
fs.protected_symlinks = 1

rp_filter verwirft Pakete, deren Quelladresse nicht zum eingehenden Interface passt, und erschwert damit Spoofing. accept_redirects = 0 verhindert, dass ein ICMP-Redirect die lokale Routing-Tabelle verändert. kptr_restrict und dmesg_restrict entziehen unprivilegierten Prozessen Kernel-Adressen und Ringpuffer-Inhalte – Informationen, die Exploits zur Umgehung von Speicherschutz brauchen. Aktivieren mit sysctl --system.

Zeit, Logging und Audit

Ohne korrekte Zeit ist eine Log-Korrelation über mehrere Systeme wertlos, und TLS-Zertifikate werden fälschlich als ungültig oder gültig bewertet. Debian und Ubuntu synchronisieren mit systemd-timesyncd; der Status muss System clock synchronized: yes melden:

timedatectl show --property=NTPSynchronized --value
journalctl --disk-usage

Für das Journal lohnen zwei Einstellungen in /etc/systemd/journald.conf: Storage=persistent, damit Logs einen Reboot überleben, und ein SystemMaxUse, das die Partition nicht volllaufen lässt. Entscheidend ist aber, dass Logs den Server verlassen. Ein Angreifer mit Root-Rechten löscht lokale Spuren; ein Eintrag auf einem zentralen Log-Host bleibt.

auditd ergänzt das Journal um eine Kernel-nahe Ebene: Es protokolliert Systemaufrufe und Dateizugriffe, unabhängig davon, ob die Anwendung etwas loggt.

apt-get install auditd
auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config
auditctl -w /etc/sudoers.d/ -p wa -k sudoers
ausearch -k sshd_config -i | tail -20

Regeln gehören dauerhaft in /etc/audit/rules.d/. Setzen Sie wenige, gezielte Regeln – ein überladenes Regelwerk erzeugt Datenmengen, die niemand liest, und kostet auf E/A-intensiven Systemen messbar Leistung.

Backups mit geprobtem Restore

Ein Backup, dessen Wiederherstellung nie getestet wurde, ist eine Annahme. Ransomware trifft heute regelmäßig auch die Sicherungen, wenn diese über dieselben Zugangsdaten erreichbar sind. Drei Eigenschaften sind nicht verhandelbar: Die Sicherung liegt außerhalb des Systems, das Sicherungsziel erlaubt dem Server kein Löschen älterer Stände (Append-only-Token oder ein separates Konto auf der Zielseite), und die Wiederherstellung wird nach Kalender geprobt, nicht nach Bedarf.

# Restic mit Append-only-Repository und geprüfter Integrität
restic -r s3:s3.beispiel.tld/backups backup /var/lib /etc --exclude-caches
restic -r s3:s3.beispiel.tld/backups check --read-data-subset=5%
restic -r s3:s3.beispiel.tld/backups restore latest --target /tmp/restore-test

Notieren Sie zwei Zahlen pro Dienst: wie viel Datenverlust akzeptabel ist und wie lange die Wiederherstellung dauern darf. Erst diese Werte machen aus einem Backup-Job ein belastbares Verfahren – und sie sind auch der Grund, weshalb Wiederherstellung Teil der Linux-Infrastrukturarbeit ist und kein nachgelagertes Betriebsdetail. Wer Abhängigkeiten und Build-Artefakte mitsichert, sollte zusätzlich die Herkunft der eingesetzten Pakete prüfen; dazu passt unser Artikel zum Absichern der Software-Supply-Chain.

Checkliste für die Basishärtung

• Nicht benötigte Pakete entfernt, apt-mark showmanual gesichtet
• Kein Dienst außer den bewusst veröffentlichten lauscht auf einer öffentlichen Adresse (ss -tulpn)
• SSH: Public-Key-Auth aktiv, PasswordAuthentication no, KbdInteractiveAuthentication no, PermitRootLogin no, AllowUsers gesetzt
• Paketfilter mit policy drop aktiv, IPv6 mitkonfiguriert, Regelwerk versioniert
• unattended-upgrades aktiv, Security-Origin konfiguriert, needrestart überwacht
• Jeder Dienst läuft unter eigenem Systemnutzer ohne Shell
• systemd-Drop-in mit NoNewPrivileges, ProtectSystem=strict, PrivateTmp, leerem CapabilityBoundingSet
• sysctl --system angewendet, Zeitsynchronisation bestätigt
• Journal persistent, Logs auf einem zweiten System, auditd mit gezielten Regeln
• Backup extern, Löschschutz auf der Zielseite, Restore innerhalb der letzten 90 Tage geprobt und dokumentiert

Fazit

Basishärtung ist Handwerk mit überschaubarem Umfang, und ihr Wert liegt in der Reproduzierbarkeit: Was hier von Hand gesetzt wurde, gehört anschließend in Ansible, Terraform oder ein anderes Konfigurationswerkzeug, damit der zwanzigste Server so aussieht wie der erste. Der größte Restfehler in der Praxis ist nicht eine fehlende Direktive, sondern Drift – Systeme, die einmal gehärtet wurden und deren Zustand danach niemand mehr prüft. Ein wöchentlicher automatischer Abgleich gegen die Checkliste kostet weniger als eine einzige Kompromittierung. Wer diesen Zustand dauerhaft halten will, verbindet Härtung mit Deployment und Monitoring; wie das in Pipelines und Cloud-Umgebungen aussieht, behandeln wir unter DevOps und Cloud. Für Fragen zu einem konkreten Aufbau ist der Weg über Kontakt offen.