Firewall & Zero-Trust: Netzwerk schichtweise absichern

Firewall & Zero-Trust: Netzwerk schichtweise absichern

Du hast deinen SSH-Server abgesichert und vielleicht sogar Endlessh als Tarpit aufgesetzt. Sehr gut. Aber SSH ist nur eine Tür — dein Netzwerk hat hunderte davon. Firewalls, DNS-Anfragen, interne Kommunikation zwischen Containern: Jede Schicht ist eine potenzielle Angriffsfläche.

Hier sind fünf Maßnahmen, mit denen du dein Netzwerk Schicht für Schicht absicherst — von ufw als schnellem Einstieg bis zu Tailscale als Zero-Trust-Lösung.

DarkWolfCave.de

ℹ️ Hinweis: Die hier gezeigten Konfigurationen sind Empfehlungen aus meiner eigenen Praxis — keine Garantie für vollständige Sicherheit. Jedes Setup ist anders. Teste Änderungen immer zuerst in einer Testumgebung und passe sie an deine Infrastruktur an. Es gibt viele weitere Ansätze für Netzwerksicherheit — dieser Artikel zeigt fünf davon.

Die Netzwerk-Schichten verstehen

Die meisten konfigurieren eine Firewall und denken dann “fertig”. Aber Netzwerksicherheit hat viele Schichten — und Angreifer suchen sich immer die schwächste aus.

Schicht	Schutzmaßnahme	Angriff ohne Schutz
Paketfilter	ufw / nftables	Offene Ports werden direkt angegriffen
Angriffserkennung	CrowdSec / fail2ban	Brute-Force bleibt unerkannt
Netzwerktrennung	VLANs / Docker-Netze	Kompromittierter Dienst hat Zugriff auf alles
DNS	DNS-over-TLS / DNSSEC	DNS-Spoofing, Mitlesen der Anfragen
Zugriffskontrolle	Zero-Trust / Tailscale	Jeder im LAN hat Zugriff auf alles

Kein einzelnes Tool löst alle Probleme. Aber die Kombination dieser fünf Schichten macht es einem Angreifer schwer.

ufw Firewall — Dein erster Schutzwall

ufw (Uncomplicated Firewall) ist das Standard-Firewall-Frontend auf Ubuntu und Debian. Auf aktuellen Systemen (Debian 10+, Ubuntu 20.04+) nutzt ufw intern iptables-nft — das heißt, deine Regeln werden über die iptables-Kompatibilitätsschicht auf das nftables-Kernel-Backend übersetzt.

Grundkonfiguration in drei Befehlen

# ufw installieren (auf Ubuntu vorinstalliert, auf Debian nötig)
sudo apt install ufw

# Alles eingehende blockieren, alles ausgehende erlauben
sudo ufw default deny incoming
sudo ufw default allow outgoing

# SSH erlauben (BEVOR du die Firewall aktivierst!)
sudo ufw allow ssh

# Firewall aktivieren
sudo ufw enable

⚠️ Wichtig: Erlaube immer zuerst SSH, bevor du ufw enable ausführst. Sonst sperrst du dich auf einem Remote-Server sofort aus. Kein Spaß, wenn der Server in einem Rechenzentrum steht.

Weitere Dienste freigeben

# Webserver (HTTP/HTTPS)
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'

# Nur aus dem lokalen Netz erlauben
sudo ufw allow from 192.168.1.0/24 to any port 8080 comment 'Interner Dienst'

# Bestimmte IP für SSH erlauben
sudo ufw allow from 203.0.113.50 to any port 22 comment 'Admin SSH'

# Status prüfen
sudo ufw status verbose

Was passiert unter der Haube?

ufw übersetzt deine Regeln über iptables-nft in nftables-Kernel-Regeln. Du kannst die tatsächlichen Regeln jederzeit anschauen:

# nftables-Regeln direkt anzeigen
sudo nft list ruleset

# ufw-Regeln nummeriert anzeigen (zum gezielten Löschen)
sudo ufw status numbered

💡 Tipp: Für komplexe Setups mit Docker und mehreren Netzwerk-Interfaces lohnt sich ein Blick auf die nftables-Regeln direkt. Docker erstellt eigene nftables-Chains die ufw nicht anzeigt. Mit sudo nft list ruleset | grep docker siehst du, was Docker im Hintergrund macht.

