SD-WAN-Sicherheit für KMU: Warum die zentrale Verwaltung zum Hauptziel wird

Wer mehrere Standorte betreibt, will sie nicht einzeln konfigurieren. SD-WAN verspricht genau das: Alle Router und Tunnel werden von einer zentralen Oberfläche aus gesteuert. Der Komfort hat eine Kehrseite – wer die Zentrale übernimmt, kontrolliert das gesamte Firmennetz. Eine aktuell ausgenutzte Lücke bei Cisco macht deutlich, warum SD-WAN-Sicherheit bei der Verwaltungsebene beginnt und nicht beim einzelnen Tunnel.

Anlass: Anmeldung am Cisco Catalyst SD-WAN Manager umgehbar

Laut heise online steckt im Cisco Catalyst SD-WAN Manager eine kritische Schwachstelle (CVE-2026-76504, CVSS 9.8). Ursache ist ein Fehler in der Eingabeprüfung bei der URL-Verarbeitung: Über eine speziell kodierte Anfrage lässt sich die Authentifizierung umgehen. Angreifer erhalten aus der Ferne Admin-Rechte und können über die integrierte API die verwalteten Geräte steuern.

Dem Bericht zufolge beobachtet Cisco seit September 2026 aktive Angriffe; die US-Behörde CISA führt die Lücke seit dem 30. September in ihrem Katalog bekannter ausgenutzter Schwachstellen. Abgesicherte Versionen stehen bereit, unter anderem 20.9.10.1, 20.12.8.2, 20.15.6.1, 20.18.4.1, 26.1.2.1 und 26.2.1. Wer eine ältere Ausgabe als 20.9 betreibt, muss auf einen noch unterstützten Versionszweig wechseln.

Für die Prüfung auf einen bereits erfolgten Angriff nennt Cisco zwei Logdateien: /var/log/nms/serviceproxy-access.log und /var/log/nms/vmanage-server.log. Verdächtig sind Einträge mit der Zeichenkette /%6a_security_check. Bei einem Treffer empfiehlt der Hersteller, den Support (Cisco TAC) einzuschalten.

Die wenigsten kleinen Betriebe setzen genau dieses Produkt ein. Das Muster dahinter betrifft aber jede zentral verwaltete Standortvernetzung – egal von welchem Hersteller.

Was SD-WAN ist – und was es von klassischen VPN-Tunneln unterscheidet

SD-WAN steht für Software-Defined Wide Area Network. Statt an jedem Standort einen Router von Hand zu konfigurieren, wird die Logik in eine zentrale Steuerung ausgelagert.

Drei Ebenen, eine Zentrale

• Datenebene: Die Geräte an den Standorten bauen verschlüsselte Tunnel zueinander auf und transportieren den Datenverkehr.
• Steuerungsebene: Sie legt fest, welcher Standort mit welchem spricht und welcher Weg genutzt wird – etwa Glasfaser als Hauptleitung, Mobilfunk als Ersatz.
• Verwaltungsebene: Eine Weboberfläche samt API, über die Administratoren Richtlinien, Firewall-Regeln und Updates an alle Standorte ausrollen.

Bei einer klassischen Vernetzung mit einzelnen Site-to-Site-Tunneln gibt es diese dritte Ebene nicht. Jede Firewall wird für sich verwaltet. Das ist mühsamer, aber ein kompromittiertes Gerät bedeutet zunächst nur einen kompromittierten Standort.

Warum die Verwaltungsebene das wertvollste Ziel ist

Ein Angreifer mit Admin-Rechten auf dem Controller muss keinen Standort einzeln angreifen. Er kann Routen umleiten, Datenverkehr mitschneiden, Firewall-Regeln öffnen, eigene Geräte ins Netz aufnehmen oder Konfigurationen an alle Filialen verteilen. Die Zentrale ist damit ähnlich kritisch wie ein Domänencontroller – nur dass sie häufig aus dem Internet erreichbar ist, damit Außenstellen und Administratoren sie nutzen können.

