Ein frischer VPS ist innerhalb von Minuten nach der Inbetriebnahme automatisierten Angriffen ausgesetzt — diese Checkliste führt Sie durch die erste Stunde der Härtung, die dafür sorgt, dass er Ihnen gehört.
Jeder neue Server startet mit denselben Schwachstellen: einem Standard-Root-Login, einer nur passwortgeschützten SSH-Tür, einer weit offenen Firewall und ohne automatisches Patchen. Bots scannen kontinuierlich den gesamten IPv4-Adressraum, daher stimmt „noch kennt niemand meine IP“ nie.
Dieser Leitfaden ist eine geordnete, direkt einsetzbare Checkliste zur Härtung. Arbeiten Sie sie auf einer frischen Debian- oder Ubuntu-Maschine von oben nach unten ab, und Sie schließen genau die Lücken, die Angreifer tatsächlich ausnutzen — nicht die, um die sich Sicherheitstheater sorgt.
Bevor Sie den Server anfassen
Zwei Entscheidungen, die Sie vor Ihrem ersten Login treffen, sparen später Stunden. Bereiten Sie Ihren SSH-Schlüssel vor und wählen Sie einen Benutzernamen ohne Root-Rechte.
- 1
Einen modernen SSH-Schlüssel generieren
Führen Sie auf Ihrem eigenen Rechner ssh-keygen -t ed25519 -C "you@device" aus. Ed25519-Schlüssel sind kurz, schnell und stärker als der alte RSA-2048-Standard.
- 2
Den privaten Schlüssel vom Server fernhalten
Die private Hälfte verlässt niemals Ihren Laptop. Sie kopieren immer nur die .pub-Datei auf die Hosts. Wer sich nicht an diese Regel hält, sperrt sich selbst aus und muss den Server neu aufsetzen.
- 3
Ihre Provisioning-Zugangsdaten notieren
Die meisten Anbieter senden per E-Mail ein temporäres Root-Passwort oder hinterlegen Ihren Schlüssel bereits beim Erstellen des Servers. Wurde ein Schlüssel hinterlegt, können Sie direkt mit dem Anlegen eines Benutzers fortfahren.
Wenn Ihr Anbieter Ihren SSH-Schlüssel bereits beim Deployment hinterlegt, gibt es überhaupt kein passwortbasiertes Zeitfenster — die mit Abstand größte Angriffsfläche ist schon vor dem ersten Boot verschwunden.
Schritt 1 — Alles patchen und danach aktuell halten
Ein ungepatchter Kernel oder OpenSSL ist die eine Schwachstelle, die keine Firewall-Regel behebt. Aktualisieren Sie das System, bevor Sie irgendetwas anderes konfigurieren.
- Debian/Ubuntu: apt update && apt full-upgrade -y, danach neu starten, falls sich der Kernel geändert hat.
- Aktivieren Sie unattended-upgrades, damit Sicherheitspatches automatisch eingespielt werden: apt install unattended-upgrades && dpkg-reconfigure unattended-upgrades.
- Starten Sie nach einem selbst festgelegten Zeitplan neu — setzen Sie Unattended-Upgrade::Automatic-Reboot auf eine ruhige Stunde, statt Kernel-Updates nur halb angewendet zu lassen.
Schritt 2 — Einen echten Benutzer anlegen und Root aus dem Verkehr ziehen
Sich als Root anzumelden bedeutet, dass eine einzige kompromittierte Sitzung die gesamte Maschine übernimmt und keine Audit-Spur hinterlässt. Legen Sie sich stattdessen ein benanntes sudo-Konto an.
- 1
Den Benutzer anlegen
adduser deploy, anschließend usermod -aG sudo deploy (auf RHEL-basierten Systemen wheel verwenden).
- 2
Ihren Schlüssel für diesen Benutzer installieren
Von Ihrem Laptop aus: ssh-copy-id deploy@your-server-ip. Dadurch wird Ihr öffentlicher Schlüssel mit den korrekten Berechtigungen in ~/.ssh/authorized_keys geschrieben.
- 3
Testen, bevor Sie die Tür verschließen
Öffnen Sie ein zweites Terminal und bestätigen Sie, dass Sie sich per ssh deploy@server anmelden und sudo -v ausführen können. Deaktivieren Sie Root oder Passwörter niemals, bevor eine frische Sitzung funktioniert.
Goldene Regel der SSH-Härtung: Lassen Sie Ihre aktuelle Sitzung geöffnet und weisen Sie in einem zweiten Fenster nach, dass der neue Login funktioniert, bevor Sie irgendeine Auth-Einstellung ändern. Allein diese Gewohnheit verhindert fast jede Aussperrung.
Schritt 3 — SSH-Härtung, der wichtigste Teil
SSH ist die Eingangstür jedes VPS, und dort schlagen die meisten automatisierten Login-Versuche auf. Bearbeiten Sie /etc/ssh/sshd_config (oder eine Drop-in-Datei in /etc/ssh/sshd_config.d/) und setzen Sie diese Schlüssel.
Wenden Sie die Änderungen an, indem Sie mit sshd -t die Syntax prüfen und danach systemctl restart ssh ausführen. Meldet sshd -t einen Fehler, beheben Sie ihn vor dem Neustart, sonst riskieren Sie, den Daemon lahmzulegen.
Den SSH-Port von 22 zu ändern ist optional und reduziert lediglich das Rauschen in den Logs — das ist Obskurität, keine Sicherheit. Sobald PasswordAuthentication deaktiviert ist, haben portscannende Bots nichts mehr zu erraten, also investieren Sie Ihre Energie lieber in Schlüssel statt in Port-Spielereien.
Schritt 4 — Eine Default-Deny-Firewall aktivieren
Ein gehärteter SSH-Daemon teilt sich die Maschine dennoch mit jedem anderen lauschenden Dienst. Eine Firewall macht „geschlossen, außer ich habe es geöffnet“ zum Standard.
- 1
Die Grundeinstellung festlegen
Mit ufw: ufw default deny incoming und ufw default allow outgoing.
- 2
Nur das erlauben, was Sie tatsächlich anbieten
ufw allow OpenSSH, sowie ufw allow 80,443/tcp nur, wenn diese Maschine tatsächlich Webverkehr bedient.
- 3
Aktivieren und überprüfen
ufw enable, anschließend ufw status verbose. Alles, was nicht aufgeführt ist, ist jetzt aus dem Internet nicht mehr erreichbar.
Legen Sie die SSH-Regel in der Firewall fest, bevor Sie ufw aktivieren. Wird eine Default-Deny-Firewall ohne Allow-Regel für Ihren eigenen Port aktiviert, kappt das Ihre Sitzung.
Schritt 5 — Brute-Force mit Fail2ban ausbremsen
Auch bei deaktivierten Passwörtern klopfen Bots weiter an und blähen Ihre Logs auf. Fail2ban sperrt Wiederholungstäter auf Firewall-Ebene aus.
- apt install fail2ban — der mitgelieferte sshd-Jail funktioniert sofort ohne weitere Konfiguration.
- Kopieren Sie jail.conf nach jail.local und erhöhen Sie bantime (z. B. 1h) sowie senken Sie maxretry (z. B. 3) nach Bedarf.
- Prüfen Sie mit fail2ban-client status sshd, ob es funktioniert, und sehen Sie die Anzahl gesperrter IPs.
Schritt 6 — Die Angriffsfläche reduzieren
Der sicherste Dienst ist der, der nicht läuft. Prüfen Sie, was lauscht, und entfernen Sie, was Sie nicht brauchen.
Offene Ports prüfen
ss -tulpn listet jeden lauschenden Socket und den dahinterstehenden Prozess auf. Untersuchen Sie alles, was Sie nicht bewusst gestartet haben.
Nicht benötigte Pakete entfernen
Deaktivieren oder deinstallieren Sie Dienste, die Sie nicht nutzen — eine laufende Datenbank oder ein Mail-Agent, den Sie nicht brauchen, ist ein reines Risiko.
Dienste isolieren
Binden Sie interne Dienste wie Datenbanken an 127.0.0.1, damit sie selbst dann nie exponiert sind, wenn die Firewall versagt.
Berechtigungen absichern
Stellen Sie sicher, dass ~/.ssh auf 700 und authorized_keys auf 600 gesetzt ist. Falsche Berechtigungen führen dazu, dass sshd Ihren Schlüssel stillschweigend ignoriert.
Schritt 7 — Protokollieren, überwachen und Ihre Baseline kennen
Härtung ist kein einmaliges Ereignis. Sie müssen bemerken, wenn sich etwas ändert.
- Überprüfen Sie die Auth-Aktivität mit journalctl -u ssh oder lastb für fehlgeschlagene Logins.
- Ziehen Sie auditd für eine manipulationssichere Aufzeichnung privilegierter Aktionen in Betracht.
- Bewahren Sie ein Backup von /etc und Ihren Daten außerhalb des Servers auf, damit eine kompromittierte Maschine sauber neu aufgesetzt werden kann, statt ihr im Nachhinein zu vertrauen.
Wo der Host selbst eine Rolle spielt
Software-Härtung schützt das Betriebssystem, aber der Anbieter entscheidet darüber, was darunter liegt — Netzwerkfilterung, Zahlungsspur und ob jemals eine Identität mit dem Server verknüpft wird. Bei ChainVPS enthält jeder Plan DDoS-Filterung und unlimitierte Bandbreite, und Server werden aus einem vorausbezahlten Krypto-Guthaben in 21 Coins einschließlich Monero bezahlt, ganz ohne KYC. Wenn Ihr Bedrohungsmodell vorsieht, einen Server nicht mit Ihrer Identität zu verknüpfen, sind unsere Offshore-VPS-Pläne genau dafür gemacht.
Auch der Standort gehört zur Härtung: Sechs unserer fünfzehn Regionen sind privacy-orientierte Jurisdiktionen (NL, CH, RO, IS, MD, LU). Die Kombination aus einem gehärteten Betriebssystem und einem Offshore-Dedicated-Server hält sowohl die Software- als auch die rechtliche Angriffsfläche schmal.
Die Ein-Stunden-Checkliste, kompakt
- Vollständiges System-Update + automatische Sicherheitspatches aktiviert
- Benannter sudo-Benutzer angelegt, Schlüssel installiert, Login getestet
- Root-SSH-Login und Passwort-Authentifizierung beide deaktiviert
- SSH-Konfiguration mit sshd -t validiert und neu geladen
- Default-Deny-Firewall aktiv, nur benötigte Ports offen
- Fail2ban läuft auf dem sshd-Jail
- Offene Ports geprüft, ungenutzte Dienste entfernt
- Backup außerhalb des Servers und Log-Überprüfung eingerichtet
Sollte ich den SSH-Port auf etwas anderes als 22 ändern?
Das ist optional und reduziert nur das Log-Rauschen, nicht das eigentliche Risiko. Sobald die Passwort-Authentifizierung deaktiviert ist und Schlüssel erforderlich sind, sorgt eine Portänderung für Obskurität statt für Sicherheit — priorisieren Sie zuerst die Deaktivierung von Passwörtern.
Ist es sicher, die Passwort-Authentifizierung zu deaktivieren, wenn ich nur einen Schlüssel habe?
Ja, sofern Sie den Schlüssel-Login in einer separaten Sitzung getestet haben und ein Backup des privaten Schlüssels aufbewahren. Viele Anbieter bieten zudem eine Web-Konsole oder einen Recovery-Modus, sodass Sie nie wirklich von der Hardware ausgesperrt sind.
Brauche ich noch eine Firewall, wenn SSH der einzige Dienst ist?
Ja. Eine Default-Deny-Firewall schützt Sie vor Diensten, deren Installation Sie vergessen haben, sowie vor allem, worauf ein zukünftiges Paket unbemerkt zu lauschen beginnt. Sie kostet nichts und schließt Überraschungen aus.
Wie oft sollte ich die Härtung überprüfen?
Automatische Sicherheitsupdates erledigen die tägliche Arbeit, aber überprüfen Sie lauschende Ports und Auth-Logs nach jeder größeren Softwareinstallation und mindestens einmal im Monat. Behandeln Sie eine gehärtete Baseline als etwas, das Sie überprüfen, nicht als etwas, das Sie einmal einrichten und dann vergessen.
