Firewall-Grundlagen (ufw) für den Raspberry Pi

Firewall-Grundlagen (ufw) für den Raspberry Pi sind ein zentraler Baustein, wenn Sie Ihren Pi im Heimnetz oder sogar öffentlich erreichbar betreiben. Viele Raspberry-Pi-Projekte starten harmlos: ein kleiner Webserver, Pi-hole, Home Assistant, Nextcloud oder ein SSH-Zugang für Wartung. Doch sobald Dienste laufen, entstehen Angriffsflächen – selbst dann, wenn Sie „nichts Besonderes“ installiert haben. Eine Firewall sorgt dafür, dass nur die Verbindungen erlaubt werden, die Sie wirklich benötigen, und dass alle anderen Anfragen konsequent abgewiesen werden. Genau hier spielt ufw (Uncomplicated Firewall) seine Stärken aus: Es bietet eine leicht verständliche Oberfläche für Linux-Firewallregeln, ohne dass Sie sich sofort tief in iptables- oder nftables-Syntax einarbeiten müssen. In diesem Artikel lernen Sie, wie ufw auf Raspberry Pi OS sinnvoll eingesetzt wird, wie Sie typische Fehler (z. B. SSH-Sperre, IPv6-Leaks, unnötig offene Ports) vermeiden und wie Sie Ihr System so konfigurieren, dass es stabil, nachvollziehbar und sicher bleibt – unabhängig davon, ob Sie Einsteiger sind oder bereits mehrere Dienste auf Ihrem Pi betreiben.

Warum eine Firewall auf dem Raspberry Pi sinnvoll ist

Eine Firewall ist keine „Magie“, die Sicherheitsprobleme automatisch löst. Sie ist ein Kontrollinstrument: Sie legen fest, welche Netzwerkdienste von außen erreichbar sind und welche nicht. Gerade beim Raspberry Pi ist das wichtig, weil er häufig als Always-on-Server läuft, oft mit Standarddiensten (SSH) und gelegentlich mit Webinterfaces, die bei falscher Konfiguration öffentlich landen. Eine Firewall hilft Ihnen dabei:

• nur notwendige Ports zu öffnen und alles andere zu blockieren
• Fehlkonfigurationen schneller zu erkennen (z. B. „Warum ist Port X überhaupt offen?“)
• Angriffsversuche zu begrenzen, etwa durch Rate-Limiting für SSH
• das Prinzip „Least Privilege“ auf Netzwerkebene umzusetzen

Wichtig: Eine Firewall ersetzt keine Updates, keine sicheren Passwörter/Keys und keine saubere Dienstkonfiguration. Sie ist aber ein wirksames Sicherheitsnetz, das Fehler abfängt und den Angriffsraum deutlich reduziert.

Was ist ufw und wie passt es zur Linux-Firewall?

ufw steht für „Uncomplicated Firewall“ und ist eine komfortable Verwaltungsoberfläche für Firewallregeln. Unter der Haube arbeitet ufw mit den Kernel-Mechanismen der Linux-Firewall (je nach System iptables oder nftables). Für den Alltag bedeutet das: Sie schreiben keine komplexen Regelketten, sondern formulieren Absichten wie „SSH erlauben“ oder „Port 80 freigeben“. Das macht ufw besonders attraktiv für Raspberry-Pi-Nutzer, die Sicherheit wollen, aber nicht jedes Detail der Paketfilterung auswendig kennen.

Wenn Sie tiefer einsteigen möchten, sind diese offiziellen Einstiege hilfreich: UFW Community-Dokumentation (Ubuntu) und die Projektdokumentation zu Netfilter (technischer Hintergrund der Linux-Firewall).

Vorbereitung: Bevor Sie ufw aktivieren

Der häufigste Fehler bei ufw ist ein klassischer: Man aktiviert die Firewall, ohne den eigenen Wartungszugang (meist SSH) vorher zu erlauben – und sperrt sich aus. Besonders bei Headless-Pis (ohne Monitor) ist das unangenehm. Prüfen Sie deshalb vorab:

• Wie greifen Sie auf den Pi zu (SSH, lokales Terminal, VNC, Webinterface)?
• Welche Dienste müssen wirklich von außen erreichbar sein?
• Ist der Pi nur im LAN oder auch aus dem Internet erreichbar (Portfreigaben, VPN, Reverse Proxy)?
• Nutzen Sie IPv6 im Netz (ja/nein)?

Als Grundregel gilt: Erst die notwendigen „Allow“-Regeln setzen, dann ufw einschalten. Außerdem ist es sinnvoll, die aktuelle IP-Adresse und ggf. die lokale Konsole parat zu haben, falls Sie sich vertippen.

Installation und erster Status-Check

Auf vielen Debian-/Raspberry-Pi-OS-Installationen lässt sich ufw unkompliziert nachinstallieren. Danach prüfen Sie den Status, bevor Sie Änderungen vornehmen. Achten Sie dabei besonders auf zwei Punkte: ob ufw aktiv ist und welche Standardrichtlinien gesetzt sind (Default Policy). Eine sichere Basis ist meist: eingehend blockieren, ausgehend erlauben. Denn Ihr Pi soll Updates laden und DNS abfragen dürfen, aber nicht beliebig von außen angesprochen werden.

• Standard-Idee: eingehend „deny“, ausgehend „allow“
• Optional: eingehendes ICMP (Ping) bewusst erlauben oder blockieren – je nach Bedarf

Die drei Grundprinzipien: Default Policy, Allow, Deny

ufw folgt einem klaren Modell. Sie definieren Standardregeln und ergänzen dann Ausnahmen. In der Praxis ist das die sauberste Vorgehensweise, weil Ihre Konfiguration nachvollziehbar bleibt.

• Default eingehend: blockieren (damit nur explizit erlaubte Ports offen sind)
• Default ausgehend: erlauben (damit der Pi normal funktionieren kann)
• Regeln: gezielt erlauben (allow) oder sperren (deny) – optional mit IP-Bereich oder Interface

Dieses Muster ist besonders stabil, wenn Sie auf dem Pi im Laufe der Zeit neue Dienste testen. Ohne Default-Deny schleichen sich schnell „vergessene“ offene Ports ein.

SSH absichern: Der wichtigste Schritt für Headless-Setups

Wenn Sie den Raspberry Pi per SSH verwalten, ist SSH der kritischste Dienst. Sie sollten ihn bewusst freigeben – idealerweise nicht „für die ganze Welt“, sondern nur für Ihr lokales Netz oder ein VPN. Drei sinnvolle Stufen:

• SSH nur im LAN erlauben (z. B. für 192.168.x.x oder 10.x.x.x)
• SSH nur über VPN erlauben (WireGuard/OpenVPN), nicht direkt über Portfreigaben
• Zusätzlich Rate-Limiting für SSH aktivieren

Wenn Sie SSH doch aus dem Internet anbieten (nicht empfohlen), dann nur mit Schlüsselauthentifizierung, deaktiviertem Passwort-Login und sehr strenger Eingrenzung der erlaubten IPs. Ergänzend ist Fail2ban sinnvoll, weil es wiederholte Loginversuche aktiv blockiert: Fail2ban.

Ports sauber freigeben: Webserver, HTTPS und lokale Dienste

Viele Pi-Projekte verwenden Weboberflächen. Öffnen Sie solche Ports nur, wenn es notwendig ist. Typische Beispiele:

• HTTP (Port 80) für Testumgebungen oder Weiterleitung auf HTTPS
• HTTPS (Port 443) für produktive Webinterfaces
• Pi-hole Admin-UI nur im LAN (typisch Port 80/443 je nach Setup) und DNS (Port 53) nur für interne Clients
• Home Assistant, ioBroker oder Nextcloud möglichst hinter einem Reverse Proxy und nicht „roh“ ins Internet

Eine robuste Strategie ist: Webinterfaces nur im LAN erlauben und externen Zugriff ausschließlich über VPN oder Reverse Proxy mit zusätzlicher Authentifizierung. Für Reverse Proxies ist Nginx eine gängige Basis; Grundlagen finden Sie in der offiziellen Dokumentation: Nginx Dokumentation.

Regeln nach IP, Subnetz und Interface: Weniger offen ist meist besser

