Lab-Lektion · kostenlos

Server-Hardening lernen – Schritt für Schritt

Ein frisch aufgesetzter Server ist eine offene Einladung. Hardening bedeutet, die Angriffsfläche systematisch zu verkleinern. Hier gehst du die wichtigsten Schritte durch – und führst sie auf einer echten, eigenen VM aus, ohne etwas Echtes kaputtmachen zu können.

Updates und minimale Dienste

Der erste Schritt ist immer: System aktuell halten und alles abschalten, was du nicht brauchst. Jeder laufende Dienst ist eine potenzielle Tür. Weniger ist hier wörtlich sicherer.

Firewall mit UFW

Mit ufw erlaubst du nur die Ports, die wirklich nötig sind (z. B. SSH und HTTPS) und blockst den Rest. Eine korrekt gesetzte Firewall ist eine der wirksamsten Einzelmaßnahmen.

SSH absichern & fail2ban

Passwort-Login aus, Root-Login aus, dazu fail2ban gegen Brute-Force: So wird der häufigste Angriffsweg – das Erraten von SSH-Zugängen – praktisch geschlossen.

Angriffsfläche zuerst, Werkzeuge danach

Härten heißt nicht, möglichst viele Werkzeuge zu installieren, sondern möglichst wenig erreichbar zu lassen. Der erste Griff ist ss -tlnp: Was lauscht überhaupt, und muss es das? Ein Dienst, der nur lokal gebraucht wird, gehört an 127.0.0.1 gebunden – dann schützt ihn keine Firewall-Regel, sondern seine eigene Konfiguration.

Automatische Sicherheits-Aktualisierungen

Die meisten erfolgreichen Angriffe nutzen Lücken, für die es seit Wochen einen Patch gibt. unattended-upgrades installiert Sicherheits-Aktualisierungen ohne Zutun. Wichtig ist der zweite Teil: zu prüfen, ob es auch wirklich läuft. Ein aktivierter, aber nie ausgeführter Dienst sieht in der Konfiguration genauso aus wie ein funktionierender.

Weniger Rechte statt mehr Regeln

Jeder Dienst sollte unter einem eigenen Benutzer laufen und nur auf das zugreifen dürfen, was er braucht. Ein Webserver, der als root läuft, macht aus einer Lücke in der Anwendung sofort eine Übernahme des ganzen Systems. Systemd bietet dafür Schalter wie ProtectSystem=strict und NoNewPrivileges=true – wirksamer als jede zusätzliche Firewall-Regel.

Protokolle sind Teil der Absicherung

Härtung ohne Protokoll ist Blindflug. journalctl -u ssh --since today zeigt Anmeldeversuche, lastb die fehlgeschlagenen. Wer nicht weiß, wie oft geklopft wird, kann nicht beurteilen, ob eine Maßnahme wirkt. Genau deshalb gehört zu jeder Änderung eine Messung vorher und nachher, nicht nur ein Häkchen.

Was oft schiefgeht

Härtung scheitert selten an fehlendem Wissen und meistens an fehlender Gegenprobe. Eine Firewall-Regel wird gesetzt, aber nie von außen getestet. Ein Dienst wird abgeschaltet und startet beim nächsten Neustart wieder mit. unattended-upgrades wird installiert und läuft nie, weil ein anderer Paketvorgang die Sperre hält. Gemeinsam ist allen drei Fällen: Die Konfiguration sieht richtig aus, und niemand hat nachgesehen, ob sie wirkt.

Die Reihenfolge, in der gehaertet wird

Härtung hat eine Reihenfolge, und sie ist nicht beliebig. Zuerst der Zugang: Schlüssel einrichten und testen, solange der alte Weg noch offen ist. Dann die Angriffsfläche: abschalten, was nicht gebraucht wird, und lokal binden, was nicht von außen erreichbar sein muss. Danach die Firewall, die nur noch absichert, was ohnehin schon eng ist. Erst zum Schluss kommen Werkzeuge wie Einbruchserkennung oder automatische Sperrlisten. Wer umgekehrt anfängt, installiert Wächter über einer offenen Tür.

Befehle zum Ausprobieren

Sehen, was von außen erreichbar ist

$ sudo ss -tlnp$ sudo ufw status verbose$ systemctl list-units --type=service --state=running

