Wie Sie einen neuen VPS absichern: die ersten zehn Minuten

Ein neuer Server ist in dem Moment am verwundbarsten, in dem er eine IP-Adresse bekommt. Automatisierte Scanner durchkämmen fortlaufend den gesamten IPv4-Raum, sodass die ersten Login-Versuche gegen eine Box, die vor einer Minute bereitgestellt wurde, meist eintreffen, bevor Sie die Willkommensnachricht zu Ende gelesen haben. Nichts davon zielt gezielt auf Sie — es ist Hintergrundrauschen, und genau deshalb wird ein ungehärteter Server mit einem Passwort auf root eher innerhalb von Stunden als von Monaten kompromittiert. Die gute Nachricht: Das dichtzumachen ist schnell erledigt — zehn Minuten geordneter Schritte beseitigen praktisch das gesamte opportunistische Risiko. Diese Anleitung behandelt genau diese Checkliste, die Reihenfolge, die verhindert, dass Sie sich selbst aussperren, und eine Sache, die die meisten Härtungs-Tutorials nie erwähnen — die persönlichen Details, die eine Standardkonfiguration still und leise auf einer Maschine hinterlässt, die Sie extra gemietet haben, damit sie nicht mit Ihnen in Verbindung gebracht wird.

Wovor Härtung Sie tatsächlich schützt

Härtung lohnt sich gerade deshalb, weil ihr Nutzen eng begrenzt und zugleich real ist. Wer diese Grenze klar vor Augen hat, verfällt nicht in falsche Sicherheit bei den Dingen, die sie nicht berührt.

• Sie schaltet den opportunistischen Angreifer vollständig aus. Credential-Stuffing-Bots, SSH-Brute-Force und Scans nach offenen Admin-Panels scheitern allesamt an einer reinen Schlüssel-Authentifizierung und einer Default-Deny-Firewall.
• Sie begrenzt den Schaden, wenn etwas, das Sie betreiben, eine Schwachstelle hat. Ein Dienst, der an localhost gebunden ist und hinter einem geschlossenen Port liegt, ist für Fremde selbst an dem Tag nicht erreichbar, an dem seine CVE veröffentlicht wird.
• Sie senkt den Preis eines Fehlers. Unprivilegierte Benutzer, getrennte Schlüssel und automatisches Patchen sorgen dafür, dass eine einzelne falsche Entscheidung nicht gleich die ganze Maschine preisgibt.
• Sie verbirgt den Server nicht vor Ihrem Host. Wer Zugriff auf den Hypervisor hat, kann im Prinzip den Arbeitsspeicher einer laufenden Maschine auslesen — eine Frage danach, bei wem Sie mieten, nicht danach, wie Ihre Firewall-Regeln aussehen.
• Härtung macht Sie nicht anonym. Sie schützt die Box; ob die Box mit Ihrem Namen verknüpft ist, entscheidet sich bei der Registrierung und bei der Zahlung — lange bevor Sie sich zum ersten Mal einloggen.

Genau diese letzte Unterscheidung wird am häufigsten vertauscht. Ein perfekt gehärteter Server, gekauft mit einer Kreditkarte auf Ihren echten Namen, ist immer noch ein Server auf Ihren echten Namen. Die beiden Ebenen ergänzen sich: No-KYC-Hosting und ein mit Krypto finanziertes Guthaben entscheiden, wem die Maschine auf dem Papier gehört, und die zehn Minuten weiter unten entscheiden, wer hineinkommt.

Die Reihenfolge, die verhindert, dass Sie sich selbst aussperren

Fast jede Horrorgeschichte übers Härten ist dieselbe Geschichte: Jemand hat die Passwort-Authentifizierung deaktiviert, bevor bestätigt war, dass der eigene Schlüssel funktioniert, oder eine Firewall aktiviert, deren Regeln SSH nicht enthielten, und sich damit selbst aus einer Maschine ausgesperrt, die nicht mehr erreichbar ist. Die Reihenfolge existiert genau dafür, das unmöglich zu machen. Installieren Sie zuerst den Schlüssel und bestätigen Sie in einem zweiten Fenster, dass er funktioniert. Erst danach schalten Sie Passwörter ab. Fügen Sie die Firewall-Regel für SSH hinzu, bevor Sie die Firewall aktivieren — niemals danach.

