Sicherheitshinweis für Catalyst SD-WAN - Februar 2026

Einleitung

In diesem Dokument werden die Schritte zum Identifizieren und Beheben kritischer Sicherheitslücken in SD-WAN basierend auf PSIRT-Empfehlungen vom 25. Februar 2026 beschrieben.

---

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Cisco Catalyst SD-WAN-Architektur und Steuerungskomponenten (vManage, vSmart, vBond)
• Cisco Catalyst SD-WAN-Upgrade-Verfahren
• Cisco TAC-Fallmanagement und Verfahren zur Erfassung von Admin-Tech-Daten

Verwendete Komponenten

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

---

Hintergrundinformationen

Detaillierte Hintergrundinformationen und die neuesten Updates finden Sie auf der offiziellen PSIRT-Beratungs-Seite.

Diese Ankündigungen finden Sie unter folgenden Links:

• Sicherheitslücken in Cisco Catalyst SD-WAN
• Sicherheitslücke bei Cisco Catalyst SD-WAN-Controller-Authentifizierung umgangen
  
  

Diese Mängel werden durch folgende PSIRT-Ankündigungen behoben:

• Cisco Bug-ID CSCws52722
• Cisco Bug-ID CSCws33583
• Cisco Bug-ID CSCws33584
• Cisco Bug-ID CSCws33585
• Cisco Bug-ID CSCws33586
• Cisco Bug-ID CSCws33587
• Cisco Bug-ID CSCws93470

---

Behebungs-Workflow - Übersicht

Erforderliche Aktion: Öffnen Sie ein Cisco TAC-Ticket, um diese Sicherheitsempfehlung zu bearbeiten.

Das TAC ist verfügbar für:

• Bewertung der Umgebung auf Anzeichen für Kompromittierung
• Führen Sie den entsprechenden Behebungspfad basierend auf der Bewertung durch.
• Arbeiten Sie mit dem PSIRT-Team zusammen, wenn Anzeichen für eine Kompromittierung identifiziert werden.
• Beratung und Unterstützung bei Upgrades, wenn keine Anzeichen für Kompromittierung erkannt werden

1. Collect Admin-Techs: Führen Sie admin-tech für alle Steuerungskomponenten aus (vSmart, vManage, vBond). vSmart admin-techs darf nicht gleichzeitig ausgeführt werden, sondern muss einzeln ausgeführt werden. Alle anderen können in beliebiger Reihenfolge gesammelt werden. Wählen Sie die Optionen Protokoll und Technik aus.  Core ist nicht erforderlich.
2. Open TAC Case - Kontaktieren Sie das Cisco TAC und stellen Sie alle Control Component Admin-Tech Log-Pakete bereit
3. TAC-Analyse - TAC bewertet Ihre Umgebung auf Anzeichen für Kompromittierung
4. Problembehebung durchführen - vom TAC bereitgestellter Prozess abschließen

---

---

Schritt 1: Admin-Tech-Dateien von allen Steuerungskomponenten sammeln

Erforderlich: Sammeln Sie Admin-Tech-Dateien von allen Steuerungskomponenten, bevor Sie Ihr TAC-Ticket öffnen. Dies ist für das TAC zur Beurteilung Ihrer Umgebung unerlässlich.

Sammlung:

1. Führen Sie admin-tech auf ALLEN Controllern (vSmarts) aus - führen Sie diese nicht gleichzeitig aus. eine nach der anderen abholen
2. Admin-Tech auf ALLEN Managern (vManages) ausführen
3. Admin-Tech auf ALLEN Validatoren (vBonds) ausführen

Admin-Tech in SD-WAN-Umgebung erfassen und auf TAC-Ticket hochladen

Alternative: Manuelle Überprüfung (nur wenn Admin-Tech nicht erfasst werden kann)

Für Benutzer, die keine Admin-Tech-Dateien freigeben können, stehen manuelle Überprüfungsschritte zur Verfügung. Diese Schritte enthalten vorläufige Indikatoren, die dokumentiert und an das TAC weitergegeben werden müssen.