Dasselbe gilt für Cloud-Controller kleinerer Netzwerkplattformen: Wer das Verwaltungskonto übernimmt, übernimmt alle angeschlossenen Standorte.

SD-WAN-Sicherheit in der Praxis: Sieben Schritte

Schritt 1: Verwaltungsoberfläche aus dem Internet nehmen

Die Weboberfläche und die API des Controllers gehören nicht offen ins Netz. Der Zugriff sollte nur aus einem Management-Netz oder über ein VPN möglich sein, ergänzt um eine Beschränkung auf bekannte IP-Adressen. Eine Lücke wie die aktuelle, die die Anmeldung umgeht, ist dann für anonyme Angreifer aus dem Internet nicht erreichbar. Ob der eigene Controller von außen sichtbar ist, zeigt ein Scan der externen Angriffsfläche.

Schritt 2: Updates für den Controller mit Vorrang einspielen

Der Controller wird im Alltag oft vergessen, weil er „nur“ verwaltet. Er gehört in dieselbe Patch-Klasse wie Firewall und VPN-Gateway: Sicherheitsupdates für aktiv ausgenutzte Lücken innerhalb von Tagen, nicht zum nächsten Wartungsfenster im Quartal. Dazu gehört, die Sicherheitsmeldungen des Herstellers zu abonnieren und zu wissen, welche Version läuft. Mehr dazu in unserem Artikel zu Sicherheitslücken in Firewalls.

Schritt 3: Administratorzugänge härten

Persönliche Konten statt eines geteilten Admin-Logins, Mehrfaktor-Anmeldung für jeden Zugang, abgestufte Rollen. API-Schlüssel erhalten nur die Rechte, die die jeweilige Automatisierung braucht, und werden regelmäßig erneuert. Mehrfaktor-Anmeldung hilft nicht gegen eine Lücke, die die Anmeldung komplett umgeht – sie schließt aber den weit häufigeren Weg über gestohlene Passwörter.

Schritt 4: Logs zentral sammeln und auswerten

Der aktuelle Fall zeigt, wie wichtig Protokolle sind: Ob ein Angriff stattgefunden hat, lässt sich nur anhand der Zugriffslogs klären. Liegen diese ausschließlich auf dem betroffenen System, kann ein Angreifer sie löschen. Controller-Logs sollten deshalb an einen separaten Logserver oder ein SIEM weitergeleitet werden – mit Alarm bei neuen Admin-Konten, Konfigurationsänderungen außerhalb der Arbeitszeit und unbekannten Geräten im Verbund.

Schritt 5: Standorte gegeneinander abgrenzen

Ein vollvermaschtes Netz, in dem jede Filiale jede andere erreicht, ist bequem und gefährlich. Besser: Außenstellen dürfen nur die zentralen Dienste erreichen, die sie brauchen. In Verbindung mit Netzwerksegmentierung an jedem Standort bleibt ein Vorfall in der Filiale ein Vorfall in der Filiale.

Schritt 6: Konfiguration sichern und Notbetrieb planen

Die Konfiguration des Controllers gehört ins Backup, getrennt vom System selbst. Ebenso wichtig ist die Frage, was passiert, wenn die Zentrale ausfällt oder nach einem Angriff neu aufgesetzt werden muss: Laufen die Tunnel weiter? Gibt es lokale Notfallzugänge zu den Geräten an den Standorten? Das sollte dokumentiert und einmal durchgespielt sein.

Schritt 7: Nach einer ausgenutzten Lücke nicht nur patchen

Ein Update schließt die Lücke, entfernt aber keinen Angreifer, der bereits im System war. Nach einer aktiv ausgenutzten Schwachstelle gilt: Logs auf die vom Hersteller genannten Spuren prüfen, Admin-Konten und API-Schlüssel kontrollieren, Zugangsdaten und Zertifikate erneuern, die ausgerollte Konfiguration mit dem Sollzustand vergleichen. Bei Verdacht auf eine Kompromittierung gehört der Hersteller-Support hinzu.

Braucht ein KMU überhaupt SD-WAN?

