Neuen VPS härten: die erste Stunde nach dem Deploy

Die erste Stunde ist nicht optional

Der IPv4-Adressraum des Internets ist klein genug, dass ihn ein gut ausgestatteter Unbekannter in wenigen Minuten komplett scannen kann — ein einzelner Laptop braucht dafür ein paar Stunden. Hosting-Bereiche sind veröffentlicht, katalogisiert und werden ständig neu gescannt, eine neue Adresse ist also nicht unauffällig — sie ist ein frischer Eintrag in einer Liste, die bereits existiert. In der Praxis trifft der erste automatisierte SSH-Login-Versuch auf einer frisch gebooteten Box ein, lange bevor Sie Ihre Willkommens-E-Mail zu Ende gelesen haben, gefolgt von Tausenden weiteren aus völlig unabhängigen Quellen, die alle dieselben paar hundert Passwörter gegen dieselben paar Benutzernamen probieren. Nichts davon zielt auf Sie persönlich. Es ist eine Maschine, die das Internet in antwortet und antwortet nicht sortiert, und das Einzige, was entscheidet, in welchen Stapel Sie landen, ist das, was Sie in der ersten Stunde getan haben.

Die gute Nachricht: Die Arbeit ist langweilig und endlich. Vier Kontrollen erledigen fast alles davon: mit Schlüsseln statt Passwörtern authentifizieren, jeden eingehenden Port verweigern, den Sie nicht bewusst bedienen, Sicherheitsupdates anwenden, ohne gefragt zu werden, und aufhören, als root zu arbeiten. Jede davon dauert wenige Minuten, und keine ist exotisch. Was es lohnt, extra für einen Offshore-Server ohne KYC festzuhalten, ist die Asymmetrie am anderen Ende — der Weg zurück. Bei einem gängigen Anbieter endet eine kaputte sshd_config mit einem Support-Ticket, einer Identitätsprüfung und einer Konsolensitzung. Hier gibt es keine hinterlegte Identität zu prüfen, was der ganze Sinn des Produkts ist — und zugleich der Grund, warum ein unbedachter Tastendruck Sie die Maschine kostet statt zwanzig Minuten. Jeder Schritt weiter unten ist mit diesem Gedanken geschrieben.

Was einen kleinen Server tatsächlich angreift

In den Logs tauchen zwei sehr unterschiedliche Gruppen auf, und es lohnt sich, sie auseinanderzuhalten, denn sie werden mit unterschiedlichen Mitteln abgewehrt. Die überwältigende Mehrheit ist wahlloses Massenscanning: Bots, die sich durch den Adressraum arbeiten und nach SSH suchen, das Passwörter akzeptiert, nach Datenbanken, die an 0.0.0.0 gebunden sind, nach Admin-Panels mit Standardzugangsdaten, vergessenen Staging-Kopien, ungepatchten Webanwendungen mit einem öffentlichen Exploit. Dieser Gruppe ist egal, wofür Ihr Server da ist. Mit ihr lässt sich nicht verhandeln, sie hört nie auf, und sie wird von der Checkliste in diesem Guide vollständig geschlagen — nicht weil die Checkliste besonders clever wäre, sondern weil die Bots nach Maschinen suchen, die sie ausgelassen haben, und davon gibt es reichlich.

Die zweite Gruppe ist gezielt — jemand will genau Ihre Box — und sie ist selten, teuer und kommt fast nie über SSH hinein. Sie kommt über die Anwendung, die Sie deployt haben, eine Abhängigkeit, die Sie nicht geprüft haben, wiederverwendete Zugangsdaten, oder ein Laptop, der schon kompromittiert war, bevor er je den Server berührt hat. Deshalb hört Härtung nicht bei der Firewall auf: Die eigentlichen Fragen sind, als was Ihr Dienst läuft, was er ausgehend erreichen kann, und wie schnell Sie patchen. Gut zu wissen, während Sie planen: Unsere VPS-Pläne sind KVM-Vollvirtualisierung, Sie fahren also Ihren eigenen Kernel, und die gesamte Werkzeugkiste — nftables, ufw, Namespaces, seccomp, eigene sysctl-Werte — funktioniert tatsächlich, was bei containerbasierten "VPS"-Produkten nicht gilt, wo der Kernel jemand anderem gehört.