Detaillierte Anweisungen hierzu finden Sie im Abschnitt "Manuelle Verifizierung" am Ende dieses Dokuments. Dokumentieren Sie alle Ergebnisse, und stellen Sie sie dem TAC in Ihrem Supportfall zur Verfügung.

---

Phase 2: TAC-Ticket öffnen und Admin-Tech-Dateien hochladen

Nachdem Sie alle Admin-Tech-Dateien aus Schritt 1 gesammelt haben, öffnen Sie ein Cisco TAC-Support-Ticket.

Erforderliche Aktionen:

1. Erstellen Sie ein TAC-Ticket mit dem Schweregrad, der Ihren geschäftlichen Auswirkungen entspricht.
2. Laden Sie ALLE in Schritt 1 gesammelten Admin-Tech-Protokollpakete hoch (Controller, Manager und Prüfer).
3. Verweisen auf die PSIRT-Ankündigungen
4. TAC-Analyse und Beratung abwarten

---

Schritt 3: TAC-Analyse

Das TAC analysiert die hochgeladenen Admin-Tech-Dateien und ermittelt den Status Ihres Systems.

Während dieser Zeit:

• Abwarten einer offiziellen Bewertung durch das TAC, bevor Maßnahmen ergriffen werden
• TAC kontaktiert Sie mit seinen Ergebnissen und den nächsten Schritten

---

Schritt 4: Problembehebung durchführen (TAC-orientiert)

TAC führt Sie durch den entsprechenden Sanierungsprozess, basierend auf der Bewertung des Kunden. Befolgen Sie alle Anweisungen des TAC.

Pfad A: Keine Indications of Compromise gefunden - Upgrade

Wenn das TAC bestätigt, dass keine Anzeichen für eine Kompromittierung vorliegen, führen Sie ein Upgrade auf die feste Softwareversion durch. Wählen Sie aus der Tabelle Fixed Software Versions (Feste Softwareversionen) in diesem Dokument die entsprechende Version aus, und verweisen Sie auf den in diesem Abschnitt verknüpften Upgrade-Leitfaden.

Upgrade von SD-WAN-Controllern mithilfe der vManage-GUI oder -CLI

Pfad B: Indications of Compromise identifiziert - PSIRT-geführt

Wenn das TAC bestätigt, dass Indicators of Compromise vorhanden sind, füllen Sie alle Anweisungen des TAC aus.

---

Fest implementierte Softwareversionen

Diese Softwareversionen enthalten Korrekturen für die identifizierten Schwachstellen:

Gilt für aktuelle Versionen	Feste Version	Verfügbare Software
20,3, 20,6, 20,9	20.9.8.2 *	20.9.8.2 Upgrade-Images für vManage, vSmart und vBond
20.10, 20.11, 20.12.5 und frühere Versionen in 20.12	20.12.5.3	20.12.5.3 Upgrade-Images für vManage, vSmart und vBond
20.12.6	20.12.6.1	20.12.6.1 Upgrade-Images für vManage, vSmart und vBond
20.13, 20.14, 20.15.x	20.15.4.2	20.15.4.2 Upgrade-Images für vManage, vSmart und vBond
20.16, 20.17, 20.18.x	20.18.2.1	20.18.2.1 Upgrade-Images für vManage, vSmart und vBond

* Wenn Sie Version 20.9 oder älter sind: Die Software für Ihre Version (20.9.8.2) ist am 27.2.2 verfügbar. Cisco empfiehlt, innerhalb der aktuellen Hauptversion zu bleiben und auf die Version 20.9.8.2 zu warten, anstatt auf eine höhere Hauptversion (20.12, 20.15, 20.18) zu aktualisieren. Wenn Sie sich aktuell in einer Version unter 20.9 befinden, warten Sie, bis dort ein Upgrade auf 20.9.8.2 durchgeführt wird. Arbeiten Sie weiterhin mit dem TAC zusammen, und informieren Sie sich am 27.2. über den verfügbaren Software-Link.