fail2ban und CrowdSec — Angriffe erkennen und blocken

Eine Firewall filtert Pakete — aber sie erkennt keine Angriffsmuster. Dafür brauchst du ein Intrusion-Prevention-System. Hier kommen fail2ban und CrowdSec ins Spiel.

fail2ban: Der Klassiker

fail2ban überwacht Logdateien und sperrt IPs nach zu vielen fehlgeschlagenen Versuchen:

# Installation
sudo apt install fail2ban

# Lokale Konfiguration erstellen (wird bei Updates nicht überschrieben)
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Minimale Konfiguration in /etc/fail2ban/jail.local:

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true
port    = ssh
logpath = %(sshd_log)s
backend = systemd

CrowdSec: Die moderne Alternative

CrowdSec geht einen Schritt weiter als fail2ban. Der größte Unterschied: Community Threat Intelligence. Wenn ein Angreifer auf Server A erkannt wird, landet seine IP in einer Community-Blocklist — und wird auf Server B geblockt, bevor er dort überhaupt angreift.

# CrowdSec installieren
curl -s https://install.crowdsec.net | sudo sh
sudo apt install crowdsec

# Bouncer für die Firewall installieren
sudo apt install crowdsec-firewall-bouncer-nftables

# Status prüfen
sudo cscli metrics

Vergleich: fail2ban vs. CrowdSec

Feature	fail2ban	CrowdSec
Arbeitsweise	Lokal, Logfile-basiert	Lokal + Community Intelligence
Blocklist	Nur eigene Erkennung	Geteilte Community-Blocklists
Performance	Regex auf Logs (langsamer bei vielen Logs)	Streaming-Parser (schneller)
Dashboard	Kein eigenes	Lokale Web-UI + Cloud-Console
Konfiguration	jail.conf/jail.local	YAML-Szenarien
Docker-Support	Umständlich	Nativer Docker-Support

💡 Tipp: Du musst dich nicht entscheiden. CrowdSec kann parallel zu fail2ban laufen. Meine Empfehlung: Starte mit CrowdSec und nutze fail2ban nur noch für spezielle Anwendungsfälle die CrowdSec nicht abdeckt.

Netzwerksegmentierung — Nicht alles in ein Netz

Stell dir vor: Ein Angreifer kompromittiert deinen Webserver. Wenn der Webserver, deine Datenbank, dein NAS und dein Smart-Home im selben Netzwerk hängen, hat der Angreifer Zugriff auf alles. Netzwerksegmentierung verhindert genau das.

VLANs: Hardware-Trennung

VLANs trennen dein physisches Netzwerk in logische Segmente. Jedes VLAN ist eine eigene Broadcast-Domäne — Geräte in verschiedenen VLANs können ohne Router-Regel nicht miteinander sprechen.

VLAN	Zweck	Beispiel-Subnet
VLAN 10	Management	10.0.10.0/24
VLAN 20	Server / Docker	10.0.20.0/24
VLAN 30	IoT / Smart-Home	10.0.30.0/24
VLAN 40	Gäste-WLAN	10.0.40.0/24

⚠️ Wichtig: VLANs erfordern einen Managed Switch und einen Router der Inter-VLAN-Routing beherrscht. UniFi-Geräte machen das besonders einfach — sowohl Switch als auch Gateway unterstützen VLANs nativ.

Docker-Netzwerke: Container isolieren

Auch ohne VLANs kannst du Container voneinander trennen. Docker-Netzwerke sind der einfachste Weg (Docker installieren):

# Eigenes Netzwerk für die Datenbank
docker network create --driver bridge db-net

# Eigenes Netzwerk für den Webserver
docker network create --driver bridge web-net

In docker-compose.yml legst du fest, welcher Container in welches Netz darf:

services:
  webapp:
    image: nginx:alpine
    networks:
      - web-net

  api:
    image: node:24-alpine
    networks:
      - web-net
      - db-net

  postgres:
    image: postgres:18
    networks:
      - db-net

networks:
  web-net:
    driver: bridge
  db-net:
    driver: bridge
    internal: true  # Kein Internetzugang für die DB

Der Trick: internal: true sorgt dafür, dass der Postgres-Container keinen Internetzugang hat. Er ist nur über das db-net erreichbar — und dort nur für Container die explizit diesem Netzwerk zugeordnet sind.

WireGuard und Tailscale: VPN-basierte Segmentierung

