VPS härten: die ersten fünfzehn Minuten auf einem neuen Server

Was einen neuen Server wirklich angreift — und was ihn seinem Besitzer wirklich entreißt

Richten Sie eine frische IPv4-Adresse aufs Internet, und fast sofort trifft unaufgeforderter Datenverkehr ein. Nicht, weil jemand Sie bemerkt hätte: Der gesamte Adressraum wird kontinuierlich durchsucht, und ein Host, der auf Port 22 antwortet, reiht sich einfach in eine Warteschlange ein, die längst lief. Innerhalb des ersten Tages verzeichnet ein typischer neuer Server irgendwo zwischen ein paar Hundert und einigen Zehntausend SSH-Authentifizierungsversuchen, fast alle gegen root, admin, ubuntu, test und ein Dutzend anderer vorhersehbarer Namen, mit Passwörtern aus einer Liste, die sich seit einem Jahrzehnt kaum verändert hat. Das liest sich wie ein Angriff. Es ähnelt eher dem Wetter.

Diese Unterscheidung ist wichtig, denn sie entscheidet, welche Maßnahmen Ihre fünfzehn Minuten verdienen. Passwort-Raten in diesem Umfang wird durch das Abschalten der Passwort-Authentifizierung nicht verringert — es wird eliminiert. Es bleibt kein Restrisiko zu verwalten, nichts zu justieren, keine Rate zu überwachen. Die beiden Dinge, die kleinen Servern tatsächlich ihre Besitzer entreißen, sind dagegen wenig glamourös: eine öffentlich erreichbare Anwendung, die eine Version mit einer veröffentlichten, monatealten Schwachstelle betreibt, und ein Zugangsdatensatz, der anderswo geleakt wurde und hier immer noch funktionierte. Keines von beidem ist exotisch, und keines hat irgendetwas damit zu tun, auf welchem Port SSH lauscht.

Es gibt einen dritten Fehlermodus, und auf einem Host, der nie gefragt hat, wer Sie sind, ist er der mit Abstand häufigste: Sie sperren sich selbst aus. Bei einem gewöhnlichen Anbieter ist das ein lästiges Support-Ticket: Sie beantworten ein paar Fragen, weisen nach, dass Sie die Person auf dem Rechnungsdatensatz sind, und jemand setzt den Zugang für Sie zurück. Hier gibt es diesen Weg nicht — nicht als widerwillig getroffene Grundsatzentscheidung, sondern weil die Identität, die dafür geprüft werden müsste, nie erfasst wurde. Was stattdessen existiert, ist Zugang, der an das Konto gebunden ist statt an eine Person: eine Notfallkonsole per KVM-over-VNC im Panel, stündliche Snapshots mit sieben Tagen Aufbewahrung und die Möglichkeit, etwas völlig anderes zu booten. Das reicht. Es reicht aber nur, wenn Sie es einmal ausprobiert haben, bevor Sie es brauchen.

Die Checkliste unten ist deshalb nach Konsequenz geordnet, nicht nach Mode. Die Maßnahmen, die eine ganze Angriffsklasse eliminieren, stehen zuerst, die, die nur Rauschen reduzieren, stehen zuletzt, und der Schritt, der nichts kostet und den Abend rettet — der Nachweis, dass Sie noch hineinkommen — steht vor allen anderen.

Bauen Sie den Fluchtweg, bevor Sie die Tür schließen

Hier ist die Abfolge, die Leute aussperrt, und jeder einzelne Schritt darin ist für sich genommen richtig: die SSH-Konfiguration bearbeiten, den Port verschieben, die Passwort-Anmeldung deaktivieren, eine Firewall aktivieren, den Daemon neu laden, das Terminal schließen. Der Fehler liegt in keiner einzelnen Änderung. Er liegt darin, dass die Sitzung, in der Sie gerade tippen, der einzige Beleg dafür war, dass irgendetwas davon funktioniert hat — und Sie haben sie weggeworfen, bevor Sie es geprüft haben.