Wichtige Hinweise:

• Upgrade-Matrix
• Controller-Kompatibilitätsmatrix

---

Anhang: Manuelle Verifizierungsschritte (nur wenn Admin-Tech-Erfassung nicht möglich)

Anforderungen: Diese Schritte müssen an allen Steuerungskomponenten durchgeführt werden.

Überprüfung 1: Suchen nach nicht autorisierten SSH-Anmeldungen in Auth-Protokollen

Schritt 1: Identifizieren gültiger vManage-System-IPs

Zugriff auf jeden vSmart Controller und Ausführung:

west-vsmart# show control connections | inc "vmanage|PEER|IP"

Beispiel:

                                                    PEER                                                                                    PEER
      PEER  PEER  PEER            SITE       DOMAIN  PRIV    PEER                              PUB     PEER
INDEX TYPE  PROT  SYSTEM IP       ID         ID      PRIVATE IP                        PORT    PUBLIC IP                         PORT    ORGANIZATION        REMOTE COLOR  STATE  UPTIME
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0     vmanage dtls 10.1.0.18     101018     0       10.1.10.18                        12346   10.1.10.18                        12346   calo-auto-lab       default       up     5:17:27:22

Phase 2: Zeichenfolge für regulären Ausdruck erstellen (nur vBond und vSmart)

Alle System-IPs aus Schritt 1 in einem OR-Regex-Muster kombinieren:

system-ip1|system-ip2|...|system-ipn

Schritt 2b: Zusätzlicher Schritt für vManage-Systeme

Wenn diese Befehle auf vManage selbst ausgeführt werden, fügen Sie die IP-Adresse des lokalen Hosts (127.0.0.1), die IP-Adresse des lokalen Systems, alle Cluster-IPs und die IP-Adresse der VPN 0-Transportschnittstelle an den regulären Ausdruck an:

system-ip1|system-ip2|...|system-ipn|127.0.0.1|

Um die lokale IP-Adresse des vManage-Systems zu finden, verwenden Sie:

show control local-properties

Um die IP- und Cluster-IP-Adresse der VPN 0-Transportschnittstelle zu finden, verwenden Sie:

show interface | tab

Schritt 3: Verifizierungsbefehl ausführen

Führen Sie diesen Befehl aus, und ersetzen Sie REGEX durch Ihre reguläre Zeichenfolge aus Schritt 2:

west-vsmart# vs
west-vsmart:~$ zgrep "Accepted publickey for vmanage-admin from " /var/log/auth.log* | grep -vE "\s(REGEX)\s"

Schritt 4: Interpretation der Ergebnisse und Dokumentation für das TAC

Wenn KEINE Ausgabe angezeigt wird:

• Keine Indications of Compromise auf diesem Gerät erkannt
• Dokumentieren Sie dieses Ergebnis für Ihren TAC-Ticket.
• Bewertung der verbleibenden Controller fortsetzen

Wenn Protokollzeilen gedruckt werden:

• Überprüfen Sie sorgfältig alle angezeigten IP-Adressen.
• Überprüfen Sie, ob die IP-Adresse nicht mit der vManage-Infrastruktur (Cluster-IP, alte System-IP-Adresse oder Ähnliches) zusammenhängt.
• Wenn Sie die Quell-IP nicht als legitim identifizieren können, kann dies auf potenzielle Indications of Compromise hinweisen.
• Der Protokolleintrag zeigt einen Zeitstempel und eine Quell-IP-Adresse an
• Dokumentieren Sie alle Ergebnisse, und eröffnen Sie sofort ein TAC-Ticket.
• Integrieren Sie die Protokolleinträge, Zeitstempel und Quell-IPs in Ihrem Ticket.
• TAC führt offizielle Bewertungsbestimmung durch