ss -tlnp zeigt jeden lauschenden Port samt Prozess. Alles, was auf 0.0.0.0 steht und nicht gebraucht wird, ist der erste Kandidat zum Abschalten.

Firewall in der richtigen Reihenfolge

$ sudo ufw default deny incoming$ sudo ufw default allow outgoing$ sudo ufw allow OpenSSH$ sudo ufw enable

Die SSH-Regel steht VOR dem Einschalten. Wer ufw enable zuerst tippt, sperrt sich bei einer Fernsitzung aus – der klassische Fehler, und er passiert genau einmal.

Aktualisierungen automatisieren und nachweisen

$ sudo apt install unattended-upgrades$ sudo dpkg-reconfigure -plow unattended-upgrades$ sudo unattended-upgrade --dry-run -d | tail -20

Die dritte Zeile ist der Nachweis: Sie zeigt, was der Dienst tun würde. Ohne diese Probe weißt du nur, dass er eingeschaltet ist – nicht, dass er wirkt.

Anmeldeversuche sichtbar machen

$ sudo journalctl -u ssh --since today | grep -c 'Failed password'$ sudo lastb | head$ sudo journalctl -u ssh --since today | grep 'Accepted' | tail -5

Die erste Zahl ist deine Ausgangsmessung. Nach dem Abschalten der Passwort-Anmeldung muss sie auf null fallen – das ist der Wirksamkeitsnachweis, nicht die Konfigurationszeile.

Häufige Fehlermeldungen

Command may disrupt existing ssh connections. Proceed with operation (y|n)?: Ursache: ufw enable warnt, weil die Standardregel eingehende Verbindungen verwirft – einschließlich der Sitzung, in der du gerade tippst.; Lösung: Abbrechen, sudo ufw allow OpenSSH setzen, dann erneut einschalten. Und eine zweite Sitzung offen lassen.
Failed to start ssh.service: Unit ssh.service is masked.: Ursache: Der Dienst wurde nicht nur gestoppt, sondern maskiert – ein Zustand, aus dem start und enable nicht herausführen.; Lösung: sudo systemctl unmask ssh und danach enable --now.
0 upgraded, 0 newly installed — bei bekanntem offenem CVE: Ursache: Die Paketlisten sind alt. apt upgrade vergleicht gegen das, was es zuletzt geholt hat, nicht gegen den Server.; Lösung: Immer sudo apt update davor. Das ist der Grund, warum die beiden Befehle in jeder Anleitung als Paar auftreten.
ufw: ERROR: Could not load logging rules: Ursache: Das Kernel-Modul fuer die Protokollierung fehlt – auf manchen Cloud-Kerneln ist es nicht eingebaut.; Lösung: Mit sudo ufw logging off die Protokollierung abschalten und stattdessen ueber journalctl -k mitlesen. Die Regeln selbst greifen unabhaengig davon.
Job for ssh.service failed. See "systemctl status ssh.service": Ursache: Meist ein Syntaxfehler in /etc/ssh/sshd_config — eine Direktive falsch geschrieben oder zweimal gesetzt.; Lösung: Vor jedem Neustart sudo sshd -t laufen lassen; es nennt Datei und Zeile. Danach reload statt restart, damit bestehende Sitzungen offen bleiben.

In fünf Schritten

01Mit sudo ss -tlnp auflisten, was lauscht, und jeden Eintrag begründen können.
02Firewall setzen – SSH erlauben, BEVOR du ufw enable tippst.
03Schlüssel-Anmeldung testen, dann Passwort- und Root-Anmeldung in sshd_config abschalten.
04unattended-upgrades einrichten und mit --dry-run belegen, dass es wirkt.
05Gegenprobe von außen: erneut ss -tlnp und ein Verbindungsversuch auf einen geschlossenen Port – er muss scheitern.

Was du übst

Updates & minimale DiensteUFW-FirewallSSH-Härtung & fail2ban

Jetzt im Lab üben →

Weiterlernen

Kontakt aufnehmen

Haben Sie ein Projekt?

Lassen Sie uns gemeinsam Ihre Idee in die Tat umsetzen. Wir beraten Sie gerne unverbindlich.

Kontakt aufnehmen →