Die Regel, die die gesamte Checkliste sicher macht, ist ein einziger Satz: Halten Sie die funktionierende Sitzung offen und weisen Sie die Änderung von einer zweiten aus nach. Öffnen Sie ein neues Terminal, verbinden Sie sich frisch, führen Sie id aus, eskalieren Sie mit sudo. Gelingt das, ist die Änderung echt, und die erste Sitzung wird entbehrlich. Schlägt es fehl, haben Sie immer noch eine Shell, mit der Sie sie rückgängig machen können. Das gilt für die Firewall, für sshd, für den Schlüssel eines neuen Benutzers und für alles andere, das Sie an der Tür abweisen kann.

Bevor Sie irgendetwas davon tun, richten Sie den Out-of-Band-Zugang ein. Im BitVPS-Panel trägt jede Serverzeile eine Schaltfläche Konsole, die eine KVM-over-VNC-Sitzung gegen das Display der virtuellen Maschine öffnet. Das ist keine Shell übers Netzwerk — es sind Bildschirm und Tastatur der Maschine selbst —, weshalb sie weiterfunktioniert, wenn sshd nicht startet, wenn die Firewall jedes eingehende Paket verwirft, und wenn die Netzwerkkonfiguration falsch ist. Öffnen Sie sie einmal, und zwar jetzt, an einem Server, den Sie noch nicht kaputt gemacht haben. Bestätigen Sie, dass Sie eine Anmeldeaufforderung erhalten. Das dauert dreißig Sekunden und ist der Unterschied zwischen einem Fehler und einem Ausfall.

Erstellen Sie außerdem einen Snapshot. Sie laufen bei jedem Plan stündlich mit sieben Tagen Aufbewahrung und sind in etwa dreißig Sekunden wiederhergestellt, was aus „ich habe die falsche nft-Regel eingefügt“ statt eines abendfüllenden Wiederherstellungsprojekts nur noch einen Rollback macht. Und für Änderungen, bei denen Sie sich wirklich unsicher sind, kostet ein Totmannschalter nur eine Zeile: systemd-run --on-active=10min /usr/sbin/ufw --force disable stellt einen Timer scharf, der die Firewall nach zehn Minuten wieder abschaltet, sofern Sie ihn nicht abbrechen. Funktionieren die neuen Regeln, brechen Sie ihn ab. Sperren sie Sie aus, lässt die Maschine Sie wieder hinein, ohne dass Sie selbst dort sein müssen.

SSH: die vier Direktiven, die die Arbeit erledigen — und die Datei, die sie überschreibt

Erzeugen Sie den Schlüssel auf Ihrer eigenen Maschine, niemals auf dem Server: ssh-keygen -t ed25519 -C "laptop-2026". Ed25519 ist 2026 die richtige Voreinstellung — kurze Schlüssel, schnelle Verifikation, keine Parameterwahl, bei der man etwas falsch machen kann, und von jedem in den letzten zehn Jahren gebauten OpenSSH unterstützt. RSA mit 4096 Bit ist nicht unsicher, nur größer und langsamer, ohne dass es etwas bringt. Setzen Sie eine Passphrase auf den privaten Schlüssel; mit ssh-agent tippen Sie sie nur einmal pro Sitzung ein, und sie ist das Einzige, was zwischen einem gestohlenen Laptop und jedem Server steht, den Sie besitzen.

Kopieren Sie die öffentliche Hälfte mit ssh-copy-id hinauf und bestätigen Sie, dass Sie sich damit anmelden können, bevor Sie irgendetwas deaktivieren. Berechtigungen sind wichtig, und OpenSSH ist bei ihnen absichtlich streng: ~/.ssh mit 700, authorized_keys mit 600, beide im Besitz des Benutzers. Ein Schlüssel, der stillschweigend nicht funktioniert, ist fast immer ein Berechtigungsproblem, und sshd -e -d im Vordergrund verrät es Ihnen in einer einzigen Zeile.

Dann erledigen vier Direktiven in /etc/ssh/sshd_config im Grunde die gesamte Arbeit. Alles andere in dieser Datei ist Geschmackssache.