Es lohnt sich außerdem, den eigenen Rettungsweg zu kennen, bevor man ihn braucht. Ein VPS, den Sie nur über SSH erreichen, hat genau eine Tür — die Konsole im Dashboard Ihres Anbieters ist deshalb der Rückfallplan, der aus einer Aussperrung ein Ärgernis macht statt eines Neuaufbaus. Prüfen Sie, dass Sie sie öffnen können, solange noch alles funktioniert.

Schritt für Schritt: die ersten zehn Minuten auf einer neuen Box

1. 01Paketindex und installierte Pakete aktualisierenEin frisches Image ist eine Momentaufnahme vom Zeitpunkt seiner Erstellung. Es auf den aktuellen Stand zu bringen ist die wertvollste einzelne Maßnahme auf dieser Liste — und dauert unter einer Minute.
2. 02Einen unprivilegierten Benutzer mit sudo anlegenStändig als root zu arbeiten bedeutet, dass jeder Tippfehler und jeder Prozess mit vollen Rechten läuft. Legen Sie einen normalen Benutzer an, fügen Sie ihn der Gruppe sudo oder wheel hinzu, und nutzen Sie fortan diesen.
3. 03Ihren öffentlichen Schlüssel auf diesen Benutzer kopierenErzeugen Sie auf Ihrer eigenen Maschine einen ed25519-Schlüssel, falls Sie noch keinen haben, und übertragen Sie die öffentliche Hälfte mit ssh-copy-id. Der private Schlüssel verlässt Ihren Laptop nie.
4. 04Ein zweites Terminal öffnen und den Schlüssel-Login bestätigenÜberspringen Sie das nicht. Loggen Sie sich als neuer Benutzer mit dem Schlüssel in einem neuen Fenster ein, bevor Sie irgendetwas an der Authentifizierung ändern.
5. 05Passwort-Authentifizierung und Root-Login deaktivierenSetzen Sie PasswordAuthentication no und PermitRootLogin prohibit-password und laden Sie sshd anschließend neu. Brute-Force-Versuche gegen die Box haben jetzt nichts mehr zu erraten.
6. 06Eine Default-Deny-Firewall mit erlaubtem SSH aktivierenBlockieren Sie sämtlichen eingehenden Verkehr, erlauben Sie Ihren SSH-Port, und aktivieren Sie die Firewall erst dann. Fügen Sie die Ports, die Ihre eigenen Dienste brauchen, danach einzeln hinzu.
7. 07Automatische Sicherheitsupdates aktivierenunattended-upgrades unter Debian und Ubuntu, dnf-automatic in der RHEL-Familie. Das ist es, was die Maschine im sechsten Monat noch schützt, wenn Sie längst nicht mehr aufpassen.
8. 08Auflisten, was lauscht, und schließen, was nicht offen sein sollteEin einziges ss -tulpn zeigt Ihnen jeden offenen Socket. Alles, was Sie nicht bewusst dort platziert haben, sollte entfernt oder an localhost gebunden werden.

SSH: nur Schlüssel, und die Einstellungen, auf die es ankommt

Public-Key-Authentifizierung ist im Grunde die gesamte SSH-Härtung. Sobald Passwörter abgeschaltet sind, braucht ein Angreifer einen privaten Schlüssel, den er nicht besitzt, und beliebig viel Raten produziert keinen. Erzeugen Sie ed25519-Schlüssel — sie sind kurz, schnell und der moderne Standard — und schützen Sie den Schlüssel mit einer Passphrase, damit ein gestohlener Laptop nicht gleich einen gestohlenen Server bedeutet. Alles andere in sshd_config ist Feinschliff auf dieser einen Entscheidung.

• PasswordAuthentication no — die Einstellung, die Brute-Force-Angriffen ein Ende setzt. Bestätigen Sie zuerst in einer zweiten Sitzung, dass Ihr Schlüssel funktioniert.
• PermitRootLogin prohibit-password — root bleibt für den Notfall per Schlüssel erreichbar, aber nie per Passwort. Setzen Sie es auf no, sobald sich Ihr sudo-Benutzer bewährt hat.
• AllowUsers oder AllowGroups — eine explizite Positivliste, wer sich überhaupt einloggen darf, damit ein von irgendeinem Paket angelegtes Dienstkonto niemals zum SSH-Einfallstor werden kann.
• KbdInteractiveAuthentication no — schließt den anderen interaktiven Pfad, der auf manchen Distributionen still und leise Passwortabfragen wieder aktivieren kann.
• Ein zweiter Schlüssel für ein zweites Gerät, statt einen einzigen privaten Schlüssel überallhin zu kopieren. Ein verlorenes Telefon sollte bedeuten, eine Zeile aus authorized_keys zu entfernen — nicht, alles neu auszurollen.
• SSH von Port 22 wegzuverlegen senkt Ihr Log-Volumen drastisch, aber behandeln Sie das als Lärmreduktion, nicht als Sicherheitsmaßnahme — für jemanden, der Ihre IP tatsächlich ins Visier nimmt, ändert sich dadurch nichts.

