Scannen Sie eine neue IP-Adresse: Port 6379 Redis offen, Port 3306 MySQL antwortet. Beim VPS war Nginx korrekt konfiguriert – und standardmäßig wurde keine Firewall verweigert. Der Angreifer hat Nginx nicht gehackt; Er sprach direkt mit Redis. Dieses Szenario tritt bei jeder ungefilterten öffentlichen IP innerhalb von Minuten ein – nicht in Wochen.
Die Konfiguration der Firewall eines VPS bedeutet, zu definieren, wer das Recht hat, mit welchen Diensten zu sprechen. Installieren Sie nicht zehn Tools – fangen Sie damit an, allen eingehenden Datenverkehr bis auf den wesentlichen abzulehnen, und öffnen Sie dann nur das, was die Website wirklich atmet. Die Firewall verursacht die Schwachstelle nicht; Es macht die Abhörnachlässigkeit Ihres Netzwerks sichtbar.
Viele Teams konfigurieren Nginx, stellen die Anwendung bereit und führen dann „später die Firewall durch“. Später geschieht dies häufig nach dem ersten Scan – oder nachdem eine Redis-Kompromittierung „vorübergehend“ offen gelassen wurde.
Ports, die als Eingabe für eine klassische Website autorisiert werden sollen
| Hafen | Dienstleistungen | Hinweis |
|---|---|---|
| 22/tcp | SSH | Wenn möglich auf Admin-IP beschränken |
| 80/TCP | HTTP | ACME- und HTTPS-Umleitung |
| 443/tcp | HTTPS | Öffentliche Website |
| ICMP | ping | Optional; einige Überwachungstools verwenden es |
Alles andere ist standardmäßig geschlossen: MySQL 3306, Redis 6379, Postgres 5432, SMTP 25, Admin-Panel 8080. Interne Dienste überwachen „127.0.0.1“ oder ein privates Netzwerk – nicht „0.0.0.0“, das dem Internet ausgesetzt ist.
Bevor Sie die erste Regel schreiben, listen Sie auf, was tatsächlich zuhört:
„Bash ss -tlnp
Vergleichen Sie die Ausgabe mit dem, was Sie Ihrer Meinung nach installiert haben. Docker kann beispielsweise Ports veröffentlichen, ohne dass UFW sie basierend auf der Konfiguration filtert – siehe Fallstricke unten.
:::Hinweis
**Denken Sie daran.** Wenden Sie die Hosting-Cloud-Firewall an, **bevor** Sie versehentlich SSH bei der ersten schlecht getesteten „UFW-Aktivierung“ herunterfahren – halten Sie eine Sitzung offen.
:::
## ufw: Sichere Reihenfolge, damit Sie nicht ausgesperrt werden
Halten Sie vor der Aktivierung von ufw eine SSH-Sitzung geöffnet und testen Sie sie in einem zweiten Fenster:
„Bash
UFW-Standardeinstellung verweigert eingehende Nachrichten
UFW-Standardeinstellung: Ausgehend zulassen
ufw erlaubt 22/tcp
ufw erlaubt 80/tcp
ufw erlaubt 443/tcp
ufw aktivieren
UFW-Status ausführlich
Wenn Sie von einer festen IP aus verwalten, schränken Sie SSH ein:
„Bash ufw erlaubt von IHREM IP-BÜRO zu jedem Port 22 Proto-TCP
**IPv6**: Eine „ufwallow 443/tcp“-Regel muss Version 6 oder eine explizite Regel abdecken – das Vergessen von Version 6 führt zu einer Lücke, die den Exploit scannt. Überprüfen Sie mit „ufw status verbose“, ob die v6-Regeln übereinstimmen.
Viele Hosts – Hetzner Cloud Firewall, OVH Network Security – filtern vor dem VPS. Empfohlene Doppelschicht: restriktives Panel plus ausgerichtetes lokales UFW. Ein konkretes Beispiel für Panel-Regeln finden Sie unter [Hetzner Firewall Cloud](/de/blog/hetzner-firewall-cloud-regles/).
## Add-ons: fail2ban, SSH-Schlüssel, klassische Fehler
**fail2ban** sperrt Adressen nach wiederholten SSH-Fehlern – siehe [Sicheres SSH](/de/blog/ssh-securise/). Kein SSH-Passwort: nur Schlüssel. Die Firewall patcht keine ungepatchten Schwachstellen (CVEs); es verringert die exponierte Angriffsfläche.
Wiederkehrende Fehler:
- Erlauben Sie 3306 „vorübergehend“ für Monate;
- Docker „-p 6379:6379“, der Redis je nach Konfiguration ohne UFW-Filter veröffentlicht;
- Deaktivieren Sie ufw „zum Debuggen“ ohne Rückkehr zum Servicedatum;
- Global offenes SSH mit schwacher Passwortauthentifizierung.
Informationen zu einer Zugriffsbastion finden Sie unter [SSH-Bastion](/de/blog/ssh-bastion/) – Alternative zum direkten Offenlegen von SSH von einer beliebigen IP aus.
## Oben: Die Firewall enthüllt, was Sie normalerweise preisgeben
:::Höhepunkt
**Ohne Standardverweigerung wird jeder Dienst, der auf 0.0.0.0 lauscht, zu einem globalen Gateway – oft noch bevor Sie die Installation abgeschlossen haben.** Die Firewall verursacht die Sicherheitslücke nicht; Es macht die Abhörnachlässigkeit Ihres Netzwerks sichtbar. Wenn man mit den wesentlichen Ports beginnt, muss man prüfen, was wirklich funktioniert.
:::
Listen Sie „ss -tlnp“ auf, bevor Sie die erste Regel schreiben. Vergleichen Sie VPS mit Panel-Firewalls über das [Verzeichnis](/de/verzeichnis/) und den [Vergleich](/de/vergleich/) – einige europäische Hosts bieten eine kostenlose Cloud-Firewall an, andere berechnen diese separat.
## Entscheide dich und gehe ohne blinden Fleck voran
Innerhalb eines halben Tages können Sie sich einen neuen VPS sichern oder einen bestehenden prüfen:
1. **Inventarisieren** Sie offene Ports mit „ss -tlnp“ und scannen Sie von außen – verlassen Sie sich nicht auf Ihre Erinnerung an die Installation.
2. **Konfigurieren** Sie zuerst die restriktive Cloud-Firewall: SSH von der Büro-IP, 80 und 443 öffentlich, alles andere geschlossen.
3. **Aktivieren Sie ufw** standardmäßig als verweigern mit denselben Regeln – halten Sie während des Tests eine SSH-Sitzung offen.
4. Datenbanken **verknüpfen** und nur auf lokalem Host oder privatem Netzwerk zwischenspeichern; niemals auf 0.0.0.0 ohne Tunnel oder VPN.
5. **Paar** fail2ban und SSH-Schlüsselauthentifizierung – Firewall allein reicht nicht gegen Brute-Force-Angriffe aus.
6. **Überprüfen** Sie IPv6- und Docker-Container, die nach jeder Bereitstellung Ports ohne Filter veröffentlichen.
## Häufig gestellte Fragen
### ufw oder nftables direkt?
ufw für den schnellen Einstieg in Ubuntu oder Debian – lesbare Abstraktion. nftables oder iptables bei komplexen Regeln oder Infrastrukturskripten. Beide können nebeneinander existieren; Vermeiden Sie widersprüchliche Duplikate, die legitimen Datenverkehr blockieren.
### Sollten wir den SSH-Port 22 ändern?
Dunkelheit allein mit geringem Nutzen. Passwortlose SSH-Schlüssel plus fail2ban sind mehr wert. Benutzerdefinierter Port als Bonus zur Reduzierung des Scan-Rauschens, nicht als Ersatz für eine starke Authentifizierung.
### Cloud-Host-Firewall + lokale UFW?
Empfohlen für Tiefenverteidigung: Panel-Firewall als erste Barriere, UFW auf der Instanz. Passen Sie die Regeln an, damit Sie nicht blockiert werden – insbesondere über SSH von einer festen IP.
### MySQL im Desktop für phpMyAdmin öffnen?
Nicht live im Internet. SSH-Tunnel, VPN oder Verwaltung nur über localhost. Expose 3306 lockt Scans in wenigen Minuten an.
---
Eine effektive VPS-Firewall beginnt nicht damit, alles zuzulassen – sie fängt damit an, **alles zu verweigern** und dann nur das zu öffnen, ohne das die Site nicht funktioniert.