ufw kann Regeln nicht nur nach Port, sondern auch nach Quelle definieren. Das ist für Raspberry-Pi-Szenarien entscheidend: Ein DNS-Server muss meist nur aus dem Heimnetz erreichbar sein; ein SSH-Port nur aus dem Admin-Netz; ein Monitoring-Port nur aus dem VLAN der Überwachung. Wenn Sie VLANs nutzen, können Sie mit ufw sehr gut segmentieren: Erlauben Sie nur die Netze, die den Dienst wirklich brauchen.

• Regeln für einzelne IPs (z. B. Ihr Admin-PC)
• Regeln für Subnetze (z. B. 192.168.178.0/24)
• Regeln pro Interface (z. B. eth0 vs. wlan0), wenn Sie getrennte Netze nutzen

IPv6 nicht vergessen: Sonst ist die Firewall oft „halb offen“

Ein häufiger Sicherheitsirrtum: Man konfiguriert ufw für IPv4 und glaubt, alles sei dicht – während Clients oder Router bereits IPv6 nutzen und Dienste darüber erreichbar sind. Prüfen Sie daher, ob IPv6 in Ihrem Netzwerk aktiv ist. Wenn ja, sollte ufw IPv6 entweder bewusst mit absichern oder Sie deaktivieren IPv6 auf Systemebene (nur wenn Sie sicher sind, dass Sie es nicht brauchen). In vielen Heimnetzen ist IPv6 aktiv, und gerade Router verteilen IPv6-Konfiguration automatisch.

• Wenn IPv6 genutzt wird: ufw IPv6 aktivieren und Regeln entsprechend setzen
• Wenn IPv6 nicht genutzt wird: sauber und kontrolliert deaktivieren, nicht „zufällig“ halb aktiv lassen

Als Hintergrund zum Thema IPv6-Sicherheit ist die BSI-Perspektive grundsätzlich hilfreich: BSI.

Logging und Diagnose: Sichtbarkeit ohne SD-Karten-Verschleiß

Firewall-Logs sind wertvoll, aber auf einem Raspberry Pi (vor allem mit microSD) sollten Sie nicht dauerhaft extrem ausführlich loggen. Sinnvoll ist eine moderate Einstellung, die Ihnen auffällige Ereignisse zeigt, ohne die Schreiblast unnötig zu erhöhen. Nutzen Sie Logs vor allem in zwei Phasen: beim Einrichten (Fehler finden) und bei Verdacht auf ungewöhnlichen Traffic.

• Logging temporär höher stellen, um eine neue Regel zu prüfen
• Danach auf moderates Logging zurückschalten
• Bei 24/7-Systemen: Logrotate nutzen, damit Logs nicht ausufern

Warum Rate-Limiting bei SSH messbar hilft (MathML)

Brute-Force-Versuche wirken oft „harmlos“, sind aber in Summe belastend und erhöhen das Risiko, dass schwache Passwörter fallen. Wenn ein Angreifer beispielsweise 10 Versuche pro Minute durchbekommt, sind das pro Tag:

$\mathrm{Versuche/Tag}=10\times 60\times 24=14400$

Mit Rate-Limiting sinkt diese Zahl drastisch, und gleichzeitig werden Logfiles und CPU weniger belastet. Das ersetzt keine SSH-Keys, ist aber ein sinnvolles zusätzliches Schutznetz.

Typische Raspberry-Pi-Szenarien und passende ufw-Strategien

Die „richtigen“ Regeln hängen davon ab, was Ihr Pi tut. Bewährt ist, je Projekt eine kleine, verständliche Regelbasis zu haben, statt wild Ports zu öffnen.

• Pi als DNS-Server (Pi-hole/Unbound): DNS (53) nur im LAN erlauben; Admin-UI nur im LAN; SSH nur Admin-IP oder VPN.
• Pi als Webserver: 80/443 gezielt öffnen; Adminzugänge intern halten; optional nur 443 extern.
• Pi als VPN-Endpunkt (WireGuard): nur UDP-Port des VPN öffnen; alle anderen Zugänge intern.
• Pi als NAS/SMB: SMB nur im LAN; niemals SMB direkt ins Internet.

