# Einen neuen VPS härten
> Das Härten eines neuen VPS dauert etwa zwanzig Minuten: Deaktivieren Sie Passwort- und Root-SSH-Login, aktivieren Sie schlüsselbasierte Authentifizierung, konfigurieren Sie nftables auf Standard-Deny eingehend, aktivieren Sie unbeaufsichtigte Sicherheitsupdates und installieren Sie fail2ban. Diese fünf Schritte eliminieren die überwältigende Mehrheit realer Kompromittierungen.
**Source:** https://incognitovps.com/de/guides/harden-a-new-vps
**Updated:** 2026-07-17

## Was Server tatsächlich kompromittiert

Nicht Zero-Days. In der Praxis: SSH-Passwort-Brute-Force gegen schwache Anmeldedaten, ungepatchte Dienste, die monatelang laufen, exponierte Admin-Panels mit Standard-Passwörtern und Anwendungsschwachstellen in dem, was der Betreiber installiert hat. Die Liste ist langweilig und hat sich in fünfzehn Jahren nicht geändert.

Die folgende Checkliste ist nach dem Risiko geordnet, das jeder Schritt pro aufgewendeter Minute entfernt. Machen Sie sie in der Reihenfolge und hören Sie auf, wenn Ihnen die Geduld ausgeht – Sie haben trotzdem den größten Teil des Risikos entfernt.

## Schritt 1 – Nur SSH-Schlüssel

Diese einzelne Änderung beseitigt den häufigsten Angriffsvektor vollständig. Erzeugen Sie einen Ed25519-Schlüssel, kopieren Sie den öffentlichen Teil auf den Server und bearbeiten Sie dann `/etc/ssh/sshd_config`. Setzen Sie dabei `PasswordAuthentication no`, `PermitRootLogin prohibit-password` und `KbdInteractiveAuthentication no`.

Testen Sie den Schlüssel in einem zweiten Terminal, bevor Sie das erste schließen. Ein Aussperren ist peinlich und auf einem Rechner mit Konsolenzugriff jederzeit behebbar – aber tun Sie es trotzdem in der richtigen Reihenfolge.

## Schritt 2 – Firewall mit Standard-Deny

Verwenden Sie nftables auf modernem Debian und Ubuntu oder firewalld auf RHEL-Derivaten. Standardmäßig eingehend verweigern, etablierte und verwandte Verbindungen erlauben, Ihren SSH-Port erlauben, was auch immer die Workload benötigt, und sonst nichts.

Die wichtige Disziplin ist, dass „sonst nichts“ der Kern der Sache ist. Eine Firewall, bei der während des Debuggens eine freizügige Regel hinzugefügt und nie entfernt wurde, ist eine Firewall, die nichts tut.

- Standardrichtlinie: Eingehend verwerfen, ausgehend akzeptieren
- Etablierte und verwandte Verbindungen akzeptieren
- Loopback akzeptieren
- SSH-Port akzeptieren, idealerweise ratenbegrenzt
- Workload-Ports explizit auflisten und akzeptieren
- ICMP-Echo akzeptieren – Path-MTU-Discovery nicht brechen

## Schritt 3 – Automatische Sicherheitsupdates

Verwenden Sie `unattended-upgrades` auf Debian und Ubuntu, `dnf-automatic` auf RHEL-Derivaten, konfiguriert nur für Sicherheitsupdates. Die meisten Kompromittierungen nutzen Schwachstellen aus, die Monate zuvor gepatcht wurden.

Aktivieren Sie den automatischen Neustart in einem Wartungsfenster, wenn Ihre Workload es toleriert. Kernel-Updates wirken erst nach einem Neustart, und ein Server mit 400 Tagen Uptime und elf ausstehenden Kernel-CVEs ist kein Ehrenabzeichen.

## Schritt 4 – fail2ban und eine Anmerkung zu seinem wahren Wert

Wenn die Passwort-Authentifizierung bereits deaktiviert ist, verhindert fail2ban relativ wenige tatsächliche Kompromittierungen. Was es bewirkt, ist eine drastische Reduzierung des Log-Rauschens. Das ist wichtig, denn ein Log mit Tausenden fehlgeschlagener Versuche ist ein Log, das niemand liest, und ungelesene Logs sind der Grund, warum echte Einbrüche wochenlang unbemerkt bleiben.

Das Standard-sshd-Jail reicht aus. Fügen Sie Jails für alles hinzu, was Sie sonst noch dem Internet aussetzen.

## Schritt 5 – Angriffsfläche reduzieren

Führen Sie `ss -tlnp` aus und prüfen Sie, was lauscht. Bei einer Standardinstallation sind das oft Dienste, von denen Sie nicht wussten, dass sie laufen und die Sie nicht benötigen. Entfernen Sie sie, anstatt sie per Firewall zu blockieren – Software, die nicht installiert ist, hat keine Schwachstellen.

Binden Sie Dienste, die nur lokalen Zugriff benötigen, an 127.0.0.1 statt an 0.0.0.0. Eine Datenbank, die auf allen Schnittstellen hinter einer Firewall lauscht, ist eine Fehlkonfiguration davon entfernt, öffentlich zu sein.

## Was Sie weglassen können

Das Ändern des SSH-Ports reduziert Log-Rauschen und stoppt genau null gezielte Angriffe. Tun Sie es, wenn Sie möchten, aber zählen Sie es nicht als Sicherheit. Port Knocking fügt Fragilität für einen marginalen Gewinn hinzu. Intrusion-Detection-Systeme erzeugen Alarme, die auf einem einzelnen Server niemand triagiert.

Wenn Sie einen weiteren sinnvollen Schritt über die fünf oben genannten hinaus möchten, dann sind es verschlüsselte Offsite-Backups in einer anderen Jurisdiktion, die durch tatsächliches Wiederherstellen getestet werden. Wiederherstellungsfähigkeit ist mehr wert als eine weitere Präventionsebene.


## Häufig gestellte Fragen

### Lohnt es sich, den SSH-Port zu ändern?

Für Log-Rauschen ja, für Sicherheit nein – es stoppt opportunistische Scanner und null gezielte Angriffe. Tun Sie es, wenn Sie die ruhigeren Logs mögen, aber zählen Sie es nicht als Kontrolle.

### Brauche ich fail2ban, wenn ich SSH-Schlüssel verwende?

Für direkte Sicherheit kaum. Für Log-Hygiene ja – Tausende fehlgeschlagener Versuche machen Logs unlesbar, und unlesbare Logs sind der Grund, warum echte Einbrüche unbemerkt bleiben.

### Sollte ich automatische Neustarts aktivieren?

Wenn die Workload es toleriert, ja, in einem Wartungsfenster. Kernel-Patches wirken erst nach einem Neustart. Lange Uptime mit ausstehenden Kernel-CVEs ist eine Haftung, keine Leistung.


---

Incognito VPS — Offshore-VPS, Bare-Metal- und GPU-Server an 16 Standorten, 8 davon wegen ihrer rechtlichen Eigenschaften gewählt. Keine Identität erforderlich, nur Krypto-Zahlung, Bereitstellung in 55 Sekunden.
Operating since 2020. 16 locations, 8 of them privacy jurisdictions. AS204287.
Payment: BTC, XMR, ETH, USDT, USDC, LTC, TRX, SOL, BNB, DOGE, TON, DAI. No identity verification at any point.
Catalogue: https://incognitovps.com/pricing.md · API: https://incognitovps.com/openapi.json · Index: https://incognitovps.com/llms.txt