So konfigurieren Sie VPS-Firewall-Regeln sicher
Veröffentlicht am 4. September 2026
Eine Firewall sollte den Datenverkehr zulassen, den Ihr Server benötigt, und den Rest stillschweigend ablehnen. Um VPS-Firewall-Regeln sicher zu konfigurieren, beginnen Sie mit den Diensten, die erreichbar bleiben müssen, insbesondere SSH, und fügen Sie dann Web- und Anwendungsports nacheinander hinzu. Beginnen Sie nicht damit, von der einzigen geöffneten Terminalsitzung aus alles zu blockieren. So wird aus einer ruhigen Wartungsaufgabe eine Aufgabe zur Wiederherstellung über die Konsole.
Für die meisten Linux-VPS-Bereitstellungen ist das praktische Ziel einfach: unaufgeforderten eingehenden Datenverkehr standardmäßig verweigern, erforderlichen ausgehenden Datenverkehr zulassen und eng gefasste eingehende Regeln für vertrauenswürdige Benutzer und Dienste erstellen. Das verringert die Angriffsfläche, ohne die Routineverwaltung zu erschweren.
Beginnen Sie mit der Verkehrskarte
Bevor Sie eine Regel ändern, notieren Sie, was der VPS tatsächlich tut. Eine öffentliche WordPress-Website benötigt zum Beispiel in der Regel SSH für die Verwaltung sowie die Ports 80 und 443 für den Webverkehr. Eine private API benötigt möglicherweise nur HTTPS, während ein Datenbankserver Verbindungen in der Regel nur von einem Anwendungsserver in einem privaten Netzwerk akzeptieren sollte.
Prüfen Sie zuerst die lauschenden Dienste. Auf den meisten Linux-Distributionen liefert dieser Befehl eine nützliche Übersicht:
```bash sudo ss -tulpn ```
Öffnen Sie nicht automatisch jeden angezeigten Port. Einige Dienste lauschen nur auf localhost oder einer privaten Schnittstelle und benötigen keinen öffentlichen Firewall-Zugriff. Andere können alte Testdienste, Monitoring-Agenten oder Software sein, die vom Internet aus überhaupt nicht erreichbar sein sollte.
Beantworten Sie für jeden öffentlich erreichbaren Port drei Fragen: Wer benötigt ihn, von wo und über welches Protokoll? Eine Regel, die HTTPS von überall zulässt, ist für eine öffentliche Website normal. Eine Regel, die einen Datenbankport von überall zulässt, ist normalerweise ein Problem, das höflich in den Logs wartet.
Halten Sie einen Wiederherstellungspfad bereit, bevor Sie VPS-Firewall-Regeln konfigurieren
Halten Sie zwei aktive SSH-Sitzungen aufrecht, während Sie Firewall-Änderungen vornehmen. Verwenden Sie eine Sitzung zum Anwenden von Regeln und lassen Sie die zweite unangetastet. Testen Sie nach dem Anwenden einer Änderung eine neue Verbindung von einem anderen Terminal aus, bevor Sie irgendetwas schließen. So werden Fehler im tatsächlichen Verbindungspfad erkannt, statt sich auf Optimismus zu verlassen.
Bestätigen Sie außerdem, dass die Konsole Ihres VPS-Anbieters verfügbar ist. Eine browserbasierte Konsole oder Rettungsumgebung ist der Rückfallweg, wenn SSH blockiert ist. Sie ist kein Ersatz für sorgfältiges Arbeiten, aber eine gute betriebliche Absicherung.
Wenn SSH auf einem nicht standardmäßigen Port läuft, prüfen Sie dies vor dem Erstellen von Regeln:
```bash sudo ss -tulpn | grep ssh ```
Ein nicht standardmäßiger SSH-Port kann die Hintergrundgeräusche automatisierter Scans verringern, ist aber für sich genommen keine sinnvolle Sicherheit. Starke Authentifizierung, eingeschränkter Quellzugriff und zeitnahes Patchen leisten die eigentliche Arbeit.
Verwenden Sie mit UFW eine standardmäßige Deny-Richtlinie für eingehenden Verkehr
UFW ist eine praktische Firewall-Schnittstelle für Ubuntu- und Debian-basierte VPS-Server. Sie ist später leicht zu lesen, was wichtig ist, wenn ein anderer Administrator um 2 Uhr morgens eine Störung beheben muss.
Legen Sie zunächst sinnvolle Standardwerte fest:
```bash sudo ufw default deny incoming sudo ufw default allow outgoing ```
Erlauben Sie als Nächstes SSH, bevor Sie die Firewall aktivieren. Wenn Ihr Server den Standard-SSH-Port verwendet, nutzen Sie:
```bash sudo ufw allow OpenSSH ```
Wenn SSH auf einem benutzerdefinierten Port lauscht, geben Sie ihn explizit an. Dieses Beispiel verwendet Port 2222:
```bash sudo ufw allow 2222/tcp ```
Erlauben Sie für eine normale öffentliche Website HTTP und HTTPS:
```bash sudo ufw allow 80/tcp sudo ufw allow 443/tcp ```
Aktivieren Sie dann die Firewall und prüfen Sie die resultierende Richtlinie:
```bash sudo ufw enable sudo ufw status numbered ```
Der nummerierte Status ist nützlich, weil Regeln später gezielt entfernt werden können. Vermeiden Sie es, nach der Fehlerbehebung vorübergehende, weit gefasste Regeln zurückzulassen. Temporäre Regeln haben die lustige Angewohnheit, zu dauerhafter Einrichtung zu werden.
Wenn der VPS eine Webanwendung hinter einem Reverse Proxy hostet, muss der Anwendungsport möglicherweise nicht öffentlich sein. Zum Beispiel kann Nginx Datenverkehr auf den Ports 80 und 443 annehmen, während die Anwendung auf `127.0.0.1:3000` lauscht. In diesem Design ist keine Firewall-Regel für Port 3000 erforderlich.
Administrativen Zugriff nach Quell-IP einschränken
SSH sollte nicht für jede Adresse offen sein, es sei denn, Ihr Team benötigt diese Flexibilität wirklich. Wenn Ihr Büro, VPN oder Jump-Host eine stabile öffentliche IP-Adresse hat, beschränken Sie SSH darauf:
```bash sudo ufw allow from 203.0.113.25 to any port 22 proto tcp ```
Für ein verteiltes Team mit wechselnden Heim-IP-Adressen ist ein VPN oder Bastion-Host oft die bessere Antwort, als SSH global zu öffnen. Das bedeutet etwas mehr Einrichtungsaufwand, gibt Ihnen aber einen kontrollierten Verwaltungspfad und einen saubereren Audit-Trail.
Ratenbegrenzung kann auch grundlegende SSH-Versuche zur Passwortvermutung verringern:
```bash sudo ufw limit 22/tcp ```
Dies ist kein Ersatz für SSH-Schlüssel, deaktivierte Passwortauthentifizierung, wo angemessen, oder Multi-Faktor-Zugriff über Ihren Verwaltungspfad. Betrachten Sie es als ein Zaunfeld, nicht als den ganzen Zaun.
Behandeln Sie Datenbanken, Panels und Monitoring getrennt
Datenbankports wie MySQL auf 3306, PostgreSQL auf 5432, Redis auf 6379 und MongoDB auf 27017 sollten fast nie öffentlich verfügbar sein. Erlauben Sie sie nur von der privaten IP-Adresse oder dem Subnetz des Anwendungsservers aus.
Zum Beispiel, um MySQL-Verbindungen nur von einem Anwendungs-VPS unter `10.10.0.12` zuzulassen:
```bash sudo ufw allow from 10.10.0.12 to any port 3306 proto tcp ```
Der Datenbankdienst selbst sollte nach Möglichkeit auch an die vorgesehene private Schnittstelle gebunden werden. Firewall-Regeln und Dienstbindung sind getrennte Ebenen. Wenn Sie beides verwenden, ist es weniger wahrscheinlich, dass eine versehentliche Firewall-Änderung den Dienst offenlegt.
Hosting-Panels, Grafana-Dashboards und Monitoring-Endpunkte verdienen dieselbe Aufmerksamkeit. Wenn sie nur für Mitarbeiter bestimmt sind, beschränken Sie sie auf ein VPN, einen Büro-IP-Bereich oder ein dediziertes Verwaltungsnetzwerk. Öffentliche Monitoring-Seiten können mehr Infrastrukturdetails preisgeben als erwartet, selbst wenn sie keine Geheimnisse anzeigen.
Berücksichtigen Sie die Provider-Firewall und IPv6
Ihr VPS kann mehr als eine Firewall-Ebene haben. Eine Cloud- oder Provider-Firewall filtert den Datenverkehr, bevor er den Server erreicht, während UFW, firewalld, nftables oder iptables den Datenverkehr auf dem VPS selbst filtern. Die Verwendung beider ist sinnvoll, aber die Regeln müssen übereinstimmen.
Wenn Port 443 auf dem VPS offen ist, aber auf Provider-Ebene blockiert wird, können Besucher weiterhin keine Verbindung herstellen. Wenn der Provider einen Port zulässt, der VPS ihn aber verweigert, bleibt der VPS geschützt. Prüfen Sie bei der Fehlerbehebung beide Ebenen der Reihe nach: Provider-Richtlinie, VPS-Firewall, Dienst-Lauschadresse und Anwendungskonfiguration. Die Logs erzählen in der Regel dieselbe Geschichte, sobald diese Punkte geprüft wurden.
Vergessen Sie IPv6 nicht. Wenn Ihr VPS eine öffentliche IPv6-Adresse hat, sind gleichwertige IPv6-Regeln erforderlich. UFW kann IPv6 verwalten, wenn es in seiner Konfiguration aktiviert ist, aber prüfen Sie mit:
```bash sudo ufw status verbose ```
Eine korrekt abgesicherte IPv4-Adresse hilft nicht, wenn derselbe Dienst über IPv6 sperrangelweit offen ist.
Von außen testen und dann das Ergebnis überwachen
Testen Sie nach jeder wesentlichen Änderung von einem Netzwerk außerhalb des VPS. Bestätigen Sie, dass die vorgesehenen Dienste funktionieren, und bestätigen Sie dann, dass Ports, die privat bleiben sollen, nicht erreichbar sind. Browser-Tests sind für Websites nützlich, aber Befehlszeilentests liefern klarere Antworten für bestimmte Ports:
```bash nc -vz your-server-ip 443 ```
Bei blockierten Ports kann ein Timeout oder eine Verweigerung je nach Regel und Dienststatus unterschiedliche Dinge bedeuten. Prüfen Sie den Firewall-Status, den Dienststatus und die System-Logs, anstatt mehrere Einstellungen gleichzeitig zu ändern.
Aktivieren Sie die Protokollierung bei der Problemdiagnose mit Bedacht:
```bash sudo ufw logging low ```
Eine niedrige Protokollierungsstufe reicht in der Regel aus, um unerwartet verweigerten Datenverkehr zu erkennen, ohne unnötige Festplattenaktivität zu erzeugen. Auf stark ausgelasteten Servern können Firewall-Logs mit hohem Volumen zu einem eigenen kleinen Betriebsärgernis werden.
Prüfen Sie Firewall-Regeln immer dann, wenn Sie einen neuen Dienst bereitstellen, eine alte Anwendung außer Betrieb nehmen, Büro-IP-Adressen ändern oder die Netzwerkarchitektur anpassen. Die besten Regeln sind nicht die längste Regelsammlung. Sie sind die kleinste Menge, die genau beschreibt, wie der Server kommunizieren soll.
Wenn Sie diese Arbeit lieber nicht allein tragen möchten, kann ein Managed-VPS-Team Zugriffsanforderungen prüfen, Änderungen mit einem Wiederherstellungsplan anwenden und den Server anschließend überwachen. Bei kodu.cloud passt dies ganz natürlich zu Managed Operations und laufendem Monitoring, insbesondere für Teams, die sich lieber auf Kunden und Produkt als auf Paketfilterung konzentrieren müssen.
Eine Firewall macht ihre Arbeit, wenn sie niemand bemerkt. Halten Sie die Richtlinie eng gefasst, dokumentieren Sie, warum jede Ausnahme besteht, und testen Sie den Zugriff, bevor Sie den Dienst wieder für ruhig erklärt.
Andres Saar Customer Care Engineer