SSH: Schlüssel, und genau eine Tür

Passwort-Authentifizierung auf einem öffentlichen SSH-Port ist das mit Abstand größte selbstverschuldete Risiko auf einem gemieteten Server, und sie abzuschalten kostet die fünf wertvollsten Minuten in diesem Guide. Erzeugen Sie ein Ed25519-Schlüsselpaar auf Ihrer eigenen Maschine — niemals auf dem Server, wo die private Hälfte ausgerechnet auf dem Host zur Welt käme, den Sie eigentlich schützen wollen —, schützen Sie es mit einer Passphrase, und laden Sie es in einen Agenten, sodass die Passphrase Sie einmal pro Sitzung statt einmal pro Login kostet. Kopieren Sie die öffentliche Hälfte hinauf, bestätigen Sie, dass es funktioniert, und schalten Sie erst dann Passwörter ab. Mit PasswordAuthentication no und KbdInteractiveAuthentication no hören die täglich Tausenden Rateversuche auf, ein Risiko zu sein, und werden zu bloßem Rauschen: Es gibt kein Passwort zu erraten, also scheitert der Versuch, bevor er überhaupt interessant wird.

Root verdient eine eigene Entscheidung. PermitRootLogin prohibit-password behält schlüsselbasierten Root-Zugriff für Notfälle; PermitRootLogin no ist strenger und zwingt jede Sitzung durch ein benanntes Konto mit sudo — genau das wollen Sie, sobald mehr als eine Person die Box anfasst. Fügen Sie AllowUsers hinzu, damit ein verirrtes, von irgendeinem Paket angelegtes Konto niemals ein Anmeldeweg sein kann. Den Daemon von Port 22 zu verlegen lohnt sich, aber seien Sie ehrlich darüber, warum: Es ist keine Sicherheitskontrolle — wer Ihre Adresse scannt, findet den neuen Port in Sekunden —, es ist Log-Hygiene, und es entfernt die große Mehrheit des automatisierten Rauschens, sodass die Einträge, die in auth.log übrig bleiben, tatsächlich lesenswert sind. Was auch immer Sie ändern, validieren Sie es mit sshd -t, bevor Sie neu laden, und halten Sie Ihre aktuelle Sitzung offen, bis sich ein zweites Terminal erfolgreich verbunden hat. Diese Gewohnheit ist der Unterschied zwischen einem Tippfehler und einem verlorenen Server.

Default-Deny, und die Hälfte der Firewall, die niemand konfiguriert

Eine Firewall auf einem Server hat eine Aufgabe: Sie sorgt dafür, dass die Antwort auf "Was lauscht hier?" genau der Liste der Dinge entspricht, die Sie bewusst veröffentlicht haben. Eingehend gilt Default-Deny, ausgehend ist erlaubt, dann öffnen Sie Ports einzeln, jeweils mit einem Grund dafür. Bevor Sie auch nur eine Regel schreiben, führen Sie ss -tulpen aus und lesen Sie, was bereits gebunden ist — eine Standardinstallation lauscht auf mehr, als die meisten erwarten, und eine Datenbank oder ein Cache, der an 0.0.0.0 statt an 127.0.0.1 bindet, ist der klassische Weg, wie ein kleiner Server in irgendjemandes Datensatz landet. Binden Sie lokale Dienste zuerst an Loopback; die Firewall ist Ihre zweite Verteidigungslinie, nicht Ihre einzige.

