ESP32 Firewall: Unbefugte Zugriffe auf den Webserver blocken

Eine ESP32 Firewall ist kein klassischer „iptables“-Ersatz wie auf einem Linux-Router – und trotzdem können Sie Ihren ESP32-Webserver sehr effektiv gegen unbefugte Zugriffe absichern. In der Praxis geht es weniger um ein monolithisches Firewall-Feature, sondern um ein Bündel aus Netzwerk-Architektur, sauberen Webserver-Einstellungen, Authentifizierung, Rate-Limiting und gezielten Zugriffskontrollen direkt in Ihrer Firmware. Genau hier passieren die häufigsten Fehler: Ein ESP32-Webserver wird testweise im Heimnetz gestartet, später per Portfreigabe oder Cloud-Tunnel erreichbar gemacht – und plötzlich ist er aus dem Internet angreifbar. Dazu kommen Bots, die automatisch nach offenen HTTP-Endpunkten suchen, Login-Formulare ausprobieren oder bekannte Pfade scannen. Dieser Artikel zeigt Ihnen, wie Sie Ihren ESP32-Webserver so „abschotten“, dass er nur die gewünschten Clients akzeptiert, verdächtige Anfragen blockiert und im Idealfall gar nicht erst an der falschen Stelle sichtbar ist. Sie erhalten praxistaugliche Maßnahmen für Einsteiger bis Profis – ohne Overengineering, aber mit echter Sicherheitswirkung.

Warum „Firewall“ beim ESP32 anders gedacht werden muss

Der Begriff Firewall weckt oft die Erwartung, dass ein Gerät eingehenden und ausgehenden Netzwerkverkehr auf Paketebene filtert. Auf Mikrocontrollern wie dem ESP32 läuft jedoch meist ein schlanker TCP/IP-Stack (typischerweise lwIP), und der Webserver ist Teil Ihrer Anwendung. Das bedeutet:

• Die stärkste „Firewall“ ist die Netzwerkgrenze: Router, VLANs, Access-Point-Regeln und Reverse Proxies verhindern, dass Traffic überhaupt beim ESP32 ankommt.
• Auf dem Gerät selbst sind Filter meist appliziert: Sie prüfen Client-IP, Header, Tokens oder Pfade in Ihren Request-Handlern.
• Ressourcen sind begrenzt: Jede zusätzliche Sicherheitslogik braucht RAM, CPU und Flash – trotzdem ist „wenig, aber richtig“ sehr effektiv.

Die beste Strategie ist daher eine mehrschichtige Absicherung: erst das Netzwerk so planen, dass der ESP32 nicht exponiert ist, dann den Webserver so konfigurieren, dass unbefugte Zugriffe zuverlässig abgewiesen werden.

Grundregel: Den ESP32-Webserver nicht direkt ins Internet stellen

Wenn Sie nur eine Maßnahme umsetzen, dann diese: Vermeiden Sie Portfreigaben (Port Forwarding) auf Ihren ESP32-Webserver. Ein ESP32 ist kein gehärteter Internet-Server. Stattdessen sollten Sie auf bewährte Wege setzen:

• VPN ins Heimnetz: Zugriff nur nach VPN-Einwahl, der ESP32 bleibt im LAN.
• Reverse Proxy im LAN: Ein Raspberry Pi, NAS oder Mini-PC übernimmt TLS, Authentifizierung und Rate-Limits, der ESP32 bleibt „hinter“ dem Proxy.
• Home Assistant / MQTT statt Web-UI: Steuerung über etablierte Systeme, nicht über frei zugängliche Weboberflächen.

Wenn eine externe Erreichbarkeit zwingend ist, sollte der ESP32 hinter einem Proxy mit HTTPS, Zugriffskontrollen und Logging stehen – und nicht direkt am WAN hängen.

Netzwerk-Firewall: Der Router ist Ihr stärkster Schutz

Ein sehr großer Teil unbefugter Zugriffe lässt sich bereits im Netzwerk verhindern. Im Heimnetz ist der Router typischerweise die zentrale Firewall. Diese Maßnahmen sind besonders wirksam:

• IoT in ein eigenes VLAN oder Gastnetz: Der ESP32 bekommt ein getrenntes Netz, das keinen direkten Zugriff auf PCs oder NAS hat.
• „Client Isolation“ aktivieren: Clients im IoT-/Gastnetz dürfen nicht untereinander sprechen – dadurch wird laterale Bewegung erschwert.
• Nur erlaubte Ports freischalten: Wenn der ESP32 nur HTTP im LAN braucht, blocken Sie alles andere.
• IP-Filter am Router: Zugriff auf den ESP32-Webserver nur von definierten IPs/Subnetzen zulassen (z. B. nur vom Smart-Home-Server).

Für viele Projekte reicht diese Netzwerk-Firewall bereits aus, um den Webserver effektiv abzusichern. Die Geräte-Firewall wird dann zur zweiten Verteidigungslinie.

ESP32 Firewall auf Anwendungsebene: IP-Allowlist statt „jeder darf“

Die einfachste und oft effektivste Sperre auf dem Gerät selbst ist eine IP-Allowlist: Ihr Webserver beantwortet nur Anfragen von bekannten IPs oder Subnetzen. Das schützt zuverlässig gegen unerwünschte Clients im gleichen Netz – etwa, wenn Gäste im WLAN sind oder ein kompromittiertes Gerät scannt.

• Allowlist: Nur bestimmte IPs/Subnetze sind erlaubt (empfohlen).
• Denylist: Bestimmte IPs werden gesperrt (weniger robust, weil Angreifer IPs wechseln können).

Praktischer Tipp: Wenn Ihr Smartphone regelmäßig eine andere IP bekommt, ist eine Subnetz-Regel oft besser (z. B. „nur 192.168.10.0/24“). Noch besser ist: Der ESP32-Webserver ist nur vom Reverse Proxy erreichbar, und nur dieser Proxy ist auf der Allowlist.

Authentifizierung: Ohne Login ist ein Webserver kein „internes Tool“

Eine ESP32 Firewall sollte immer mit einem Authentifizierungskonzept kombiniert werden. IP-Filter allein schützen nicht vor internen Bedrohungen oder Fehlkonfigurationen. Je nach Projekt passen diese Optionen:

• HTTP Basic Auth: Einfach umzusetzen, aber nur sinnvoll in Kombination mit HTTPS (sonst Klartext).
• Token-basierte Auth: Ein statischer oder rotierender API-Token im Header (z. B. „Authorization: Bearer …“).
• Session-Cookies: Komfortabel für Web-UIs, aber Sie müssen auf sichere Cookie-Flags und CSRF achten.
• mTLS (Client-Zertifikate): Sehr stark, aber auf Mikrocontrollern und im Browser-Kontext oft aufwendiger.

Wichtig: Speichern Sie Zugangsdaten nicht im Klartext. Wenn möglich, nutzen Sie Hashing (z. B. für Passwörter) und schützen Sie Secrets über Secure Boot und Flash Encryption – insbesondere bei Geräten, die physisch zugänglich sind.

Transportverschlüsselung: HTTPS ist keine Option, sondern Pflicht

Wenn Ihr ESP32-Webserver über untrusted Netze erreichbar ist (z. B. Gäste-WLAN, öffentliche WLANs, Internet), muss die Verbindung verschlüsselt sein. HTTPS schützt vor Mitlesen und Manipulation. Auch im Heimnetz kann HTTPS sinnvoll sein, wenn Sie sensible Daten übertragen (Zugangscodes, Sensorhistorie, Steuerbefehle).

Wenn Sie HTTPS nicht direkt auf dem ESP32 betreiben möchten (Ressourcen, Zertifikatsverwaltung), ist ein Reverse Proxy die saubere Alternative: Der Proxy macht HTTPS nach außen, der ESP32 spricht nur intern über HTTP – aber ausschließlich im isolierten Netzsegment.

Rate-Limiting und „Mini-WAF“: Bots und Scanner ausbremsen

Viele Angriffe sind nicht „gezielt“, sondern automatisiert: Bots senden viele Requests pro Minute, testen Standardpfade oder versuchen Login-Kombinationen. Sie können das bereits mit einfachen Mitteln stark eindämmen:

• Request-Limit pro IP: Maximal X Requests pro Minute; danach temporär sperren.
• Login-Versuche begrenzen: Nach N Fehlversuchen Cooldown aktivieren.
• Pfad-Whitelist: Nur erlaubte Endpunkte akzeptieren; alles andere sofort mit 404/403 beantworten.
• Header-Prüfungen: Unplausible User-Agents, fehlende Header oder falsche Content-Types abweisen (nicht als alleinige Sicherheit, aber als Filter).

Für eine grobe Dimensionierung kann ein simples Limit in „Requests pro Minute“ helfen:

$r=\frac{N}{t}$

Hier ist N die Anzahl der Requests in einem Zeitfenster t (z. B. 60 Sekunden). In der Praxis sind für eine Web-UI oft 30–120 Requests/Minute pro Client ausreichend, während Bots deutlich darüber liegen. Entscheidend ist: Blockieren Sie nicht zu aggressiv, aber konsequent genug, um Scanner auszubremsen.

Schutz sensibler Endpunkte: OTA, Konfiguration und Reset sperren

ESP32-Webserver enthalten häufig besonders kritische Funktionen: OTA-Updates, WLAN-Konfiguration, Geräte-Reset, GPIO-Steuerung oder das Auslesen von Logs. Diese Endpunkte sollten niemals „frei“ zugänglich sein.

• OTA nur nach Authentifizierung: Zusätzlich idealerweise nur aus dem Admin-Subnetz.
• Konfigurationsmodus zeitlich begrenzen: Z. B. nur für 5–10 Minuten nach Tastendruck aktiv.
• Factory-Reset nicht per Web ohne zweite Hürde: Etwa durch Hardware-Taster oder doppelte Bestätigung.
• Separate Admin-URL: Admin-Pfade nicht „erratbar“ machen (Security by Obscurity ist kein Ersatz, aber kann Bot-Traffic reduzieren).

Wenn Sie Konfigurationsseiten anbieten (SSID/Passwort, API-Keys), behandeln Sie diese wie ein Login-Portal: HTTPS, starke Auth, CSRF-Schutz, und keine sensiblen Daten in URLs oder Logs.

Cross-Site-Risiken: CSRF, CORS und sichere HTTP-Methoden

Unbefugter Zugriff bedeutet nicht nur „jemand tippt die IP ein“. Ein häufiger Angriffsweg in Heimnetzen sind Cross-Site-Angriffe: Ein Nutzer besucht eine Website, die im Hintergrund Requests an lokale Geräte absetzt.

• CSRF-Schutz: Zustandsändernde Requests (z. B. „/relay/on“) brauchen ein CSRF-Token oder einen Auth-Header, nicht nur ein Cookie.
• Nur notwendige Methoden erlauben: Deaktivieren Sie PUT/DELETE, wenn nicht gebraucht, und erzwingen Sie POST für Änderungen.
• CORS restriktiv setzen: Erlauben Sie keine pauschalen „Access-Control-Allow-Origin: *“ bei geschützten Endpunkten.
• Keine Aktionen via GET: GET sollte nur lesen. Schalten, Reset und Updates gehören in POST.

Diese Regeln sind leicht umzusetzen und verhindern, dass „nebenbei“ aus dem Browserkontext heraus ungewollte Aktionen ausgelöst werden.

Reverse Proxy als Firewall-Booster: Nginx, Caddy oder Traefik vor den ESP32

Wenn Sie mehrere ESP32-Geräte betreiben oder externe Zugriffe brauchen, ist ein Reverse Proxy oft die professionellste Lösung. Der Proxy fungiert praktisch als vorgelagerte Firewall- und Sicherheits-Schicht:

• HTTPS-Terminierung: Zertifikate und TLS-Konfiguration zentral verwalten.
• Basic Auth / OAuth / Single Sign-On: Authentifizierung „richtig“ lösen, ohne ESP32-Ressourcen zu belasten.
• Rate-Limits und IP-Blocking: Viele Proxies können verdächtige IPs automatisch drosseln oder blocken.
• Logging und Monitoring: Sie sehen, wer wann was anfragt – ohne den ESP32 mit Logs zu überlasten.

