Cisco Applied Mitigation Bulletin-
Dieses "Applied Mitigation Bulletin" ist ein Begleitdokument zur PSIRT-Sicherheitsempfehlung Mehrere Schwachstellen in Cisco NX-OS-basierten Produkten und bietet Identifizierungs- und Mitigationstechniken, die Administratoren auf Cisco Netzwerkgeräten bereitstellen können. Sie gilt nur für SNMP-basierte Schwachstellen.
-
Buffer Overflow Vulnerability der Cisco NX-OS Software, SNMP und License Manager: Diese Schwachstelle kann per Remote-Zugriff mit Authentifizierung und ohne Benutzereingriff ausgenutzt werden. Eine erfolgreiche Ausnutzung dieser Schwachstelle könnte die Ausführung von beliebigem Code ermöglichen. Der Angriffsvektor zur Ausnutzung wird durch SNMP IPv4- und IPv6-Pakete über den UDP-Port 161 generiert. Ein Angreifer könnte diese Verwundbarkeit mit gefälschten Paketen ausnutzen.
Dieser Schwachstelle wurde die Common Vulnerabilities and Exposures (CVE)-ID CVE-2013-1179 zugewiesen.
SNMP-Buffer-Overflow-Schwachstelle der Cisco NX-OS Software: Diese Schwachstelle kann per Remote-Zugriff mit Authentifizierung und ohne Benutzereingriff ausgenutzt werden. Eine erfolgreiche Ausnutzung dieser Schwachstelle könnte die Ausführung von beliebigem Code ermöglichen. Der Angriffsvektor zur Ausnutzung wird durch SNMP IPv4- und IPv6-Pakete über den UDP-Port 161 generiert. Ein Angreifer könnte diese Verwundbarkeit mit gefälschten Paketen ausnutzen.
Dieser Schwachstelle wurde die Common Vulnerabilities and Exposures (CVE)-ID CVE-2013-1180 zugewiesen.
-
Informationen zu anfälliger, nicht betroffener und fest installierter Software finden Sie in der Cisco Security Advisory, die unter folgendem Link verfügbar ist: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130424-nxosmulti.
-
Die Cisco IOS Software bietet mithilfe der folgenden Methoden einen effektiven Schutz vor Exploits:
- InfrastrukturZugriffskontrolllisten (iACLs)
- Unicast Reverse Path Forwarding (URPF)
- IP Source Guard (IPSG)
Diese Schutzmechanismen filtern und löschen Pakete, die versuchen, diese Schwachstelle auszunutzen, und überprüfen die Quell-IP-Adresse von.
Die ordnungsgemäße Bereitstellung und Konfiguration von uRPF bietet einen effektiven Schutz vor Angriffen, bei denen Pakete mit gefälschten Quell-IP-Adressen verwendet werden. Unicast-RPF sollte so nahe wie möglich an allen Datenverkehrsquellen bereitgestellt werden.
Die ordnungsgemäße Bereitstellung und Konfiguration von IPSG bietet einen effektiven Schutz vor gefälschten Paketen auf der Zugriffsebene.
Die Cisco Adaptive Security Appliance der Serie ASA 5500 und das Firewall Services Module (FWSM) für Cisco Catalyst Switches der Serie 6500 bieten zudem folgende effektive Möglichkeiten zur Verhinderung von Exploits:
- tACL
- uRPF
Diese Schutzmechanismen filtern und löschen Pakete, die versuchen, diese Schwachstelle auszunutzen, und überprüfen die Quell-IP-Adresse von.
Cisco IOS NetFlow-Datensätze bieten Transparenz für netzwerkbasierte Exploit-Versuche.
Die Firewalls Cisco IOS Software, Cisco ASA und Cisco FWSM bieten Transparenz durch Syslog-Meldungen und Leistungsindikatorwerte, die in der Ausgabe von show-Befehlen angezeigt werden.
Der Cisco Security Manager bietet außerdem Transparenz für Vorfälle, Abfragen und Ereignisberichte.
-
Den Unternehmen wird empfohlen, die potenziellen Auswirkungen dieser Schwachstellen anhand ihrer Standardprozesse zur Risikobewertung und -minderung zu ermitteln. Triage bezieht sich auf das Sortieren von Projekten und die Priorisierung von Bemühungen, die am wahrscheinlichsten erfolgreich sein werden. Cisco hat Dokumente bereitgestellt, die Unternehmen bei der Entwicklung einer risikobasierten Triage-Funktion für ihre Informationssicherheitsteams unterstützen. Risikoanalyse für Ankündigungen zu Sicherheitslücken sowie Risikoanalyse und -prototyping unterstützen Unternehmen bei der Entwicklung wiederholbarer Sicherheitsevaluierungs- und Reaktionsprozesse.
-
Vorsicht: Die Effektivität jeglicher Eindämmungstechnik hängt von spezifischen Kundensituationen wie Produktmix, Netzwerktopologie, Datenverkehrsverhalten und organisatorischem Auftrag ab. Prüfen Sie wie bei jeder Konfigurationsänderung die Auswirkungen dieser Konfiguration, bevor Sie die Änderung übernehmen.
Spezifische Informationen zur Risikominderung und Identifizierung sind für diese Geräte verfügbar:
- Cisco IOS-Router und -Switches
- Cisco IOS NetFlow und Cisco IOS Flexible NetFlow
- Cisco ASA, Cisco ASASM und Cisco FWSM-Firewalls
Cisco IOS-Router und -Switches
Eindämmung: Infrastruktur-Zugriffskontrolllisten
Um Infrastrukturgeräte zu schützen und das Risiko, die Auswirkungen und die Effektivität direkter Angriffe auf die Infrastruktur zu minimieren, sollten Administratoren Infrastruktur-Zugriffskontrolllisten (iACLs) implementieren, um die Durchsetzung von Richtlinien für den an Infrastrukturgeräte gesendeten Datenverkehr zu ermöglichen. Administratoren können eine iACL erstellen, indem sie explizit zulassen, dass nur autorisierter Datenverkehr gemäß den bestehenden Sicherheitsrichtlinien und -konfigurationen an die Geräte der Infrastruktur gesendet wird. Um einen maximalen Schutz für Infrastrukturgeräte zu gewährleisten, sollten bereitgestellte iACLs in Eingangsrichtung auf alle Schnittstellen angewendet werden, für die eine IP-Adresse konfiguriert wurde. Eine iACL-Problemumgehung kann keinen vollständigen Schutz vor diesen Schwachstellen bieten, wenn der Angriff von einer vertrauenswürdigen Quelladresse ausgeht.
Die iACL-Richtlinie verweigert nicht autorisierte UDP IPv4- und IPv6-Pakete an UDP-Port 161, die an betroffene Geräte gesendet werden. Im folgenden Beispiel stellen 192.168.60.0/24 und 2001:DB8:1:60::/64 den IP-Adressraum dar, der von den betroffenen Geräten verwendet wird, und die Hosts unter 192.168.100.1 und 2001:DB8::100:1 gelten als vertrauenswürdige Quellen, die Zugriff auf die betroffenen Geräten. Es sollte darauf geachtet werden, dass der für das Routing und den Administratorzugriff erforderliche Datenverkehr zugelassen wird, bevor nicht autorisierter Datenverkehr abgelehnt wird.
Wenn möglich, sollte sich der Infrastruktur-Adressraum vom Adressraum unterscheiden, der für Benutzer- und Service-Segmente verwendet wird. Mit dieser Adressierungsmethode können Sie iACLs erstellen und bereitstellen.
Weitere Informationen zu iACLs finden Sie unter Protecting Your Core: Infrastructure Protection Access Control Lists (Schützen Ihres Kerns: Zugriffskontrolllisten für Infrastrukturschutz).
ip access-list extended Infrastructure-ACL-Policy ! !-- Include explicit permit statements for trusted sources !-- that require access on the vulnerable port ! permit udp host 192.168.100.1 192.168.60.0 0.0.0.255 eq 161 ! !-- The following vulnerability-specific access control entries !-- (ACEs) can aid in identification of attacks ! deny udp any 192.168.60.0 0.0.0.255 eq 161 ! !-- Explicit deny ACE for traffic sent to addresses configured within !-- the infrastructure address space ! deny ip any 192.168.60.0 0.0.0.255 ! !-- Permit or deny all other Layer 3 and Layer 4 traffic in accordance !-- with existing security policies and configurations ! ! !-- Create the corresponding IPv6 iACL ! ipv6 access-list IPv6-Infrastructure-ACL-Policy ! !-- Include explicit permit statements for trusted sources !-- that require access on the vulnerable protocols and ports ! permit udp host 2001:DB8::100:1 2001:DB8:1:60::/64 eq 161 ! !-- The following vulnerability-specific access control entries !-- (ACEs) can aid in identification of attacks to global and !-- link-local addresses ! deny udp any 2001:DB8:1:60::/64 eq 161 ! !-- Permit other required traffic to the infrastructure address !-- range and allow IPv6 neighbor discovery packets, which !-- include neighbor solicitation packets and neighbor !-- advertisement packets ! permit icmp any any nd-ns permit icmp any any nd-na ! !-- Explicit deny for all other IPv6 traffic to the global !-- infrastructure address range !
deny ipv6 any 2001:DB8:1:60::/64 ! !-- Permit or deny all other Layer 3 and Layer 4 traffic !-- in accordance with existing security policies and configurations ! ! !-- Apply iACLs to interfaces in the ingress direction ! interface GigabitEthernet0/0 ip access-group Infrastructure-ACL-Policy in ipv6 traffic-filter IPv6-Infrastructure-ACL-Policy inBeachten Sie, dass das Filtern mit einer Schnittstellenzugriffsliste die Übertragung von nicht erreichbaren ICMP-Nachrichten zurück an die Quelle des gefilterten Datenverkehrs auslöst. Das Generieren dieser Nachrichten könnte den unerwünschten Effekt einer erhöhten CPU-Auslastung auf dem Gerät haben. In Cisco IOS-Software ist nicht-erreichbare Generation ICMP auf ein Paket alle 500 Millisekunden standardmäßig begrenzt. Die Erzeugung von nicht erreichbaren ICMP-Nachrichten kann mit dem Schnittstellenkonfigurationsbefehl no ip unreachables und no ipv6 unreachables deaktiviert werden. Die Durchsatzbegrenzung "ICMP unreachable" kann mithilfe des globalen Konfigurationsbefehls ip icmp rate-limit unreachable interval-in-ms und ipv6 icmp error-interval-interval-in-ms vom Standard geändert werden.
Identifikation: Infrastruktur-Zugriffskontrolllisten
Nachdem der Administrator die iACL auf eine Schnittstelle angewendet hat, identifizieren die Befehle show ip access-lists und show ipv6 access-lists die Anzahl der SNMP-Pakete auf dem UDP-Port 161, die auf Schnittstellen gefiltert wurden, auf die die iACL angewendet wird. Administratoren sollten gefilterte Pakete untersuchen, um festzustellen, ob es sich dabei um Versuche handelt, diese Schwachstelle auszunutzen. Beispielausgabe für show ip access-lists Infrastructure-ACL-Policy und show ipv6 access-list IPv6-Infrastructure-ACL-Policy:
router#show ip access-lists Infrastructure-ACL-Policy Extended IP access list Infrastructure-ACL-Policy 10 permit udp host 192.168.100.1 192.168.60.0 0.0.0.255 eq 161 20 deny udp any 192.168.60.0 0.0.0.255 eq 161 (49 matches) 30 deny ip any 192.168.60.0 0.0.0.255 router#Im vorherigen Beispiel wurden 49 SNMP-Pakete vom UDP-Port 161 für die Zugriffskontrolllisteneintragszeile (ACE) 20 durch die Infrastruktur-ACL-Richtlinie der Zugriffsliste verworfen.
router#show ipv6 access-list IPv6-Infrastructure-ACL-Policy IPv6 access list IPv6-Infrastructure-ACL-Policy permit udp host 2001:DB8::100:1 2001:DB8:1:60::/64 eq 161 (512 matches) sequence 10 deny udp any 2001:DB8:1:60::/64 eq 161 (216 matches) sequence 20 permit icmp any any nd-ns (80 matches) sequence 30 permit icmp any any nd-na (80 matches) sequence 40 deny ipv6 any 2001:DB8:1:60::/64 (5 matches) sequence 50Im vorherigen Beispiel wurden 216 SNMP-Pakete vom UDP-Port 161 für die Zugriffskontrolllisteneintragszeile (ACE) 20 von der Zugriffsliste IPv6-Infrastructure-ACL-Policy verworfen.
Weitere Informationen zur Untersuchung von Vorfällen mithilfe von ACE-Zählern und Syslog-Ereignissen finden Sie im Whitepaper Identifying Incidents Using Firewall and IOS Router Syslog Events Cisco Security.
Administratoren können den Embedded Event Manager verwenden, um eine Instrumentierung bereitzustellen, wenn bestimmte Bedingungen erfüllt sind, z. B. ACE-Zählerzugriffe. Das Cisco Security Whitepaper Embedded Event Manager in a Security Context enthält weitere Informationen zur Verwendung dieser Funktion.
Identifizierung: Protokollierung der Zugriffsliste
Die Option log and log-input access control list (ACL) bewirkt, dass Pakete protokolliert werden, die bestimmten ACEs entsprechen. Die Option log-input ermöglicht die Protokollierung der Eingangsschnittstelle zusätzlich zu den IP-Adressen und -Ports für die Paketquelle und das Ziel.
Achtung: Die Protokollierung von Zugriffskontrolllisten kann sehr CPU-intensiv sein und muss mit äußerster Vorsicht verwendet werden. Faktoren, die die Auswirkungen der ACL-Protokollierung auf die CPU verstärken, sind die Protokollgenerierung, die Protokollübertragung und das Prozess-Switching für die Weiterleitung von Paketen, die mit protokollfähigen ACEs übereinstimmen.
Bei Cisco IOS-Software kann der Befehl ip access-list logging interval interval-in-ms die Auswirkungen des durch die ACL-Protokollierung induzierten Prozesswechsels begrenzen. Der Befehl logging rate-limit rate-per-second [except loglevel] begrenzt die Auswirkungen der Protokollgenerierung und -übertragung.
Die CPU-Auswirkungen der ACL-Protokollierung können mithilfe optimierter ACL-Protokollierung in der Hardware der Cisco Catalyst Switches der Serie 6500 und Cisco Router der Serie 7600 mit der Supervisor Engine 720 oder der Supervisor Engine 32 berücksichtigt werden.
Weitere Informationen zur Konfiguration und Verwendung der ACL-Protokollierung finden Sie im Whitepaper Understanding Access Control List Logging Cisco Security.
Eindämmung: Spoofing-Schutz
Die in diesem Dokument beschriebene Schwachstelle kann durch gefälschte IP-Pakete ausgenutzt werden. Administratoren können Unicast Reverse Path Forwarding (uRPF) als Schutzmechanismus gegen Spoofing bereitstellen und konfigurieren.
uRPF wird auf Schnittstellenebene konfiguriert und kann Pakete erkennen und verwerfen, denen eine verifizierbare Quell-IP-Adresse fehlt. Administratoren sollten sich nicht darauf verlassen, dass uRPF einen vollständigen Spoofing-Schutz bietet, da gefälschte Pakete über eine uRPF-fähige Schnittstelle in das Netzwerk gelangen können, wenn eine entsprechende Rückgaberoute zur Quell-IP-Adresse vorhanden ist. Den Administratoren wird empfohlen, während der Bereitstellung dieser Funktion sicherzustellen, dass der geeignete uRPF-Modus (flexibel oder strikt) konfiguriert wird, da legitimer Datenverkehr, der das Netzwerk durchquert, verworfen werden kann. In einer Unternehmensumgebung kann uRPF am Internet-Edge und auf der internen Zugriffsebene an den benutzerunterstützenden Layer-3-Schnittstellen aktiviert werden.
Weitere Informationen finden Sie im Funktionsleitfaden zur Unicast Reverse Path Forwarding Loose Mode.
Weitere Informationen zur Konfiguration und Verwendung von uRPF finden Sie im Cisco Security Whitepaper Understanding Unicast Reverse Path Forwarding.
Eindämmung: Spoofing-Schutz mit IP Source Guard
IP Source Guard (IPSG) ist eine Sicherheitsfunktion, die den IP-Datenverkehr an nicht gerouteten Layer-2-Schnittstellen beschränkt, indem Pakete auf Basis der DHCP-Snooping-Bindungsdatenbank und manuell konfigurierter IP-Source-Bindings gefiltert werden. Administratoren können IPSG verwenden, um Angriffe eines Angreifers zu verhindern, der versucht, Pakete durch Fälschung der Quell-IP-Adresse und/oder der MAC-Adresse zu fälschen. Bei ordnungsgemäßer Bereitstellung und Konfiguration bietet IPSG in Verbindung mit dem strengen Modus "uRPF" den effektivsten Spoofing-Schutz für die in diesem Dokument beschriebenen Schwachstellen.
Weitere Informationen zur Bereitstellung und Konfiguration von IPSG finden Sie unter Konfigurieren der DHCP-Funktionen und von IP Source Guard.
Identifizierung: Spoofing-Schutz mit Unicast Reverse Path Forwarding
Bei ordnungsgemäßer Bereitstellung und Konfiguration von uRPF in der gesamten Netzwerkinfrastruktur können Administratoren den internen Steckplatz/Port des Schnittstellentyps "show cef", die Befehle "show ip interface", "show cef drop", "show ip cef switching statistics" und "show ip traffic" verwenden, um die Anzahl der Pakete zu identifizieren, die uRPF verworfen hat.
Hinweis: Ab Version 12.4(20)T der Cisco IOS-Software wurde der Befehl show ip cef switching durch die Funktion show ip cef switching statistics ersetzt.
Hinweis: Der Befehl show | Regex starten und Befehl anzeigen | Includeregex-Befehlsmodifizierer werden in den folgenden Beispielen verwendet, um die Ausgabe zu minimieren, die Administratoren analysieren müssen, um die gewünschten Informationen anzuzeigen. Weitere Informationen zu Befehlsmodifizierern finden Sie in den Abschnitten show command in der Cisco IOS Configuration Fundamentals Command Reference.
router#show cef interface GigabitEthernet 0/0 internal | include drop ip verify: via=rx (allow default), acl=0, drop=18, sdrop=0 IPv6 unicast RPF: via=rx acl=None, drop=10, sdrop=0 router#
Hinweis: show cef interface type slot/port internal ist ein ausgeblendeter Befehl, der vollständig in die Kommandozeile eingegeben werden muss. Die Befehlsvervollständigung steht dafür nicht zur Verfügung.
router#show cef drop CEF Drop Statistics Slot Encap_fail Unresolved Unsupported No_route No_adj ChkSum_Err RP 27 0 0 18 0 0 router#
router#show ip interface GigabitEthernet 0/0 | begin verify IP verify source reachable-via RX, allow default, allow self-ping 18 verification drops 0 suppressed verification drops router#
router#show ipv6 interface GigabitEthernet 0/0 | section IPv6 verify IPv6 verify source reachable-via rx 0 verification drop(s) (process), 10 (CEF) 0 suppressed verification drop(s) (process), 0 (CEF) -- CLI Output Truncated -- router#router#show ip cef switching statistics feature IPv4 CEF input features: Path Feature Drop Consume Punt Punt2Host Gave route
RP PAS uRPF 18 0 0 0 0 Total 18 0 0 0 0 -- CLI Output Truncated -- router#router#show ipv6 cef switching statistics feature IPv6 CEF input features: Feature Drop Consume Punt Punt2Host Gave route RP LES Verify Unicast R 10 0 0 0 0 Total 10 0 0 0 0 -- CLI Output Truncated -- router#router#show ip traffic | include RPF 18 no route, 18 unicast RPF, 0 forced drop router#
router#show ipv6 traffic | include RPF 10 RPF drops, 0 RPF suppressed, 0 forced drop router#
Im vorherigen Beispiel zeigen cef-Schnittstellentyp Slot/Port intern, zeigen cef drop, zeigen ip-Schnittstellentyp Slot/Port und zeigen ipv6-Schnittstellentyp Slot/Port, zeigen ip cef-Switching-Statistik-Funktion und zeigen ipv6 cef-Switching-Statistik-Funktion, und zeigen ip-Verkehr und zeigenIPv6-Verkehr Beispiele, uRPF hat die folgenden empfangenen Pakete verworfen global an allen Schnittstellen mit uRPF konfiguriert, da die Quelladresse der IP-Pakete in der Weiterleitungsdatenbank von Cisco Express Forwarding nicht überprüft werden kann.
Cisco IOS NetFlow und Cisco IOS Flexible NetFlow
Identifikation: Identifikation des IPv4-Datenverkehrs mithilfe von NetFlow-Datensätzen
Administratoren können Cisco IOS NetFlow auf Cisco IOS-Routern und -Switches konfigurieren, um Datenverkehrsflüsse zu identifizieren, bei denen möglicherweise versucht wird, die Schwachstelle auszunutzen. Den Administratoren wird empfohlen, Datenflüsse zu untersuchen, um festzustellen, ob es sich dabei um Versuche handelt, die Schwachstelle auszunutzen, oder ob es sich um legitime Datenflüsse handelt.
router#show ip cache flow
IP packet size distribution (90784136 total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .000 .698 .011 .001 .004 .005 .000 .004 .000 .000 .003 .000 .000 .000 .000
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .000 .001 .256 .000 .010 .000 .000 .000 .000 .000 .000
IP Flow Switching Cache, 4456704 bytes 1885 active, 63651 inactive, 59960004 added 129803821 ager polls, 0 flow alloc failures Active flows timeout in 30 minutes Inactive flows timeout in 15 seconds IP Sub Flow Cache, 402056 bytes 0 active, 16384 inactive, 0 added, 0 added to flow 0 alloc failures, 0 force free 1 chunk, 1 chunk added last clearing of statistics never Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec) -------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow TCP-Telnet 11393421 2.8 1 48 3.1 0.0 1.4 TCP-FTP 236 0.0 12 66 0.0 1.8 4.8 TCP-FTPD 21 0.0 13726 1294 0.0 18.4 4.1 TCP-WWW 22282 0.0 21 1020 0.1 4.1 7.3 TCP-X 719 0.0 1 40 0.0 0.0 1.3 TCP-BGP 1 0.0 1 40 0.0 0.0 15.0 TCP-Frag 70399 0.0 1 688 0.0 0.0 22.7 TCP-other 47861004 11.8 1 211 18.9 0.0 1.3 UDP-DNS 582 0.0 4 73 0.0 3.4 15.4 UDP-NTP 287252 0.0 1 76 0.0 0.0 15.5 UDP-other 310347 0.0 2 230 0.1 0.6 15.9 ICMP 1614 0.0 3 61 0.0 19.8 15.5 IPv6INIP 15 0.0 1 1132 0.0 0.0 15.4 GRE 4 0.0 1 48 0.0 0.0 15.3 Total: 59957957 14.8 1 196 22.5 0.0 1.5
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts Gi0/0 192.168.10.201 Gi0/1 192.168.60.102 11 0984 00A1 1 Gi0/0 192.168.11.54 Gi0/1 192.168.60.158 11 0911 00A1 3 Gi0/1 192.168.150.60 Gi0/0 10.89.16.226 06 0016 12CA 1 Gi0/0 192.168.13.97 Gi0/1 192.168.60.28 11 0B3E 00A1 5 Gi0/0 192.168.10.17 Gi0/1 192.168.60.97 11 0B89 00A1 1 Gi0/0 10.88.226.1 Gi0/1 192.168.202.22 06 007B 007B 1 Gi0/0 192.168.12.185 Gi0/1 192.168.60.239 11 0BD7 00A1 1 Gi0/0 10.89.16.226 Gi0/1 192.168.150.60 06 12CA 0016 1 router#Im vorherigen Beispiel gibt es mehrere Datenflüsse für SNMP auf dem UDP-Port 161 (Hexadezimalwert 00A1).
Dieser Datenverkehr wird an Adressen im Adressblock 192.168.60.0/24 gesendet, der für Infrastrukturgeräte verwendet wird. Die Pakete in diesen Flows können gefälscht sein und einen Versuch anzeigen, diese Schwachstelle auszunutzen. Den Administratoren wird empfohlen, diese Datenflüsse mit der Basisauslastung für den SNMP-Datenverkehr zu vergleichen, der an UDP-Port 161 gesendet wird. Außerdem sollten sie die Flüsse untersuchen, um festzustellen, ob sie von nicht vertrauenswürdigen Hosts oder Netzwerken stammen.
Um nur die Datenverkehrsflüsse für SNMP-Pakete auf UDP-Port 161 (Hexadezimalwert 00A1) anzuzeigen, muss der Befehl show ip cache flow | include SrcIf|_11_.*00A1 zeigt die zugehörigen UDP NetFlow-Datensätze wie folgt an:
UDP-Datenflüsse
router#show ip cache flow | include SrcIf|_11_.*00A1 SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts Gi0/0 192.168.10.201 Gi0/1 192.168.60.102 11 0984 00A1 1 Gi0/0 192.168.11.54 Gi0/1 192.168.60.158 11 0911 00A1 3 Gi0/0 192.168.13.97 Gi0/1 192.168.60.28 11 0B3E 00A1 5 Gi0/0 192.168.10.17 Gi0/1 192.168.60.97 11 0B89 00A1 1 Gi0/0 192.168.12.185 Gi0/1 192.168.60.239 11 0BD7 00A1 1 router#
Identifikation: Identifikation des IPv6-Datenverkehrs mit Cisco IOS NetFlow
Administratoren können Cisco IOS NetFlow auf Cisco IOS-Routern und -Switches konfigurieren, um die Identifizierung von IPv6-Datenverkehrsflüssen zu unterstützen, bei denen möglicherweise versucht wird, die in diesem Dokument beschriebenen Schwachstellen auszunutzen. Den Administratoren wird empfohlen, Datenflüsse zu untersuchen, um festzustellen, ob es sich dabei um Versuche handelt, diese Schwachstellen auszunutzen, oder ob es sich um legitime Datenflüsse handelt.
Die folgende Ausgabe stammt von einem Cisco IOS-Gerät, auf dem die Cisco IOS Software 12.4 Mainline Train ausgeführt wird. Die Befehlssyntax variiert je nach Cisco IOS Software-Zügen.
router#show ipv6 flow cache IP packet size distribution (50078919 total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .000 .990 .001 .008 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 IP Flow Switching Cache, 475168 bytes 8 active, 4088 inactive, 6160 added 1092984 ager polls, 0 flow alloc failures Active flows timeout in 30 minutes Inactive flows timeout in 15 seconds IP Sub Flow Cache, 33928 bytes 16 active, 1008 inactive, 12320 added, 6160 added to flow 0 alloc failures, 0 force free 1 chunk, 1 chunk added SrcAddress InpIf DstAddress OutIf Prot SrcPrt DstPrt Packets 2001:DB...6A:5BA6 Gi0/0 2001:DB...28::21 Gi0/1 3A 0000 8000 1191 2001:DB...6A:5BA6 Gi0/0 2001:DB...134::3 Gi0/1 3A 0000 8000 1191 2001:DB...6A:5BA6 Gi0/0 2001:DB...128::4 Gi0/1 3A 0000 8000 1192 2001:DB...6A:5BA6 Gi0/0 2001:DB...128::2 Gi0/1 11 160A 00A1 1992 2001:DB...06::201 Gi0/0 2001:DB...128::3 Gi0/1 11 1619 00A1 1900 2001:DB...06::201 Gi0/0 2001:DB...128::4 Gi0/1 11 1714 00A1 1194 2001:DB...6A:5BA6 Gi0/0 2001:DB...128::3 Gi0/1 3A 0000 8000 1155 2001:DB...6A:5BA6 Gi0/0 2001:DB...146::3 Gi0/1 3A 0000 8000 1092 2001:DB...6A:5BA6 Gi0/0 2001:DB...144::4 Gi0/1 3A 0000 8000 1193Um die Anzeige der vollständigen 128-Bit-IPv6-Adresse zu ermöglichen, verwenden Sie den Befehl terminal width 132 exec mode.
Im vorherigen Beispiel gibt es mehrere IPv6-Flows für SNMP an UDP-Port 161 (Hexadezimalwert 00A1).
Die SNMP-Pakete auf dem UDP-Port 161 stammen von Adressen aus dem Adressblock 2001:DB8:1:60::/64, der von den betroffenen Geräten verwendet wird, und werden an diese gesendet. Die Pakete in den UDP-Flows können gefälscht werden und einen Versuch anzeigen, diese Schwachstellen auszunutzen. Den Administratoren wird empfohlen, diese Datenflüsse mit der Basisnutzung für den SNMP-Datenverkehr auf UDP-Port 161 zu vergleichen und zu untersuchen, ob sie von nicht vertrauenswürdigen Hosts oder Netzwerken stammen.
Um nur die SNMP-Pakete auf UDP-Port 161 (Hexadezimalwert 00A1) anzuzeigen, verwenden Sie den Befehl show ip cache flow. | include SrcIf|_11_.*00A1 command to display the related Cisco NetFlow records:
UDP-Datenflüsse
router#show ip cache flow | include SrcIf|_11_.*00A1 SrcAddress InpIf DstAddress OutIf Prot SrcPrt DstPrt Packets 2001:DB...06::201 Gi0/0 2001:DB...28::20 Local 0x11 0x16C1 0x00A1 1368 2001:DB...06::201 Gi0/0 2001:DB...128::3 Gi0/1 0x11 0x1629 0x00A1 1201 2001:DB...06::201 Gi0/0 2001:DB...128::4 Gi0/1 0x11 0x1644 0x00A1 1993 router#
Identifikation: Identifikation des IPv4-Datenverkehrs mithilfe von Cisco Flexible NetFlow
Cisco IOS Flexible NetFlow wurde in den Cisco IOS Software-Versionen 12.2(31)SB2 und 12.4(9)T eingeführt und verbessert die ursprüngliche Cisco NetFlow-Lösung, indem es die Möglichkeit bietet, die Parameter für die Datenverkehrsanalyse an die spezifischen Anforderungen des Administrators anzupassen. Original Cisco NetFlow verwendet feste sieben Tupel an IP-Informationen, um einen Datenfluss zu identifizieren. Cisco IOS Flexible NetFlow hingegen ermöglicht eine benutzerdefinierte Definition des Datenflusses. Sie vereinfacht die Erstellung komplexerer Konfigurationen für die Datenverkehrsanalyse und den Datenexport durch die Verwendung wiederverwendbarer Konfigurationskomponenten.
Die folgende Beispielausgabe stammt von einem Cisco IOS-Gerät, auf dem eine Version der Cisco IOS-Software im 15.1T-Zug ausgeführt wird. Obwohl die Syntax für die Züge 12.4T und 15.0 nahezu identisch sein wird, kann sie je nach verwendeter Cisco IOS-Version leicht variieren. In der folgenden Konfiguration erfasst Cisco IOS Flexible NetFlow Informationen über die Schnittstelle GigabitEthernet0/0 für eingehende IPv4-Datenflüsse basierend auf der Quell-IPv4-Adresse, wie in der Schlüsselfeldaussage match ipv4 source address definiert. Cisco IOS Flexible NetFlow umfasst außerdem nicht-wichtige Feldinformationen zu Quell- und Ziel-IPv4-Adressen, Protokollen, Ports (falls vorhanden), Eingangs- und Ausgangsschnittstellen und Paketen pro Datenfluss.
! !-- Configure key and nonkey fields !-- in the user-defined flow record ! flow record FLOW-RECORD-ipv4 match ipv4 source address collect ipv4 protocol collect ipv4 destination address collect transport source-port collect transport destination-port collect interface input collect interface output collect counter packets ! !-- Configure the flow monitor to !-- reference the user-defined flow !-- record ! flow monitor FLOW-MONITOR-ipv4 record FLOW-RECORD-ipv4 ! !-- Apply the flow monitor to the interface !-- in the ingress direction ! interface GigabitEthernet0/0 ip flow monitor FLOW-MONITOR-ipv4 input
Die Ausgabe des Cisco IOS Flexible NetFlow-Workflows lautet wie folgt:
router#show flow monitor FLOW-MONITOR-ipv4 cache format table Cache type: Normal Cache size: 4096 Current entries: 6 High Watermark: 1 Flows added: 9181 Flows aged: 9175 - Active timeout ( 1800 secs) 9000 - Inactive timeout ( 15 secs) 175 - Event aged 0 - Watermark aged 0 - Emergency aged 0 IPV4 SRC ADDR ipv4 dst addr trns src port trns dst port intf input intf output pkts ip prot ============== ============== ============= ============= ========== =========== ===== ======= 192.168.10.201 192.168.60.102 1456 80 Gi0/0 Gi0/1 1128 6 192.168.11.54 192.168.60.158 1216 161 Gi0/0 Gi0/1 1912 17 192.168.150.60 10.89.16.226 2567 443 Gi0/0 Gi0/1 13 6 192.168.13.97 192.168.60.28 3451 80 Gi0/0 Gi0/1 1 6 192.168.10.17 192.168.60.97 9439 161 Gi0/0 Gi0/1 546 17 10.88.226.1 192.168.202.22 2678 443 Gi0/0 Gi0/1 10567 6 10.89.16.226 192.168.150.60 3562 80 Gi0/0 Gi0/1 30012 6Um nur die SNMP-Pakete auf dem UDP-Port 161 anzuzeigen, verwenden Sie die Formattabelle show flow monitor FLOW-MONITOR-ipv4. | ipv4-dst-Adresse einfügen |_161_.*_17_, um zugehörige NetFlow-Datensätze anzuzeigen.
Weitere Informationen zu Cisco IOS Flexible NetFlow finden Sie im Flexible NetFlow-Konfigurationsleitfaden, Cisco IOS Release 15.1M&T und Cisco IOS Flexible NetFlow-Konfigurationsleitfaden, Version 12.4T.
Identifikation: Identifikation des IPv6-Datenverkehrs mithilfe von Cisco IOS Flexible NetFlow
Die folgende Beispielausgabe stammt von einem Cisco IOS-Gerät, auf dem eine Version der Cisco IOS-Software im 15.1T-Zug ausgeführt wird. Obwohl die Syntax für die Züge 12.4T und 15.0 nahezu identisch sein wird, kann sie je nach verwendeter Cisco IOS-Version leicht variieren. In der folgenden Konfiguration erfasst Cisco IOS Flexible NetFlow Informationen über die Schnittstelle GigabitEthernet0/0 für eingehende IPv6-Datenflüsse basierend auf der IPv6-Quelladresse, wie in der Schlüsselfeldanweisung match ipv6 source address definiert. Cisco IOS Flexible NetFlow bietet darüber hinaus Feldinformationen ohne Schlüssel zu Quell- und Ziel-IPv6-Adressen, Protokollen, Ports (falls vorhanden), Eingangs- und Ausgangsschnittstellen und Paketen pro Datenfluss.
! !-- Configure key and nonkey fields !-- in the user-defined flow record ! flow record FLOW-RECORD-ipv6 match ipv6 source address collect ipv6 protocol collect ipv6 destination address collect transport source-port collect transport destination-port collect interface input collect interface output collect counter packets ! !-- Configure the flow monitor to !-- reference the user-defined flow !-- record ! flow monitor FLOW-MONITOR-ipv6 record FLOW-RECORD-ipv6 ! !-- Apply the flow monitor to the interface !-- in the ingress direction ! interface GigabitEthernet0/0 ipv6 flow monitor FLOW-MONITOR-ipv6 input
Die Ausgabe des Cisco IOS Flexible NetFlow-Workflows lautet wie folgt:
router#show flow monitor FLOW-MONITOR-ipv6 cache format table Cache type: Normal Cache size: 4096 Current entries: 6 High Watermark: 2 Flows added: 539 Flows aged: 532 - Active timeout ( 1800 secs) 350 - Inactive timeout ( 15 secs) 182 - Event aged 0 - Watermark aged 0 - Emergency aged 0 IPV6 SRC ADDR ipv6 dst addr trns src port trns dst port intf input intf output pkts ip prot ================= ================ ============= ============= ========== =========== ===== ======= 2001:DB...06::201 2001:DB...28::20 123 123 Gi0/0 Gi0/0 17 17 2001:DB...06::201 2001:DB...28::20 4763 161 Gi0/0 Gi0/0 1241 17 2001:DB...06::201 2001:DB...28::20 5542 161 Gi0/0 Gi0/0 2100 17 2001:DB...06::201 2001:DB...28::20 9391 161 Gi0/0 Gi0/0 9123 17 2001:DB...06::201 2001:DB...28::20 2856 80 Gi0/0 Gi0/0 486 6 2001:DB...06::201 2001:DB...28::20 3012 53 Gi0/0 Gi0/0 1016 17 2001:DB...06::201 2001:DB...28::20 2477 53 Gi0/0 Gi0/0 1563 17Um die Anzeige der vollständigen 128-Bit-IPv6-Adresse zu ermöglichen, verwenden Sie den Befehl terminal width 132 exec mode.
Um nur das SNMP auf UDP-Port 161 anzuzeigen, verwenden Sie die Tabelle show flow monitor FLOW-MONITOR-ipv6 cache format | IPv6-dst-Adresse einfügen |_161_.*_17_, um die zugehörigen Cisco IOS Flexible NetFlow-Datensätze anzuzeigen.
Cisco ASA und FWSM-Firewalls
Eindämmung: Transit-Zugriffskontrolllisten
Um das Netzwerk vor Datenverkehr zu schützen, der am Eingangspunkt in das Netzwerk gelangt, z. B. Internetverbindungspunkte, Verbindungspunkte für Partner und Lieferanten oder VPN-Verbindungspunkte, sollten Administratoren tACLs bereitstellen, um die Richtlinien durchzusetzen. Administratoren können eine tACL erstellen, indem sie explizit zulassen, dass nur autorisierter Datenverkehr an den Eingangs-Access Points in das Netzwerk eindringt, oder indem sie autorisiertem Datenverkehr gestatten, das Netzwerk gemäß den bestehenden Sicherheitsrichtlinien und -konfigurationen zu passieren. Eine tACL-Problemumgehung kann keinen vollständigen Schutz vor dieser Schwachstelle bieten, wenn der Angriff von einer vertrauenswürdigen Quelladresse ausgeht.
Die tACL-Richtlinie verweigert nicht autorisierte IPv4- und IPv6-SNMP-Pakete auf dem UDP-Port 161, die an betroffene Geräte gesendet werden. Beachten Sie, dass die Blockierung des Zugriffs auf den UDP-Port 161 Geräte nicht vollständig schützt. Wenn SNMP mit permanenten Ports konfiguriert wurde, müssen diese konfigurierten Ports der iACL ebenfalls hinzugefügt werden. Im folgenden Beispiel stellen 192.168.60.0/24 und 2001:DB8:1:60::/64 den IP-Adressraum dar, der von den betroffenen Geräten verwendet wird, und die Hosts unter 192.168.100.1 und 2001:DB8::100:1 gelten als vertrauenswürdige Quellen, die Zugriff auf die betroffenen Geräten. Es sollte darauf geachtet werden, dass der für das Routing und den Administratorzugriff erforderliche Datenverkehr zugelassen wird, bevor nicht autorisierter Datenverkehr abgelehnt wird.
Weitere Informationen zu tACLs finden Sie in Transit Access Control Lists: Filtering at Your Edge.
! !-- Include explicit permit statements for trusted sources !-- that require access on the vulnerable port ! access-list tACL-Policy extended permit udp host 192.168.100.1 192.168.60.0 255.255.255.0 eq 161
! !-- The following vulnerability-specific access control entry !-- (ACE) can aid in identification of attacks ! access-list tACL-Policy extended deny udp any 192.168.60.0 255.255.255.0 eq 161
! !-- Permit or deny all other Layer 3 and Layer 4 traffic in accordance !-- with existing security policies and configurations ! !-- Explicit deny for all other IP traffic ! access-list tACL-Policy extended deny ip any any ! !-- Create the corresponding IPv6 tACL ! !-- Include explicit permit statements for trusted sources !-- that require access on the vulnerable protocols and ports ! ipv6 access-list IPv6-tACL-Policy permit udp host 2001:DB8::100:1 2001:db8:1:60::/64 eq 161 ! !-- The following vulnerability-specific access control entries !-- (ACEs) can aid in identification of attacks ! ipv6 access-list IPv6-tACL-Policy deny udp any 2001:db8:1:60::/64 eq 161 ! !-- Permit or deny all other Layer 3 and Layer 4 traffic in accordance !-- with existing security policies and configurations ! !-- Explicit deny for all other IP traffic ! ipv6 access-list IPv6-tACL-Policy deny ip any any ! !-- Apply tACLs to interfaces in the ingress direction ! access-group tACL-Policy in interface outside access-group IPv6-tACL-Policy in interface outside ! !-- Apply tACL to interface(s) in the ingress direction ! access-group tACL-Policy in interface outsideIdentifizierung: Transit-Zugriffskontrolllisten
Nachdem die tACL auf eine Schnittstelle angewendet wurde, können Administratoren mit dem Befehl show access-list die Anzahl der gefilterten SNMP-Pakete auf dem UDP-Port 161 identifizieren. Den Administratoren wird empfohlen, gefilterte Pakete zu untersuchen, um festzustellen, ob es sich dabei um Versuche handelt, diese Schwachstelle auszunutzen. Beispielausgabe für show access-list tACL-Policy und show access-list IPv6-tACL-Policy:
firewall#show access-list tACL-Policy access-list tACL-Policy; 3 elements access-list tACL-Policy line 1 extended permit udp host 192.168.100.1 192.168.60.0 255.255.255.0 eq 161 access-list tACL-Policy line 2 extended deny udp any 192.168.60.0 255.255.255.0 eq 161 (hitcnt=91) access-list tACL-Policy line 3 extended deny ip any any firewall#Im vorherigen Beispiel hat die Zugriffsliste tACL-Policy 91 SNMP-Pakete auf dem UDP-Port 161 für ACE-Leitung 2 verworfen.
firewall#show access-list IPv6-tACL-Policy ipv6 access-list IPv6-tACL-Policy; 3 elements; name hash: 0x566a4229 ipv6 access-list IPv6-tACL-Policy line 1 permit udp host 2001:db8:1:100::1 2001:db8:1:60::/64 eq 161 (hitcnt=124) ipv6 access-list IPv6-tACL-Policy line 2 deny udp any 2001:db8:1:60::/64 eq 161 (hitcnt=216) ipv6 access-list IPv6-tACL-Policy line 3 deny ip any any (hitcnt=27)Im vorherigen Beispiel hat die Zugriffsliste IPv6-tACL-Policy 216 SNMP-Pakete auf dem UDP-Port 161 verworfen, die von einem nicht vertrauenswürdigen Host oder Netzwerk empfangen wurden. Darüber hinaus kann die Syslog-Meldung 106023 nützliche Informationen bereitstellen, z. B. die Quell- und Ziel-IP-Adresse, die Quell- und Ziel-Port-Nummern und das IP-Protokoll für das abgelehnte Paket.
Eindämmung: Spoofing-Schutz mit Unicast Reverse Path Forwarding
Die in diesem Dokument beschriebene Schwachstelle kann durch gefälschte IP-Pakete ausgenutzt werden. Administratoren können uRPF als Spoofing-Schutzmechanismus bereitstellen und konfigurieren.
uRPF wird auf Schnittstellenebene konfiguriert und kann Pakete erkennen und verwerfen, denen eine verifizierbare Quell-IP-Adresse fehlt. Administratoren sollten sich nicht darauf verlassen, dass uRPF einen vollständigen Spoofing-Schutz bietet, da gefälschte Pakete über eine uRPF-fähige Schnittstelle in das Netzwerk gelangen können, wenn eine entsprechende Rückgaberoute zur Quell-IP-Adresse vorhanden ist. In einer Unternehmensumgebung kann uRPF am Internet-Edge und auf der internen Zugriffsebene der benutzerunterstützenden Layer-3-Schnittstellen aktiviert werden.
Weitere Informationen zur Konfiguration und Verwendung von uRPF finden Sie in der Cisco Security Appliance Command Reference for ip verify reverse path und im Cisco Security Whitepaper Understanding Unicast Reverse Path Forwarding.
Identifizierung: Firewall Access List, Syslog-Meldungen
Die Firewall-Syslog-Meldung 106023 wird für Pakete generiert, die von einem Zugriffskontrolleintrag (Access Control Entry, ACE) abgelehnt wurden, für die kein log-Schlüsselwort vorhanden ist. Weitere Informationen zu dieser Syslog-Meldung finden Sie in Cisco ASA 5500 Series System Log Message, 8.2 - 106023.
Informationen zur Konfiguration von Syslog für die Cisco Adaptive Security Appliance der Serie ASA 5500 finden Sie unter Überwachung - Konfigurieren der Protokollierung. Informationen zur Konfiguration von Syslog auf dem FWSM für Cisco Catalyst Switches der Serie 6500 und Cisco Router der Serie 7600 finden Sie im Monitoring the Firewall Services Module.
Im folgenden Beispiel zeigt die Protokollierung | grep regex extrahiert Syslog-Meldungen aus dem Protokollierungspuffer der Firewall. Diese Meldungen enthalten zusätzliche Informationen zu abgelehnten Paketen, die auf potenzielle Versuche hinweisen könnten, die in diesem Dokument beschriebene Schwachstelle auszunutzen. Es ist möglich, verschiedene reguläre Ausdrücke mit dem grep-Schlüsselwort zu verwenden, um nach bestimmten Daten in den protokollierten Nachrichten zu suchen.
Weitere Informationen zur Syntax regulärer Ausdrücke finden Sie unter Erstellen eines regulären Ausdrucks.
firewall#show logging | grep 106023 Apr 24 2013 00:12:15: %ASA-4-106023: Deny udp src outside:192.0.2.18/5934 dst inside:192.168.60.191/161 by access-group "tACL-Policy" Apr 24 2013 00:12:15: %ASA-4-106023: Deny udp src outside:192.0.2.200/5935 dst inside:192.168.60.33/161 by access-group "tACL-Policy" Apr 24 2013 00:12:15: %ASA-4-106023: Deny udp src outside:192.0.2.99/5936 dst inside:192.168.60.240/161 by access-group "tACL-Policy" Apr 24 2013 00:12:15: %ASA-4-106023: Deny udp src outside:192.0.2.100/5937 dst inside:192.168.60.115/161 by access-group "tACL-Policy" Apr 24 2013 00:12:15: %ASA-4-106023: Deny udp src outside:192.0.2.88/5938 dst inside:192.168.60.38/161 by access-group "tACL-Policy" Apr 24 2013 00:12:15: %ASA-4-106023: Deny udp src outside:192.0.2.175/5939 dst inside:192.168.60.250/161 by access-group "tACL-Policy" Apr 24 2013 00:12:15: %ASA-4-106023: Deny udp src outside:2001:db8:2::2:172/2951 dst inside:2001:db8:1:60::23/161 by access-group "IPv6-tACL-Policy" Apr 24 2013 00:12:15: %ASA-4-106023: Deny udp src outside:2001:db8:d::a85e:172/2952 dst inside:2001:db8:1:60::134/161 by access-group "IPv6-tACL-Policy" firewall#Im vorherigen Beispiel zeigen die für die tACL-tACL-Richtlinie protokollierten Meldungen potenziell gefälschte SNMP-Pakete für den UDP-Port 161 an, die an den den Infrastrukturgeräten zugewiesenen Adressblock gesendet wurden.
Weitere Informationen zu Syslog-Meldungen für ASA Security Appliances finden Sie in Cisco ASA 5500 Series System Log Messages, 8.2. Weitere Informationen zu Syslog-Meldungen für FWSM finden Sie in den Protokollnachrichten des Catalyst Switches der Serie 6500 und des Cisco Routers der Serie 7600, Protokollierungssystem für Firewall-Services-Module.
Weitere Informationen zur Untersuchung von Vorfällen mithilfe von Syslog-Ereignissen finden Sie im Cisco Security Whitepaper Identifying Incidents Using Firewall and IOS Router Syslog Events.
Identifizierung: Spoofing-Schutz mit Unicast Reverse Path Forwarding
Die Firewall-Syslog-Meldung 106021 wird für Pakete generiert, die von Unicast RPF abgelehnt wurden. Weitere Informationen zu dieser Syslog-Meldung finden Sie in Cisco ASA 5500 Series System Log Message, 8.2 - 106021.
Informationen zur Konfiguration von Syslog für die Cisco Adaptive Security Appliance der Serie ASA 5500 finden Sie unter Überwachung - Konfigurieren der Protokollierung. Informationen zur Konfiguration von Syslog auf dem FWSM für Cisco Catalyst Switches der Serie 6500 und Cisco Router der Serie 7600 finden Sie im Monitoring the Firewall Services Module.
Im folgenden Beispiel zeigt die Protokollierung | grep regex extrahiert Syslog-Meldungen aus dem Protokollierungspuffer der Firewall. Diese Meldungen enthalten zusätzliche Informationen zu abgelehnten Paketen, die auf potenzielle Versuche hinweisen könnten, die in diesem Dokument beschriebene Schwachstelle auszunutzen. Es ist möglich, verschiedene reguläre Ausdrücke mit dem grep-Schlüsselwort zu verwenden, um nach bestimmten Daten in den protokollierten Nachrichten zu suchen.
Weitere Informationen zur Syntax regulärer Ausdrücke finden Sie unter Erstellen eines regulären Ausdrucks.
firewall#show logging | grep 106021 Apr 24 2013 00:12:20: %ASA-1-106021: Deny UDP reverse path check from 192.168.60.1 to 192.168.60.100 on interface outside Apr 24 2013 00:12:20: %ASA-1-106021: Deny UDP reverse path check from 192.168.60.1 to 192.168.60.100 on interface outside Apr 24 2013 00:12:20: %ASA-1-106021: Deny TCP reverse path check from 192.168.60.1 to 192.168.60.100 on interface outsideDer Befehl show asp drop kann außerdem die Anzahl der Pakete identifizieren, die von der Unicast RPF-Funktion verworfen wurden, wie im folgenden Beispiel gezeigt:
firewall#show asp drop frame rpf-violated Reverse-path verify failed 11 firewall#
Im vorherigen Beispiel hat Unicast RPF 11 SNMP-Pakete verworfen, die an Schnittstellen mit konfigurierter Unicast RPF empfangen wurden. Fehlende Ausgabe zeigt an, dass die Unicast-RPF-Funktion der Firewall keine Pakete verworfen hat.
Weitere Informationen zum Debuggen von Paketen oder Verbindungen, die über einen beschleunigten Sicherheitspfad verworfen wurden, finden Sie unter Cisco Security Appliance Command Reference (Cisco Security Appliance-Befehlsreferenz) für show asp drop.
-
Dieses Dokument wird in der vorliegenden Form bereitgestellt und impliziert keine Garantie oder Gewährleistung, einschließlich der Gewährleistung der Marktgängigkeit oder Eignung für einen bestimmten Zweck. Die Nutzung der Informationen im Dokument oder den Materialien, die mit dem Dokument verknüpft sind, erfolgt auf Ihr eigenes Risiko. Cisco behält sich das Recht vor, dieses Dokument jederzeit zu ändern oder zu aktualisieren.
-
Weniger anzeigenVersion Beschreibung Abschnitt Datum 1 Erstveröffentlichung
24. April 2013, 16:14 Uhr GMT
-
Vollständige Informationen zur Meldung von Sicherheitslücken in Cisco Produkten, zum Erhalt von Unterstützung bei Sicherheitsvorfällen und zur Registrierung für den Erhalt von Sicherheitsinformationen von Cisco finden Sie auf der weltweiten Cisco Website unter https://sec.cloudapps.cisco.com/security/center/resources/security_vulnerability_policy.html. Dies beinhaltet Anweisungen für Presseanfragen bezüglich der Sicherheitshinweise von Cisco. Alle Cisco Sicherheitsankündigungen finden Sie unter http://www.cisco.com/go/psirt
-
Die Sicherheitslücke betrifft die folgenden Produktkombinationen.
Primäre Produkte Cisco Cisco NX-OS-Software Cisco Nexus 1000V Switch für VMware vSphere (Base, 4.0(4)SV1(1), 4.0(4)SV1(2), 4.0(4)SV1(3), 4.0(4)SV1(3a), 4.0(4)SV1(3b), 4.0(4)SV1(3c), 4 0,0(4)SV1(3d), 4,2(1)SV1(4), 4,2(1)SV1(4a), 4,2(1)SV1(4b)) | für Nexus Serie 3000 (Base, 5.0(3)U1(1), 5.0(3)U1(1a), 5.0(3)U1(1b), 5.0(3)U1(1d), 5.0(3)U1(2), 5.0(3)U1(2a), 5.0(3)U2 (1), 5.0(3)U2(2), 5.0(3)U2(2a), 5.0(3)U2(2b), 5.0(3)U2(2c), 5.0(3)U2(2d), 5.0(3)U3(1)) | für Nexus Serie 4000 (Base, 4.1(2)E1(1), 4.1(2)E1(1b), 4.1(2)E1(1d), 4.1(2)E1(1e), 4.1(2)E1(1f), 4.1(2)E1(1g)) | für Nexus Serie 5000 (Base, 4.0(0)N1(1a), 4.0(0)N1(2), 4.0(0)N1(2a), 4.0(1a)N1(1), 4.0(1a)N1(1a), 4.0(1a)N2(1), 4.0(1a) N2(1a), 4.1(3)N1(1), 4.1(3)N1(1a), 4.1(3)N2(1), 4.1(3)N2(1a), 4.2(1)N1(1), 4.2(1)N2(1), 4.2(1)N2(1a), 5.0(2) N1(1), 5.0(3)N1(1c), 5.0(2)N2(1), 5.0(2)N2(1a), 5.0(3)N2(1), 5.0(3)N2(2), 5.0(3)N2(2a), 5.0(3)N2(2b)) | für Nexus-Switches der Serie 7000 (Basis, 4.1.(2), 4.1.(3), 4.1.(4), 4.1.(5), 4.2.(2a), 4.2(3), 4.2(4), 4.2(6), 5.0(2a), 5.0(3), 5.0(5), 5.1(1), 5.1(1a), 5.1(3), 5.1(4), 5.1(5), 5.1(6), 5.2(1), 5.2(3a), 5.2(4), 6.0(1), 6.0(2), 6.0(3), 6.0(4) Cisco MDS 9000 NX-OS-Software 4.1 (Basis, 1b, 1c, 3a) | 4.2 (Basis, (1a), (1b), (3), (3a), (5), (7a), (7b), (7d), (7e) | 5,0 (Basis, (1a), (4), (4b), (4c), (4d), (7)) | 5.2 (Basis, (1), (2), (2a), (2d)) Cisco Unified Computing System (Managed) 1,0 (Basis, 2.000) | 1,1 (Basis, 1 m) | 1,2 (Basis, 1 d) | 1,3 (Basis, (1c), (1m), (1n), (1o), (1p), (1q), (1t), (1w), (1y)) | 1.4 (Basis, (1i), (1j), (1m), (3i), (3l), (3m), (3q), (3s), (3u), (3y), (4f), (4g), (4i), (4j), (4k)) | 2,0 (Basis, (1m), (1q), (1s), (1t), (1w), (1x)) Cisco CG-OS CG1 (4, 5) | CG3 (1), (2), (3)
Zugehörige Produkte
-
Dieses Dokument wird in der vorliegenden Form bereitgestellt und impliziert keine Garantie oder Gewährleistung, einschließlich der Gewährleistung der Marktgängigkeit oder Eignung für einen bestimmten Zweck. Die Nutzung der Informationen im Dokument oder den Materialien, die mit dem Dokument verknüpft sind, erfolgt auf Ihr eigenes Risiko. CISCO BEHÄLT SICH DAS RECHT VOR, WARNUNGEN JEDERZEIT ZU ÄNDERN ODER ZU AKTUALISIEREN.
Eine eigenständige Kopie oder Umschreibung des Texts in diesem Dokument, die die Verteilungs-URL auslässt, ist eine unkontrollierte Kopie und enthält möglicherweise keine wichtigen Informationen oder sachliche Fehler. Die Informationen in diesem Dokument sind für Endbenutzer von Cisco Produkten bestimmt.