Dann gibt es noch die Hälfte, die übersprungen wird. Jeder Plan hier liefert einen /64-Adressblock IPv6 neben seinem IPv4, und die meisten modernen Daemons binden bereitwillig beide Familien. Wenn Ihre Regeln nur v4 abdecken, ist ein Dienst, von dem Sie glauben, er sei durch die Firewall geschützt, über v6 für jeden erreichbar, der die Adresse auflöst — und IPv6-Scanning eines bekannten Hosting-Präfixes ist völlig routinemäßig. ufw handhabt zwar beide, aber nur, wenn IPV6=yes in /etc/default/ufw gesetzt ist; prüfen Sie das mit ufw status verbose, statt es anzunehmen. Docker verdient dasselbe Misstrauen: Einen Container-Port mit -p zu veröffentlichen, fügt Regeln in seine eigene iptables-Chain ein, die vor denen von ufw ausgewertet werden, sodass ein Container, den Sie für geschützt hielten, oft weit offen steht. Binden Sie ihn explizit an 127.0.0.1:port und stellen Sie einen Reverse Proxy davor. Was auch immer Sie konfigurieren, testen Sie es von einem anderen Punkt im Internet aus — eine Regel, die nur je gelesen wurde, ist eine Regel, die nie getestet wurde.

Updates, an die Sie nicht denken müssen

Ungepatchte Software ist der Grund, warum die meisten kleinen Server tatsächlich verloren gehen, und die Ursache ist menschlich, nicht technisch: Patchen ist eine lästige Pflicht, die mit allem anderen konkurriert, was Sie zu tun haben. Automatisieren Sie den Sicherheitskanal, und das Problem verschwindet. unattended-upgrades wendet unter Debian und Ubuntu Sicherheitsupdates nach Zeitplan an und bleibt dabei unauffällig; beschränken Sie es auf den Sicherheitsbereich statt auf jedes verfügbare Upgrade, damit ein routinemäßiges Feature-Release Ihre Anwendung nie um drei Uhr morgens neu startet. Das zählt auf einer selbstverwalteten Offshore-Box mehr als auf einer verwalteten Plattform, weil niemand sie für Sie patcht und kein Account-Manager Ihnen wegen einer kritischen CVE eine E-Mail schickt — es gibt keine hinterlegte E-Mail-Adresse, die er erreichen könnte.

Kernel-Updates brauchen einen Neustart, um zu greifen, entscheiden Sie Ihre Neustart-Richtlinie also bewusst, statt sie erst hinterher zu entdecken. needrestart sagt Ihnen, welche Dienste noch gegen gelöschte Bibliotheken laufen, und ein Unattended-Upgrade::Automatic-Reboot-Fenster in den frühen Morgenstunden ist für einen zustandslosen Dienst völlig in Ordnung. Eine wichtige Wechselwirkung: Wenn Sie unserem Guide zur Festplattenverschlüsselung gefolgt sind und Ihr Root-Dateisystem verschlüsselt ist, bleibt ein automatischer Neustart an einem Passphrase-Prompt hängen und wartet dort, bis Sie ihn über das Netzwerk entsperren. Lassen Sie auf solchen Maschinen entweder automatische Neustarts aus, oder stellen Sie sicher, dass Remote-Unlock getestet ist und Sie für das Zeitfenster wach sind. Wofür Sie sich auch entscheiden, schreiben Sie es auf — eine Richtlinie, die nur in Ihrem Kopf existiert, hört in dem Moment auf zu existieren, in dem Sie im Urlaub sind.

Rate Limiting, fail2ban und das Grundrauschen

Sobald die Passwort-Authentifizierung aus ist, kann Brute-Force gegen SSH nicht mehr gelingen. Es lohnt sich, klar zu benennen, was Werkzeuge wie fail2ban ab diesem Punkt noch bringen: keine Verteidigung gegen Erraten — das ist bereits unmöglich —, sondern ein ruhigeres Log, weniger CPU-Last durch zum Scheitern verurteilte Handshakes, und eine echte Kontrolle auf den Schichten, wo Geheimnisse noch tatsächlich erraten werden können. Richten Sie es auf die Stellen, die zählen: das Login-Formular einer Webanwendung, das SMTP-AUTH eines Mailservers, einen Admin-Pfad, den jemand durchprobiert. ufw limit gibt Ihnen eine günstige Begrenzung der Verbindungsrate ganz ohne zusätzliche Software. Eine Handvoll Kernel-Stellschrauben sind dieselben fünf Minuten wert — SYN-Cookies an, Reverse-Path-Filtering an, ICMP-Broadcast-Antworten aus, und IPv6-Router-Advertisements ignoriert auf einem Server mit statischer Adresse.