Für ein Unternehmen mit Dutzenden Filialen und mehreren Leitungen pro Standort ist SD-WAN sinnvoll. Bei zwei bis fünf Standorten reicht in der Regel eine schlankere Lösung: Site-to-Site-Tunnel mit WireGuard zwischen OPNsense-Firewalls, ergänzt um eine Ausfallleitung über Mobilfunk. Es gibt dann keinen zentralen Controller, der aus dem Internet erreichbar sein muss – und damit ein lohnendes Ziel weniger.

Der Preis ist mehr Handarbeit bei Änderungen. Diese lässt sich durch saubere Dokumentation und versionierte Konfigurationen abfedern. Entscheidend ist eine ehrliche Abwägung: Wie oft ändert sich das Netz wirklich, und wer betreut die Zentrale, wenn eine kritische Lücke bekannt wird?

Was das für KMU in Sachsen bedeutet

Viele ostdeutsche KMU sind über mehrere Orte verteilt: Verwaltung in Dresden, Produktion oder Lager im Umland, dazu Außenstellen bei Kunden. Die Anschlüsse sind unterschiedlich gut, Mobilfunk dient oft als Reserve. Standortvernetzung ist dort kein Luxus, sondern Voraussetzung für ERP, Telefonie und Dateizugriff. Umso wichtiger ist SD-WAN-Sicherheit im Alltag: Die Vernetzung in Sachsen muss nicht nur funktionieren, jemand muss auch ihre Verwaltungsebene im Blick haben – mit bekannten Versionsständen, geregelten Updates und überwachten Zugängen.

Sie suchen Unterstützung in Dresden?

Rexoma hilft KMU bei der sicheren Standortvernetzung: Prüfung bestehender SD-WAN- und VPN-Umgebungen, Absicherung der Verwaltungszugänge, Vernetzung von Standorten mit OPNsense und WireGuard sowie laufende Betreuung mit Patch-Management und Monitoring. Sprechen Sie uns an – als IT-Dienstleister aus Dresden sind wir für Betriebe in ganz Sachsen schnell vor Ort.

FAQ

Was ist der Unterschied zwischen SD-WAN und einem Site-to-Site-VPN?

Ein Site-to-Site-VPN ist ein verschlüsselter Tunnel zwischen zwei Standorten, der an beiden Enden einzeln eingerichtet wird. SD-WAN nutzt ebenfalls verschlüsselte Tunnel, steuert sie aber zentral, verteilt Richtlinien automatisch und wählt zwischen mehreren Leitungen. Der Zugewinn an Komfort bringt eine zentrale Verwaltungsinstanz mit, die besonders geschützt werden muss.

Wir nutzen kein Cisco – betrifft uns das Thema trotzdem?

Die konkrete Lücke betrifft nur den Cisco Catalyst SD-WAN Manager. Das Grundproblem gilt aber für jede zentral verwaltete Netzwerkplattform, auch für Cloud-Controller: Wer die Verwaltung übernimmt, kontrolliert alle angeschlossenen Geräte. Die Schutzmaßnahmen sind herstellerunabhängig dieselben.

Wie erkenne ich, ob unser SD-WAN-Controller angegriffen wurde?

Zuerst die Hinweise des Herstellers prüfen – im aktuellen Fall nennt Cisco konkrete Logdateien und eine Zeichenkette, nach der gesucht werden soll. Zusätzlich lohnt der Blick auf unbekannte Admin-Konten, neue API-Schlüssel, geänderte Richtlinien und Geräte, die niemand hinzugefügt hat. Ohne zentral gesicherte Logs ist eine verlässliche Aussage oft nicht möglich.

Reicht WireGuard für die Vernetzung mehrerer Standorte aus?

Für wenige Standorte in der Regel ja. WireGuard-Tunnel zwischen Firewalls sind schnell, stabil und kommen ohne zentralen Controller aus. Ab einer größeren Zahl von Standorten oder bei mehreren Leitungen pro Standort mit automatischer Wegewahl wird die manuelle Pflege aufwendig – dann kann SD-WAN die bessere Wahl sein.