Jetzt der Teil, der erfahrene Leute erwischt. Bei Debian 12, Ubuntu 22.04 und allem Neueren beginnt /etc/ssh/sshd_config mit Include /etc/ssh/sshd_config.d/*.conf, und OpenSSH verwendet für jedes Schlüsselwort den ersten Wert, den es erhält. Cloud-Images liefern in diesem Verzeichnis Drop-in-Dateien mit — häufig eine, die PasswordAuthentication yes setzt —, und weil das Include ganz oben steht, gewinnt dieses Drop-in gegen die Zeile, die Sie zweihundert Zeilen weiter unten sorgfältig bearbeitet haben. Die Datei sagt das eine, der Daemon tut das andere.

Die Lösung besteht darin, der Datei niemals zu vertrauen. Fragen Sie den Daemon, was er tatsächlich aufgelöst hat: sshd -T | grep -Ei 'passwordauth|permitrootlogin|kbdinteractive|pubkeyauth' gibt die effektive Konfiguration aus, nachdem jedes Include, jeder Match-Block und jeder Standardwert angewendet wurde. Dieser eine Befehl ist mehr wert als der Rest dieses Abschnitts. Kombinieren Sie ihn mit sshd -t, das die Syntax validiert und sich bei einem Fehler mit einem Wert ungleich null beendet, und erst danach mit systemctl reload ssh — ein Reload stört bestehende Sitzungen nicht, sodass selbst ein misslungener Reload Ihre aktuelle Shell am Leben lässt.

Und wenn es ums Verschieben von SSH auf einen anderen Port als 22 geht: Es entfernt vielleicht 95 % Ihres Log-Volumens und null Prozent Ihres Risikos. Jeder Scanner, über den man sich wirklich Sorgen machen muss, durchsucht alle 65,535 Ports, und diejenigen, die das nicht tun, hätten ohnehin nie die Nur-Schlüssel-Authentifizierung überwunden. Verschieben Sie ihn, wenn das Rauschen Sie stört oder wenn es einen Monitoring-Alarm ruhigstellt, aber verzeichnen Sie es nicht als Sicherheitsmaßnahme — und wenn Sie ihn verschieben, halten Sie ihn unter 1024, denn nur privilegierte Prozesse dürfen sich an diese Ports binden, sodass sich kein unprivilegierter Prozess dort einnisten kann, falls der Daemon jemals stoppt.

Die Firewall: Default-Deny eingehend, und die Hälfte, die jeder vergisst

Eine Firewall auf einem Server mit nur einem Zweck hat genau eine Aufgabe: die Menge der erreichbaren Ports gleich der Menge der Ports zu machen, für die Sie einen Grund nennen können. Default-Deny eingehend, ausgehend erlauben, established- und related-Verbindungen wieder hereinlassen, dann die zwei oder drei Dinge öffnen, die Sie tatsächlich betreiben. Wenn Sie Debian oder Ubuntu einsetzen, ist ufw vier Befehle und korrekt; wenn Sie lieber eine einzige lesbare Regeldatei besitzen möchten, ist nftables die moderne Antwort im Kernel und das, worauf ufw darunter eigentlich schreibt.

Die Reihenfolge zählt an genau einer Stelle: Erlauben Sie Ihren SSH-Port, bevor Sie die Richtlinie aktivieren. ufw allow 22/tcp, dann ufw default deny incoming, dann ufw enable. In umgekehrter Reihenfolge kappt der Enable-Schritt die Sitzung, in der Sie gerade tippen — überlebbar, wenn Sie den vorherigen Abschnitt befolgt haben und noch eine Konsole besitzen, ansonsten die klassische Art, einen Abend vorzeitig zu beenden.

Die vergessene Hälfte ist IPv6. Jeder Server hier wird mit einem gerouteten /64 ausgeliefert, und Dienste binden standardmäßig an beide Adressfamilien. Ein nur mit iptables geschriebenes Regelwerk regelt IPv4 und sagt rein gar nichts über IPv6 aus, sodass die Datenbank, die Sie sorgfältig mit einer Firewall abgesichert haben, über das andere Protokoll für das gesamte Internet erreichbar bleibt. ufw deckt beide ab, wenn IPV6=yes in /etc/default/ufw gesetzt ist (der Standard bei aktuellen Releases — prüfen statt annehmen), und nftables umgeht das Problem strukturell: Ein Regelwerk vom Typ table inet deckt beide Adressfamilien mit einem einzigen Regelsatz ab. Wenn Sie nur eine einzige Zeile Firewall-Konfiguration von Hand schreiben, dann diese.

Dann ist da noch Docker, das Ihre Firewall weniger umgeht als vielmehr darunter ankommt. Das Veröffentlichen eines Ports mit -p 5432:5432 fügt DNAT-Regeln in die nat-Tabelle ein, und diese werden ausgewertet, bevor die Filterketten greifen, die ufw verwaltet. Das Ergebnis ist ein Container, der aus dem Internet erreichbar ist, während ufw status den Port als geschlossen anzeigt, und das überrascht Jahr für Jahr Leute, die eine Datenbank in einem Container hinter etwas betreiben, von dem sie annahmen, es sei eine Deny-all-Richtlinie. Veröffentlichen Sie stattdessen auf Loopback — -p 127.0.0.1:5432:5432 — oder legen Sie den Container in ein internes Netzwerk und erreichen Sie ihn von einem anderen Container aus über den Namen.

Was tatsächlich lauscht — der Befehl, der dem Rätselraten ein Ende macht

Ein einziger Befehl beantwortet die mit Abstand nützlichste Frage zur Exposition eines Servers: ss -tulpn. Er listet jeden lauschenden TCP- und UDP-Socket zusammen mit dem Prozess auf, dem er gehört, und die entscheidende Spalte ist die lokale Adresse. 127.0.0.1:5432 bedeutet, dass nur diese Maschine sich verbinden kann. 0.0.0.0:5432 bedeutet, dass jede Adresse, die die Maschine erreicht, es kann, einzig vorbehaltlich der Firewall. [::]:5432 bedeutet dasselbe über IPv6 — die Zeile, über die man leicht hinwegliest.

Die immer wiederkehrenden Übeltäter sind stets dieselbe Handvoll. Redis, das den größten Teil seiner Geschichte über breit gebunden hat und ohne Authentifizierung ausgeliefert wurde. PostgreSQL und MySQL, wenn eine Konfigurationsdatei so bearbeitet wurde, dass sie Verbindungen „von der App“ akzeptiert, und die App dann umgezogen ist. MongoDB und Elasticsearch, die zusammen genau aus diesem Grund ein Jahrzehnt an Schlagzeilen über Datenexposition produziert haben. Memcached, dessen UDP-Listener zu einem beliebten Bandbreitenverstärker wurde. Prometheus node_exporter, der jedem, der fragt, bereitwillig die internen Details Ihres Hosts erzählt. Die Docker-API auf Port 2375, die Remote-Code-Ausführung im Gewand einer REST-Schnittstelle ist. Und ein Entwicklungsserver, den jemand vor elf Monaten „nur für eine Minute“ in einer tmux-Sitzung gestartet hat.

Die Regel ist einfach und erfordert kein Fingerspitzengefühl: Wenn ein Dienst nicht aus dem Internet erreichbar sein muss, binden Sie ihn an Loopback. Alles, wofür Sie ihn persönlich erreichen müssen, funktioniert weiterhin — ssh -L 5432:127.0.0.1:5432 user@server gibt Ihnen einen lokalen Port, der über die Verbindung tunnelt, der Sie bereits vertrauen, und falls mehrere Maschinen Zugriff brauchen, gibt ihnen ein privates WireGuard-Interface einen Adressbereich, der das öffentliche Internet nie berührt. Beides kostet nichts, und beides entfernt den Dienst vollständig aus der Angriffsfläche, statt ihn zu verteidigen.

Verifizieren Sie von außen, nicht von innen. Ein Port, den Ihre eigene Maschine als gefiltert meldet, ist eine Behauptung über Ihren Loopback-Stack; ein Port, den eine zweite Maschine nicht erreichen kann, ist ein Beweis. Verbinden Sie sich von Ihrem Laptop oder von einem anderen Server aus, und prüfen Sie die Ports, von denen Sie erwarten, dass sie offen sind, sowie einen, von dem Sie erwarten, dass er geschlossen ist — ein Test, der nur bestehen kann, ist kein Test.

Fail2ban und CrowdSec: was sie wert sind, sobald Passwörter verschwunden sind

Das ist der Punkt, den die meisten Checklisten weit oben platzieren und den die meisten Betreiber überbewerten, weshalb sich Genauigkeit lohnt. Mit PasswordAuthentication no kann ein Passwort-Ratenversuch nicht gelingen — nicht selten, nicht schwer, sondern überhaupt nicht. Eine Adresse nach fünf Fehlversuchen zu sperren, macht eine unmögliche Authentifizierung nicht noch unmöglicher. Was Ihnen fail2ban auf der SSH-Ebene bringt, ist ein ruhigeres auth.log, marginal weniger CPU-Aufwand für den Verbindungsaufbau und Monitoring-Grafiken, die sich leichter lesen lassen. Das sind echte Vorteile. Sie sind operative Hygiene, keine Sicherheitsmaßnahme, und sie unter der falschen Überschrift abzulegen, ist der Weg, auf dem Leute mit einer gehärteten Logdatei und einer ungepatchten Anwendung enden.

Wo sich diese Werkzeugklasse tatsächlich verdient macht, ist jede Ebene, auf der noch ein Passwort existiert: ein Login-Formular einer Webanwendung, ein Mail-Submission-Port, ein Nextcloud- oder WordPress-Admin, ein IMAP-Server. Diese lassen sich nicht auf Public-Key-Authentifizierung umstellen, sodass Raten möglich bleibt und Rate-Limiting die eigentliche Verteidigung ist. CrowdSec fügt obendrauf einen geteilten Reputations-Feed hinzu, der auf der HTTP-Ebene spürbar nützlich ist — Sie profitieren von Adressen, die andere Leute bereits beim Fehlverhalten beobachtet haben —, und auf der SSH-Ebene fast irrelevant, sobald Schlüssel verpflichtend sind.

Zwei Selbstschuss-Fallen verdienen es, genannt zu werden. Die erste ist, sich selbst zu sperren, meist beim Testen von irgendetwas um drei Uhr morgens; setzen Sie ignoreip so, dass es Ihre eigenen Bereiche einschließt, und denken Sie daran, dass eine geteilte Adresse oder eine im Carrier-Grade-NAT bedeutet, dass die Sperrung „eines Angreifers“ auch ein paar Hundert unbeteiligte Menschen aussperren kann. Die zweite ist, dass das Werkzeug in der Lage sein muss, die Logs zu lesen, die es filtert: Auf Distributionen, die nur ins systemd-Journal loggen, beobachtet das Standard-Datei-Backend stillschweigend eine Datei, die nichts mehr empfängt, und der Jail sitzt da, sieht gesund aus und tut nichts.

Die ehrliche Empfehlung: Installieren Sie es, wenn das Rauschen Sie stört, konfigurieren Sie es für die Anwendungsebene, auf der es tatsächlich zählt, und rechnen Sie es nicht doppelt an. Wenn Sie dieselbe Ruhe ohne Wartungsaufwand wollen, bringen Sie MaxStartups und LoginGraceTime im SSH-Daemon zusammen mit Nur-Schlüssel-Authentifizierung den größten Teil des Weges dorthin, und zwar ohne dass Sie sich aus Ihrer eigenen Maschine aussperren können.

Patchen: die langweilige Maßnahme, die die meisten echten Kompromittierungen verhindert

Lesen Sie einen beliebigen Vorfallsbericht zu einem kleinen, aus dem Internet erreichbaren Server, und das Muster wiederholt sich: Die Schwachstelle hatte einen Patch, der Patch war seit Wochen oder Monaten verfügbar, und niemand hat ihn eingespielt. Der von CISA geführte Katalog bekannt ausgenutzter Schwachstellen ist hier die nützliche Lektüre, gerade weil er keine Liste theoretischer Schweregrade ist — es ist eine Liste von Dingen, die gerade jetzt in freier Wildbahn ausgenutzt werden, und sie wird von Problemen mit veröffentlichten Fixes dominiert. Automatische Sicherheitsupdates sind folglich die fünfzehn Sekunden mit dem höchsten Ertrag auf dieser ganzen Seite.

Installieren Sie unter Debian und Ubuntu unattended-upgrades, aktivieren Sie es mit dpkg-reconfigure -plow unattended-upgrades, und bestätigen Sie, dass der Security-Origin derjenige ist, der in /etc/apt/apt.conf.d/50unattended-upgrades ausgewählt ist. Verifizieren Sie mit unattended-upgrades --dry-run --debug, dass es tatsächlich etwas tut — der Befehl gibt genau aus, welche Pakete er einspielen würde und warum; die Debian-Wiki-Seite ist die Referenz dafür. Unter Rocky und Alma erledigt dnf-automatic mit apply_updates = yes und aktiviertem Timer denselben Job. Die Beschränkung auf das Security-Repository ist Absicht: Es ist die Konfiguration, die so gut wie nie etwas kaputtmacht — die einzige Art von Automatisierung, die Leute eingeschaltet lassen.

Entscheiden Sie dann explizit über Neustarts, denn genau hier läuft die Maßnahme normalerweise leer. Das Installieren eines neuen Kernel-Pakets ersetzt nicht den laufenden Kernel, und das Ersetzen einer Shared Library startet nicht die Daemons neu, die die alte Kopie bereits in den Speicher gemappt haben. needrestart listet unter Debian und Ubuntu präzise auf, welche Dienste noch gelöschte Bibliotheken offen halten; ein Kernel-Update braucht einen Neustart, Punkt, und Live-Patching ist ein kostenpflichtiges Feature, das nicht auf einer $8.50-Instanz ankommt. Setzen Sie entweder Unattended-Upgrade::Automatic-Reboot mit einer unauffälligen Automatic-Reboot-Time, oder tragen Sie einen monatlichen Neustart in Ihren Kalender ein und behandeln Sie ihn als Wartung statt als Vorfall.

Wissen Sie schließlich, was automatische Updates nicht abdecken, denn genau in dieser Lücke werden Leute erwischt. Alles, was außerhalb des Paketmanagers installiert wurde, ist für ihn unsichtbar: eine Binärdatei aus einem GitHub-Release, eine Sprachlaufzeit-Abhängigkeit von pip, npm oder cargo, ein Theme oder Plugin innerhalb einer Webanwendung, und vor allem Container-Images. Ein Host, der null ausstehende Updates meldet, kann trotzdem ein Basis-Image ausführen, das vor zwei Jahren gebaut wurde, und nichts auf der Maschine wird es Ihnen verraten. Wenn Sie Container betreiben, ist regelmäßiges Neubauen und erneutes Pullen Teil des Patchens, keine separate Tätigkeit.

Benutzer, sudo und die Türen, die sich leise wieder öffnen

Legen Sie einen gewöhnlichen Benutzer an, fügen Sie ihn zu sudo oder wheel hinzu, installieren Sie dort Ihren Schlüssel, und melden Sie sich nicht mehr als Root an. Der Grund ist nicht, dass Root mit einem Schlüssel an sich gefährlich wäre — es ist ein Single-Faktor-Konto mit universell bekanntem Namen und ohne Aufzeichnung, welcher Mensch es benutzt hat. Ein benanntes Konto plus sudo erzeugt eine Audit-Spur, erlaubt mehr als einen Betreiber, ohne einen Zugangsdatensatz zu teilen, und macht die irgendwann fällige Frage „wer hat das ausgeführt“ beantwortbar. Geben Sie ihm aber nicht NOPASSWD für alles und verwenden Sie das Konto dann für einen Webdienst weiter.

Auch Dienste sollten nicht als Root laufen, und systemd macht die günstige Version davon fast kostenlos. Ein mit systemctl edit <unit> erzeugtes Drop-in mit NoNewPrivileges=yes, ProtectSystem=strict, ProtectHome=yes und PrivateTmp=yes sperrt einen kompromittierten Daemon in eine schreibgeschützte Dateisystemsicht ohne Weg zur Rechteausweitung ein — vier Zeilen, beschrieben in der systemd.exec-Dokumentation, die aus vielen Anwendungs-Schwachstellen statt „Root auf dem Host“ nur noch „einen Fehler in einem Log“ machen. systemd-analyze security bewertet jede Unit auf der Maschine und verrät Ihnen, welche die fünf Minuten wert sind.

Halten Sie authorized_keys ehrlich. Ein Schlüssel pro Gerät, jeder mit einem Kommentar, der das Gerät benennt, und löschen Sie alles, was Sie nicht identifizieren können. Lesen Sie die Datei erneut, nachdem ein Provisioning-Tool gelaufen ist, denn cloud-init, Imaging-Pipelines und Control-Panels hängen alle ihre eigenen Einträge an, und ein Schlüssel, den Sie nicht selbst hinzugefügt haben, ist ein Schlüssel, den Sie nicht widerrufen können. Dasselbe gilt für Konten: ein von einem Image hinterlassener Standardbenutzer, mit einem von einem Skript gesetzten und seither nie benutzten Passwort, ist ein Zugang, den Sie nicht im Blick haben.

Der subtilste Punkt auf dieser Liste ist Agent-Forwarding. ForwardAgent yes erlaubt einem Prozess auf dem entfernten Host, Ihren lokalen privaten Schlüssel zu benutzen, solange Sie verbunden sind — genau dafür ist es entworfen, und deshalb kann Root auf einer Maschine, die Sie nicht vollständig kontrollieren, sich Ihren Schlüssel ausleihen, um jeden anderen Server zu erreichen, der ihm vertraut. Verwenden Sie stattdessen ProxyJump (ssh -J bastion target): Es verschafft Ihnen dieselbe Erreichbarkeit, indem es die Verbindung tunnelt, und Ihr Schlüssel wird auf dem zwischengeschalteten Host niemals nutzbar. Wenn Sie einen Agent unbedingt weiterleiten müssen, tun Sie es pro Host in ~/.ssh/config, niemals global.

Backups: die Maßnahme, die aus einem schlechten Tag einen Nachmittag macht

Alles, was oben steht, senkt die Wahrscheinlichkeit eines schlechten Tages. Backups entscheiden, was der schlechte Tag kostet, und bei einem Anbieter, der Sie absichtlich nicht identifizieren kann, zählen sie mehr als sonst: Es gibt keinen Support-Weg, der Ihre Maschine aus der Kopie eines anderen rekonstruiert, keinen Kontowiederherstellungs-Ablauf, der Ihnen still und leise eine Wiederherstellung in die Hand drückt, und keinen Rechnungsdatensatz mit einer angehängten Telefonnummer. Was Sie haben, ist das, was Sie sich gesichert haben.

Die Form, die funktioniert, ist unaufregend. restic oder borg, verschlüsselt auf dem Server, sodass die Daten bereits unlesbar sind, bevor sie das Netzwerk überqueren, gepusht auf eine zweite Maschine — und idealerweise in eine zweite Rechtsordnung, was eine Checkbox statt eines Projekts ist, wenn dasselbe Panel Island, die Niederlande, Rumänien und die Schweiz anbietet. Die stündlichen, bei jedem Plan enthaltenen Snapshots sind eine wirklich gute erste Verteidigungslinie und decken den Fall „ich habe die Konfiguration vor einer Stunde kaputtgemacht“ perfekt ab. Sie decken keine Datei ab, die Sie vor fünf Wochen gelöscht haben, und sie leben auf derselben Infrastruktur wie das, was sie schützen sollen. Snapshots und Backups lösen unterschiedliche Probleme; betreiben Sie beide.

Machen Sie das Repository append-only. Das ist das Detail, das ein Backup von einer bloßen Kopie unterscheidet: Ein kompromittierter Server besitzt die Zugangsdaten zu seinem eigenen Backup-Ziel, und alles, was löschen kann, wird auch zum Löschen angewiesen. Sowohl borg serve --append-only als auch rest-server --append-only von restic erzwingen das auf der empfangenden Seite, sodass die Maschine neue Snapshots schreiben, aber keine alten entfernen kann. Führen Sie das Pruning von woanders aus durch, nach Zeitplan, mit einem Zugangsdatensatz, den der Server nie gesehen hat.

Zwei letzte Dinge, die beide gerne übersprungen werden. Die Repository-Passphrase darf nicht nur auf der Maschine leben, die sie schützt — schreiben Sie sie auf, legen Sie sie an anderer Stelle in einem Passwortmanager ab, behandeln Sie sie wie die Seed-Phrase, die sie faktisch ist. Und stellen Sie einmal wieder her. Ein Backup, das Sie nie wiederhergestellt haben, ist eine Hypothese; der übliche Weg, herauszufinden, dass eine Exclude-Regel den Datenbank-Dump still und leise übersprungen hat, ist während der Wiederherstellung, bei der Sie sich keinen Fehlschlag leisten können. Starten Sie eine Starter-Instanz, stellen Sie darauf wieder her, prüfen Sie die Daten, zerstören Sie sie danach. Das kostet $8.50 und eine Stunde, und es ist der einzige Weg, wie der Rest dieser Seite jemals eine Generalprobe wird statt eines ersten Versuchs.

Wogegen Härtung Sie nicht schützt

Sie schützt die Festplatte nicht vor jemandem, der die Festplatte physisch in Händen hält. Jede Maßnahme auf dieser Seite setzt voraus, dass das Betriebssystem läuft und seine eigenen Regeln durchsetzt; keine davon gilt für eine ausgeschaltete Maschine, deren Speicher abgezogen wurde. Das ist ein anderes Problem mit einer anderen Antwort — siehe Festplattenverschlüsselung, Remote-Unlock und was eine Beschlagnahmung tatsächlich zutage fördert —, und die ehrliche Zusammenfassung lautet, dass Härtung und Verschlüsselung sich gegen disjunkte Bedrohungen verteidigen. Das eine zu tun, erledigt das andere nicht teilweise mit.

Sie repariert nicht die Anwendung, die Sie betreiben. Ein Server kann jede Prüfung hier bestehen und trotzdem an ein veraltetes Forum, einen Admin-Endpunkt ohne Authentifizierung, eine Template-Engine, die Nutzereingaben auswertet, oder einen in ein öffentliches Repository committeten Token verloren gehen. Host-Härtung reduziert den Explosionsradius einer Anwendungs-Kompromittierung — genau dafür ist die systemd-Einsperrung oben gedacht —, aber sie auditiert nicht Ihren Code, und der häufigste Weg, wie ein kleiner Server verloren geht, ist immer noch etwas, das der Betreiber selbst installiert hat.

Sie ändert nicht, wer weiß, dass Sie die Maschine gemietet haben. Eine perfekt gehärtete Kiste, bezahlt von einem identitätsverifizierten Exchange-Konto, bestellt mit einer persönlichen E-Mail-Adresse, ist eine perfekt gehärtete Kiste mit Ihrem Namen darauf. Die Sicherheitsebene und die Identitätsebene sind unabhängig voneinander, und Letztere wird beim Checkout entschieden, nicht in der Shell — wie rückverfolgbar Krypto-Hosting wirklich ist beschreibt, wo die Verknüpfungen tatsächlich entstehen.

Und sie tut nichts gegen Traffic-Analyse. Ein Beobachter, der in der Position ist, Ihre Verbindungen zu beobachten, erfährt deren Form — Timing, Volumen, wer mit wem spricht —, unabhängig davon, wie gut die Endpunkte konfiguriert sind. Verschlüsselung verbirgt Inhalt, nicht die Kommunikation selbst, und keine noch so ausgefeilte sshd-Abstimmung ändert daran etwas.

Die Checkliste, in der Reihenfolge, in der Sie sie abarbeiten

Acht Schritte. Die ersten vier sind die fünfzehn Minuten aus dem Titel und eliminieren ganze Risikokategorien; die letzten vier dauern länger und sind das, was einen Server, den Sie verteidigen können, von einem unterscheidet, den Sie nur konfiguriert haben. Jede Zeile enthält, woran Sie erkennen, dass es funktioniert hat, denn ein Härtungsschritt, den Sie nicht überprüft haben, ist ein Härtungsschritt, den Sie nicht durchgeführt haben.

Nichts davon ist exotisch, und genau das ist der Punkt. Die Maßnahmen, die auf einem kleinen Server zählen, sind die, die eine Problemklasse eliminieren, statt sie zu verwalten: keine Passwörter, keine unerwarteten Listener, keine ungepatchten Pakete, keine einzige Kopie der Daten. Alles andere ist Geschmackssache, und Geschmackssache ist billig, sobald die vier tragenden Änderungen vorhanden und verifiziert sind.

Wenn Sie die Maschine gerade jetzt bereitstellen, statt nur vorauszulesen, passt die Abfolge bequem in die erste Sitzung: eine Instanz bereitstellen, die Konsole einmal öffnen, um zu beweisen, dass sie funktioniert, und die acht Schritte der Reihe nach ausführen, bevor Sie überhaupt irgendetwas installieren. Ein Server, der gehärtet wird, bevor ein Dienst darauf läuft, hat keine Altlasten, um die man herumarbeiten müsste — das ist der eine Vorteil, den eine neue Kiste hat, und er hält ungefähr einen Tag.