Wissen Sie aber, wo der Host aufhört. Nichts davon übersteht einen volumetrischen Angriff, denn eine Flut füllt die Netzwerkleitung lange bevor sie die CPU belastet: Bis Pakete Ihre nftables-Regeln erreichen, haben sie die Bandbreite, die Sie eigentlich schützen wollten, bereits verbraucht. Deshalb ist der gesamten Flotte ein L3/L4-Scrubbing von bis zu 1.5 Tbps vorgelagert, das bei jedem Plan inklusive ist statt als Extra verkauft zu werden, dazu ein optionales L7-Schutzschild für Floods auf Anwendungsebene, die wie legitime Anfragen aussehen. Ihre Host-Firewall übernimmt die Präzision; das Netzwerk übernimmt das Volumen. Das eine als Ersatz für das andere zu behandeln ist, wie Leute am Ende überrascht werden.

Sich selbst auszusperren ist hier das eigentliche Risiko

Von allem, was in dieser ersten Stunde schiefgehen kann, ist das mit Abstand wahrscheinlichste Ergebnis kein Einbruch. Es sind Sie selbst — am Ende einer langen Sitzung, beim Neuladen einer kaputten sshd_config oder beim Aktivieren einer Firewall, deren Allow-Regel einen Tippfehler enthält —, die feststellen, dass sich die Tür hinter Ihnen geschlossen hat. Bei einem gängigen Anbieter ist das ärgerlich. Hier verdient es echten Respekt, denn die Registrierung besteht aus einem Benutzernamen und einem Passwort mit acht Wiederherstellungscodes, ganz ohne E-Mail irgendwo im Ablauf — genau damit es keine Identität gibt, die durchsickern könnte. Und ein Anbieter, der Sie nicht identifizieren kann, kann Sie auch nicht zurück in Ihren Server identifizieren. Niemand kann für Sie bürgen. Diese Eigenschaft ist das Produkt, das wie vorgesehen funktioniert, und deshalb sind die Schutzmaßnahmen unten Gewohnheiten und keine bloßen Vorschläge.

Vier davon kosten nichts. Machen Sie einen Snapshot, bevor Sie SSH oder die Firewall anfassen, damit ein missglücktes Neuladen ein Rollback ist und kein Neuaufbau. Hinterlegen Sie einen zweiten Public Key von einem anderen Gerät — einem Handy, einem Arbeitslaptop, einem Offline-Backup —, denn ein Schlüssel auf einer Festplatte ist nur einen verschütteten Kaffee davon entfernt, überhaupt kein Schlüssel mehr zu sein. Halten Sie ein zweites Terminal verbunden, während Sie etwas ändern, das das erste kappen könnte, und testen Sie die neue Konfiguration immer über eine frische Verbindung, bevor Sie die alte loslassen. Und akzeptieren Sie, wo die Leiter der Wiederherstellung endet: Snapshots liegen auf demselben Host und sind eine Rollback-Annehmlichkeit, kein Backup, also gehört alles, was Ihnen wirklich fehlen würde, in einen Speicher außerhalb der Maschine — das Add-on für tägliche verschlüsselte Backups, oder Ihre eigenen clientseitig verschlüsselten Kopien, die Sie woandershin schieben. Ihr schlimmster Fall sollte Neuausrollen und Wiederherstellen sein, gemessen in Minuten, statt weg.

Was als Nächstes dazukommt, je nachdem, was die Box tut

Die Checkliste oben ist der Boden, und der ist für jede Maschine gleich. Was obendrauf kommt, hängt vollständig von der Aufgabe ab. Ein öffentlicher Webserver will TLS, einen Reverse Proxy, der es terminiert, die Anwendung als unprivilegierten Benutzer, und die Datenbank auf Loopback oder komplett auf einer anderen Box. Ein VPN-Endpunkt hat eine andere Form — ein UDP-Port, kein Webstack, überhaupt keine öffentlichen Dienste —, das komplette Vorgehen dazu steht in ein eigenes WireGuard-VPN aufsetzen. Ein Mailserver ist der anspruchsvollste der drei und braucht rDNS-Kontrolle über die Adresse, was jeder Plan mitbringt; Mail selbst hosten auf einem Offshore-VPS deckt die Zustellbarkeits-Hälfte ab. Ein Tor-Relay ist bewusst das Gegenteil von anonym — es ist ein veröffentlichter, kontaktierbarer Dienst —, und die Kompromisse sind dargelegt in ein Relay auf einem no-KYC-VPS betreiben. Alles, was privaten Zustand im Ruhezustand hält, sollte außerdem verschlüsselt werden, was eine eigene Kontrolle mit eigenen Fehlermodi ist, behandelt in LUKS und Remote-Unlock.