Überprüfung 2: Suchen nach nicht autorisierten Peer-Verbindungen in Controller-Syslogs

Dieser Befehl extrahiert alle Peer-Typ- und Peer-System-IP-Paare aus den Syslog-Dateien des Controllers und gibt sie als Liste aus, die Sie überprüfen können. Verdächtige Einträge werden nicht automatisch gekennzeichnet. Sie müssen die Ausgabe überprüfen und feststellen, ob jede IP-Adresse des Peer-Systems ein bekannter, legitimer Teil Ihrer SD-WAN-Infrastruktur ist. Führen Sie diesen Vorgang für alle Steuerelementkomponenten aus (Controller, Manager und Validatoren).

Schritt 1: Führen Sie den Befehl für jede Steuerelementkomponente aus:

Rufen Sie zunächst vshell auf, und navigieren Sie zum Protokollverzeichnis:

vs
cd /var/log

Führen Sie dann den folgenden Befehl aus:

awk '{
  match($0, /peer-type:([a-zA-Z0-9]+)[^ ]* peer-system-ip:([0-9.:]+)/, arr);
  if(arr[1] && arr[2]) print "(" arr[1] ", " arr[2] ")";
}' vsyslog* | sort | uniq

Phase 2: Interpretation der Ergebnisse und Dokumentation für das TAC

Wenn die Ausgabe nur bekannte IPs des vManage/vSmart/vBond-Systems anzeigt:

• Bei dieser Prüfung wurden keine Anzeichen für eine Kompromittierung erkannt.
• Dokumentieren Sie dieses Ergebnis für Ihren TAC-Ticket.
• Bewertung der verbleibenden Steuerungskomponenten fortsetzen

Wenn die Ausgabe nicht erkannte IPs des Peer-Systems enthält:

• Überprüfen Sie sorgfältig alle abgebildeten IP-Adressen und Peer-Typen.
• Vergewissern Sie sich, dass die IP nicht mit Ihrer bekannten SD-WAN-Kontrollebeneninfrastruktur in Zusammenhang steht.
• Wenn Sie die Quell-IP nicht als legitim identifizieren können, kann dies auf potenzielle Indications of Compromise hinweisen.
• Dokumentieren Sie alle Ergebnisse, und eröffnen Sie sofort ein TAC-Ticket.
• Integrieren Sie die vollständige Befehlsausgabe mit Peer-Typ- und Peer-System-IP-Paaren in Ihrem Fall.
• TAC führt offizielle Bewertungsbestimmung durch

Überprüfung 3: DCA-Datei gelesen

Schritt 1: Zu suchende Elemente

Protokolldatei: /var/log/nms/containers/service-proxy/serviceproxy-access.log

Beispiel für Protokollzeile:

[2026-03-04T01:45:06.239Z] "GET /reports/data/opt/data/containers/config/data-collection-agent/.dca HTTP/1.1" 200 - 0 32 1 - "" "python-requests/2.32.5" "ae076862-2244-45a6-844f-bc2af970e570" "192.168.2.3" "127.0.0.1:8080"

Phase 2: Manueller Suchbefehl

Vom Terminal aus: Suchen Sie im extrahierten Admin-Tech-Paket:

zgrep -r "data-collection-agent/.dca" var/log/nms/containers/service-proxy/serviceproxy-access.log*

Überprüfung 4: Pfadüberquerung/Überschreiben beliebiger Dateien

Schritt 1: Zu suchende Elemente

Protokolldatei: /var/log/nms/vmanage-server.log

Beispiel für Protokollzeilen:

06-Mar-2026 02:16:34,029 UTC INFO  [285fcdc0-30fa-4ca0-8e06-6953a095a59a] [LAB-TEST-1] [SmartLicensingManager] (default task-11229) |57501bad-32a7-4f52-8f54-8547dcd7403e| Time taken to write file ../../../../../../../../../../../var/lib/wildfly/standalone/deployments/cmd.gz.war = 2 ms to directory /opt/data/app-server/software/package/license/ack
04-Mar-2026 15:40:02,683 IST INFO  [ca0e641b-acc7-42a6-b39b-bf3d28be0bcb] [LAB-TEST-1] [SmartLicensingManager] (default task-1235) |default| Time taken to write file ../../../../../../../../../../../var/lib/wildfly/standalone/deployments/sysv.gz.war = 0 ms to directory /opt/data/app-server/software/package/license/ack
27-Feb-2026 08:49:27,169 IST INFO  [d9976a9d-071e-4e07-a3ef-4e90019cae12] [LAB-TEST-1] [SmartLicensingManager] (default task-809) |default| Time taken to write file ../../../../../../../../../../../var/lib/wildfly/standalone/deployments/authscp.gz.war = 0 ms to directory /opt/data/app-server/software/package/license/ack

Vorsicht: Der in den Beispielen gezeigte Dateiname (z. B. cmd.gz.war) dient lediglich zur Veranschaulichung. In der Praxis können unterschiedliche Dateinamen verwendet werden. Notieren Sie alle eindeutigen Traversal-Dateinamen, die identifiziert wurden, da jeder eine separate verworfene Nutzlast darstellt.

Phase 2: Manueller Suchbefehl

Vom Terminal aus: Suchen Sie im extrahierten Admin-Tech-Paket:

grep -rE "SmartLicensingManager.*Time taken to write file \.\.\/" var/log/nms/vmanage-server.log*

Einschließlich rotierter/komprimierter Protokolle:

zgrep -E "SmartLicensingManager.*Time taken to write file \.\.\/" var/log/nms/vmanage-server.log*

So erfassen Sie verwandte Kontextzeilen (Upload-API-Verarbeitungs- und Schreibereignisse):

grep -rE "SmartLicensingManager.*(write file|is processing|stringUrl|Failed to download).*/wildfly" var/log/nms/vmanage-server.log*

Überprüfung 5: Dateibereitstellung 

Schritt 1: Zu suchende Elemente

Protokolldatei: /var/log/nms/containers/service-proxy/serviceproxy-access.log

