Was bauen wir?

Am Ende läuft UFW auf deinem Debian 13 mit der Grundregel „alles eingehende blocken", geöffnet sind nur SSH (dein Zugang) sowie HTTP/HTTPS (Port 80/443, die du später für Traefik brauchst). Ausgehende Verbindungen bleiben erlaubt. Das Wichtigste dabei: Wir gehen so vor, dass du dich nicht selbst aussperrst.

Voraussetzungen

• Ein abgesicherter Server mit sudo-Benutzer
• Du weißt, auf welchem Port dein SSH läuft (Standard: 22)

Schritt für Schritt

Schritt 1: UFW installieren

sudo apt update
sudo apt install -y ufw

Prüfe die Version – UFW ist zunächst inaktiv, das ist gewollt:

ufw version

Schritt 2: Grundregeln festlegen

Zuerst die Standardrichtung: alles Eingehende ablehnen, alles Ausgehende erlauben.

sudo ufw default deny incoming
sudo ufw default allow outgoing

Default incoming policy changed to 'deny'
(be sure to update your rules accordingly)
Default outgoing policy changed to 'allow'
(be sure to update your rules accordingly)

Diese Regeln greifen noch nicht – UFW ist ja inaktiv. Deshalb kommen jetzt die Ausnahmen, bevor wir einschalten.

Schritt 3: SSH freigeben – zuerst, sonst Aussperrung

Wenn dein SSH auf dem Standardport 22 läuft (und openssh-server installiert ist), gibt es dafür ein fertiges Profil:

sudo ufw allow OpenSSH

Hast du den SSH-Port geändert (z. B. auf 2222), erlaube stattdessen genau diesen Port:

sudo ufw allow 2222/tcp

Schritt 4: HTTP und HTTPS freigeben

Für den späteren Reverse Proxy mit Traefik brauchst du die Web-Ports. Öffne sie gleich mit:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Jede Regel bestätigt UFW mit Rules updated und Rules updated (v6) (die IPv6-Variante).

Schritt 5: Firewall aktivieren und prüfen

Jetzt einschalten:

sudo ufw enable

Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

Kontrolliere das Ergebnis:

sudo ufw status verbose

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere
OpenSSH (v6)               ALLOW IN    Anywhere (v6)
80/tcp (v6)                ALLOW IN    Anywhere (v6)
443/tcp (v6)               ALLOW IN    Anywhere (v6)

Status: active und deine drei Freigaben – fertig. Teste zur Sicherheit in einer zweiten SSH-Sitzung, dass du dich weiterhin verbinden kannst, bevor du die erste schließt.

Wenn es nicht funktioniert

Symptom: Nach ufw enable kommst du per SSH nicht mehr rein.

Ursache & Lösung: Die SSH-Regel fehlte oder betraf den falschen Port. Verbinde dich über die Konsole im netcup SCP (VNC, unabhängig von SSH), erlaube dort deinen SSH-Port (sudo ufw allow …) und teste erneut. Genau davor warnt Schritt 3.

Symptom: ERROR: Could not find a profile matching 'OpenSSH'

Ursache & Lösung: Das OpenSSH-Profil existiert nur, wenn openssh-server installiert ist. Nutze stattdessen die Portnummer: sudo ufw allow 22/tcp (bzw. deinen Port). sudo ufw app list zeigt die verfügbaren Profile.

Symptom: Ein Docker-Container ist von außen erreichbar, obwohl UFW den Port nicht freigibt.

Ursache & Lösung: Kein Fehler von dir – Docker umgeht UFW. Docker schreibt seine Regeln direkt in iptables und hängt sie vor die UFW-Ketten. Ein veröffentlichter Container-Port (ports: in der compose.yaml) ist damit offen, egal was UFW sagt. Die saubere Lösung ist eine zweite Firewall-Ebene vor dem Server (ein vorgelagerter Perimeter, z. B. eine Cloud-/Provider-Firewall). Auf dem Host hilft außerdem, Container-Ports nur an 127.0.0.1 zu binden statt an 0.0.0.0.

Wartung & Backups

• Regeln ansehen und löschen: sudo ufw status numbered nummeriert alle Regeln; sudo ufw delete 3 entfernt Regel 3. So räumst du auf, wenn ein Dienst wegfällt.
• Neue Dienste: Für jeden zusätzlichen öffentlichen Port eine gezielte Regel – nie „mal eben alles" öffnen. Was nicht offen sein muss, bleibt zu.
• Kein Backup nötig, aber notiere dir deine Freigaben (oder halte sie im selben Dokument wie deine DNS-Records fest). Der Regelsatz ist in Sekunden neu getippt.
• Grenzen kennen: UFW schützt den Host, aber nicht gegen die Docker-Lücke oben. Eine vorgelagerte Provider-/Perimeter-Firewall ergänzt UFW zu zwei Ebenen, die sich gegenseitig absichern – ideal, sobald Container mit offenen Ports laufen.