Wer weiter gehen will als bloße Schlüssel, für den ist die stärkste Lösung, SSH überhaupt nicht öffentlich zu exponieren: Legen Sie die Maschine hinter einen WireGuard-Tunnel und blockieren Sie Port 22 per Firewall so, dass nur Verbindungen von der Tunnel-Adresse akzeptiert werden. Das macht Ihren SSH-Daemon zu etwas, das das Internet gar nicht erst sehen kann — ein besseres Ergebnis als jede noch so gründliche Konfigurationshärtung an einem offen liegenden Daemon.

Die Firewall: standardmäßig blockieren, dann genau das öffnen, was Sie nutzen

Eine Firewall ist nur dann sinnvoll, wenn ihr Standardverhalten die Ablehnung ist. Alles zu erlauben und dann bekannt schlechte Ports zu sperren, ist die falsche Reihenfolge: Am Ende schützen Sie genau die Dienste, an die Sie sich erinnert haben, und lassen die offen, die Sie vergessen haben. Blockieren Sie sämtlichen eingehenden Verkehr, erlauben Sie ausgehenden, und öffnen Sie danach einzelne Ports genau dann, wenn Sie etwas bereitstellen, das sie braucht. Modernes Linux nutzt darunter nftables, und ufw oder firewalld sind völlig brauchbare Oberflächen dafür — das Werkzeug spielt eine viel kleinere Rolle als die Grundeinstellung.

• Erlauben Sie SSH, bevor Sie die Firewall aktivieren — nicht danach. Das ist die zweithäufigste Art, sich selbst auszusperren.
• Öffnen Sie nur die Ports, die ein Dienst wirklich von außen braucht. Ein Webserver will 80 und 443; eine Datenbank will so gut wie nie etwas.
• Binden Sie rein lokale Dienste an 127.0.0.1 statt an 0.0.0.0. Ein geschlossener Port und ein Dienst, der nie öffentlich lauscht, sind zwei voneinander unabhängige Schutzschichten — Sie wollen beide.
• Schreiben Sie IPv6-Regeln genauso wie IPv4-Regeln. Ein Regelwerk, das auf einer Dual-Stack-Box nur v4 abdeckt, lässt denselben Dienst auf seiner v6-Adresse weit offen stehen.
• Beschränken Sie Management-Ports wo möglich auf bestimmte Quelladressen. Wenn Administration immer von einem einzigen VPN-Endpunkt kommt, legen Sie das genau so in der Regel fest.
• Lesen Sie die Regeln erneut durch, nachdem Sie einen Dienst hinzugefügt haben. Ports, die für etwas geöffnet wurden, das Sie inzwischen wieder entfernt haben, sind genau die stille Anhäufung, die einen sauberen Start am Ende zunichtemacht.

Manche Workloads drehen die Logik um und brauchen absichtlich einen weit offenen Port — ein Tor-Relay muss Verbindungen von überall annehmen, und ein vollständiger Bitcoin-Node bedient Peers nur, wenn 8333 erreichbar ist. Das ist völlig in Ordnung. Die Regel lautet nicht "nichts öffnen", sondern "bewusst öffnen", und ein Dienst, der von Anfang an öffentlich sein soll, ist genau das: eine bewusste Entscheidung.

fail2ban, und warum es weniger wichtig ist, als Sie denken

fail2ban beobachtet Ihre Logs und sperrt Adressen aus, die wiederholt an der Authentifizierung scheitern. Das ist wirklich nützlich, aber es lohnt sich, ehrlich zu sein, was es leistet, sobald die Passwort-Authentifizierung bereits deaktiviert ist: Ab diesem Punkt kann niemand mehr durch Raten Erfolg haben, sodass fail2ban keinen Einbruch mehr verhindert. Was es verhindert, sind Tausende sinnlose Logzeilen pro Tag, die CPU, die diese Verbindungsversuche verbrauchen, und das Risiko, dass ein echtes Ereignis in einem Rauschen untergeht, das Sie seit Monaten nicht mehr lesen.