Es lohnt sich, damit zu enden, wo Härtung im größeren Bild steht, denn sie ist nur eine von drei Schichten, und die versagen unabhängig voneinander. Was der Host über Sie weiß, ist die erste, und hier ist es fast nichts: ein Benutzername, finanziert durch ein vorausbezahltes Krypto-Guthaben ab $30.00, keine Karte und kein Dokument in der Kette — das Thema von Hosting anonym bezahlen. Welches Recht gilt, ist die zweite, entschieden davon, wo die Hardware in unseren 6 Regionen steht, statt davon, wo Sie sitzen, und Region für Region ausgearbeitet in welchen Offshore-Standort sollten Sie wählen?. Was die Maschine selbst erlaubt, ist die dritte, und die liegt allein bei Ihnen — kein Anbieter kann sie für Sie konfigurieren. Ein VPS ab $8.00/Monat ist online in etwa 15 min, was bedeutet, dass in der folgenden Stunde die tatsächliche Sicherheit der Sache entschieden wird. Verbringen Sie sie bewusst.

Schritt für Schritt

1. 01

   Deployen, dann zuerst einloggen

   Deployen Sie über das Panel und wählen Sie eine Distribution, die Sie auch tatsächlich patchen werden — ein aktuelles Debian oder ein Ubuntu LTS ist die langweilige, richtige Antwort. Ein VPS ist online in etwa 15 min, und die Root-Zugangsdaten landen in Ihrem Panel. Verbinden Sie sich sofort, bringen Sie das System vollständig auf den neuesten Stand, und setzen Sie einen Hostnamen, damit spätere Logs lesbar sind. Auf dieser Box passiert nichts weiter, bis der Rest dieser Schritte erledigt ist.

   ssh root@203.0.113.10
   apt update && apt full-upgrade -y
   hostnamectl set-hostname edge-01
   apt install -y ufw unattended-upgrades needrestart

2. 02

   Weg von root: ein benanntes Konto, ein Schlüssel und sudo

   Erzeugen Sie das Schlüsselpaar auf Ihrem Laptop, niemals auf dem Server. Legen Sie dann ein benanntes Konto auf der Box an, packen Sie die öffentliche Hälfte in dessen authorized_keys, und geben Sie ihm sudo. Öffnen Sie ein zweites Terminal und loggen Sie sich sofort als dieser Benutzer ein — bevor Sie irgendetwas anderes ändern, solange root über SSH noch als Fallback funktioniert.

   # on your own machine
   ssh-keygen -t ed25519 -C "laptop"
   ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.10
   
   # on the server
   adduser --disabled-password --gecos "" ops
   usermod -aG sudo ops
   install -d -m 700 -o ops -g ops /home/ops/.ssh
   cp /root/.ssh/authorized_keys /home/ops/.ssh/
   chown ops:ops /home/ops/.ssh/authorized_keys
   chmod 600 /home/ops/.ssh/authorized_keys