Für WireGuard ist die offizielle Projektseite ein guter Einstieg: WireGuard.

ufw und Docker: Eine wichtige Stolperfalle bei Containern

Wenn Sie Docker auf dem Raspberry Pi nutzen, sollten Sie wissen: Docker kann eigene iptables-Regeln setzen, die klassische ufw-Regeln in der Praxis umgehen oder anders priorisieren. Das führt zu Überraschungen wie „Port ist erreichbar, obwohl ufw ihn blockieren sollte“. Die Lösung hängt vom Setup ab (Docker-Bridge, Host-Netzwerk, Compose, Reverse Proxy). Wenn Sie Container öffentlich anbieten, ist eine saubere Architektur wichtig: Reverse Proxy davor, nur Proxy-Ports offen, Container-Ports nicht direkt exponieren.

• Container-Ports nicht unnötig nach außen veröffentlichen
• Nur den Reverse Proxy nach außen öffnen (typisch 80/443)
• Docker-Regeln und ufw-Regeln gemeinsam testen, nicht nur „konfigurieren“

Als Referenz für Docker-Netzwerke und Port-Publishing eignet sich die offizielle Dokumentation: Docker Networking.

Best Practices: So bleibt Ihre Firewall wartbar und sicher

Eine Firewall ist dann gut, wenn sie nicht nur sicher, sondern auch verständlich ist. Wartbarkeit ist Sicherheit: Je klarer Regeln sind, desto geringer ist die Wahrscheinlichkeit, dass Sie später „aus Versehen“ Lücken reißen.

• Default eingehend blockieren, ausgehend erlauben
• So wenig offene Ports wie möglich, so viele wie nötig
• Regeln auf Subnetze/Quellen begrenzen, statt global zu öffnen
• Änderungen dokumentieren (welcher Dienst braucht welchen Port und warum?)
• Nach Änderungen testen: Zugriff von innen, Zugriff von außen, IPv4 und IPv6
• Regelmäßig prüfen, welche Dienste tatsächlich lauschen, und ungenutzte Ports schließen

Fehler vermeiden: Was tun, wenn Sie sich ausgesperrt haben?

Wenn Sie ufw aktivieren und der SSH-Zugang bricht ab, gibt es je nach Situation verschiedene Rettungswege. Am einfachsten ist der lokale Zugriff: Monitor und Tastatur am Pi oder serieller Zugriff. Wenn das nicht möglich ist, bleibt manchmal nur, die SD-Karte in einen anderen Rechner zu stecken und Konfigurationen zu korrigieren. Deshalb ist die wichtigste Prävention: SSH-Regel setzen, bevor ufw aktiviert wird, und im Zweifel zuerst „dry run“ durch Statusprüfungen und vorsichtiges Vorgehen.

• Vor Aktivierung: SSH-Regel setzen und verifizieren
• Nach Aktivierung: bestehende Session offen lassen, parallel eine zweite Verbindung testen
• Bei Remote-Systemen: Wartungsfenster und Notfallzugriff planen

Checkliste für ein solides ufw-Setup auf dem Raspberry Pi

• Feste IP oder DHCP-Reservierung für den Pi
• SSH nur aus dem LAN oder über VPN erlauben, idealerweise mit Rate-Limiting
• Default: eingehend blockieren, ausgehend erlauben
• Webinterfaces nicht ungeschützt ins Internet stellen
• IPv6 bewusst behandeln (absichern oder sauber deaktivieren)
• Logging moderat halten, besonders auf microSD
• Docker-Ports und ufw-Regeln gemeinsam testen
• Regeln regelmäßig überprüfen und aufräumen

Weiterführende Informationsquellen (Outbound-Links)

• UFW Community-Dokumentation (Grundlagen und Beispiele)
• Netfilter (Linux-Firewall-Hintergrund)
• Fail2ban (Ergänzung zum Schutz von SSH und Diensten)
• Docker Networking (Ports, Bridges, Firewall-Interaktion)
• WireGuard (VPN als sicherer Fernzugriff)
• BSI (Sicherheitsgrundlagen und Orientierung)

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.