Zehn Sekunden Einrichtung sind dafür trotzdem gut investiert, und es wird genau in dem Moment wirklich schützend, in dem Sie etwas betreiben, das tatsächlich ein Passwort akzeptiert — ein Login für eine Webanwendung, einen Mailserver, ein Control Panel. Richten Sie es auf diese Logs statt nur auf sshd aus. Setzen Sie das Sperrfenster in Stunden statt in Minuten an, und tragen Sie Ihre eigene Adresse in die Ignore-Liste ein, damit ein vertipptes Passwort Sie nicht aus Ihrer eigenen Maschine aussperrt.

Updates, an die Sie nicht denken müssen

Die realistische Bedrohung für einen gut konfigurierten Server ist nicht, dass jemand Ihre SSH-Schlüssel überwindet. Es ist eine veröffentlichte Schwachstelle in etwas, das Sie installiert und dann vergessen haben, ausgenutzt von einem Scanner drei Tage später, während Sie längst mit etwas anderem beschäftigt waren. Automatische Sicherheitsupdates sind die Antwort darauf: Unter Debian oder Ubuntu ist das unattended-upgrades, konfiguriert auf das Security-Repository; unter Fedora, Rocky oder Alma ist es dnf-automatic. Schalten Sie es in den ersten zehn Minuten ein, und die Maschine patcht sich selbst weiter, lange nachdem Ihre Aufmerksamkeit woanders hingewandert ist.

Kernel- und libc-Updates sind die Ausnahme, die Sie trotzdem noch brauchen: Sie wirken erst nach einem Neustart, sodass ein Server, der seit vierhundert Tagen läuft, mit ziemlicher Sicherheit Code ausführt, der auf der Platte schon vor einem Jahr gepatcht wurde. needrestart unter Debian zeigt Ihnen, welche Dienste noch gegen gelöschte Bibliotheken laufen, und ein geplantes Neustart-Fenster — und sei es nur monatlich — ist der Unterschied zwischen installierten Patches und tatsächlich wirksamen. Alles, was Sie betreiben, sollte ohnehin einen unerwarteten Neustart überstehen; falls nicht, ist das ein eigenes Problem, das es sich zu beheben lohnt.

Die Identitätslecks, die eine Härtungs-Checkliste übersieht

Dieser Abschnitt zählt, wenn Sie sich bewusst für einen Offshore-Host ohne KYC entschieden haben. Eine gewöhnliche Härtungsanleitung ist für einen Firmenserver geschrieben, dessen Besitzer ohnehin öffentlich bekannt ist, und fragt deshalb nie, was die Standardkonfiguration eigentlich über Sie verrät. Auf einer Maschine, die Sie anonym gemietet haben, verknüpfen mehrere dieser Standardeinstellungen still und leise Ihren Namen wieder mit ihr.

• Ihr öffentlicher SSH-Schlüssel trägt einen Kommentar — standardmäßig Ihren lokalen Benutzernamen und den Hostnamen Ihres Laptops, etwa alex@alex-macbook —, und dieser Kommentar landet wortwörtlich in authorized_keys auf dem Server. Setzen Sie ihn beim Erzeugen des Schlüssels über die Option -C, oder bearbeiten Sie die Zeile nach dem Kopieren.
• Der Server-Hostname, den Sie wählen, landet in Logs, in Mail-Headern, in Monitoring-Ausgaben und manchmal in Service-Bannern. Ein generischer Hostname verrät nichts; Ihr Name oder der Ihrer Firma dagegen schon.
• Die Systemzeitzone. Cloud-Images stehen standardmäßig auf UTC, was niemandem irgendetwas verrät. Sie auf Ihre lokale Zeitzone zu stellen, grenzt schon ein, wo Sie sich befinden, und die Zeitstempel in jedem Log bestätigen anschließend noch Ihre Arbeitszeiten.
• Eine auf die Box kopierte Git-Konfiguration, die Namen und E-Mail-Adresse trägt, unter denen Sie committen. Genauso Shell-History-Dateien, von Ihrer Workstation synchronisierte Dotfiles, und alle Zugangsdaten, die während eines schnellen Tests im Cache gelandet sind.
• Die E-Mail-Adresse, die Sie bei der Zertifikatsausstellung an Let's Encrypt weitergeben, wird Teil eines öffentlichen Datensatzes zu diesem Zertifikat. Verwenden Sie eine Adresse, die nicht mit Ihrer Identität verknüpft ist.
• Versions-Banner des Webservers und X-Powered-By-Header, dazu jedes Analytics-Tool, jeder Crash-Reporter oder Monitoring-Agent eines Anbieters, der von der Maschine aus nach Hause telefoniert und dabei eine Konto-Kennung mitschickt.