3. 03

   SSH-Daemon abriegeln — bei offenem zweiten Terminal

   Schreiben Sie die Änderungen in eine Drop-in-Datei, statt die mitgelieferte Konfiguration zu bearbeiten, damit ein Distributions-Upgrade sie nie stillschweigend zurücksetzt. Validieren Sie die Syntax mit sshd -t, bevor Sie neu laden, laden Sie neu, und weisen Sie es dann über eine brandneue Verbindung nach, während die aktuelle noch lebt. Schlägt die neue Verbindung fehl, haben Sie immer noch eine funktionierende Sitzung, in der Sie es rückgängig machen können. Eine Distributionsfalle: Unter Ubuntu 24.04 ist der Daemon socket-aktiviert, sodass Port in sshd_config ignoriert wird — setzen Sie den Port stattdessen mit systemctl edit ssh.socket, oder deaktivieren Sie die Socket-Unit.

   cat > /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
   Port 2222
   PermitRootLogin prohibit-password
   PasswordAuthentication no
   KbdInteractiveAuthentication no
   AllowUsers ops
   X11Forwarding no
   MaxAuthTries 3
   LoginGraceTime 20
   EOF
   sshd -t && systemctl reload ssh
   # new terminal, do not close the old one:
   ssh -p 2222 ops@203.0.113.10

4. 04

   Firewall auf Default-Deny stellen, für beide IP-Familien

   Bestätigen Sie, dass IPv6 in ufw aktiviert ist, verweigern Sie dann alles Eingehende, und öffnen Sie nur die Ports, die Sie bewusst bedienen — einschließlich des neuen SSH-Ports, der erlaubt sein muss, bevor Sie die Firewall aktivieren. Prüfen Sie dabei gleich, was tatsächlich lauscht, und verschieben Sie alles, was lokal sein sollte, auf Loopback.

   grep IPV6 /etc/default/ufw          # must read IPV6=yes
   ufw default deny incoming
   ufw default allow outgoing
   ufw limit 2222/tcp
   ufw allow 80,443/tcp
   ufw enable
   ufw status verbose
   ss -tulpen                           # anything on 0.0.0.0 or :: ?

5. 05

   Unbeaufsichtigte Sicherheitsupdates einschalten

   Aktivieren Sie nur den Sicherheitskanal, damit Patches landen, ohne dass ein Feature-Upgrade Ihre Anwendung unangekündigt neu startet. Entscheiden Sie die Neustart-Richtlinie explizit — und lassen Sie automatische Neustarts aus, wenn das Root-Dateisystem verschlüsselt ist und ein manuelles Entsperren braucht.

   dpkg-reconfigure -plow unattended-upgrades
   cat > /etc/apt/apt.conf.d/51-local <<'EOF'
   Unattended-Upgrade::Automatic-Reboot "false";
   Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
   EOF
   unattended-upgrade --dry-run --debug | tail -20

6. 06

   Rauschen reduzieren und an den Kernel-Stellschrauben drehen

   Fügen Sie fail2ban für die Schichten hinzu, wo ein Geheimnis noch erraten werden kann, und setzen Sie die Handvoll sysctl-Werte, die auf einem öffentlichen Server mit statischer Adresse einfach richtig sind. Das kostet wenig und macht die Logs lesenswert.

   apt install -y fail2ban
   cat > /etc/sysctl.d/99-harden.conf <<'EOF'
   net.ipv4.tcp_syncookies = 1
   net.ipv4.conf.all.rp_filter = 1
   net.ipv4.icmp_echo_ignore_broadcasts = 1
   net.ipv4.conf.all.accept_redirects = 0
   net.ipv6.conf.all.accept_ra = 0
   kernel.kptr_restrict = 2
   EOF
   sysctl --system

7. 07

   Von außen verifizieren, dann das Runbook schreiben

   Vertrauen Sie der Sicht vom Internet aus, nicht der Sicht von innerhalb der Box. Bestätigen Sie, dass der alte SSH-Port verschwunden ist, dass nichts Unerwartetes antwortet, und dass Login ausschließlich per Schlüssel wirklich durchgesetzt wird. Schreiben Sie dann die drei Fakten auf, die Sie an Ihrem schlimmsten Tag brauchen werden: wo Ihr zweiter Schlüssel liegt, welchen Snapshot Sie genommen haben, und wo das Backup außerhalb der Maschine liegt.

   # from another machine
   ssh -p 22 ops@203.0.113.10          # must time out or be refused
   ssh -p 2222 -o PreferredAuthentications=password ops@203.0.113.10
   # expected: Permission denied (publickey)
   ssh -p 2222 ops@203.0.113.10 'sudo ufw status verbose; uptime'