Einen neuen VPS in der ersten Stunde härten

Beobachten Sie journalctl -u ssh auf einem Server, der seit einer Stunde online ist, und das Volumen wirkt beim ersten Anblick alarmierend. Das sollte es nicht. Was Sie sehen, ist die Hintergrundstrahlung des Internets: eine Handvoll Scan-Operationen, manche akademisch, manche kommerziell, manche kriminell, die den gesamten IPv4-Raum fortlaufend durchzählen und die Ergebnisse an Bots weiterreichen, die Zugangsdaten erraten. Ihre Adresse wurde erreicht, weil sie existiert, in numerischer Reihenfolge, und sie wird in ein paar Stunden erneut erreicht werden, was immer Sie tun.

Das verändert die Form des Problems auf nützliche Weise. Sie verteidigen sich nicht gegen einen Angreifer, der Sie gezielt ausgesucht hat und sich anpassen wird; Sie verteidigen sich gegen ein Skript mit einem festen Repertoire – root, admin, ubuntu, test, git, oracle, postgres und die zwanzigtausend Passwörter, die in Datenlecks aufgetaucht sind. Es hat keine Geduld, keine Kreativität und kein Interesse an einer Maschine, die nicht beim ersten Versuch antwortet. Passwort-Authentifizierung abzuschalten bremst diesen Angreifer nicht etwa nur aus. Es entfernt ihn vollständig vom Spielfeld.

Zwei Details lohnen sich zu wissen. Erstens ist IPv6 dramatisch ruhiger, weil sich ein /64 nicht durchkämmen lässt – aber sobald Ihr AAAA-Eintrag öffentlich ist oder die Adresse Ihrer Maschine in einem Mail-Header oder einem Certificate-Transparency-Log auftaucht, endet die Ruhe. Behandeln Sie IPv6 nie als Versteck; behandeln Sie es als kleineren Heuhaufen. Zweitens hat eine IPv4-Adresse eine Vergangenheit. Sie hatte einen Vormieter, und wenn dieser Vormieter einen Mailserver schlecht betrieben oder etwas gehostet hat, das gelistet wurde, erben Sie den Ruf, bis er verblasst. Wenn Mail für Sie wichtig ist, prüfen Sie die Adresse auf den üblichen Blocklisten, bevor Sie darauf aufbauen – das ist ein Fünf-Minuten-Check, der zwei Wochen Debugging der Zustellbarkeit erspart.

Fast jede echte Kompromittierung eines kleinen Servers beginnt an einer von zwei Stellen: einem Passwort, das sich erraten ließ, oder einem Dienst, der lauschte und das nicht hätte tun sollen. Die entsprechenden Abhilfen sind PasswordAuthentication no und eine Firewall mit der Standardregel drop. Sie sind unspektakulär, brauchen zusammen fünfzehn Minuten und sind mehr wert als alle anderen Maßnahmen auf dieser Seite zusammen.

Der Grund ist struktureller, nicht statistischer Natur. Beide sind standardmäßig geschlossen – sie schlagen in Richtung Sicherheit fehl. Ein sshd, der nur Schlüssel akzeptiert, lässt sich durch keine noch so hohe Zahl an Versuchen per Brute-Force knacken, weil es im Code keinen Pfad gibt, der ein Passwort akzeptiert. Eine Default-Deny-Firewall schützt auch Dienste, die Sie noch gar nicht installiert haben, einschließlich der Datenbank, die Sie in drei Monaten hinzufügen und dabei vergessen werden, an localhost zu binden. Alles andere in einer Hardening-Checkliste ist eine Aufzählung von Schlechtem: eine Liste konkreter Dinge, die man abschalten soll, und die immer nur so vollständig ist wie die Liste selbst.

Wenn Sie also nur einen Abschnitt lesen und dann den Tab schließen, lesen Sie diesen, führen Sie die Schritte 2 bis 5 unten aus, und betrachten Sie die Stunde als gut investiert. Der Rest ist wirklich nützlich und wirklich zweitrangig.