Für Verbindungen zwischen Standorten oder Remote-Zugriff ist WireGuard das Mittel der Wahl. Tailscale baut auf WireGuard auf und macht die Konfiguration deutlich einfacher:

# Tailscale installieren
curl -fsSL https://tailscale.com/install.sh | sh

# Verbinden
sudo tailscale up

# ACLs definieren (in der Tailscale Admin Console)
# Beispiel: Nur Gruppe "admins" darf auf Server zugreifen

Tailscale ACLs in der Admin-Console (JSON-Format):

{
  "acls": [
    {
      "action": "accept",
      "src": ["group:admins"],
      "dst": ["tag:server:*"]
    },
    {
      "action": "accept",
      "src": ["group:developers"],
      "dst": ["tag:server:80,443"]
    }
  ]
}

So können Admins auf alle Ports zugreifen, Entwickler aber nur auf HTTP/HTTPS. Alles andere wird geblockt — und das komplett ohne Port-Forwarding oder offene Firewall-Ports.

DNS-Security — Die vergessene Angriffsfläche

DNS ist das Telefonbuch des Internets — und überraschend oft komplett ungeschützt. Ohne Verschlüsselung kann jeder im Netzwerk (und dein ISP) mitlesen, welche Domains du auflöst. Ohne DNSSEC kann ein Angreifer gefälschte DNS-Antworten einschleusen.

DNS-over-TLS mit systemd-resolved

Die meisten modernen Linux-Distributionen nutzen systemd-resolved. DNS-over-TLS lässt sich dort direkt aktivieren:

# /etc/systemd/resolved.conf
[Resolve]
DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net
FallbackDNS=1.1.1.1#cloudflare-dns.com
DNSOverTLS=yes
DNSSEC=yes

# Konfiguration anwenden
sudo systemctl restart systemd-resolved

# Prüfen ob DNS-over-TLS aktiv ist
resolvectl status

In der Ausgabe von resolvectl status sollte DNSOverTLS: yes und DNSSEC: yes stehen. Damit sind deine DNS-Anfragen verschlüsselt und gegen Manipulation geschützt.

Unbound als lokaler Resolver

Für mehr Kontrolle kannst du Unbound als lokalen DNS-Resolver betreiben. Unbound leitet deine Anfragen verschlüsselt per TLS an einen Upstream-Resolver wie Quad9 weiter — dein ISP sieht dabei nichts:

# Installation
sudo apt install unbound

# Konfiguration: /etc/unbound/unbound.conf.d/custom.conf

server:
    interface: 127.0.0.1
    port: 5353
    do-ip6: no

    # DNSSEC aktivieren
    auto-trust-anchor-file: "/var/lib/unbound/root.key"

    # DNS-over-TLS zu Upstream
    tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt

    # Cache-Einstellungen
    cache-min-ttl: 300
    cache-max-ttl: 86400
    prefetch: yes

forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 9.9.9.9@853#dns.quad9.net
    forward-addr: 149.112.112.112@853#dns.quad9.net

# Unbound starten und testen
sudo systemctl enable --now unbound

# dig installieren (für DNS-Tests)
sudo apt install dnsutils
dig @127.0.0.1 -p 5353 darkwolfcave.de

💡 Tipp: Quad9 (9.9.9.9) blockiert bekannte Malware-Domains automatisch. In Kombination mit DNSSEC und DNS-over-TLS hast du damit drei Schutzschichten auf DNS-Ebene: Verschlüsselung, Integritätsprüfung und Malware-Filterung.

Zero-Trust-Architektur — Warum der Perimeter nicht mehr reicht

Das klassische Sicherheitsmodell funktioniert so: Innerhalb der Firewall ist alles vertrauenswürdig, außerhalb ist alles feindlich. Mit Remote-Work, Cloud-Diensten und IoT-Geräten im Heimnetz funktioniert dieses Perimeter-Modell aber nicht mehr zuverlässig.

Zero-Trust dreht das Prinzip um: Vertraue niemandem, verifiziere alles — egal ob die Anfrage von innen oder außen kommt.

NIST SP 800-207: Der Standard

Das National Institute of Standards and Technology (NIST) hat mit SP 800-207 den Referenzstandard für Zero-Trust definiert. Die Kernprinzipien:

1. Jede Ressource hat eigene Zugriffskontrolle — nicht nur der Netzwerk-Perimeter
2. Jede Verbindung wird authentifiziert und autorisiert — kein implizites Vertrauen
3. Zugriff wird pro Session gewährt — nicht dauerhaft
4. Zugriff basiert auf Kontext — Identität, Gerätezustand, Standort, Verhaltensmuster

Tailscale: Zero-Trust in 5 Minuten

Tailscale ist der einfachste Weg zu einer Zero-Trust-Architektur. Es baut ein WireGuard-basiertes Mesh-VPN auf, bei dem jede Verbindung authentifiziert und verschlüsselt ist:

# Auf jedem Gerät installieren und verbinden
sudo tailscale up

# Gerät sieht nur Geräte im eigenen Tailnet
tailscale status

# SSH über Tailscale (ohne offene Ports!)
tailscale ssh user@server-hostname

Mit Tailscale SSH brauchst du keinen offenen SSH-Port mehr. Tailscale authentifiziert über SSO (Google, GitHub, Microsoft) und verbindet die Geräte direkt — kein Port-Forwarding, kein VPN-Gateway, kein offener Port in der Firewall.

Cloudflare Access: Zero-Trust für Webdienste

Für Web-Anwendungen ist Cloudflare Access eine Alternative. Es setzt einen Identity-Aware Proxy vor deine Dienste:

# Cloudflare Tunnel installieren
curl -fsSL https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -o cloudflared
sudo install cloudflared /usr/local/bin/

# Tunnel erstellen
cloudflared tunnel login
cloudflared tunnel create mein-tunnel

Tunnel-Konfiguration in ~/.cloudflared/config.yml:

tunnel: mein-tunnel
credentials-file: /root/.cloudflared/<tunnel-id>.json

ingress:
  - hostname: app.deine-domain.de
    service: http://localhost:3000
  - service: http_status:404

Damit ist deine Anwendung über app.deine-domain.de erreichbar — aber nur nach Authentifizierung über Cloudflare Access. Der Server selbst hat keine offenen eingehenden Ports. Kein Port 80, kein Port 443, nichts. Alle Verbindungen laufen über den ausgehenden Tunnel.

Vergleich der Zero-Trust-Ansätze

Feature	Tailscale	Cloudflare Access
Typ	Mesh-VPN	Reverse-Proxy
Protokoll	WireGuard	HTTPS
Ideal für	SSH, interne Dienste, Homelab	Web-Apps, öffentliche Dienste
Auth	SSO (Google, GitHub, etc.)	SSO + Device Posture
Offene Ports nötig	Nein	Nein
Kostenlos	Bis 100 Geräte	Bis 50 User

Alle Schichten zusammen

Netzwerksicherheit ist kein einzelnes Tool — es ist eine Strategie aus mehreren Schichten. Jede Maßnahme in diesem Artikel schließt eine bestimmte Lücke:

• ufw schützt auf Paketfilter-Ebene
• CrowdSec erkennt Angriffsmuster und teilt Bedrohungsdaten
• Netzwerksegmentierung begrenzt den Schaden bei einem Einbruch
• DNS-Security verhindert Mitlesen und Manipulation
• Zero-Trust eliminiert das Konzept von “vertrauenswürdigen Zonen”

Du musst nicht alles auf einmal umsetzen. Starte mit ufw und CrowdSec, trenne deine Docker-Netzwerke sauber und aktiviere DNS-over-TLS. Das dauert einen Nachmittag und bringt dich ein gutes Stück weiter.

Und wenn du die Angreifer dabei in Echtzeit beobachten willst: Endlessh auf Port 22 zeigt dir in Grafana, wer alles anklopft — während dein echter SSH-Server auf einem anderen Port hinter all diesen Schutzschichten verborgen liegt.

Die komplette Artikelserie

Diese sechs Artikel bilden zusammen einen Leitfaden für Linux-Server-Sicherheit:

1. SSH-Server absichern — Die Eingangstür härten
2. Netzwerk-Sicherheit & Firewall (dieser Artikel) — Den Perimeter schützen
3. Linux-Server härten — Die Angriffsfläche minimieren
4. Monitoring & Intrusion Detection — Angriffe erkennen
5. Endlessh SSH Tarpit — Bots aufhalten und beobachten
6. Backup & Defense-in-Depth — Das Sicherheitsnetz und die Gesamtstrategie