Der ESP32 sollte in diesem Modell idealerweise nur vom Proxy erreichbar sein. Auf dem ESP32 setzen Sie dann eine IP-Allowlist, die ausschließlich die Proxy-IP akzeptiert.

Praktische Firewall-Regeln für typische ESP32-Webserver-Szenarien

Je nach Einsatzgebiet sind andere Regeln sinnvoll. Diese Muster haben sich in der Praxis bewährt:

• Smart-Home-Aktor (Relais, Rollladen, Licht): Nur Steuerzentrale (Home Assistant/Node-RED) darf schreiben; Smartphones dürfen lesen (Status), wenn überhaupt.
• Sensor-Webserver (Werte, Dashboard): Lesend für definierte Clients; alle Schreib- und Konfigurationsendpunkte strikt sperren.
• Kamera/Stream (z. B. ESP32-CAM): Stream nur im LAN, idealerweise hinter Proxy; harte Limits gegen parallele Streams, weil Ressourcen knapp sind.
• Gerät mit Captive Portal/WiFi-Setup: Setup-Modus nur nach Tastendruck und nur für ein kurzes Zeitfenster aktivieren.

Die Leitfrage lautet: Wer muss wirklich Zugriff haben – und auf welche Endpunkte? Alles andere wird konsequent blockiert.

Stabilität und Sicherheit: Blocken ohne den ESP32 zu „DoS-en“

Eine ESP32 Firewall darf nicht selbst zur Schwachstelle werden. Wenn Sie jeden Request aufwendig prüfen (z. B. große Token-Parsing-Logik, komplexe Regex), kann ein Angreifer den ESP32 durch viele Anfragen ausbremsen. Achten Sie deshalb auf diese Prinzipien:

• Schnell scheitern: Erst IP prüfen, dann Method/Path, dann Auth. Teure Checks erst nach günstigen Filtern.
• Kurze Timeouts: Vermeiden Sie lange Keep-Alive- und Socket-Timeouts, wenn Sie Ressourcen sparen müssen.
• Maximale Verbindungen begrenzen: Webserver-Settings so wählen, dass ein einzelner Client nicht alles belegt.
• Speicher defensiv nutzen: Keine unnötig großen Request-Bodies akzeptieren; Content-Length prüfen.

So bleibt Ihr Gerät auch dann reaktionsfähig, wenn jemand „Lärm“ im Netz erzeugt.

Fehlersuche: Woran Sie unbefugte Zugriffe erkennen

Ohne Sichtbarkeit ist Sicherheit blind. Sie müssen nicht alles loggen, aber einige Signale sind hilfreich:

• Häufige 404 auf typische Pfade: Hinweise auf Scanner (z. B. „/admin“, „/wp-login“).
• Viele Requests in kurzer Zeit: Bot-Verhalten oder fehlerhafte Clients.
• Fehlende oder falsche Auth-Header: Versuche, geschützte Endpunkte ohne Berechtigung zu nutzen.
• Unerwartete Methoden: PUT/DELETE/TRACE sind oft ein Warnsignal, wenn Ihr Gerät diese nicht nutzt.

Wenn Sie Logging auf dem ESP32 zu teuer finden, loggen Sie am Reverse Proxy oder an Ihrer Netzwerk-Firewall. Das ist oft der sauberere Ort für Auswertung.

Outbound-Links zu hilfreichen Referenzen

• ESP-IDF Sicherheitsfunktionen: Secure Boot und Flash Encryption
• ESP-IDF HTTP Server: Grundlagen und Konfigurationsmöglichkeiten
• OWASP Top 10: Häufige Web-Sicherheitsrisiken und Gegenmaßnahmen
• OWASP IoT Project: IoT-spezifische Sicherheitsprinzipien
• CORS verstehen: Wie Browser Zugriffe zwischen Origins steuern
• CSRF-Grundlagen: Warum Tokens für zustandsändernde Requests wichtig sind

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.