Cisco Applied Mitigation Bulletin-
Dieses "Applied Mitigation Bulletin" ist ein Begleitdokument zum PSIRT Security Advisory für Cisco Unified IP-Telefone Local Kernel System Call Input Validation Vulnerability und bietet Identifizierungs- und Mitigationstechniken, die Administratoren auf Cisco Netzwerkgeräten bereitstellen können.
-
Die Cisco Unified IP-Telefone der Serie 7900, auch Cisco TNP-Telefone genannt, weisen eine Schwachstelle bei der Eingangsvalidierung auf. Diese Schwachstelle ist darauf zurückzuführen, dass Eingaben, die an Kernel-Systemaufrufe von Anwendungen weitergeleitet werden, die im Benutzerbereich laufen, nicht ordnungsgemäß validiert wurden. Ein solcher Angriff würde aus einem unprivilegierten Kontext stammen. Ein Angreifer könnte dieses Problem ausnutzen, indem er lokalen Zugriff über den AUX-Port auf der Rückseite des Geräts erhält oder indem er sich beim Gerät über SSH authentifiziert und eine von einem Angreifer gesteuerte Binärdatei ausführt, die das Problem ausnutzen soll. Die SSH-Methode ist auf dem Gerät standardmäßig deaktiviert, sobald es von einem Cisco Unified Call Manager bereitgestellt wurde.
Die Angriffsvektoren werden über die lokale Konsole und Pakete mit den folgenden Protokollen und Ports ausgeführt:
- SSH mit TCP-Port 22
- TFTP mit zufälligen UDP-Ports größer als 1023
Dieser Schwachstelle wurde die Common Vulnerabilities and Exposures (CVE)-ID CVE-2012-5445 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-20130109-uipphone.
-
Cisco Geräte bieten verschiedene Gegenmaßnahmen für diese Schwachstelle. Den Administratoren wird empfohlen, diese Schutzmethoden als allgemeine Best Practices für die Sicherheit von Infrastrukturgeräten und des Datenverkehrs im Netzwerk zu betrachten. Dieser Abschnitt des Dokuments bietet einen Überblick über diese Techniken.
Bei der Risikobewertung und -minimierung eines Unternehmens können die folgenden Aspekte der in diesem Dokument beschriebenen Schwachstelle berücksichtigt werden:- Um erfolgreich zu sein, muss die SSH-Authentifizierung über das Netzwerk oder den AUX-Port auf der Rückseite des Geräts erfolgen.
- SSH ist deaktiviert, sobald das Cisco Unified IP-Telefon bereitgestellt wurde.
- Nach erfolgreicher Authentifizierung des Telefons muss der Angreifer versuchen, das Telefon zu zwingen, eine schädliche, nicht signierte Binärdatei herunterzuladen, indem er die IP-Adresse des legitimen TFTP-Servers manipuliert.
- Cisco Unified Communications Manager 8.0.1 und höher signiert standardmäßig Konfigurationsdateien, die über TFTP an Telefone gesendet werden, und unterstützt Verschlüsselungssicherheit für Konfigurationsdateien für Telefone. Das Signieren und die Verschlüsselung von Gerätekonfigurationsdateien verhindern Manipulationen oder den Austausch der Dateien durch Spoofing eines TFTP-Servers oder einer Serverantwort, da die kryptografische Signatur überprüft wird, bevor die Dateien von einem Gerät verwendet werden.
Cisco Unified Communications Manager bietet einen effektiven Exploit-Schutz mit den folgenden Methoden:
- Deaktivieren Sie den Cisco Unified IP-Telefon SSH-Server.
- Konfiguration verschlüsselter Telefonkonfigurationsdateien
Diese Schutzmechanismen verhindern den Konsolenzugriff und überprüfen die Integrität und Gültigkeit von Konfigurationsdateien, die auf den Telefonen ausgeführt werden sollen.
Die Cisco IOS Software bietet mithilfe der folgenden Methoden einen effektiven Schutz vor Exploits:
- Infrastruktur-Zugriffslisten (iACLs)
- VLAN-Zugriffslisten (vACLs)
- Unicast Reverse Path Forwarding (URPF)
- DHCP-Snooping
- Dynamic ARP Inspection (DAI)
- IP-Quellschutz
- 802.1x
Diese Schutzmechanismen filtern und löschen und überprüfen die Quell-MAC- und IP-Adressen von Paketen, die versuchen, diese Schwachstelle auszunutzen.
Die ordnungsgemäße Bereitstellung und Konfiguration von uRPF bietet einen effektiven Schutz vor Angriffen, die Pakete mit gefälschten Quell-IP-Adressen verwenden. uRPF sollte so nahe wie möglich an allen Datenverkehrsquellen bereitgestellt werden.
Die ordnungsgemäße Bereitstellung und Konfiguration von DAI bietet einen effektiven Schutz vor Spoofing-Angriffen auf Layer 2. Für die Bereitstellung von DAI ist die Implementierung von DHCP-Snooping erforderlich. DAI löscht alle ARP-Pakete mit ungültigen IP-MAC-Adressbindungen.
Die ordnungsgemäße Bereitstellung und Konfiguration von IPSG bietet einen effektiven Schutz vor Spoofing-Angriffen auf der Zugriffsebene.
Die Cisco Adaptive Security Appliance der Serie ASA 5500, das Cisco Catalyst ASA Services Module (ASASM) der Serie 6500 und das Firewall Services Module (FWSM) für Cisco Catalyst Switches der Serie 6500 und Cisco Router der Serie 7600 bieten ebenfalls eine effektive Exploit-Abwehr. Dazu werden folgende Funktionen verwendet:
- Transit-Zugriffskontrolllisten (tACLs)
- Unicast Reverse Path Forwarding (URPF)
Diese Schutzmechanismen filtern und löschen Pakete, die versuchen, diese Schwachstelle auszunutzen, und überprüfen die Quell-IP-Adresse von.
-
Den Unternehmen wird empfohlen, die potenziellen Auswirkungen dieser Schwachstelle 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 Unified Communications Manager
- Cisco IOS-Router und -Switches
- Cisco IOS NetFlow und Cisco IOS Flexible NetFlow
- Cisco ASA, Cisco ASASM und Cisco FWSM-Firewalls
- Cisco Security Manager
Cisco Unified Communications Manager
Die Sicherung der Komponenten in einem Cisco Unified Communication System ist erforderlich, um die Integrität und Vertraulichkeit von Sprachanrufen zu schützen. Speziell für die Unified Communications-Technologie und das Sprachnetzwerk stehen Sicherheitsrichtlinien zur Verfügung, die Administratoren dabei unterstützen, ihre Cisco Unified Communications-Systeme besser zu schützen. Zu diesen Ressourcen gehören:
- Cisco Unified Communications System 9.x SRND - Unified Communications Security
- Cisco Unified Communications Manager Sicherheitsleitfaden, Version 8.6(1)
- Cisco IP-Telefonzertifikate und sichere Kommunikation
In Cisco Unified Communications Manager stehen spezifische Einstellungen zur Verfügung, um die in diesem Dokument beschriebene Schwachstelle zu beheben. Die Einstellungen werden nachfolgend erläutert.
Eindämmung: Deaktivieren Sie den PC-Port des Cisco Unified IP-Telefons.
Um nicht autorisierten Zugriff auf das Unternehmensnetzwerk zu verhindern, wird den Administratoren empfohlen, den PC-Port in der Lobby, im Konferenzraum und in anderen physisch nicht gesicherten Cisco Unified IP-Telefonen zu deaktivieren. Administratoren können die folgenden Schritte ausführen, um den PC-Port zu deaktivieren:
Schritt 1: Wählen Sie in der Cisco Unified Communications Manager-Verwaltungsoberfläche Device > Phone (Gerät > Telefon).
Schritt 2: Listen Sie die Telefone auf, für die der PC-Port mithilfe der entsprechenden Suchkriterien deaktiviert werden soll, und wählen Sie Suchen.
Schritt 3: Wählen Sie den Gerätenamen aus, um das Fenster "Phone Configuration" zu öffnen.
Schritt 4: Suchen Sie nach dem produktspezifischen Parameter PC Port
Schritt 5: Wählen Sie in der Dropdown-Liste für den PC Port-Parameter Disabled (Deaktiviert) aus.
Schritt 6: Wählen Sie Speichern
Schritt 7: Wählen Sie Zurücksetzen
Weitere Informationen zum Deaktivieren des PC-Ports auf Cisco Unified IP-Telefonen finden Sie im Dokument Disabling the PC Port Setting (Deaktivieren der PC-Porteinstellung) im Cisco Unified Communications Manager Security Guide (Cisco Unified Communications Manager Sicherheitsleitfaden).
Eindämmung: Deaktivieren Sie den Cisco Unified IP Phone SSH-Server.
Standardmäßig ist der SSH-Server des Cisco Unified IP-Telefons deaktiviert. Diese Einstellung sollte überprüft werden, um zu verhindern, dass der Remote-Zugriff versucht, die in diesem Dokument beschriebene Schwachstelle auszunutzen. Administratoren können folgende Schritte durchführen, um die Einstellung zu überprüfen:
Schritt 1: Wählen Sie in der Cisco Unified Communications Manager-Verwaltungsoberfläche Device > Phone (Gerät > Telefon).
Schritt 2: Listen Sie die Telefone auf, die anhand der entsprechenden Suchkriterien überprüft werden sollen, und wählen Sie Suchen.
Schritt 3: Wählen Sie den Gerätenamen aus, um das Fenster "Phone Configuration" zu öffnen.
Schritt 4: Suchen nach dem produktspezifischen Parameter SSH Access
Schritt 5: Vergewissern Sie sich, dass in der Dropdown-Liste für den SSH-Zugriffsparameter die Option Deaktiviert ausgewählt ist.
Weitere Informationen zum Deaktivieren des SSH-Servers auf Cisco Unified IP-Telefonen finden Sie im Dokument Enabling and Disabling SSH (Aktivieren und Deaktivieren von SSH) im Abschnitt Cisco Unified IP Phone 8961, 9951 and 9971 Administration Guide for Cisco Unified Communications Manager (Administratoranleitung für Cisco Unified Communications Manager).
Risikominderung: Konfigurieren verschlüsselter Telefonkonfigurationsdateien
Administratoren müssen die Verschlüsselung der Konfigurationsdatei für das Cisco Unified IP-Telefon konfigurieren, um den Datenschutz zu gewährleisten. Die Konfigurationsdateien werden vom Unified Communications Manager-TFTP-Server heruntergeladen. Die Konfiguration der Verschlüsselung verringert zudem die in diesem Dokument beschriebene Schwachstelle, da Konfigurationsdateien, die nicht verschlüsselt, digital signiert und von einer authentifizierten Quelle empfangen wurden, ignoriert und verworfen werden.
Cisco Unified Communications Manager ab Version 8.0(1) bietet die Möglichkeit, Telefonkonfigurationsdateien zu signieren und unterstützt standardmäßig die Verschlüsselung von Telefonkonfigurationsdateien. Weitere Informationen zu den Standardfunktionen von Sicherheit finden Sie im Abschnitt Sicherheit durch Standard des Cisco Unified Communications Manager Security Guide-Dokuments.
Die Schritte zum Konfigurieren verschlüsselter Konfigurationsdateien für Telefone werden in der Verschlüsselungskonfigurationscheckliste vollständig beschrieben. Weitere Informationen zu verschlüsselten Telefonkonfigurationsdateien finden Sie im Dokument Configuring Encrypted Phone Configuration Files and Configuring a Phone Security Profile im Abschnitt Cisco Unified Communications Manager Security Guide.
Administratoren können die folgenden Schritte durchführen, um verschlüsselte Konfigurationsdateien für Telefone zu überprüfen:
Schritt 1: Wählen Sie in der Cisco Unified Communications Manager-Verwaltungsoberfläche System > Security Profile > Phone Security Profile aus.
Schritt 2: Geben Sie Suchkriterien ein, um den entsprechenden Datensatz in der Datenbank zu suchen, und wählen Sie Suchen aus.
Schritt 3: Wählen Sie den zu überprüfenden Datensatz aus.
Schritt 4: Suchen Sie nach dem Sicherheitsprofilparameter für die TFTP-verschlüsselte Konfiguration.
Schritt 5: Vergewissern Sie sich, dass das Kontrollkästchen für den Parameter für die TFTP-verschlüsselte Konfiguration aktiviert ist.
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 dieser Schwachstelle bieten, wenn der Angriff von einer vertrauenswürdigen Quelladresse ausgeht.
Die VLAN-Technologie von Cisco trennt das physische Netzwerk in mehrere logische Netzwerke. Aus den folgenden Gründen werden separate Sprach- und Daten-VLANs empfohlen:
- Schutz von Räumlichkeiten und Sprachgeräten durch externe Netzwerke Die private Adressierung von Telefonen im Sprach- oder Hilfs-VLAN gewährleistet die Adresserhaltung und den direkten Zugriff auf Telefone über öffentliche Netzwerke. PCs und Server werden in der Regel mit öffentlich gerouteten Subnetzadressen adressiert. Die Adressierung von Sprachendpunkten kann jedoch auch mit privaten RFC 1918-Subnetzadressen erfolgen.
- Erweiterung der Vertrauensgrenze für Quality of Service (QoS) auf Sprachgeräte Cisco Switches können IP-Telefone mithilfe des Cisco Discovery Protocol erkennen und die QoS-Vertrauenswürdigkeit automatisch dynamisch auf den Telefon-Port erweitern.
- Schutz vor böswilligen Netzwerkangriffen VLAN-Zugriffskontrolle, 802.1Q- und 802.1p-Tagging bietet Schutz für Sprachgeräte vor schädlichen internen und externen Netzwerkangriffen wie Würmern, Denial-of-Service-Angriffen (DoS) und Versuchen von Datengeräten, über Paket-Tagging Zugriff auf Prioritätswarteschlangen zu erhalten.
- Einfache Verwaltung und Konfiguration Separate VLANs für Sprach- und Datengeräte auf Zugriffsebene vereinfachen das Management und die QoS-Konfiguration.
In den folgenden iACL-Beispielen verweigern die Zugriffslisten Infrastructure-ACLdata-Policy und IPv6-Infrastructure-ACLdata-Policy nicht autorisierte SSH IPv4- und IPv6-Pakete auf dem TCP-Port 22 sowie TFTP IPv4- und IPv6-Pakete auf UDP-Ports über 1023, die vom Datennetzwerk an betroffene Geräte gesendet werden im Sprachnetzwerk. Die Zugriffslisten Infrastructure-ACLvoice-Policy und IPv6-Infrastructure-ACLvoice-Policy verweigern nicht autorisierte RTP-IPv4- und IPv6-Pakete an UDP-Ports über 1023, die von betroffenen Geräten im Sprachnetzwerk an das Datennetzwerk gesendet werden können, um Sprachkommunikation auszufiltern. 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 im Sprachnetzwerk verwendet wird, und die Schnittstelle GigabitEthernet0/0 ist die Schnittstelle zur Datennetzwerkseite eines Routers, der zwischen den Daten- und Sprachnetzwerken bereitgestellt wird. Die Schnittstelle GigabitEthernet0/1 ist die Schnittstelle zur Sprachnetzwerkseite des Routers, der zwischen dem Daten- und Sprachnetzwerk bereitgestellt wird. 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-ACLdata-Policy ! !-- Include explicit permit statements for trusted sources !-- that require access on the vulnerable protocols and ports !-- This includes softphones, web access to the phone (if allowed), !-- the Attendant Console or other applications communication end-points !-- that need access to the voice VLAN subnets ! permit tcp host 192.168.100.1 192.168.60.0 0.0.0.255 eq 22 permit udp host 192.168.100.1 gt 1023 192.168.60.0 0.0.0.255 gt 1023 ! !-- The following vulnerability-specific access control entries !-- (ACEs) can aid in identification of attacks ! deny tcp any 192.168.60.0 0.0.0.255 eq 22 deny udp any 192.168.60.0 0.0.0.255 gt 1023 ! !-- 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-ACLdata-Policy ! !-- Include explicit permit statements for trusted sources !-- that require access on the vulnerable protocols and ports !-- This includes softphones, web access to the phone (if allowed), !-- the Attendant Console or other applications communication end-points !-- that need access to the voice VLAN subnets ! permit tcp host 2001:DB8::100:1 2001:DB8:1:60::/64 eq 22 permit udp host 2001:DB8::100:1 gt 1023 2001:DB8:1:60::/64 gt 1023 ! !-- The following vulnerability-specific access control entries !-- (ACEs) can aid in identification of attacks to global and !-- link-local addresses ! deny tcp any 2001:DB8:1:60::/64 eq 22 deny udp any gt 1023 2001:DB8:1:60::/64 gt 1023 ! !-- 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-ACLdata-Policy in ipv6 traffic-filter IPv6-Infrastructure-ACLdata-Policy inip access-list extended Infrastructure-ACLvoice-Policy ! !-- Include explicit permit statements for trusted sources !-- that require access on the vulnerable protocols and ports !-- This includes softphones, web access to the phone (if allowed), !-- the Attendant Console or other applications communication end-points !-- that need access to the voice VLAN subnets ! permit udp 192.168.60.0 0 0.0.0.255 gt 1023 host 192.168.100.1 gt 1023 ! !-- The following vulnerability-specific access control entries !-- (ACEs) can aid in identification of attacks ! deny udp 192.168.60.0 0.0.0.255 gt 1023 any gt 1023 ! ! !-- 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-ACLvoice-Policy ! !-- Include explicit permit statements for trusted sources !-- that require access on the vulnerable protocols and ports !-- This includes softphones, web access to the phone (if allowed), !-- the Attendant Console or other applications communication end-points !-- that need access to the voice VLAN subnets ! permit udp 2001:DB8:60::/64 gt 1023 2001:DB8::100::1 gt 1023 ! !-- The following vulnerability-specific access control entries !-- (ACEs) can aid in identification of attacks to global and !-- link-local addresses ! deny udp 2001:DB8::60::/64 gt 1023 any gt 1023 ! !-- 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 ! !-- 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/1 ip access-group Infrastructure-ACLvoice-Policy in ipv6 traffic-filter IPv6-Infrastructure-ACLvoice-Policy in
Identifikation: Infrastruktur-Zugriffskontrolllisten
Nachdem der Administrator die iACL auf eine Schnittstelle angewendet hat, identifiziert der Befehl show ip access-lists die Anzahl der SSH-Pakete auf dem TCP-Port 22 und der TFTP-Pakete auf UDP-Ports mit mehr als 1023, 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 Infrastruktur-ACLdata-Policy:
router#show ip access-lists Infrastructure-ACLdata-Policy Extended IP access list Infrastructure-ACLdata-Policy 10 permit tcp host 192.168.100.1 192.168.60.0 0.0.0.255 eq 22 20 permit udp host 192.168.100.1 gt 1023 192.168.60.0 0.0.0.255 gt 1023 30 deny tcp any 192.168.60.0 0.0.0.255 eq 22 (11 matches) 40 deny udp any gt 1023 192.168.60.0 0.0.0.255 gt 1023 (43 matches) 50 deny ip any 192.168.60.0 0.0.0.255
router#Im vorherigen Beispiel hat access list Infrastructure-ACLdata-Policy 11 SSH-Pakete auf TCP-Port 22 für Zugriffskontrolllisteneintrag (ACE) 30 und 43 TFTP-Pakete auf UDP-Ports größer als 1023 für Zugriffskontrolllisteneintrag (ACE) Zeile 40 verworfen.
Nachdem der Administrator die iACL auf eine Schnittstelle angewendet hat, identifiziert der Befehl show ipv6 access-list IPv6-Infrastructure-ACLdata-Policy die Anzahl der SSH-Pakete auf dem TCP-Port 22 und der TFTP-Pakete auf UDP-Ports mit mehr als 1023, die auf Schnittstellen gefiltert wurden, auf die die iACL angewendet wurde. Administratoren sollten gefilterte Pakete untersuchen, um festzustellen, ob es sich dabei um Versuche handelt, diese Schwachstelle auszunutzen. Beispielausgabe für show ip access-lists IPv6-Infrastructure-ACLdata-Policy:
router#show ipv6 access-list IPv6-Infrastructure-ACLdata-Policy IPv6 access list IPv6-Infrastructure-ACLdata-Policy permit tcp host 2001:DB8::100:1 2001:DB8:1:60::/64 eq 22 sequence 10 permit udp host 2001:DB8::100:1 gt 1023 2001:DB8:1:60::/64 gt 1023 sequence 20 deny tcp any 2001:DB8:1:60::/64 eq 22 (1240 matches) sequence 30 deny udp any gt 1023 2001:DB8:1:60::/64 gt 1023 (740 matches) sequence 40 permit icmp any any nd-ns sequence 50 permit icmp any any nd-na sequence 60 deny ipv6 any 2001:DB8:1:60::/64 sequence 70 router#Im vorherigen Beispiel hat die Zugriffsliste IPv6-Infrastructure-ACL-Policy die folgenden Pakete verworfen, die von einem nicht vertrauenswürdigen Host oder Netzwerk empfangen wurden:
- 1.240 IPv6 SSH-Pakete auf TCP-Port 22 für ACE-Leitung 30
- 740 IPv6 TFTP-Pakete an UDP-Ports größer als 1023 für ACE-Leitung 40
Nachdem der Administrator die iACL auf eine Schnittstelle angewendet hat, identifiziert der Befehl show ip access-lists die Anzahl der RTP-Pakete auf UDP-Ports, die größer als 1023 sind und 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-ACLvoice-Policy:
router#show ip access-lists Infrastructure-ACLvoice-Policy Extended IP access list Infrastructure-ACL-Policy 10 permit udp 192.168.60.0 0 0.0.0.255 gt 1023 host 192.168.100.1 gt 1023 20 deny udp 192.168.60.0 0.0.0.255 gt 1023 any gt 1023 (87 matches)
30 deny ip any 192.168.60.0 0.0.0.255
router#Im vorherigen Beispiel wurden 87 RTP-Pakete an UDP-Ports, die größer als 1023 sind, für die Zugriffskontrolllisteneingangsleitung (ACE) 20 verworfen.
Nachdem der Administrator die iACL auf eine Schnittstelle angewendet hat, identifiziert der Befehl show ipv6 access-lists die Anzahl der RTP-Pakete auf UDP-Ports, die größer als 1023 sind und 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 ipv6 access-list IPv6-Infrastructure-ACLvoice-Policy:
router#show ipv6 access-list IPv6-Infrastructure-ACLvoice-Policy IPv6 access list IPv6-Infrastructure-ACLvoice-Policy permit udp 2001:DB8:60::/64 gt 1023 2001:DB8::100::1 gt 1023 sequence 10 deny udp 2001:DB8::60::/64 gt 1023 any gt 1023 (52 matches) sequence 20 permit icmp any any nd-ns sequence 30 permit icmp any any nd-na sequence 40 deny ipv6 any 2001:DB8:1:60::/64 sequence 50 router#Im vorherigen Beispiel wurden 52 RTP-Pakete an UDP-Ports, die größer als 1023 sind, für Zugriffskontrolllisteneintrag (ACE) Leitung 20 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.
Reduzierung: VLAN-Zugriffskontrolllisten (VACLs)
Um das Netzwerk vor allen Paketen zu schützen, die innerhalb eines VLAN überbrückt werden oder die in ein VLAN oder aus einem VLAN heraus geroutet werden, sollten Administratoren VLAN-Zugriffskontrolllisten (VACLs) bereitstellen, um die Richtlinien durchzusetzen. Wenn Sie eine VACL bereitstellen möchten, sollten Sie überprüfen, welche Ports erforderlich sind, damit die Telefone mit jeder Anwendung funktionieren, die in Ihrem IP-Telefonienetzwerk verwendet wird. Normalerweise wird jede VACL auf das VLAN angewendet, das von den Telefonen verwendet wird. Dies ermöglicht die Steuerung am Access-Port. Administratoren können eine VACL erstellen, indem sie explizit zulassen, dass nur autorisierter Datenverkehr innerhalb eines VLAN überbrückt oder gemäß den bestehenden Sicherheitsrichtlinien und Konfigurationen in ein VLAN oder aus einem VLAN heraus geroutet wird. Eine VACL-Problemumgehung kann keinen vollständigen Schutz vor Schwachstellen mit einem IPv4-Netzwerkangriffsvektor bieten, wenn der Angriff von einer vertrauenswürdigen Quelladresse stammt.
Hinweis: VACLs unterscheiden sich von herkömmlichen Cisco IOS-ACLs dadurch, dass sie für alle Pakete gelten, nicht nur für geroutete Pakete. Neben Unicast-Datenverkehr gelten VACLs auch für Multicast- und Broadcast-Datenverkehr. Diese Pakettypen müssen in der VACL-Konfiguration berücksichtigt werden.
Die VACL-Richtlinie verweigert nicht autorisierte SSH-Pakete auf dem TCP-Port 22, die an betroffene Geräte im Sprach-VLAN gesendet werden (wie es der Fall ist, wenn ein kompromittiertes Gerät versucht, SSH auf ein Telefon zu übertragen). Im folgenden Beispiel ist 192.168.60.0/24 der IP-Adressraum, der von den betroffenen Geräten in VLAN 60 verwendet wird. 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 VACLs finden Sie im Dokument Configuring Port ACLs and VLAN ACLs (Konfigurieren von Port-ACLs und VLAN-ACLs) im Kapitel Catalyst 6500 Release 12.2SXH and Later Software Configuration Guide (Catalyst 6500, Version 12.2SXH und höher).
! !-- Create an access list policy that will be applied in a !-- VLAN access map that includes vulnerability-specific !-- access control entries (ACEs) that can aid in !-- identification of attacks ! ip access-list extended VACL-deny permit TCP any 192.168.60.0 0.0.0.255 eq 22 ! !-- Create an access list policy that will be applied !-- in a VLAN access map that permits all other !-- Layer 2 and Layer 3 traffic in accordance with !-- existing security polices and configurations. ! !-- Broadcast and multicast traffic must be accounted !-- for as well !-- !-- This access list policy could be implemented as an !-- explicit permit statement allowing all other IP traffic !-- as shown here ! ip access-list extended Permit-All permit ip any any ! !-- Define the VLAN access map that will be used to !-- perform policy enforcement (either permit or deny) !-- on the traffic matched by the previously defined !-- access control lists ! ! vlan access-map VACL 10 match ip address VACL-deny action drop ! vlan access-map VACL 20 match ip address Permit-All action forward ! !-- Apply the VACL policy to the VLAN or list of VLANs !-- to filter traffic (Note: The 'vlan-list' operator !-- is a single VLAN or comma separated list of VLANs) ! vlan filter VACL vlan-list 60 !
Hinweis: Im vorherigen VACL-Beispiel führen die Zugriffskontrolllisteneinträge (ACEs), die den potenziellen Exploit-Paketen mit der permit-Anweisung entsprechen, dazu, dass diese Pakete durch die VLAN Access-Map Drop-Anweisung verworfen werden.
Identifikation: VLAN-Zugriffskontrolllisten
Nachdem der Administrator die VACL auf ein VLAN oder eine Liste von VLANs angewendet hat, identifiziert der Befehl show tcam interface vlan vlan-interface-number acl in ip die Anzahl der gefilterten Pakete. Den Administratoren wird empfohlen, gefilterte Pakete zu untersuchen, um festzustellen, ob es sich dabei um Versuche handelt, diese Schwachstelle auszunutzen. Beispielausgabe für show tcam interface vlan 60 acl in ip folgt:
Hinweis: Ein Administrator kann mithilfe des Befehls show tcam interface vlan vlan-interface-number acl in ip detail zusätzliche Statistiken zu Zugriffssteuerungseinträgen anzeigen.
switch#show tcam interface vlan 60 acl in ip * Global Defaults shared Entries from Bank 0 Entries from Bank 1 deny tcp any 192.168.60.0 0.0.0.255 eq 22 (35 matches) permit ip any any (379 matches) switch#Im vorherigen Beispiel haben Regeln für die VACL-Richtlinie VACL 35 SSH-Pakete auf dem TCP-Port 22 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 Intelligence Operations.
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.
Eindämmung: Spoofing-Schutz
Administratoren können die folgenden Spoofing-Schutzmechanismen verwenden, um sich vor kompromittierten Geräten zu schützen, die versuchen, den TFTP-Server-Datenverkehr zu manipulieren.
Unicast Reverse Path Forwarding
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.
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 show ip interface, die show cef drop-Funktion, die Funktion "show ip cef switching statistics" und die show ip traffic-Befehle 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 | include regex-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 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 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 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 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 ip traffic | include RPF 18 no route, 18 unicast RPF, 0 forced drop router#Im vorherigen Abschnitt werden die cef-Schnittstelle, GigabitEthernet 0/0 intern, die ip-Schnittstelle, GigabitEthernet 0/0, show cef drop, die ip cef-Switching-Statistikfunktion und show ip-Traffic-Beispiele angezeigt. In uRPF wurden 18 IP-Pakete verworfen, die global an allen Schnittstellen empfangen wurden, wobei uRPF konfiguriert wurde, da die Quelladresse der IP-Pakete in der Datenbank für Weiterleitungsinformationen von Cisco Express Forwarding.
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.
Zu den Funktionen zur Risikominimierung in diesem Dokument, die bei einem Layer-2-Angriff verwendet werden, gehören DHCP-Snooping und Dynamic ARP Inspection (DAI). Beachten Sie, dass die Konfiguration von DHCP-Snooping eine Voraussetzung für die Konfiguration von DAI ist.
DHCP-Snooping
DHCP-Snooping ist eine Sicherheitsfunktion, die DHCP-Nachrichten über einen Switch abfängt und nicht vertrauenswürdige DHCP-Angebote blockiert. DHCP-Snooping verwendet das Konzept vertrauenswürdiger und nicht vertrauenswürdiger Ports. In der Regel werden vertrauenswürdige Ports verwendet, um DHCP-Server oder Relay-Agenten zu erreichen, während nicht vertrauenswürdige Ports für die Verbindung mit Clients verwendet werden. Alle DHCP-Nachrichten sind an vertrauenswürdigen Ports zulässig, während an nicht vertrauenswürdigen Ports nur DHCP-Client-Nachrichten akzeptiert werden. Da weder Server noch Relay-Agenten Verbindungen zu nicht vertrauenswürdigen Ports herstellen sollen, werden Servermeldungen wie DHCPOFFER, DHCPACK und DHCPNAK für nicht vertrauenswürdige Ports verworfen. Darüber hinaus erstellt und pflegt DHCP-Snooping eine MAC-zu-IP-Bindungstabelle, mit der DHCP-Pakete validiert werden, die von nicht vertrauenswürdigen Ports empfangen wurden. Die Bindungstabelle für DHCP-Snooping enthält die MAC-Adresse, die IP-Adresse, die Leasedauer in Sekunden und die VLAN-Port-Informationen für die DHCP-Clients an den nicht vertrauenswürdigen Ports eines Switches. Die Informationen in einer Bindungstabelle für DHCP-Snooping werden aus der Bindungstabelle entfernt, wenn die Lease abläuft oder DHCP-Snooping im VLAN deaktiviert wird.
Verwenden Sie den Befehl show ip dhcp snooping, um die DHCP-Snooping-Einstellungen anzuzeigen, und den Befehl show ip dhcp snooping binding, um die Bindungseinträge für nicht vertrauenswürdige Ports anzuzeigen.
Weitere Informationen zur Bereitstellung und Konfiguration von DHCP-Snooping finden Sie unter Konfigurieren der DHCP-Funktionen und von IP Source Guard.
Dynamic ARP Inspection (DAI)
Die ordnungsgemäße Bereitstellung und Konfiguration von DAI bietet einen effektiven Schutz vor Spoofing-Angriffen auf Layer 2. Für die Bereitstellung von DAI ist die Implementierung von DHCP-Snooping erforderlich. DAI verwirft alle ARP-Pakete mit ungültigen IP-MAC-Adressbindungen, die die Überprüfung nicht bestanden haben.
DAI verwendet die Einträge in der Datenbank für die DHCP-Snooping-Bindung, um die IP-MAC-Adressbindungen zu überprüfen. Konfigurieren Sie jede sichere Schnittstelle mit dem Konfigurationsbefehl ip arp inspection trust interface als vertrauenswürdig. Die vertrauenswürdigen Schnittstellen umgehen die Validierungsprüfungen der ARP-Prüfung, und alle anderen Pakete werden geprüft, wenn sie an nicht vertrauenswürdigen Schnittstellen eintreffen. Das folgende Beispiel zeigt, wie eine Schnittstelle als vertrauenswürdig konfiguriert wird und wie DAI für die VLANs 5 bis 10 aktiviert wird.
DAI-Konfigurationsbeispiel:
Switch(config)#interface GigabitEthernet 1/0/1 Switch(config-if)#ip arp inspection trust Switch(config)#ip arp inspection vlan 5-10
IP-Quellschutz
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 beschriebene Schwachstelle.
Die IP Source Guard-Funktion wird in Kombination mit der DHCP-Snooping-Funktion an Layer-2-Schnittstellen aktiviert, einschließlich Zugriffs- und Trunk-Ports.
Konfigurationsbeispiel für IP Source GuardSwitch(config)#interface GigabitEthernet 1/0/1 Switch(config-if)#ip verify source port-security
Das obige Beispiel zeigt, wie das IPSG mit dynamischer Quell-IP- und MAC-Adressfilterung aktiviert wird.
Verwenden Sie den Befehl show ip verify source, um die IPSG-Konfiguration anzuzeigen, und den Befehl show ip source binding, um die IP-Quellbindungen auf dem Switch anzuzeigen.
Weitere Informationen zur Bereitstellung und Konfiguration von IPSG finden Sie unter Konfigurieren der DHCP-Funktionen und von IP Source Guard.
Identitätsbasierte Netzwerke mit IEEE 802.1X-fähigen Netzwerken
IEEE 802.1x ist ein Protokollstandard-Framework für kabelgebundene und Wireless-LANs, das Benutzer oder Netzwerkgeräte authentifiziert und Funktionen zur Richtliniendurchsetzung auf Port-Ebene für eine sichere Netzwerkzugriffskontrolle bietet. Der IEEE 802.1x-Standard bietet in Verbindung mit der Möglichkeit für Netzwerkgeräte, unter Verwendung bestehender Protokolle wie EAP und RADIUS zu kommunizieren, mehr Sicherheit und eine bessere Kontrolle des Zugriffs auf Netzwerksegmente und -ressourcen, indem die Identität einer mit dem Netzwerk verbundenen Einheit mit einem entsprechenden Satz von Kontrollrichtlinien verknüpft wird.
Weitere Informationen zur Bereitstellung und Konfiguration von 802.1x finden Sie im Identity-Based Networking Services: IP Telefony In IEEE 802.1X-Enabled Networks Deployment and Configuration Guide.
Cisco IOS NetFlow und Cisco IOS Flexible NetFlow
Identifikation: Identifikation des IPv4-Datenverkehrs mit Cisco IOS NetFlow
Administratoren können Cisco IOS NetFlow auf Cisco IOS-Routern und -Switches konfigurieren, die Datenverkehr zwischen den Daten- und Sprachnetzwerken weiterleiten, um IPv4-Datenverkehrsflüsse zu identifizieren, bei denen versucht werden kann, diese Schwachstelle durch ein Gerät im Datennetzwerk oder durch ein kompromittiertes Sprachnetzwerktelefon auszunutzen. Den Administratoren wird empfohlen, diese Datenströme zu untersuchen, um festzustellen, ob es sich dabei um Versuche handelt, diese Schwachstellen auszunutzen, oder ob es sich um legitime Datenströme 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 1023 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 11674 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.60.10 Gi0/1 192.168.60.102 11 1785 1941 12 Gi0/1 192.168.60.28 Gi0/0 192.168.13.97 11 1B3E 2A53 5391 Gi0/1 192.168.150.60 Gi0/0 10.89.16.226 06 0016 12CA 1 Gi0/0 192.168.10.17 Gi0/1 192.168.60.97 06 2B89 0016 45 Gi0/1 192.168.60.158 Gi0/0 192.168.11.54 06 0911 3628 1612 Gi0/0 10.88.226.1 Gi0/1 192.168.202.22 11 007B 007B 1 router#Im vorherigen Beispiel sehen wir Ströme mit
- 12 Pakete an hohen UDP-Ports (Hexadezimalwerte 1785 und 1941) von 192.168.60.10 an 192.168.60.102. Handelt es sich um zwei Telefonendpunkte, die voraussichtlich über hohe UDP-Ports (d. h. RTP-Sprachströme) kommunizieren, können dies legitime Transaktionen sein.
- 5.391 Pakete an hohen UDP-Ports (Hexadezimalwerte 1B3E und 2A53) von 192.168.60.28 bis 192.168.13.97 bestimmt. Wenn 192.168.13.97 kein TFTP-Server oder kein Sprach-Endpunkt oder -Gateway ist, der voraussichtlich mit dem Telefon 192.168.60.28 kommuniziert, könnte dies ein Versuch sein, diese Schwachstelle auszunutzen, indem eine TFTP-Transaktion getäuscht wird, um Daten von einem kompromittierten Telefon zu entnehmen (192.12 168 60 28). Weitere Untersuchungen werden erforderlich sein.
- 45 SSH-Pakete an TCP-Port 22 (Hexadezimalwert 0016) zwischen 192.168.10.17 und Telefon 192.168.60.97. Wenn nicht erwartet wird, dass 192.168.10.17 das Telefon 192.168.60.97 über SSH verwaltet, kann dies ein Versuch sein, diese Schwachstelle auszunutzen. Weitere Untersuchungen werden erforderlich sein.
- 1612 Pakete hoher TCP-Port (Hexadezimalwerte 0911 und 3628) zwischen 192.168.60.158 und 192.168.11.54. Wenn 192.168.11.54 kein Sprach-Endpunkt oder -Gateway ist, der bzw. das voraussichtlich über diese TCP-Ports mit dem Telefon 192.168.60.158 kommuniziert, wird das Telefon möglicherweise kompromittiert, und es wird versucht, Daten zu extrahieren. Weitere Untersuchungen werden erforderlich sein.
Der legitime TFTP-Datenverkehr, der vom Daten- zum Sprachnetzwerk gesendet wird, stammt von der IP-Adresse des vertrauenswürdigen Sprach-TFTP-Servers und wird an Adressen innerhalb des Adressblocks 192.168.60.0/24 gesendet, der von den betroffenen Geräten 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 Auslastung des Netzwerkverkehrs zu vergleichen, der von den Daten an die Sprachnetzwerke 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 SSH-Pakete auf TCP-Port 22 (Hexadezimalwert 16) anzuzeigen, verwenden Sie den Befehl show ip cache flow | include SrcIf|_06_.*0016 command to display the related Cisco NetFlow records:
router#show ip cache flow | include SrcIf|_06_.*0016 SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts Gi0/0 192.168.10.17 Gi0/1 192.168.60.97 06 2B89 0016 45 router#
Wie im folgenden Beispiel gezeigt, verwenden Sie show ip cache flow, um nur Pakettransaktionen anzuzeigen, die Telefonadressen betreffen. | include Src_If|192.168.60 command to display the related Cisco NetFlow records:
router#show ip cache flow | include Src_If|192.168.60 SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts Gi0/0 192.168.60.10 Gi0/1 192.168.60.102 11 1785 1941 12 Gi0/1 192.168.60.28 Gi0/0 192.168.13.97 11 1B3E 2A53 5391 Gi0/0 192.168.10.17 Gi0/1 192.168.60.97 06 2B89 0016 45 Gi0/1 192.168.60.158 Gi0/0 192.168.11.54 06 0911 3628 1612 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 Schwachstelle 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 1023 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...128::201 Gi0/0 2001:DB..128::20 Gi0/1 0x11 0x16C4 0x13C4 12 2001:DB...6A:5BA6 Gi0/0 2001:DB...28::21 Gi0/1 0x3A 0x0000 0x8000 841 2001:DB...128::10 Gi0/1 1445:DB...17::121 Gi0/0 0x11 0x4281 0x4510 5101 2001:DB...6A:5BA6 Gi0/0 2001:DB...134::3 Gi0/1 0x3A 0x0000 0x8000 1191 2001:DB...128::15 Gi0/1 3411:DB...22::44 Gi0/0 0x10 0x4281 0x0016 6814 2001:DB...6A::15B Gi0/0 2001:DB...128::2 Gi0/1 0x06 0x160A 0x134A 1597 2001:DB...6A:5BA6 Gi0/0 2001:DB...146::3 Gi0/1 0x3A 0x0000 0x8000 1092
Um die Anzeige der vollständigen 128-Bit-IPv6-Adresse zu ermöglichen, verwenden Sie den Befehl terminal width 132 exec mode.
Im vorherigen Beispiel sehen wir Ströme mit
- 12 Pakete an hohen UDP-Ports (Hexadezimalwerte 16C4 und 13C4) von 2001:DB8:1:60:128::2001:DB8:1:60:128::20. Handelt es sich um zwei Telefonendpunkte, die voraussichtlich über hohe UDP-Ports (d. h. RTP-Sprachströme) kommunizieren, können dies legitime Transaktionen sein.
- 5101 Pakete an hohen UDP-Ports (Hexadezimalwerte 1B3E und 2A53) von 2001:DB8:1:60:128:10, bestimmt für 2001:DB8:17:121. Wenn 2001:DB8:17:121 kein TFTP-Server oder kein Sprach-Endpunkt oder -Gateway ist, der voraussichtlich mit dem Telefon kommunizieren wird 2001:DB8:1:60:128:10, dann könnte dies ein Versuch sein, diese Schwachstelle auszunutzen, indem eine TFTP-Transaktion getäuscht wird, um Daten aus einem Kompromittierer zu entwenden mized-Telefon (2001:DB8:1:60:128:10). Weitere Untersuchungen werden erforderlich sein.
- 6814 SSH-Pakete an TCP-Port 22 (Hexadezimalwert 0016) zwischen 2001:DB8:1:128:15 und Telefon 2001:DB8:1:60:22:44. Wenn 2001:DB8:1:128::15 voraussichtlich nicht das Telefon 2001:DB8:1:60:22::44 über SSH verwaltet, kann dies ein Versuch sein, diese Sicherheitslücke auszunutzen. Weitere Untersuchungen werden erforderlich sein.
- 1.597 Pakete an hohem TCP-Port (Hexadezimalwerte 160A und 134A) zwischen 2001:DB8:1:60:6A::15B und 2001:DB8:3:128::2. Wenn 2001:DB8:3:128::2 kein Sprach-Endpunkt oder -Gateway ist, der bzw. das voraussichtlich über diese TCP-Ports mit dem Telefon 2001:DB8:1:60:6A::15B kommuniziert, ist das Telefon möglicherweise beschädigt und versucht, Daten zu extrahieren. Weitere Untersuchungen werden erforderlich sein.
Der Leser sollte beachten, dass legitimer TFTP-Datenverkehr, der vom Daten- zum Sprachnetzwerk gesendet wird, von der IP-Adresse des vertrauenswürdigen Sprach-TFTP-Servers stammt und an Adressen innerhalb des Adressblocks 2001:DB8:1:60::/64 gesendet wird, der von den betroffenen Geräten 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 Auslastung des Netzwerkverkehrs zu vergleichen, der von den Daten an die Sprachnetzwerke 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 SSH-Pakete auf TCP-Port 22 (Hexadezimalwert 16) anzuzeigen, verwenden Sie den Befehl show ip cache flow | include SrcIf|_06_.*0016 command to display the related Cisco NetFlow records:
router#show ip cache flow | include SrcIf|_06_.*0016 SrcAddress InpIf DstAddress OutIf Prot SrcPrt DstPrt Packets 2001:DB...128::15 Gi0/1 3411:DB...22::44 Gi0/0 0x10 0x4281 0x0016 6814 router#
Wie im folgenden Beispiel gezeigt, verwenden Sie show ip cache flow, um nur Pakettransaktionen anzuzeigen, die Telefonadressen betreffen. | include Src_If|2001:DB8:1:60 command to display the related Cisco NetFlow records:
router#show ip cache flow | include Src_If|2001:DB8:1:60 SrcAddress InpIf DstAddress OutIf Prot SrcPrt DstPrt Packets 2001:DB...128::201 Gi0/0 2001:DB..128::20 Gi0/1 0x11 0x16C4 0x13C4 12 2001:DB...128::10 Gi0/1 1445:DB...17::121 Gi0/0 0x11 0x4281 0x4510 5101 2001:DB...128::15 Gi0/1 3411:DB...22::44 Gi0/0 0x10 0x4281 0x0016 6814 2001:DB...6A::15B Gi0/0 2001:DB...128::2 Gi0/1 0x06 0x160A 0x134A 1597
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.60.10 192.168.60.201 1456 7631 Gi0/0 Gi0/1 1128 17 192.168.60.28 192.168.13.97 8123 33112 Gi0/0 Gi0/1 5391 17 192.168.150.60 10.89.16.226 2567 443 Gi0/0 Gi0/1 13 6 192.168.10.17 192.168.60.97 1289 22 Gi0/0 Gi0/1 45 6 192.168.60.158 192.168.11.54 32211 3628 Gi0/0 Gi0/1 1612 6So zeigen Sie nur die SSH-Flows an: TCP-Port 22: Verwenden Sie die Formattabelle für den show flow monitor FLOW-MONITOR-ipv4. | IPV4 DST-ADDR einschließen |_22_.*_6_, um die zugehörigen NetFlow-Datensätze anzuzeigen.
Um nur Pakettransaktionen mit Telefonadressen anzuzeigen, verwenden Sie den Befehl show ip cache flow. | include Src_If|192.168.60 command to display the related Cisco NetFlow records.
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 prt trns dst prt intf inpt intf outpt pkts ip prot ================ =============== ============ ============ ========= ========== ==== ======= 2001:DB...128::201 2001:DB..128::20 Gi0/0 Gi0/1 21345 12134 222 17 2001:DB...6A:5BA6 2001:DB...28::21 Gi0/0 Gi0/1 12134 23 841 6 2001:DB...128::10 20015:DB...17::121 Gi0/1 Gi0/0 23254 45234 56 17 2001:DB...6A:5BA6 2001:DB...134::3 Gi0/0 Gi0/1 1231 53 135 17 2001:DB...128::15 2001:DB...22::44 Gi0/1 Gi0/0 4234 22 234 6 2001:DB...6A::15B 2001:DB...128::2 Gi0/0 Gi0/1 21431 12134 843 6 2001:DB...6A:5BA6 2001:DB...146::3 Gi0/0 Gi0/1 48212 121 1092 17 To permit display of the full 128-bit IPv6 address, use the terminal width 132 exec mode command.Um nur die SSH-Flows auf dem TCP-Port 22 anzuzeigen, verwenden Sie die Formattabelle show flow-MONITOR-ipv6 cache | fügen Sie den IPV6 DST ADDR|_22_.*_6_-Befehl ein, um die zugehörigen Cisco IOS Flexible NetFlow-Datensätze anzuzeigen.
Um nur Pakettransaktionen mit Telefonadressen anzuzeigen, verwenden Sie show ip cache flow. | includeSrc_If|2001:DB8:1:60 Befehl zum Anzeigen der zugehörigen Cisco NetFlow-Datensätze ein.
Cisco ASA und Cisco 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 Transit-Zugriffskontrolllisten (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 ersten Zugriffslisten tACL-Policy-Data und IPv6-tACL-Policy-Data verweigern nicht autorisierte SSH IPv4- und IPv6-Pakete auf den TCP-Ports 22 und TFTP IPv4- und IPv6-Pakete auf UDP-Ports größer als 1023, die vom Datennetzwerk an betroffene Geräte im Sprachnetzwerk gesendet werden. Der zweite Zugriffsliste tACL-Policy-Voice und IPv6-tACL-Policy-Voice verweigern nicht autorisierte RTP IPv4- und IPv6-Pakete auf UDP-Ports größer als 1023, die von betroffenen Geräten im Sprachnetzwerk an das Datennetzwerk gesendet werden und die ein Versuch sein können, Sprachkommunikation auszufiltern. 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 im Sprachnetzwerk verwendet wird, und die Hosts unter 192.168.100.1 und 2001:DB8::100:1 gelten als vertrauenswürdige Quellen, Zugriff auf die betroffenen Geräte benötigen. 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 TCP and UDP ports !-- This includes softphones and other communication end-points !-- deployed on the data network
!
access-list tACL-Policy-Data extended permit tcp host 192.168.100.1 192.168.60.0 255.255.255.0 eq 22 access-list tACL-Policy-Data extended permit udp host 192.168.100.1 gt 1023 192.168.60.0 255.255.255.0 gt 1023 !
!-- The following vulnerability-specific access control entries
!-- (ACEs) can aid in identification of attacks
!
access-list tACL-Policy-Data extended deny tcp any 192.168.60.0 255.255.255.0 eq 22 access-list tACL-Policy-Data extended deny udp any gt 1023 192.168.60.0 255.255.255.0 gt 1023 !
!-- 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-Data extended deny ip any any !
!-- Create the corresponding IPv6 tACL
! !
!-- Include explicit permit statements for trusted sources
!-- that require access on the vulnerable TCP and UDP ports !-- This includes softphones and other communication end-points !-- deployed on the data network
! ipv6 access-list IPv6-tACL-Policy-Data permit tcp host 2001:DB8::100:1 2001:DB8:1:60::/64 eq 22 ipv6 access-list IPv6-tACL-Policy-Data permit udp host 2001:DB8::100:1 gt 1023 2001:DB8:1:60::/64 gt 1023
!
!-- The following vulnerability-specific ACEs can
!-- aid in identification of attacks to global and
!-- link-local addresses
! ipv6 access-list IPv6-tACL-Policy-Data deny tcp any 2001:DB8:1:60::/64 eq 22 ipv6 access-list IPv6-tACL-Policy-Data deny udp any gt 1023 2001:DB8:1:60::/64 gt 1023
!
!-- Permit or deny all other Layer 3 and Layer 4 traffic in
!-- accordance with existing security policies and configurations
!
!-- Explicit deny for all other IPv6 traffic
!
ipv6 access-list IPv6-tACL-Policy-Data deny ip any any !
!
!-- Apply tACLs to interfaces in the ingress direction
! access-group tACL-Policy-Data in interface outside access-group IPv6-tACL-Policy-Data in interface outside
!
!-- Include explicit permit statements for trusted sources
!-- that require access on the vulnerable TCP and UDP ports
!-- This includes softphones and other communication end-points !-- deployed on the data network.
! access-list tACL-Policy-Voice permit udp 192.168.60.0 255.255.255.0 gt 1023 host 192.168.100.1 gt 1023 !
!-- The following vulnerability-specific access control entries
!-- (ACEs) can aid in identification of attacks
! access-list tACL-Policy-Voice deny udp 192.168.60.0 255.255.255.0 gt 1023 any gt 1023 !
!-- 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-Voice deny ip any any !
!-- Create the corresponding IPv6 tACL
!
!-- Include explicit permit statements for trusted sources
!-- that require access on the vulnerable TCP and UDP ports !-- This includes softphones and other communication end-points !-- deployed on the data network
! ipv6 access-list IPv6-tACL-Policy-Voice permit udp 2001:DB8:60::/64 gt 1023 host 2001:DB8:1:100::1 gt 1023
!
!-- The following vulnerability-specific ACEs can
!-- aid in identification of attacks to global and
!-- link-local addresses
! ipv6 access-list IPv6-tACL-Policy-Voice deny udp 2001:DB8:60::/64 gt 1023 any gt 1023
!
!-- Permit or deny all other Layer 3 and Layer 4 traffic in
!-- accordance with existing security policies and configurations
!
!-- Explicit deny for all other IPv6 traffic
!
ipv6 access-list IPv6-tACL-Policy-Voice deny ip any any !
!-- Apply tACLs to interfaces in the ingress direction! access-group tACL-Policy-Voice in interface inside access-group IPv6-tACL-Policy-Voice in interface inside
Identifizierung: Protokollierung der Zugriffsliste
Nachdem die tACLs auf eine Schnittstelle angewendet wurden, können Administratoren mithilfe von show ip access-lists die Anzahl der SSH IPv4- und IPv6-Pakete an den TCP-Ports 22 sowie der TFTP IPv4- und IPv6-Pakete an UDP-Ports mit mehr als 1023 identifizieren, die gefiltert wurden. Den Administratoren wird empfohlen, gefilterte Pakete zu untersuchen, um festzustellen, ob es sich dabei um Versuche handelt, diese Schwachstelle auszunutzen. Beispielausgabe für show ip access-lists tACL-Policy-Data und show access-list IPv6-tACL-Policy-Data:
Firewall#show ip access-lists tACL-Policy-Data access-list tACL-Policy-Data; 5 elements; name hash: 0x47502853 access-list tACL-Policy-Data line 1 extended permit tcp host 192.168.100.1 gt 1023 192.168.60.0 0.0.0.255 eq 22 access-list tACL-Policy-Data line 2 extended permit udp host 192.168.100.1 gt 1023 192.168.60.0 0.0.0.255 gt 1023 access-list tACL-Policy-Data line 3 extended deny tcp any 192.168.60.0 0.0.0.255 eq 22 (hitcnt=57) access-list tACL-Policy-Data line 4 extended deny udp any gt 1023 192.168.60.0 0.0.0.255 gt 1023 (hitcnt=40) access-list tACL-Policy-Data line 5 extended deny ip any any Firewall#Im vorherigen Beispiel hat die Zugriffsliste tACL-Policy-Data die folgenden Pakete verworfen, die von einem nicht vertrauenswürdigen Host oder Netzwerk empfangen wurden:
- 57 SSH-Pakete am TCP-Port 22 für ACE-Leitung 3
- 40 TFTP-Pakete an UDP-Ports größer als 1023 für ACE-Leitung 4
Firewall#show ipv6 access-list IPv6-tACL-Policy-Data ipv6 access-list IPv6-tACL-Policy-Data; 5 elements; name hash: 0x342aba4c Ipv6 access-list IPv6-tACL-Policy-Data line 1 permit tcp host 2001:DB8::100:1 2001:DB8:1:60::/64 eq 22 (hitcnt=55) Ipv6 access-list IPv6-tACL-Policy-Data line 2 permit udp host 2001:DB8::100:1 gt 1023 2001:DB8:1:60::/64 gt 1023 (hitcnt=38) Ipv6 access-list IPv6-tACL-Policy-Data line 3 deny tcp any 2001:DB8:1:60::/64 eq 22 (hitcnt=18) Ipv6 access-list IPv6-tACL-Policy-Data line 4 deny udp any gt 1023 2001:DB8:1:60::/64 gt 1023 (hitcnt=21) Ipv6 access-list IPv6-tACL-Policy-Data line 5 deny ip any any (hitcnt=21)Im vorherigen Beispiel hat die Zugriffsliste "IPv6-tACL-Policy-Data" die folgenden Pakete verworfen, die von einem nicht vertrauenswürdigen Host oder Netzwerk empfangen wurden:
- 18 SSH-Pakete am TCP-Port 22 für ACE-Leitung 3
- 21 TFTP-Pakete an TCP-Ports mit mehr als 1023 für ACE-Leitung 4
Firewall#show access-list tACL-Policy-Voice access-list tACL-Policy-Voice; 3 elements; name hash: 0xef0bf5e access-list tACL-Policy-Voice line 1 extended permit udp 192.168.60.0 255.255.255.0 gt 1023 host 192.168.100.1 gt 1023 (hitcnt=0) access-list tACL-Policy-Voice line 2 extended deny udp 192.168.60.0 255.255.255.0 gt 1023 any gt 1023 (hitcnt=29) access-list tACL-Policy-Voice line 3 extended deny ip any any (hitcnt=0) Firewall#Im vorherigen Beispiel hat die Zugriffsliste IPv6-tACL-Policy-Voice die folgenden Pakete verworfen, die von einem nicht vertrauenswürdigen Host oder Netzwerk empfangen wurden:
- 29 RTP-Pakete an UDP-Ports größer als 1023 für ACE-Leitung 2
Firewall#router#show ipv6 access-list IPv6-tACL-Policy-Voice ipv6 access-list IPv6-tACL-Policy-Voice line 1 permit udp 2001:db8:60::/64 gt 1023 host 2001:db8:1:100::1 gt 1023 (hitcnt=0) ipv6 access-list IPv6-tACL-Policy-Voice line 2 deny udp 2001:db8:60::/64 gt 1023 any gt 1023 (hitcnt=44) ipv6 access-list IPv6-tACL-Policy-Voice line 3 deny ip any any (hitcnt=0)Im vorherigen Beispiel hat die Zugriffsliste IPv6-tACL-Policy-Voice die folgenden Pakete verworfen, die von einem nicht vertrauenswürdigen Host oder Netzwerk empfangen wurden:
- 44 RTP-Pakete an UDP-Ports, die größer als 1023 für ACE-Leitung 2 sind
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 Cisco Catalyst ASA Services Module der Serie 6500 finden Sie unter Configuring Logging (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 beschriebenen Schwachstellen 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 Jan 09 2013 00:15:13: %ASA-4-106023: Deny udp src outside:192.0.2.18/2944 dst inside:192.168.60.191/6281 by access-group "tACL-Policy-Data" Jan 09 2013 00:15:13: %ASA-4-106023: Deny udp src inside:192.168.60.33/5298 dst outside:192.0.2.200/2834 by access-group "tACL-Policy-Voice" Jan 09 2013 00:15:13: %ASA-4-106023: Deny tcp src outside:2001:db8:2::2:172/2951 dst inside:2001:db8:1:60::23/22 by access-group "IPv6-tACL-Policy-Data" Jan 09 2013 00:15:13: %ASA-4-106023: Deny udp src inside:2001:db8:1:60::134/7528 dst outside:2001:db8:d::a85e:172/4752 by access-group "IPv6-tACL-Policy-Voice" firewall#Weitere Informationen zu Syslog-Meldungen für Cisco Adaptive Security Appliances der ASA-Serie finden Sie in Cisco ASA 5500 Series System Log Messages, 8.2. Weitere Informationen zu Syslog-Meldungen für das Cisco Catalyst ASA Services Module der Serie 6500 finden Sie im Abschnitt Analyzing Syslog Messages (Analysieren von Syslog-Meldungen) des Cisco ASASM CLI Configuration Guide. Weitere Informationen zu Syslog-Meldungen für Cisco 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 Whitepaper Identifying Incidents Using Firewall and IOS Router Syslog Events Cisco Security Intelligence Operations.
Eindämmung: Spoofing-Schutz mit Unicast Reverse Path Forwarding
Die in diesem Dokument beschriebenen Schwachstellen können 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: Spoofing-Schutz mit Unicast Reverse Path Forwarding
Die Firewall-Syslog-Meldung 106021 wird für Pakete generiert, die von uRPF 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 für das Cisco Catalyst ASA Services Module der Serie 6500 finden Sie unter Configuring Logging (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 beschriebenen Schwachstellen 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 Jan 09 2013 00:15:13: %ASA-1-106021: Deny UDP reverse path check from 192.168.60.1 to 192.168.60.99 on interface outside Jan 09 2013 00:15:13: %ASA-1-106021: Deny UDP reverse path check from 192.168.60.1 to 192.168.60.99 on interface outside Jan 09 2013 00:15:13: %ASA-1-106021: Deny TCP reverse path check from 192.168.60.1 to 192.168.60.99 on interface outsideDer Befehl show asp drop kann außerdem die Anzahl der Pakete identifizieren, die durch die uRPF-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 uRPF 11 IP-Pakete verworfen, die an Schnittstellen mit konfiguriertem uRPF empfangen wurden. Fehlende Ausgabe zeigt an, dass die uRPF-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.
Cisco Security Manager
Identifikation: Cisco Security Manager
Cisco Security Manager, Ereignisanzeige
Ab Softwareversion 4.0 kann Cisco Security Manager Syslogs von Cisco Firewalls und Cisco IPS-Geräten sammeln und stellt die Ereignisanzeige bereit, mit der nach Ereignissen gesucht werden kann, die mit den in diesem Dokument beschriebenen Sicherheitslücken zusammenhängen.
Die Verwendung der folgenden Filter in der vordefinierten Ansicht "Firewall Denied Events" in der Ereignisanzeige stellt alle erfassten Cisco Firewall-Zugriffslisten-Syslog-Meldungen Deny bereit, die auf potenzielle Versuche hinweisen könnten, die in diesem Dokument beschriebenen Schwachstellen auszunutzen.
- Verwenden Sie den Zielereignisfilter, um Netzwerkobjekte zu filtern, die den von den betroffenen Geräten verwendeten IP-Adressraum enthalten (z. B. IPv4-Adressbereich 192.168.60.0/24 und IPv6-Adressbereich 2001:DB8:1:60::/64).
- Verwenden Sie den Zieldienst-Ereignisfilter, um Objekte zu filtern, die TCP-Port 22 und UDP-Ports 1023 - 65535 enthalten.
Ein Ereignistyp-ID-Filter kann in Verbindung mit der vordefinierten Ansicht Firewall Denied Events (Von Firewall abgelehnte Ereignisse) in der Ereignisanzeige verwendet werden, um die in der folgenden Liste aufgeführten Syslog-IDs zu filtern und alle erfassten Cisco Firewall-Syslog-Meldungen Deny bereitzustellen, die auf potenzielle Versuche hinweisen könnten, die in diesem Dokument beschriebenen Schwachstellen auszunutzen:
- ASA-4-106021 (uRPF-Spoofing)
- ASA-4-106023 (ACL verweigert)
Weitere Informationen zu Cisco Security Manager-Ereignissen finden Sie im Abschnitt Filtering and Querying Events im Cisco Security Manager User Guide.
Identifikation: Event Management System - Partnerveranstaltungen
Cisco arbeitet über das Cisco Developer Network mit branchenführenden Anbietern von Security Information and Event Management (SIEM) zusammen. Diese Partnerschaft unterstützt Cisco bei der Bereitstellung validierter und getesteter SIEM-Systeme, die geschäftliche Herausforderungen wie langfristige Protokollarchivierung und Forensik, heterogene Ereigniskorrelation und erweiterte Compliance-Berichte bewältigen. Partnerprodukte für das Security Information and Event Management können zum Erfassen von Ereignissen von Cisco Geräten und anschließenden Abfragen der erfassten Ereignisse nach Vorfällen verwendet werden, die durch eine Cisco IPS-Signatur verursacht wurden, oder Syslog-Meldungen von Firewalls verweigern, die auf potenzielle Versuche hinweisen könnten, die in diesem Dokument beschriebenen Schwachstellen auszunutzen. Die Abfragen können anhand der Signature-ID und der Syslog-ID durchgeführt werden, wie in der folgenden Liste gezeigt:
- ASA-4-106021 (uRPF-Spoofing)
- ASA-4-106023 (ACL verweigert)
Weitere Informationen zu SIEM-Partnern finden Sie auf der Website zum Security Management System (Sicherheitsmanagementsystem).
-
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 2013-09-Januar 16:01 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 Unified IP-Telefon 7906G 7,2 (3) | 8,0 (3, 4, 4) SR1, 4 (SR2, 4) SR3A) | 8.2 (1, 2, 2) SR1, 2) SR2, 2) SR4, 2) SR3) | 8,3 (1, 2, 2) SR1, (2) SR2, (2) SR3, (2) SR4, (3) SR2 | 9,0 (9,0(2)SR1, 9,0(2)SR2, 9,0(3), 9,1(1)SR1, 9,2(1)) Cisco Unified IP-Telefon 7911G 7.2 (1), (2)SR2, (3) | 8,0 (1, 2, SR2, 3, 4, SR1, 4, SR2, 4, SR3A) | 8.2 (1, 2) SR1, 2) SR2, 2) SR3, 2) SR4) | 8,3 (1, 2, 2) SR1, (3) SR2) | 9,0 (9,0(2)SR1, 9,0(2)SR2, 9,0(3), 9,1(1)SR1, 9,2(1)) Cisco Unified IP-Telefon 7931G 8.3 (1, 2, 2, SR1, 3, 3, SR2) | 9,0 (9,0(2)SR1, 9,0(2)SR2, 9,0(3), 9,1(1)SR1, 9,2(1)) Cisco Unified IP-Telefon 7941G 7,0 (2, 2, SR1, 3) | 8,0 (1, 2, SR1, 3, 4, 4, SR1, 4, SR2, 4, SR3A) | 8.2 (1, 2) SR1, 2) SR2, 2) SR3, 2) SR4) | 8,3 (1, 2, 2) SR1, (3) SR2) | 9,0 (9,0(2)SR1, 9,0(2)SR2, 9,0(3), 9,1(1)SR1, 9,2(1)) Cisco Unified IP-Telefon 7942G 8,3 (2, 2, SR1, 3, 3, SR2) | 9,0 (9,0(2)SR1, 9,0(2)SR2, 9,0(3), 9,1(1)SR1, 9,2(1)) Cisco Unified IP-Telefon 7945G 8,3 (2, 2, SR1, 3, 3, SR2) | 9,0 (9,0(2)SR1, 9,0(2)SR2, 9,0(3), 9,1(1)SR1, 9,2(1)) Cisco Unified IP-Telefon 7961G 7,0 (2), (2) SR1, (3) | 8,0 (1, 2, SR1, 3, 4, SR1, 4, SR2, 4, SR3A) | 8.2 (1, 2) SR1, 2) SR2, 2) SR3, 2) SR4) | 8,3 (1, 2, 2) SR1, (3) SR2) | 9,0 (9,0(2)SR1, 9,0(2)SR2, 9,0(3), 9,1(1)SR1, 9,2(1)) Cisco Unified IP-Telefon 7962G 8,3 (2, 2, SR1, 3, 3, SR2) | 9,0 (9,0(2)SR1, 9,0(2)SR2, 9,0(3), 9,1(1)SR1, 9,2(1)) Cisco Unified IP-Telefon 7965G 8,3 (2, 2, SR1, 3, 3, SR2) | 9,0 (9,0(2)SR1, 9,0(2)SR2, 9,0(3), 9,1(1)SR1, 9,2(1)) Cisco Unified IP-Telefon 7970G 5,0 (1, 3) | 6,0 (1, 1, SR1, 2, 2, SR1, 3, SR1) | 7,0 (1), (2), (2)SR1, (3) | 8,0 (1, 2, SR1, 3, 4, SR1, 4, SR2, 4, SR3A) | 8,3 (1, 2, 2) SR1, (3) SR2) | 9,0 (9,0(2)SR1, 9,0(2)SR2, 9,0(3), 9,1(1)SR1, 9,2(1)) Cisco Unified IP-Telefon 7971G-GE 9,0 (9,0(2)SR1, 9,0(2)SR2, 9,0(3), 9,1(1)SR1, 9,2(1)) Cisco Unified IP-Telefon 7961G-GE 9,0 (9,0(2)SR1, 9,0(2)SR2, 9,0(3), 9,1(1)SR1, 9,2(1)) Cisco Unified IP-Telefon 7941G-GE 9,0 (9,0(2)SR1, 9,0(2)SR2, 9,0(3), 9,1(1)SR1, 9,2(1)) Cisco Unified IP-Telefon 7975G 8.3(2) (Basis, SR1) | 8.3(3) (Basis, SR2) | 8.3(4) (Basis, SR1) | 8.3(5) (Basis) | 8.4(1) (Basis, SR1, SR2) | 8.4(2) (Basis) | 8.4(3) (Basis) | 8.4(4) (Basis) | 8.5(2) (Basis, SR1) | 8.5(3) (Basis, SR1) | 8.5(4) (Basis) | 9.0(2) (Basis, SR1, SR2) | 9.0(3) (Basis) | 9.1(1) (Basis, SR1) | 9.2(1) (Basis, SR2) | 9.2(3) (Basis) | 9.3(1) (Basis, SR1)
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.