Jede POST-Anfrage an ein *.gz/*.jsp URI-Muster wird markiert. HTTP-Status bestimmt den Schweregrad:

HTTP-Status	Bedeutung	Kompromittierung bestätigt?
200	Der Server hat die Webshell ausgeführt. Nutzlast ist aktiv	Ja - bestätigter Kompromiss

Beispiel für Protokollzeilen:

[2026-03-04T08:03:33.295Z] "POST /cmd.gz/cmd.jsp HTTP/1.1" 200 - 6 63 78 - "" "python-requests/2.32.5" "9d842c1a-b96f-4d04-ac3d-542ec3dd734b" "192.168.2.3" "127.0.0.1:8080"

Phase 2: Manueller Suchbefehl

Vom Terminal aus: Suchen Sie im extrahierten Admin-Tech-Paket:

grep -rE '"POST /[^"]+\.gz/[^"]+\.jsp HTTP' var/log/nms/containers/service-proxy/serviceproxy-access.log*

Einschließlich rotierter/komprimierter Protokolle:

zgrep -E '"POST /[^"]+\.gz/[^"]+\.jsp HTTP' var/log/nms/containers/service-proxy/serviceproxy-access.log*

So trennen Sie bestätigte Ausführung (HTTP 200) von nicht-200 Versuchen:

# HTTP 200 only - confirmed webshell execution:
grep -rE '"POST /[^"]+\.gz/[^"]+\.jsp HTTP[^"]*" 200' var/log/nms/containers/service-proxy/serviceproxy-access.log*

---

Häufig gestellte Fragen

F: Was ist der erste Schritt, um diese Sicherheitsempfehlung umzusetzen?

A : Sammeln Sie Admin-Tech-Dateien von allen Steuerungskomponenten, und öffnen Sie ein TAC-Ticket, um die Dateien hochzuladen. Das TAC bewertet Ihre Umgebung und gibt Ihnen Hinweise zu den nächsten Schritten.

Frage: Welche Version benötige ich für ein Upgrade? 

A. Bitte aktualisieren Sie frühestens auf die nächstgelegene feste Version.

F: Muss ich Admin-Techniker von allen Steuerungskomponenten sammeln?

A : Ja, das TAC erfordert Admin-Tech-Dateien von allen Controllern (vSmart, jeweils eine erfasst), allen Managern (vManage) und allen Validatoren (vBond), um Ihre Umgebung richtig zu bewerten.

F: Wie ermittelt das TAC, ob mein System kompromittiert wurde?

A : Das TAC analysiert die Admin-Tech-Dateien mithilfe spezieller Tools, um Ihre Umgebung auf Anzeichen für eine Kompromittierung zu untersuchen.

F: Was passiert, wenn Anzeichen für eine Kompromittierung erkannt werden?

A : TAC kontaktiert Sie, um die nächsten Schritte und spezifische Richtlinien für Ihre Umgebung zu besprechen. Cisco führt die Fehlerbehebung nicht in Ihrem Namen durch - das TAC bietet Ihnen die nötigen Anleitungen für die Vorgehensweise.

F: Woher weiß ich, welche feste Softwareversion ich verwenden soll?

A : Weitere Informationen finden Sie in der Tabelle Fixed Software Versions in diesem Dokument. TAC bestätigt die für Ihre spezifische Umgebung passende Version.

F: Kann ich das Upgrade starten, bevor das TAC meine Admin-Techniker analysiert?

A : Nein, warten Sie, bis das TAC die Analyse abgeschlossen und sich beraten hat, bevor Sie Abhilfemaßnahmen ergreifen.

F: Sind Ausfallzeiten während der Problembehebung zu erwarten?

A : Die Auswirkungen hängen von Ihrer Bereitstellungsarchitektur und dem Wiederherstellungspfad ab. Das TAC bietet Hilfestellung bei der Minimierung der Auswirkungen auf den Service während des Prozesses.

F: Sind die PSIRT-Korrekturen in der kommenden Version 20.15.5 und anderen kommenden Versionen enthalten? 

A : Ja, Fixes sind in 20.15.5 und anderen kommenden Versionen enthalten. Das Upgrade zur Beseitigung der in diesem Dokument beschriebenen Schwachstellen muss jedoch SOFORT priorisiert werden. (Warten Sie nicht!)

F: Müssen alle Controller aktualisiert werden, wenn keine Anzeichen für eine Kompromittierung gefunden werden?

A : Ja, alle SD-WAN-Steuerungskomponenten (vManage, vSmart und vBond) müssen auf eine feste Softwareversion aktualisiert werden. Ein Upgrade nur einer Untergruppe von Controllern ist nicht ausreichend.

F: Ich habe ein Cloud-gehostetes SD-WAN-Overlay. Welche Upgrade-Optionen stehen zur Verfügung?

A : Für in der Cloud gehostete Overlays haben Kunden zwei Optionen:

1. Überprüfen Sie, ob für Ihre Umgebung ein automatisches Upgrade geplant ist, indem Sie zu SSP > Overlay Details > Change Windows navigieren.
2. Wenn Sie nicht auf das geplante Upgrade warten möchten, haben Sie zwei Möglichkeiten:
   • Die in diesem Dokument verfügbaren Upgrade-Leitfäden unterstützen Sie dabei.

   • Öffnen Sie ein Standby-TAC-Ticket für Ihr bevorzugtes Wartungsfenster. Das TAC steht Ihnen bei Problemen mit dem Upgrade zur Verfügung.

F: Müssen auch die Edge-Router aktualisiert werden?

A : Cisco IOS XE-Geräte sind von dieser Ankündigung nicht betroffen.

Frage: Wir sind ein von Cisco gehostetes Overlay. Müssen ACLs behoben oder Maßnahmen für SSP ergriffen werden?

A : Allen von Cisco gehosteten Kunden wird empfohlen, ihre eigenen zulässigen eingehenden Regeln für SSP zu überprüfen und sicherzustellen, dass nur die von Ihnen benötigten Präfixe zulässig sind. Diese Regeln gelten nur für den Managementzugriff und nicht für Edge-Router. Überprüfen Sie diese unter SSP > Overlay Details > Allow Inbound rules (Eingehende Regeln zulassen). Beachten Sie, dass die Ports 22 und 830 bei der Bereitstellung durch Cisco von außen für die in der Cloud gehosteten Controller am Tag 0 standardmäßig immer blockiert wurden.

F: Wir arbeiten mit CDCS/Shared Tenant. Auf welche Version wird das Upgrade durchgeführt? 

A : Basierend auf der aktuellen Version sind ein Upgrade der Shared Tenant- oder CDCS-Cluster derzeit geplant ODER ein Upgrade auf die festen Versionen ist bereits geplant. Die Shared Tenant- und CDCS Fixed-Versionen:

1. Early-Adopter-Cluster => 20.18.2.1 (entspricht der Standardversion)

2. Empfehlen Sie Release Cluster => 20.15.405 (CDCS-spezifische Version mit PSIRT Fixes)

CDCS-Kunden müssen keine wirksamen Maßnahmen ergreifen, um dieses PSIRT zu bewältigen.

F: Welche allgemeinen Best Practices oder Möglichkeiten zur Reduzierung von Schwachstellen in meinem SD-WAN-Overlay gibt es?

A : Im Cisco Catalyst SD-WAN Hardening Guide (Leitfaden zur Absicherung von SD-WAN) finden Sie Best Practices und Empfehlungen zur Verringerung von Schwachstellen in Ihrem SD-WAN-Overlay.

F: Wir sehen Protokolle von einem "root"-Benutzer auf unserem System.  Ist das Besorgnis erregend? 

A : Überprüfen Sie, was noch im System vor sich geht.   Diese Protokolle können vollständig erwartet werden.  Beispielsweise werden beim Generieren von admin-techs System-Login-Änderungsprotokolle eines "Root"-Benutzers angezeigt.  Protokolle können auch von einem "Root"-Benutzer während eines Neustarts angezeigt werden.  

Feb 28 23:03:44 Manager01 SYSMGR[863]: %Viptela-Manager01-sysmgrd-6-INFO-1400002: Notification: system-login-change severity-level:minor host-name:"Manager01" system-ip: user-name:"root" user-id:245  generated-at:2-28-2026T23:3:44
Feb 28 23:03:47 Manager01 SYSMGR[863]: %Viptela-Manager01-sysmgrd-6-INFO-1400002: Notification: system-login-change severity-level:minor host-name:"Manager01" system-ip: user-name:"root" user-id:248  generated-at:2-28-2026T23:3:47

F: Wir haben bereits ein Upgrade ohne Anzeichen für eine Kompromittierung durchgeführt. Was muss ich tun, nachdem die neuen IOCs am 17. März veröffentlicht wurden?

A : Die als fix aufgelistete Software schützt vor weiteren Versuchen, die in den beiden in diesem Artikel behandelten Ratgebern aufgeführten CVEs auszunutzen. Während ein Upgrade Schutz vor zukünftigen Exploits bietet, kann es noch Exploits geben, die vor dem Upgrade aufgetreten sind. Es wird empfohlen, dass Kunden den Self-Service "Check Bug Applicability" verwenden, der auf der Bug Search Tool-Seite für die Cisco Bug-ID CSCws52722 integriert ist, um admin-techs aus den Steuerungskomponenten erneut zu scannen. Bei Bedarf können Kunden ein TAC-Ticket erstellen und den in diesem Artikel beschriebenen Prozess wiederholen, um Admin-Techniker basierend auf den neuen IOCs erneut zu scannen. b

---

---