Wenn die Firewall zur Schwachstelle wird: Warum Netzwerk-Upgrades keine Kür sind
Firewalls schützen Netzwerke. Das ist ihre Aufgabe. Was viele Unternehmen dabei übersehen: Eine Firewall, die seit Jahren nicht aktualisiert wurde, ist kein Schutz mehr. Sie ist ein offenes Fenster.
In unserer täglichen Arbeit mit IT-Infrastruktur für KMUs sehen wir regelmäßig dasselbe Muster: Geräte laufen stabil, niemand beschwert sich, also wird nichts angefasst. Diese Logik ist gefährlich, und reale Angriffsdaten belegen das eindrücklich.
Die folgenden Beispiele stammen aus Hersteller-Advisories und Warnmeldungen von Sicherheitsbehörden der letzten Monate. Fortinet und MikroTik gehören zu den in unseren Kundennetzwerken am häufigsten eingesetzten Geräten, aber das Problem ist kein herstellerspezifisches. Cisco, Palo Alto Networks, Zyxel, Juniper: Die CVE-Listen ziehen sich durch die gesamte Branche. Wer auf dem Patch-Stand von vor zwölf Monaten steht, betreibt mit hoher Wahrscheinlichkeit Geräte mit bekannten, offenen Schwachstellen.
Eine klassische Firewall entscheidet auf Basis von IP-Adressen und Ports: Darf dieser Rechner mit jenem Server auf Port 443 reden? Ja oder nein. Das war lange ausreichend, weil Anwendungen klaren Protokollen folgten und Angreifer diese Regeln nicht ohne weiteres umgehen konnten.
Das ist heute nicht mehr der Fall. Malware, Command-and-Control-Kommunikation und Datenexfiltration laufen längst über Port 443, also über normalen HTTPS-Verkehr, der von einfachen Paketfiltern ungeprüft durchgelassen wird. Moderne Firewalls setzen deshalb auf Deep Packet Inspection, kurz DPI. Dabei wird nicht nur der Header eines Datenpakets geprüft, also Quelle, Ziel und Port, sondern der tatsächliche Inhalt bis auf die Anwendungsschicht. Eine Firewall mit DPI erkennt, ob auf Port 443 wirklich ein legitimer Webbrowser kommuniziert oder ob ein Schadprogramm dort seine Befehle empfängt. Sie kann Protokollanomalien identifizieren, bekannte Angriffsmuster abgleichen und auffällige Datenmengen im ausgehenden Verkehr erkennen, bevor eine Exfiltration abgeschlossen ist.
DPI ist rechnerisch aufwändig. Je mehr Durchsatz eine Firewall bewältigen muss, desto mehr Hardware steckt dahinter. Das ist einer der Gründe, warum ein Gerät, das vor Jahren für das damalige Verkehrsaufkommen ausgelegt wurde, heute schlicht überlastet sein kann. Ein überlastetes Gerät fängt an, DPI-Prüfungen zu überspringen oder abzuschalten, weil der Durchsatz sonst zusammenbricht. Sicherheit gegen Verfügbarkeit ist dann kein theoretisches Abwägungsproblem mehr, sondern gelebte Praxis.
Ergänzend zur DPI-Funktionalität spielt TLS-Inspection eine wachsende Rolle: Da immer mehr Datenverkehr verschlüsselt ist, entschlüsseln Firewalls mit SSL/TLS-Inspection den Verkehr an einem definierten Punkt, prüfen ihn und verschlüsseln ihn wieder. Das erfordert sorgfältige Konfiguration und klare interne Richtlinien, weil dabei per Definition Einblick in Inhalte entsteht, die sonst niemand sieht.
Nicht jede Firewall passt in jedes Umfeld. Das klingt selbstverständlich, wird in der Praxis aber häufig ignoriert, weil ein bekanntes Gerät einfach weiter beschafft wird, ohne zu fragen, ob es zum Einsatzprofil passt.
Büronetzwerke haben in der Regel viele Benutzer, viel unstrukturierten Datenverkehr, WLAN, VoIP, Cloud-Dienste und VPN-Zugänge. Die Anforderung ist hier vor allem: Application Control, Webfilter, Benutzerverwaltung und ein IDS/IPS-System, das auch mit gemischtem Traffic umgeht. Was dabei oft unterschätzt wird: Wenn 50 Personen gleichzeitig mit aktivierter TLS-Inspection surfen, ist das eine erhebliche Rechenlast. Ein Gerät, das auf dem Papier 1 Gbit/s schafft, kann mit vollem DPI und TLS-Inspection auf ein Viertel davon einbrechen.
Rechenzentren und Server-Segmente stellen andere Anforderungen. Hier geht es primär um Nord-Süd-Verkehr zwischen internen Servern und dem Internet sowie um Ost-West-Verkehr zwischen Segmenten innerhalb des Rechenzentrums. Letzteres ist besonders kritisch: Ein Angreifer, der einmal in einem Segment ist, nutzt laterale Bewegung, um sich im Netz auszubreiten. Eine Firewall, die nur den Perimeter schützt, hilft dabei wenig. Moderne Datacenter-Firewalls trennen Segmente granular, prüfen auch internen Verkehr und sind auf hohen Durchsatz bei gleichzeitig niedriger Latenz ausgelegt. In unserem eigenen Rechenzentrum, das wir für unsere Proxmox-basierte Infrastruktur und die Ethereum Staking Nodes betreiben, ist Segmentierung kein optionales Feature, sondern Grundvoraussetzung.
Industrienetzwerke und OT-Umgebungen sind ein eigenes Kapitel. Hier treffen oft Geräte aufeinander, die seit Jahren laufen, keine Updates vertragen und mit proprietären Protokollen kommunizieren, die eine normale Firewall nicht versteht. OT-Firewalls müssen Protokolle wie Modbus, Profinet oder DNP3 kennen und sicher behandeln können. Gleichzeitig sind Ausfälle in diesen Umgebungen oft keine IT-Unannehmlichkeit, sondern ein Produktionsstopp mit direktem wirtschaftlichem Schaden.
Was alle diese Umgebungen gemeinsam haben: Das Gerät muss zur Aufgabe passen, es muss korrekt konfiguriert sein, und es muss aktuell gehalten werden. Eine Firewall, die für keines dieser drei Kriterien regelmäßig überprüft wird, ist keine Sicherheitslösung, sondern eine falsche Gewissheit.
Im Januar 2025 veröffentlichte Fortinet einen Advisory zu CVE-2024-55591, einer Authentication-Bypass-Schwachstelle in FortiOS und FortiProxy, die bereits seit November 2024 aktiv ausgenutzt wurde. Ein nicht authentifizierter Angreifer konnte über manipulierte Anfragen an das Node.js-WebSocket-Modul vollständige Super-Admin-Rechte auf der Firewall erlangen. Das BSI bewertete die Schwachstelle mit CVSS 9.6, also "kritisch".
Kurz darauf wurde CVE-2025-24472 für Ransomware-Angriffe genutzt, eine verwandte Schwachstelle mit identischem Angriffsmuster. Die Gruppe Mora_001 mit mutmaßlichen Verbindungen zu LockBit nutzte beide Lücken, um sich auf exponierten FortiGate-Geräten Super-Admin-Zugang zu verschaffen, neue Admin-Accounts anzulegen und sich über VPN-Tunnel ins interne Netz zu bewegen. CISA nahm CVE-2025-24472 in den KEV-Katalog bekannter ausgenutzter Schwachstellen auf.
Noch im Januar 2026 veröffentlichte Fortinet CVE-2025-25249, eine weitere kritische Lücke in FortiOS und FortiSwitchManager, die einem nicht authentifizierten Angreifer Remote Code Execution ermöglicht.
FortiOS 7.0.17 schloss CVE-2024-55591. Trotzdem waren Monate nach der Patch-Veröffentlichung noch tausende FortiGates weltweit angreifbar, weil schlicht nicht aktualisiert wurde.
Cisco hatte 2025 gleich mehrere kritische Vorfälle. Im Herbst 2025 wurden CVE-2025-20333 (CVSS 9.9) und CVE-2025-20362 als kombinierte Schwachstellen in Cisco ASA und Firewall Threat Defense aktiv ausgenutzt, im Rahmen der ArcaneDoor-Spionagekampagne gegen ältere ASA 5500-X-Geräte ohne Secure Boot. Angreifer erlangten vollständige Kontrolle über die betroffenen Systeme. BSI und CISA gaben Notfallwarnungen heraus.
Im Dezember 2025 folgte CVE-2025-20393, eine Zero-Day-Schwachstelle mit CVSS 10.0 in Cisco Secure Email Gateway, aktiv von der chinesischen APT-Gruppe UAT-9686 ausgenutzt, noch bevor ein Patch verfügbar war. Die Angriffe liefen nach Erkenntnissen von Cisco Talos bereits seit Ende November 2025. Cisco erfuhr davon am 10. Dezember.
Anfang 2026 folgte CVE-2026-20131 im Cisco Secure Firewall Management Center, ebenfalls CVSS 10.0, mit aktiver Ausnutzung und KEV-Eintrag.
Die Geräte, die in der ArcaneDoor-Kampagne kompromittiert wurden, liefen teils auf Firmware, deren Hersteller-Support bereits abgelaufen war.
Im Februar 2025 veröffentlichte Palo Alto Networks einen Patch für CVE-2025-0108, eine Authentication-Bypass-Schwachstelle in der PAN-OS Web-Management-Oberfläche. Innerhalb weniger Tage begannen Angreifer, diese Lücke mit CVE-2024-9474 (Privilege Escalation) und CVE-2025-0111 (File Read) zu einer Exploit-Kette zu kombinieren. Das Ergebnis: Root-Zugriff auf das Gerät, ohne gültige Anmeldedaten.
Das Zeitfenster zwischen Patch-Veröffentlichung und aktivem Angriff war kleiner als eine Woche.
CVE-2024-40891 (CVSS 8.8), eine Remote Code Execution-Schwachstelle in der Telnet-Implementierung bestimmter Zyxel CPE-Geräte, war Mitte 2024 bekannt. Zyxel stellte keinen Patch bereit, weil die betroffenen Produkte als End-of-Life eingestuft wurden. Anfang 2025 wurde die Schwachstelle aktiv ausgenutzt. Zu diesem Zeitpunkt wurden die betroffenen Geräte noch über den offiziellen Zyxel-Shop auf Amazon verkauft.
Dazu kommt CVE-2025-0890 (CVSS 9.8): werkseitig hinterlegte Standard-Zugangsdaten wie admin:1234, die nicht über die Web-Oberfläche sichtbar, aber per Telnet erreichbar sind. Angreifer brauchten damit keinerlei Vorkenntnisse über das Zielnetz. CVE-2024-11667, eine Directory-Traversal-Schwachstelle in Zyxel USG Flex und ATP-Firewalls, wurde für Ransomware-Angriffe der Gruppe Helldown genutzt. Das BSI veröffentlichte dazu eine Warnung.
CVE-2024-54772 (gepatcht Februar 2025) betraf den WinBox-Dienst: Unterschiede in der Antwortgröße bei gültigen gegenüber ungültigen Benutzernamen ermöglichten systematische Account-Enumeration durch Brute-Force. Betroffen waren alle RouterOS-Versionen vor 6.49.18 und 7.18.
CVE-2025-10948 beschreibt einen Buffer-Overflow in der REST-API von RouterOS 7, der aus der Ferne ausnutzbar ist. Exploit-Code war öffentlich zugänglich, noch bevor MikroTik reagierte.
Keiner dieser Angriffe war unvermeidbar. In fast allen Fällen war zum Zeitpunkt der Ausnutzung bereits ein Patch verfügbar, oder der Hersteller hatte zumindest konkrete Gegenmaßnahmen veröffentlicht.
Das BSI hat in mehreren Warnungen zu Fortinet festgehalten, dass Schwachstellen mit längst bekannten Patches noch Monate später massenhaft ausgenutzt werden. Nicht weil die Patches fehlen, sondern weil die Prozesse fehlen.
Netzwerkgeräte sind für Angreifer besonders interessant: Sie sitzen an der Perimeter, sehen sämtlichen Datenverkehr, erlauben nach einer Kompromittierung den Zugang ins gesamte Netz und hinterlassen bei schlechtem Logging kaum Spuren. Trotzdem werden sie, anders als Server oder Endgeräte, selten in strukturierte Update-Prozesse eingebunden.
Ein funktionierendes Vorgehen sieht in der Praxis so aus:
Hersteller-Advisories und Quellen wie das BSI oder den CISA KEV-Katalog regelmäßig prüfen. Feste Wartungsfenster einplanen, in denen Updates eingespielt, getestet und protokolliert werden. Vor jedem Update ein Konfigurationsbackup anlegen, damit ein Rollback jederzeit möglich ist. Das Netz segmentieren, damit ein kompromittiertes Gerät nicht gleich den Zugang zu allem öffnet. Und ein aktuelles Inventar aller Netzwerkgeräte führen, mit Firmware-Versionen und End-of-Support-Daten. Ein Gerät ohne Hersteller-Support bekommt keine Patches mehr und gehört damit nicht mehr in ein produktives Netz.
Für Unternehmen, die unter das NISG 2026 fallen, ist nachvollziehbares Patch-Management keine Empfehlung, sondern eine regulatorische Pflicht. Ungepatchte Netzwerkgeräte an der Perimeter sind bei einer Prüfung schwer zu begründen.
Wir betreiben Netzwerkinfrastruktur für Kunden mit Geräten verschiedener Hersteller, nach ISO 27001:2022-Anforderungen. Das bedeutet dokumentierte Change-Management-Prozesse, vollständige Protokollierung von Änderungen und klare Zuständigkeiten für das Patch-Management.
Wir betreiben außerdem eigene Server-Infrastruktur für unsere Ethereum Staking Nodes. Das sind Systeme, die rund um die Uhr erreichbar sein müssen und bei denen Netzwerksicherheit direkten wirtschaftlichen Einfluss hat. Die Anforderungen, die wir intern stellen, sind dieselben, die wir unseren Kunden anbieten.
Wenn Sie wissen möchten, ob Ihre Netzwerkinfrastruktur aktuell ist, sprechen Sie uns an. Ein erster Überblick über Firmware-Versionen, offene CVEs und fehlende Härtungsmaßnahmen ist schnell erstellt.