Debian 13 (Trixie): Firewall & Zugriffsschutz (Teil 3)

Warum Netzwerk-Härtung?

Teil 2 hat den Server selbst gehärtet: SSH nur mit Schlüssel, automatische Updates, Dienste-Check. Doch ein gehärteter Server bringt wenig, wenn er seine Dienste ungeschützt ins Netz hängt. Genau darum geht es in Teil 3: Wer darf von außen überhaupt eine Verbindung aufbauen – und wie erkennst und stoppst du Angriffsversuche?

Konzept: Default-Deny & Ebenen

Das Grundprinzip jeder Firewall heißt Default-Deny: Alles ist verboten, was nicht ausdrücklich erlaubt ist. Zusammen mit dem Minimalprinzip aus Teil 2 ergibt sich ein mehrschichtiges Modell (Defense in Depth):

• Netzwerk: Firewall regelt, welche Ports überhaupt erreichbar sind.
• Transport: Rate-Limits & Intrusion-Detection bremsen Brute-Force-Versuche.
• Anwendung: Dienste selbst härten (SSL, Auth, Updates – Teil 1 & 2).

Ziel von Teil 3: Dein Server soll von außen nur noch SSH (22) und die Dienste sehen, die du wirklich öffentlich anbietest – alles andere bleibt zu.

Voraussetzungen

• Debian-13-Server im Zustand von Teil 1 & 2 (SSH-Zugang funktioniert).
• Eine offene Konsole oder ein zweiter SSH-Zugang als Notausgang (Lockout-Schutz!).
• Für den Portscan: ein zweites Gerät im selben Netz (Laptop) mit nmap.

sudo apt update
sudo apt install ufw fail2ban nmap

Bestandsaufnahme: Was lauscht?

Vor jeder Regel steht die Frage: Welche Dienste sind aktuell offen? Die Antwort liefert ss:

sudo ss -tulpn

Die Ausgabe zeigt alle lauschenden TCP-/UDP-Sockets. Notiere dir, was wirklich öffentlich erreichbar sein muss (z. B. 22/SSH, 443/HTTPS) und was nur lokal gehört (127.0.0.1-Bindings – genau die Praxis aus unseren Docker-Artikeln). Danach der Blick von außen, vom Laptop aus:

nmap -sS -p- SERVER-IP

UFW vertieft

UFW (Uncomplicated Firewall) nutzt auf Debian 13 automatisch das nftables-Backend und bleibt der einfachste Einstieg. Wichtig ist die Reihenfolge: Erst SSH erlauben, dann erst aktivieren – sonst bist du ausgesperrt.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw limit OpenSSH    # Rate-Limit: max. 6 Verbindungen / 30 s
sudo ufw enable
sudo ufw status verbose

Weitere nützliche UFW-Befehle:

sudo ufw app list                 # verfügbare App-Profile
sudo ufw allow 80,443/tcp         # Web
sudo ufw delete allow 8080        # Regel wieder entfernen
sudo ufw logging on               # Logging aktivieren

nftables-Einstieg

Wer UFW hinter sich lassen und das Regelwerk selbst in der Hand haben will, nutzt direkt nftables – den Standard-Framework von Debian. Wichtig: UFW und eine eigene nftables.conf nicht gleichzeitig betreiben – entscheide dich für einen Weg.

Minimales Grundregelwerk für einen SSH-/Webserver (in /etc/nftables.conf):

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority filter; policy drop;

        # Bestehende und verwandte Verbindungen zulassen
        ct state established,related accept

        # Lokalen Loopback erlauben
        iif "lo" accept

        # Dienste freigeben (Port 22 anpassen, falls in Teil 2 geändert!)
        tcp dport 22 accept
        tcp dport { 80, 443 } accept

        # Ping für IPv4 und lebenswichtige ICMPv6-Pakete erlauben
        icmp type echo-request accept
        icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert } accept
    }
    chain forward {
        type filter hook forward priority filter; policy drop;
    }
    chain output {
        type filter hook output priority filter; policy accept;
    }
}

sudo systemctl enable --now nftables
sudo nft -f /etc/nftables.conf

fail2ban: Brute-Force-Schutz

fail2ban überwacht Logdateien und sperrt IPs nach wiederholten Fehlversuchen per nftables-Regel. Für SSH reicht eine minimale Konfiguration:

sudo apt install fail2ban
sudo systemctl enable --now fail2ban

Eigene Einstellungen in /etc/fail2ban/jail.local:

# /etc/fail2ban/jail.local
[DEFAULT]
# WICHTIG für Debian 13: Da kein auth.log mehr existiert, systemd als Backend erzwingen!
backend = systemd
bantime = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true
# Falls du in Teil 2 den SSH-Port geändert hast (z.B. auf 2222), hier anpassen:
port = ssh

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd
tail -n 30 /var/log/fail2ban.log

Selbsttest & Kontrolle

Nach dem Setzen der Regeln folgt der Selbsttest – vom Laptop im selben Netz oder von außen:

nmap -sS -p- SERVER-IP         # offene Ports von außen
nmap -sV -p 22 SERVER-IP       # SSH-Version prüfen

Kontroll-Routine für den Alltag:

• sudo ufw status verbose bzw. sudo nft list ruleset – Regeln sichtbar prüfen.
• sudo fail2ban-client status sshd – wie viele IPs sind aktuell gebannt?
• sudo ss -tulpn – tauchen unbekannte Listener auf?
• Monatlich einen externen Portscan durchführen und die Portliste dokumentieren.

Häufige Probleme (FAQ)

Fazit & Ausblick Teil 4

Mit Teil 3 steht dein Server jetzt auch auf Netzwerk-Ebene auf festen Füßen: Die Bestandsaufnahme zeigt, was offen ist, UFW oder nftables setzen Default-Deny durch, und fail2ban bremst Brute-Force-Angriffe. Damit ist die Basis für den Betrieb geschaffen.

Ausblick Teil 4: CrowdSec als moderne Intrusion-Detection, Monitoring & Alarmierung (Uptime Kuma), Kernel-Parameter (sysctl) und eine Backup-Strategie mit Restore-Test runden die Serie ab.