Es lohnt sich, die Ebenen sauber auseinanderzuhalten. Härtung hält Fremde von der Maschine fern. Diese Details verhindern, dass die Maschine Sie gegenüber jemandem beschreibt, der sie sich ohnehin schon ansieht. Und die Zahlungsebene entscheidet, ob es überhaupt je einen Namen zu finden gab — ein Thema, das ob der Kauf eines VPS mit Bitcoin wirklich anonym ist ehrlich behandelt, und das das Aufladen in Monero noch weiterführt. Jede Ebene versagt für sich allein; zusammen halten sie.

Backups: der Teil, den Härtung Ihnen nicht abnimmt

Keine Firewall-Regel schützt vor einer gelöschten Datenbank, einer ausgefallenen Festplatte oder einer Konfigurationsänderung, die im Moment vernünftig erschien. Backups sind die einzige Maßnahme, die Sie vor Ihren eigenen Fehlern rettet — und das ist statistisch der wahrscheinlichste Weg, auf einer gut abgesicherten Maschine Daten zu verlieren. Verschlüsseln Sie sie, bevor sie den Server verlassen, bewahren Sie mindestens eine Kopie irgendwo auf, wo der Server selbst nicht herankommt, und lassen Sie sie nach einem festen Zeitplan laufen statt dann, wenn Sie zufällig daran denken.

Dieser letzte Punkt wiegt schwerer, als er klingt: Ein Backup-Prozess, den der Server selbst überschreiben kann, ist ein Backup, das alles mit root-Rechten auf dem Server zerstören kann. Verschlüsselte Archive auf einen separaten Storage-Server zu schieben — oder sie von dort abzuholen, sodass die Zugangsdaten die gesicherte Maschine gar nicht erst berühren — liefert Ihnen eine Kopie, die die Maschine überlebt. Und testen Sie die Wiederherstellung einmal ganz bewusst, solange nichts kaputt ist. Ein ungetestetes Backup ist eine Vermutung, kein Sicherheitsnetz.

Fehler, die die Arbeit still und leise zunichtemachen

• Die Passwort-Authentifizierung deaktivieren, bevor der Schlüssel getestet wurde, und den Fehler dann von einem Laptop aus entdecken, der sich nicht mehr einloggen kann.
• Die Firewall aktivieren, bevor SSH erlaubt ist — dieselbe Aussperrung, nur aus der anderen Richtung erreicht.
• Nur IPv4-Regeln schreiben und dabei jeden Dienst über die IPv6-Adresse der Box erreichbar lassen.
• Am ersten Tag sorgfältig härten und danach ein Control Panel, eine Datenbank und einen Monitoring-Stack installieren, die jeweils ungefragt ihren eigenen Port öffnen.
• Alles als root laufen lassen, weil das ein sudo weniger ist — sodass die erste Schwachstelle in irgendetwas davon gleich die vollständige Kompromittierung bedeutet.
• fail2ban als Ersatz für Schlüssel behandeln, wodurch ein Passwort-Ratespiel weiterläuft, das nur noch etwas langsamer geworden ist.
• Annehmen, ein gemieteter Server ließe sich durch Festplattenverschlüsselung vor seinem Host verbergen — Full-Disk-Encryption schützt eine gestohlene Festplatte, keine laufende Maschine.
• Nie neu starten, sodass monatelang installierte Kernel-Patches auf der Platte liegen bleiben, während der alte Kernel weiterläuft.

Nichts davon ist schwierig, und nichts davon dauert lange. Erledigen Sie es der Reihe nach, bestätigen Sie jeden Schritt aus einem zweiten Terminal, bevor Sie weitermachen — und die Maschine, die Sie vor ein paar Minuten bereitgestellt haben, hört auf, eine Gelegenheit für jeden zu sein, der den Adressraum durchkämmt. Stellen Sie danach bereit, weswegen Sie eigentlich hier sind — eine Website, einen Node, einen Tunnel, einen privaten Modell-Endpunkt — auf einer Basis, die Sie tatsächlich durchschauen.