Unter Debian 13 und Ubuntu 24.04 beginnt /etc/ssh/sshd_config mit einer Zeile Include /etc/ssh/sshd_config.d/*.conf, und Cloud-Images liefern in diesem Verzeichnis eine Datei aus – meist 50-cloud-init.conf –, die PasswordAuthentication bereits setzt. Die Hauptdatei zu bearbeiten und eigene Direktiven unten anzuhängen, fühlt sich natürlich an und erzeugt eine Konfiguration, die nicht das tut, was sie zu tun scheint.

Die Regel ist das eine an sshd, das fast jeden überrascht: Für jedes Schlüsselwort gewinnt der zuerst gelesene Wert. Das ist das Gegenteil von fast jedem anderen Config-Merge-System, das Sie bisher benutzt haben. Das Include steht nahe am Anfang der Hauptdatei, sodass ein Drop-in vor dem Rumpf von sshd_config gelesen wird – und unter den Drop-ins entscheidet die alphabetische Reihenfolge. Eine Datei namens 10-hardening.conf schlägt 50-cloud-init.conf. Eine Datei namens 60-hardening.conf verliert dagegen, still und leise, und ein Neustart, der Erfolg meldet, wird Sie das nicht lehren.

Deshalb sollten Sie nie der Datei vertrauen, die Sie gerade geschrieben haben. Fragen Sie den Daemon, was er tatsächlich aufgelöst hat:

sshd -t                 # syntax check — silence means valid
sshd -T | grep -Ei '^(permitrootlogin|passwordauthentication|pubkeyauthentication|kbdinteractive|allowusers|port) '

sshd -T gibt die effektive Konfiguration aus, nachdem jedes Include, jeder Override und jeder Default aufgelöst wurde. Wenn diese Ausgabe passwordauthentication yes zeigt, dann ist Passwort-Authentifizierung aktiv, ganz gleich, was irgendeine Datei auf der Platte behauptet. Nichts anderes zählt als Nachweis.

Die zweite Falle gehört zur selben Familie. Ubuntu 24.04 startet sshd über Socket-Aktivierung: ssh.socket besitzt den lauschenden Port, und Port in sshd_config wird vollständig ignoriert. Prüfen Sie das mit systemctl is-enabled ssh.socket; ist es aktiviert und Sie wollen einen anderen Port, ändern Sie ihn mit systemctl edit ssh.socket und einem ListenStream=-Override – nicht in sshd_config, wo die Einstellung richtig aussieht und nichts bewirkt.

Seien wir ehrlich bei diesem Punkt, denn das Internet ist es nicht. sshd auf Port 2222 oder 47000 zu verschieben, hält null kompetente Angreifer auf. Ein vollständiger TCP-Scan eines einzelnen Hosts dauert Sekunden, der Dienst verrät sich selbst im Banner, und wer beschlossen hat, gezielt Sie anzugreifen, findet ihn, bevor der Kaffee kalt wird.

Was es tatsächlich bewirkt: Es reduziert Ihr Authentifizierungs-Log um etwa fünfundneunzig Prozent, und das hat echten Wert – es ist der Unterschied zwischen Logs, die Sie überfliegen, und Logs, die Sie tatsächlich lesen. Sichtbares Signal schlägt vergrabenes Signal. Wenn Sie überhaupt irgendetwas überwachen, ist ein ruhiges auth.log die mit Abstand billigste Methode, eine Anomalie sichtbar zu machen.

Die Kosten sind klein, aber real, und deshalb nennen wir es optional statt empfohlen. Sie werden den Port vergessen, wenn Sie in acht Monaten zurückkommen. Ein nicht standardmäßiger Port oberhalb von 1024 kann im Prinzip von einem unprivilegierten Prozess belegt werden, falls sshd jemals nicht lauscht. Restriktive ausgehende Firewalls in Kundennetzwerken blockieren ungewöhnliche Ports, sodass Sie gelegentlich Ihren eigenen Server nicht aus einem Büro oder einem Hotel erreichen können. Und auf einem socket-aktivierten System müssen Sie ihn an der richtigen Stelle ändern, wie im vorigen Abschnitt beschrieben. Tun Sie es, wenn Ihnen ruhige Logs wichtig sind. Tun Sie es nicht und fühlen Sie sich dann sicher, und tun Sie es niemals anstelle von SSH nur mit Schlüssel.

Eine Firewall, die auflistet, was blockiert wird, ist ein Ablagesystem. Eine Firewall, die auflistet, was erlaubt wird, ist eine Sicherheitsmaßnahme. Dieser Unterschied ist das ganze Spiel, denn nur Letztere deckt auch den Dienst ab, den Sie nächsten Monat installieren, den Debug-Port, den Sie an einem Freitag geöffnet haben, und den Container, der sich entschlossen hat, sich selbst offenzulegen.

Auf unserer Plattform haben Sie zwei Schichten, und sie sind unabhängig voneinander. Der Edge-Filter ist optional, wird pro Server im Panel konfiguriert und auf dem Hypervisor durchgesetzt, sodass blockierter Traffic Ihren Gast überhaupt nie erreicht – nützlich für Layer-4-Regeln, die angewendet werden sollen, bevor Ihr Kernel auch nur einen Zyklus dafür aufwendet, und um einen kompromittierten Gast unerreichbar zu halten, während Sie daran arbeiten. Die Gast-Firewall gehört vollständig Ihnen: nftables, iptables, pf, was auch immer Ihr Image mitbringt. Wir fassen sie nie an. Nutzen Sie beide, wenn die Maschine wichtig ist; nutzen Sie zumindest die zweite immer.

Zwei Dinge im Regelwerk aus Schritt 5 verdienen eine Erklärung, weil die meisten kopierten Regelwerke sie falsch machen. Verwerfen Sie nicht das gesamte ICMP. Das fühlt sich ordentlich an und zerstört dabei die Path-MTU-Discovery, was die übelste Klasse von Fehlern überhaupt erzeugt: Kleine Anfragen funktionieren, große Antworten hängen, und nichts in Ihren Logs erwähnt die Firewall. Akzeptieren Sie mindestens destination-unreachable, time-exceeded und parameter-problem. Filtern Sie ICMPv6 nicht nach Typ, außer Sie kennen die Liste genau. IPv6 verlässt sich für Neighbour Discovery und Router Advertisement auf ICMPv6; blockieren Sie es pauschal, stirbt Ihre IPv6-Konnektivität auf eine Weise, die wie ein Routing-Problem aussieht. Das gesamte ICMPv6 auf einem einzelnen Host zu akzeptieren, ist ein vernünftiger Kompromiss, und genau das tut das Regelwerk weiter unten.

Eine Warnung, bevor Sie flush ruleset ausführen: Ist Docker installiert, entfernt diese Zeile auch die NAT- und Filterregeln, die Docker geschrieben hat, und das Container-Networking steht still, bis systemctl restart docker sie zurückbringt. Laden Sie zuerst Ihr Regelwerk, starten Sie danach Docker neu, und lesen Sie den nächsten Abschnitt, bevor Sie auch nur einen einzigen Container-Port veröffentlichen.

Fragen Sie die Maschine, worauf sie lauscht. Nicht das, von dem Sie glauben, es installiert zu haben – sondern das, was gerade jetzt gebunden ist:

ss -tulpn | grep -vE '127\.0\.0\.1|\[::1\]'

Alles, was diesen Filter übersteht, ist von irgendwo anders als der Maschine selbst erreichbar. Auf einem Standard-Image sind die üblichen Funde rpcbind auf 111 (nichts, was Sie betreiben, braucht das), ein exim4-Listener, der von der Grundinstallation übrig geblieben ist, und ein systemd-resolved-Stub, der auf Loopback harmlos ist und ein offener Resolver, wenn er es nicht ist. Die gefährlichen kommen später hinzu, mit Software, die Sie absichtlich installiert haben: PostgreSQL auf 0.0.0.0:5432, weil ein Tutorial gesagt hat, listen_addresses zu bearbeiten, Redis ohne Passwort, weil Redis den größten Teil seines Bestehens standardmäßig kein Passwort hatte, ein Elasticsearch-Knoten, ein Prometheus-Exporter, ein Jupyter-Notebook. Jedes davon war schon mehrfach der erste Schritt einer echten Kompromittierung.

Jetzt die Falle, die sorgfältige Leute erwischt. Docker fragt Ihre Firewall nicht um Erlaubnis. Wenn Sie -p 5432:5432 schreiben, fügt Docker DNAT-Regeln in die PREROUTING-Chain der nat-Tabelle ein, die der Kernel auswertet, bevor Ihre input-Chain das Paket überhaupt zu sehen bekommt; der Traffic wird dann an den Container weitergeleitet. Ihre Default-Deny-Regel für input wird nicht befragt, ufw status zeigt den Port als geschlossen an, und die Datenbank steht im öffentlichen Internet. Das ist dokumentiertes Docker-Verhalten, das seit einem Jahrzehnt so besteht, und es hat schon eine enorme Zahl an Datenbanken offengelegt.

Die Lösung ist eine einzige Zeichenkette, und es ist die Gewohnheit, die sich zu bilden lohnt:

# wrong — reachable from the entire internet, whatever your firewall says
docker run -p 5432:5432 postgres

# right — bound to loopback, reachable only through an SSH tunnel or a proxy
docker run -p 127.0.0.1:5432:5432 postgres

Holen Sie sich schließlich eine Meinung von außen. Ein Portscan vom Server aus verrät Ihnen, was der Kernel denkt; ein Scan von woanders verrät Ihnen, was die Welt sieht, und das ist die einzige Zahl, die zählt. Führen Sie nmap -Pn -p- <your-ip> von Ihrem Laptop aus aus, nicht von der Maschine, und vergleichen Sie das Ergebnis mit der Liste, die Sie erwartet hatten.

Das Zeitfenster, in dem kleine Server kompromittiert werden, ist nicht der Zero-Day. Es sind die vier Wochen zwischen der Veröffentlichung einer CVE mit funktionierendem Proof of Concept und dem nächsten Mal, dass Sie sich zufällig einloggen. Angriffs-Tooling nimmt einen neuen Remote-Bug innerhalb von Tagen auf; eine Maschine, die Sie patchen, „wenn Sie dazu kommen“, ist das gesamte Intervall über exponiert, und jeder ehrliche Betreiber weiß, wie lang dieses Intervall in Wirklichkeit ist.

Der Einwand gegen automatische Updates ist die Angst vor Breakage, und es lohnt sich, sie ernst zu nehmen – und dann einzugrenzen. Beschränken Sie die Automatisierung auf das Security-Segment Ihrer Distribution, wo Maintainer Fixes in die paketierte Version zurückportieren, statt neue Upstream-Releases auszuliefern. Ein Debian-Sicherheitsupdate für openssl ist ein gepatchter Build derselben Version, die Sie bereits betreiben; das Risiko, dass es das Verhalten ändert, ist weit kleiner als das Risiko, ein Remote-Loch einen Monat lang offen zu lassen. Feature-Upgrades bleiben manuell, wo sie hingehören.

Der Teil, den Leute überspringen, ist der Neustart. Ein gepatchtes libssl auf der Platte nützt dem Prozess nichts, der die alte Version beim Start eingebunden hat, und ein Kernel-Update bewirkt gar nichts, bis Sie in ihn hineinbooten. Akzeptieren Sie entweder einen unbeaufsichtigten Neustart in einem Fenster, das Sie selbst wählen, oder installieren Sie needrestart und lassen Sie es Ihnen mitteilen, welche Dienste gegen gelöschte Bibliotheken laufen – aber tun Sie eines von beidem. „Automatische Updates sind aktiviert“, während uptime 340 Tage anzeigt, ist eine bequeme Illusion, und es ist die häufigste, die wir sehen.

fail2ban liest Ihre Logs, bemerkt wiederholte Fehlschläge von einer Adresse und sperrt sie für eine Weile. CrowdSec macht dasselbe und teilt die Urteile über ein Netzwerk von Teilnehmern, sodass Sie eine Adresse blockieren können, die sich anderswo bereits daneben benommen hat, bevor sie Sie erreicht. Beides ist gute Software. Keines von beiden tut das, was die meisten Leute bei einem SSH-Server mit ausschließlich Schlüssel-Login annehmen.

Sobald PasswordAuthentication auf no steht, kann eine SSH-Brute-Force nicht erfolgreich sein. Nicht „ist unwahrscheinlich“ – es gibt keinen Codepfad dafür. Eine Adresse nach fünf Fehlschlägen zu sperren, verhindert deshalb nichts; es reduziert Log-Volumen und eine verschwindend geringe Menge CPU. Das ist ein echter Nutzen, nur eben kein Sicherheitsnutzen, und der Kompromiss ist nicht kostenlos: Ein schlecht geschriebener Jail, der das falsche Log beobachtet, hat schon mehr Administratoren aus ihren eigenen Servern ausgesperrt, als er je Angreifer ausgesperrt hat.

Wo sich diese Werkzeuge tatsächlich verdient machen, ist eine Ebene höher, bei den Diensten, die Sie wirklich exponieren: ein Login-Formular, ein WordPress-Admin, eine API mit Rate-Limits, ein Mailserver mit SMTP AUTH. Die akzeptieren tatsächlich Passwörter, sie sind per Brute-Force angreifbar, und eine Bannliste ist genau die richtige Maßnahme. Unser Urteil ist also eng und spezifisch. Lassen Sie den SSH-Jail weg. Setzen Sie CrowdSec oder fail2ban vor das, was ein Passwortfeld hat. Und für welches Sie sich auch entscheiden, setzen Sie zuerst Ihre eigene Management-Adresse auf die Whitelist – ignoreip existiert für den Abend, an den Sie sich sonst aus den falschen Gründen erinnern werden.

Prävention ist das, was Sie in einer Stunde schaffen können. Detektion ist das, was Ihnen sagt, dass die Stunde nicht gereicht hat. Sie muss nicht aufwendig sein, und auf einem einzelnen Server decken drei günstige Maßnahmen das meiste ab.

Behalten Sie die Logs. Auf vielen Images liegt das Journal in /run und verflüchtigt sich beim Neustart, was bedeutet, dass die Aufzeichnung eines Vorfalls genau in dem Neustart verschwindet, der ihm folgt. /var/log/journal anzulegen ist eine Ein-Zeilen-Lösung und die wertvollste Sache in diesem Abschnitt.

Lassen Sie sich über Logins informieren. Eine Zeile in /etc/ssh/sshrc, die bei jedem Sitzungsstart logger auslöst, kostet nichts und liefert Ihnen eine saubere, mit grep durchsuchbare Aufzeichnung getrennt vom eigenen Geplapper von sshd. Eine Falle, die Leute erwischt: sshd führt ~/.ssh/rc statt /etc/ssh/sshrc aus, wenn der Benutzer eine solche Datei besitzt, sodass die systemweite Datei ausgerechnet für das Konto übersprungen wird, das am ehesten ein angepasstes Dotfile hat. Wenn Sie einen Hook brauchen, der nicht überschattet werden kann, verwenden Sie stattdessen pam_exec.

Wissen Sie, wie das Dateisystem am ersten Tag aussah. AIDE zeichnet Hashes Ihrer Binärdateien, Bibliotheken und Unit-Dateien auf und meldet, was sich seitdem verändert hat. Der Haken ist grundlegend und wird meist ignoriert: Eine Datenbank, die auf der Maschine gespeichert ist, die sie überwacht, kann von demjenigen neu erzeugt werden, der sie kompromittiert hat, und danach meldet die Prüfung für immer „keine Änderungen“. Kopieren Sie die Datenbank von der Maschine herunter, oder notieren Sie zumindest ihren Hash anderswo, dann lohnen sich die zwanzig Minuten für das Werkzeug. Bleibt sie, wo sie ist, ist es nur ein Sicherheits-Placebo.

Das allgemeine Prinzip lohnt sich, für sich genannt zu werden: Das Log, dem Sie nicht vertrauen können, ist das auf der kompromittierten Maschine. Alles, worauf Sie sich wirklich verlassen wollen – ein Journal, eine Integritätsdatenbank, ein Backup – sollte eine Kopie irgendwo haben, das derselbe Angreifer nicht kontrolliert. Ein zweiter kleiner Server in einer anderen Jurisdiktion ist eine legitime Antwort darauf, und ein Fünf-Dollar-Server reicht dafür aus.

Alles oben ist Perimeterschutz, und es lohnt sich, bei der Grenze genau zu sein, damit Sie eine verschlossene Haustür nicht mit einem Tresor verwechseln.

Es schützt keine Daten auf einer laufenden Maschine. Ein gehärteter Kernel und eine geschlossene Firewall sind irrelevant für jeden mit Hypervisor-Zugriff, und für den Inhalt des RAM, solange die Maschine läuft. Wenn Ihre Sorge der Festplatte gilt, wenn der Server ausgeschaltet, beschlagnahmt oder außer Betrieb genommen wird, dann ist das Festplattenverschlüsselung, und das ist ein anderes Verfahren mit einem anderen Fehlerbild – siehe VPS-Festplatte mit LUKS verschlüsseln.

Es macht Sie nicht anonym. Ein Server kann tadellos gehärtet sein und trotzdem verraten, wem er gehört – durch einen WHOIS-Eintrag, einen wiederverwendeten SSH-Key, ein Analytics-Tag, einen SSH-Client, der ohne Zwischenstation von zu Hause aus verbindet, oder ein Zertifikat, das zwei Identitäten miteinander verknüpft. Mit Monero zu bezahlen und sich dann von der eigenen Adresse aus einzuloggen, macht die Zahlung zunichte. Dieses Fehlerbild hat seine eigene Seite: die Fehler, die Sie deanonymisieren.

Es repariert nicht Ihre Anwendung. Eine SQL-Injection, ein unauthentifizierter Admin-Endpunkt oder eine Abhängigkeit mit Backdoor kümmert sich nicht um Ihre sshd-Einstellungen. Die meisten Kompromittierungen gut betriebener Server kommen über den Port, den Sie bewusst und absichtlich für einen selbst geschriebenen oder installierten Dienst geöffnet haben.

Es ist kein Backup. Ransomware, rm -rf mit einer Variable, die leer war, und ein fehlgeschlagenes Upgrade enden alle gleich. Machen Sie eine Kopie, legen Sie sie woanders ab, und stellen Sie einmal daraus wieder her, bevor Sie es wirklich brauchen – dieselbe Disziplin, die einen Umzug zu einem anderen Anbieter überlebbar macht, macht auch einen schlechten Dienstag überlebbar.

Nichts davon ist ein Argument gegen die Stunde. Es ist ein Argument dafür, genau zu wissen, was die Stunde gebracht hat.