ASA/PIX 7.x und spätere Version: Abwehr von Netzwerkangriffen

Einleitung

In diesem Dokument wird beschrieben, wie Sie die verschiedenen Netzwerkangriffe wie Denial-of-Services (DoS) mithilfe der Cisco Security Appliance (ASA/PIX) eindämmen können.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf der Cisco Adaptive Security Appliance (ASA) der Serie 5500, auf der die Software-Version 7.0 und höher ausgeführt wird.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netz Live ist, überprüfen Sie, ob Sie die mögliche Auswirkung jedes möglichen Befehls verstehen.

Verwandte Produkte

Dieses Dokument kann auch mit Cisco PIX der Serie 500 verwendet werden, auf der die Softwareversion 7.0 oder höher ausgeführt wird.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

Schutz vor SYN-Angriffen

Wie können die SYN-Angriffe (Transmission Control Protocol) auf die ASA/PIX abgewehrt werden?

TCP-SYN-Angriff

TCP SYN-Angriff ist eine Art von DoS-Angriff, bei dem ein Absender ein Volumen von Verbindungen überträgt, die nicht abgeschlossen werden können. Dies führt dazu, dass sich die Verbindungswarteschlangen füllen, wodurch legitimen TCP-Benutzern der Dienst verweigert wird.

Wenn eine normale TCP-Verbindung beginnt, empfängt ein Zielhost ein SYN-Paket von einem Quellhost und sendet eine Synchronisierungsbestätigung (SYN ACK) zurück. Der Ziel-Host muss dann eine ACK der SYN ACK hören, bevor die Verbindung hergestellt wird. Dies wird als TCP-Drei-Wege-Handshake bezeichnet.

Während der Wartezeit für die ACK-Verbindung zur SYN-ACK wird in einer endlichen Verbindungswarteschlange auf dem Ziel-Host nachverfolgt, welche Verbindungen auf den Abschluss warten. Diese Warteschlange wird in der Regel schnell geleert, da erwartet wird, dass die ACK einige Millisekunden nach der SYN ACK ankommt.

Der TCP SYN-Angriff nutzt dieses Design aus, indem ein angreifender Quell-Host TCP SYN-Pakete mit zufälligen Quell-Adressen in Richtung eines Opfer-Hosts generiert. Der Ziel-Host des Opfers sendet eine SYN ACK zurück an die zufällige Quelladresse und fügt einen Eintrag zur Verbindungswarteschlange hinzu. Da die SYN ACK für einen falschen oder nicht vorhandenen Host bestimmt ist, wird der letzte Teil des "Drei-Wege-Handshakes" nie abgeschlossen, und der Eintrag verbleibt in der Verbindungswarteschlange, bis ein Timer abläuft, in der Regel für etwa eine Minute. Durch die schnelle Generierung falscher TCP SYN-Pakete von zufälligen IP-Adressen ist es möglich, die Verbindungswarteschlange zu füllen und TCP-Services (wie E-Mail, Dateiübertragung oder WWW) legitimen Benutzern zu verweigern.

Es gibt keine einfache Möglichkeit, den Urheber des Angriffs zu verfolgen, da die IP-Adresse der Quelle gefälscht ist.

Zu den externen Manifestationen des Problems gehören die Unfähigkeit, E-Mails abzurufen, die Unfähigkeit, Verbindungen zu WWW- oder FTP-Diensten zu akzeptieren, oder eine große Anzahl von TCP-Verbindungen auf Ihrem Host im Zustand SYN_RCVD.

Weitere Informationen zu TCP-SYN-Angriffen finden Sie unter Defining Strategies to Protect Against TCP SYN Denial of Service Attacks (Strategien zum Schutz vor TCP-SYN-Angriffen).

Eindämmung

In diesem Abschnitt wird beschrieben, wie Sie die SYN-Angriffe durch Festlegung der maximalen TCP- und UDP-Verbindungen (User Datagram Protocol), der maximalen Anzahl von embryonalen Verbindungen, der Verbindungszeitüberschreitungen und der Deaktivierung der TCP-Sequenzrandomisierung abwehren.

Wenn die embryonale Verbindungsgrenze erreicht ist, antwortet die Sicherheits-Appliance auf jedes an den Server gesendete SYN-Paket mit SYN+ACK und gibt das SYN-Paket nicht an den internen Server weiter. Wenn das externe Gerät mit einem ACK-Paket antwortet, weiß die Sicherheits-Appliance, dass es sich um eine gültige Anforderung handelt (und nicht um einen Teil eines potenziellen SYN-Angriffs). Die Security Appliance stellt dann eine Verbindung mit dem Server her und verbindet die Verbindungen miteinander. Erhält die Sicherheits-Appliance keine ACK vom Server zurück, wird diese noch nicht genutzte Verbindung aggressiv überschritten.

Jede TCP-Verbindung hat zwei ISNs (Initial Sequence Number): eine vom Client und eine vom Server generierte. Die Sicherheits-Appliance randomisiert die ISN des TCP-SYN, das sowohl in die ein- als auch in die ausgehende Richtung weitergeleitet wird.

Durch das Randomisieren der ISN des geschützten Hosts wird ein Angreifer daran gehindert, die nächste ISN für eine neue Verbindung vorherzusagen und möglicherweise die neue Sitzung zu kapern.

Die Randomisierung der TCP-Erstsequenznummer kann bei Bedarf deaktiviert werden. Beispiele:

• Wenn eine andere Inline-Firewall die ersten Sequenznummern ebenfalls zufällig bestimmt, müssen diese beiden Firewalls nicht aktiv werden, auch wenn diese Aktion den Datenverkehr nicht beeinträchtigt.

• Wenn Sie einen externen BGP (eBGP)-Multi-Hop über die Sicherheits-Appliance verwenden und die eBGP-Peers MD5 verwenden, wird die MD5-Prüfsumme durch die Randomisierung unterbrochen.

• Sie verwenden ein Wide Area Application Services (WAAS)-Gerät, bei dem die Sicherheits-Appliance die Sequenznummern von Verbindungen nicht nach dem Zufallsprinzip ändern muss.

Hinweis: Sie können die maximale Anzahl von Verbindungen, die maximale Anzahl von embryonalen Verbindungen und die TCP-Sequenzrandomisierung in der NAT-Konfiguration konfigurieren. Wenn Sie diese Einstellungen für denselben Datenverkehr mit beiden Methoden konfigurieren, verwendet die Sicherheits-Appliance den unteren Grenzwert. Wenn die TCP-Sequenzrandomisierung mithilfe einer der Methoden deaktiviert wird, deaktiviert die Sicherheits-Appliance die TCP-Sequenzrandomisierung.

Gehen Sie wie folgt vor, um die Verbindungslimits festzulegen:

1. Um den Datenverkehr zu identifizieren, fügen Sie eine Klassenzuordnung mit dem Befehl class-map gemäß Using Modular Policy Framework hinzu.

2. Um eine Richtlinienzuordnung hinzuzufügen oder zu bearbeiten, die die Aktionen festlegt, die mit dem Datenverkehr der Klassenzuordnung ausgeführt werden sollen, geben Sie den folgenden Befehl ein:

   hostname(config)#policy-map name
   

3. Geben Sie den folgenden Befehl ein, um die Klassenzuordnung (aus Schritt 1) zu ermitteln, der Sie eine Aktion zuweisen möchten:

   hostname(config-pmap)#class class_map_name
   

4. Geben Sie den folgenden Befehl ein, um die maximalen Verbindungen (TCP und UDP), die maximalen embryonalen Verbindungen, pro-client-embryonic-max, pro-client-max oder ob die TCP-Sequenzrandomisierung deaktiviert werden soll:

   hostname(config-pmap-c)#set connection {[conn-max number] 
   [embryonic-conn-max number] [per-client-embryonic-max number] 
   [per-client-max number][random-sequence-number {enable | 
   disable}}

   Dabei ist number eine Ganzzahl zwischen 0 und 65535. Der Standardwert ist 0, d. h. es gibt keine Beschränkung für Verbindungen.

   Sie können diesen Befehl in einer Zeile (in beliebiger Reihenfolge) oder jedes Attribut als separaten Befehl eingeben. Der Befehl wird in der aktuellen Konfiguration in einer Zeile zusammengefasst.

5. Geben Sie den folgenden Befehl ein, um den Timeout für Verbindungen, embryonale Verbindungen (halb geöffnet) und halb geschlossene Verbindungen festzulegen:

   hostname(config-pmap-c)#set connection {[embryonic hh[:mm[:ss]]] 
   [half-closed hh[:mm[:ss]]] [tcp hh[:mm[:ss]]]}

   Dabei ist embryonales hh[:mm[:ss] eine Zeit zwischen 0:0:5 und 1192:59:59. Der Standardwert ist 0:0:30. Sie können diesen Wert auch auf 0 setzen, d. h. die Verbindung wird nie unterbrochen.

   Die Werte für hh[:mm[:ss] und tcp hh[:mm[:ss] liegen zwischen 0:5:0 und 1192:59:59. Der Standardwert für half-closed ist 0:10:0, der Standardwert für tcp ist 1:0:0. kann diese Werte auch auf 0 setzen, was bedeutet, dass die Verbindung nie ausläuft.

   Sie können diesen Befehl in einer Zeile (in beliebiger Reihenfolge) oder jedes Attribut als separaten Befehl eingeben. Der Befehl wird in der aktuellen Konfiguration in einer Zeile zusammengefasst.

   • Embryonale (halb geöffnete) Verbindung - Eine embryonale Verbindung ist eine TCP-Verbindungsanforderung, die den notwendigen Handshake zwischen Quelle und Ziel nicht beendet hat.

   • Halb geschlossene Verbindung - Halb geschlossene Verbindung, wenn die Verbindung nur in eine Richtung durch Senden von FIN geschlossen wird. Die TCP-Sitzung wird jedoch weiterhin vom Peer aufrechterhalten.

   • Per-client-embryonic-max - Die maximale Anzahl gleichzeitiger embryonaler Verbindungen pro Client, zwischen 0 und 65535. Der Standardwert ist 0, wodurch unbegrenzte Verbindungen möglich sind.

   • Per-client-max: Die maximale Anzahl gleichzeitiger Verbindungen, die pro Client zulässig sind, zwischen 0 und 65535. Der Standardwert ist 0, wodurch unbegrenzte Verbindungen möglich sind.

6. Um die Richtlinienzuordnung auf einer oder mehreren Schnittstellen zu aktivieren, geben Sie den folgenden Befehl ein:

   hostname(config)#service-policy policymap_name {global | interface interface_name}
   
   

   Hierbei wendet global die Richtlinienzuordnung auf alle Schnittstellen an, und interface wendet die Richtlinie auf eine Schnittstelle an. Es ist nur eine globale Richtlinie zulässig. Sie können die globale Richtlinie für eine Schnittstelle überschreiben, indem Sie eine Dienstrichtlinie auf diese Schnittstelle anwenden. Sie können auf jede Schnittstelle nur eine Policy-Map anwenden.

Beispiel:

ciscoasa(config)#class-map tcp_syn
ciscoasa(config-cmap)#match port tcp eq 80
ciscoasa(config-cmap)#exit
ciscoasa(config)#policy-map tcpmap
ciscoasa(config-pmap)#class tcp_syn
ciscoasa(config-pmap-c)#set connection conn-max 100
ciscoasa(config-pmap-c)#set connection embryonic-conn-max 200
ciscoasa(config-pmap-c)#set connection per-client-embryonic-max 10
ciscoasa(config-pmap-c)#set connection per-client-max 5
ciscoasa(config-pmap-c)#set connection random-sequence-number enable
ciscoasa(config-pmap-c)#set connection timeout embryonic 0:0:45
ciscoasa(config-pmap-c)#set connection timeout half-closed 0:25:0
ciscoasa(config-pmap-c)#set connection timeout tcp 2:0:0
ciscoasa(config-pmap-c)#exit
ciscoasa(config-pmap)#exit
ciscoasa(config)#service-policy tcpmap global

Hinweis: Verwenden Sie den folgenden Befehl, um die Gesamtanzahl halb offener Sitzungen für einen bestimmten Host zu überprüfen:

ASA-5510-8x# show local-host all

Interface dmz: 0 active, 0 maximum active, 0 denied
Interface management: 0 active, 0 maximum active, 0 denied
Interface xx: 0 active, 0 maximum active, 0 denied
Interface inside: 7 active, 18 maximum active, 0 denied

local host: <10.78.167.69>,

    TCP flow count/limit = 2/unlimited

    TCP embryonic count to host = 0

    TCP intercept watermark = unlimited

    UDP flow count/limit = 0/unlimited

Hinweis: Die Zeile, TCP embryonic count to host, zeigt die Anzahl der halb offenen Sitzungen.

Schutz vor IP-Spoofing-Angriffen

Können IP-Spoofing-Angriffe durch PIX/ASA blockiert werden?

IP-Spoofing

Um Zugriff zu erhalten, erstellen Eindringlinge Pakete mit gefälschten Quell-IP-Adressen. Dies nutzt Anwendungen aus, die eine auf IP-Adressen basierende Authentifizierung verwenden, und führt zu nicht autorisierten Benutzern und möglicherweise zu Root-Zugriff auf das Zielsystem. Beispiele hierfür sind die Dienste rsh und rlogin.

Es ist möglich, Pakete über Filterrouter-Firewalls weiterzuleiten, wenn sie nicht für das Filtern eingehender Pakete konfiguriert sind, deren Quelladresse sich in der lokalen Domäne befindet. Es ist wichtig zu beachten, dass der beschriebene Angriff möglich ist, auch wenn keine Antwortpakete den Angreifer erreichen können.

Beispiele für potenziell anfällige Konfigurationen:

• Proxy-Firewalls, bei denen die Proxy-Anwendungen die Quell-IP-Adresse für die Authentifizierung verwenden

• Router zu externen Netzwerken, die mehrere interne Schnittstellen unterstützen

• Router mit zwei Schnittstellen, die Subnetzfunktionen im internen Netzwerk unterstützen

Eindämmung

Unicast Reverse Path Forwarding (uRPF) schützt vor IP-Spoofing (ein Paket verwendet eine falsche Quell-IP-Adresse, um seine wahre Quelle zu verschleiern), indem es sicherstellt, dass alle Pakete eine Quell-IP-Adresse aufweisen, die der richtigen Quell-Schnittstelle gemäß der Routing-Tabelle entspricht.

Normalerweise betrachtet die Sicherheits-Appliance die Zieladresse nur, wenn sie bestimmt, wohin das Paket weitergeleitet werden soll. Unicast RPF weist die Sicherheits-Appliance an, auch die Quelladresse zu überprüfen. Aus diesem Grund wird es Reverse Path Forwarding genannt. Für jeden Datenverkehr, den Sie über die Security Appliance zulassen möchten, muss die Routing-Tabelle der Security Appliance eine Route zurück zur Quelladresse enthalten. Weitere Informationen finden Sie unter RFC 2267 .

Hinweis: Das :- %PIX-1-106021: Die Protokollprüfung des Rückwärtspfads verweigern von src_addr auf dest_addr in der Protokollmeldung int_name wird angezeigt, wenn die Prüfung des Rückwärtspfads aktiviert ist. Deaktivieren Sie die umgekehrte Pfadüberprüfung mit dem Befehl no ip verify reverse path interface (Schnittstellenname), um das Problem zu beheben:

no ip verify reverse-path interface (interface name)

Für externen Datenverkehr kann die Security Appliance beispielsweise die Standardroute verwenden, um den Unicast-RPF-Schutz zu gewährleisten. Wenn Datenverkehr von einer externen Schnittstelle eingeht und die Quelladresse der Routing-Tabelle nicht bekannt ist, verwendet die Security Appliance die Standardroute, um die externe Schnittstelle korrekt als Quellschnittstelle zu identifizieren.

Wenn Datenverkehr von einer Adresse, die der Routing-Tabelle bekannt ist, aber mit der internen Schnittstelle verknüpft ist, in die externe Schnittstelle eingeht, verwirft die Sicherheits-Appliance das Paket. Ebenso verwirft die Sicherheits-Appliance das Paket, wenn Datenverkehr von einer unbekannten Quelladresse in die interne Schnittstelle gelangt, weil die passende Route (die Standardroute) die externe Schnittstelle angibt.

Unicast-RPF wird wie folgt implementiert:

• ICMP-Pakete haben keine Sitzung, daher wird jedes Paket überprüft.

• UDP und TCP verfügen über Sitzungen, sodass das ursprüngliche Paket eine umgekehrte Routensuche erfordert. Die nachfolgenden Pakete, die während der Sitzung eingehen, werden anhand eines bestehenden Zustands überprüft, der während der Sitzung beibehalten wird. Pakete, die keine Initial Packets sind, werden überprüft, um sicherzustellen, dass sie über die gleiche Schnittstelle eintreffen, die auch für die Initial Packets verwendet wird.

Um Unicast RPF zu aktivieren, geben Sie den folgenden Befehl ein:

hostname(config)#ip verify reverse-path interface interface_name

Beispiel:

Wie in dieser Abbildung dargestellt, sendet der Angreifer-PC eine Anforderung an den Anwendungsserver 10.1.1.10, indem er ein Paket mit einer gefälschten Quell-IP-Adresse 10.1.1.5/24 sendet, und der Server sendet als Antwort auf die Anforderung ein Paket an die echte IP-Adresse 10.1.1.5/24. Diese Art von illegalen Paketen greift sowohl den Anwendungsserver als auch legitime Benutzer im internen Netzwerk an.

Unicast-RPF kann Angriffe verhindern, die auf dem Spoofing von Quelladressen basieren. Sie müssen uRPF wie folgt in der externen Schnittstelle der ASA konfigurieren:

ciscoasa(config)#ip verify reverse-path interface outside

Spoofing-Identifizierung mithilfe von Syslog-Meldungen

Die Sicherheits-Appliance empfängt weiterhin Syslog-Fehlermeldungen wie dargestellt. Dies weist auf potenzielle Angriffe hin, die gefälschte Pakete verwenden oder die durch asymmetrisches Routing ausgelöst werden können.

1. %PIX|ASA-2-106001: Inbound TCP connection denied from IP_address/port 
   to IP_address/port flags tcp_flags on interface interface_name
   

   Erläuterung

   Dies ist eine verbindungsbezogene Nachricht. Diese Meldung wird angezeigt, wenn ein Verbindungsversuch mit einer internen Adresse von der Sicherheitsrichtlinie abgelehnt wird, die für den angegebenen Datenverkehrstyp definiert ist. Mögliche tcp_flags-Werte entsprechen den Flags im TCP-Header, die bei der Ablehnung der Verbindung vorhanden waren. Beispielsweise wurde ein TCP-Paket empfangen, für das in der Sicherheits-Appliance kein Verbindungsstatus vorhanden ist, und es wurde verworfen. Die tcp_flags in diesem Paket sind FIN und ACK.

   Die tcp_flags sind:

   • ACK - Die Bestätigungsnummer wurde empfangen.

   • FIN: Die Daten wurden gesendet.

   • PSH: Der Empfänger hat Daten an die Anwendung übergeben.

   • RST - Die Verbindung wurde zurückgesetzt.

   • SYN - Sequenznummern wurden synchronisiert, um eine Verbindung herzustellen.

   • URG - Der dringend benötigte Zeiger wurde als gültig erklärt.

   Es gibt viele Gründe, warum die statische Übersetzung auf dem PIX/ASA-System fehlschlägt. Ein häufiger Grund besteht jedoch darin, dass die DMZ-Schnittstelle (Demilitarized Zone) mit derselben Sicherheitsstufe (0) konfiguriert ist wie die externe Schnittstelle.

   Um dieses Problem zu beheben, weisen Sie allen Schnittstellen eine andere Sicherheitsstufe zu.

   Weitere Informationen finden Sie unter Konfigurieren von Schnittstellenparametern.

   Diese Fehlermeldung wird auch angezeigt, wenn ein externes Gerät ein IDENT-Paket an den internen Client sendet, das von der PIX-Firewall verworfen wird. Weitere Informationen finden Sie unter PIX Performance Issues Caused by IDENT Protocol

2. %PIX|ASA-2-106007: Deny inbound UDP from outside_address/outside_port 
   to inside_address/inside_port due to DNS {Response|Query}
   

   Erläuterung

   Dies ist eine verbindungsbezogene Nachricht. Diese Meldung wird angezeigt, wenn die angegebene Verbindung aufgrund eines Befehls outbound deny fehlschlägt. Die Protokollvariable kann ICMP, TCP oder UDP sein.

   Empfohlene Aktion: Verwenden Sie den Befehl show outbound, um ausgehende Listen zu überprüfen.

3. %PIX|ASA-3-106014: Deny inbound icmp src interface_name: IP_address dst 
   interface_name: IP_address (type dec, code dec)

   Erläuterung

   Die Sicherheits-Appliance hat den Zugriff auf eingehende ICMP-Pakete verweigert. Standardmäßig wird allen ICMP-Paketen der Zugriff verweigert, es sei denn, dies ist ausdrücklich erlaubt.

4. %PIX|ASA-2-106016: Deny IP spoof from (IP_address) to IP_address on 
   interface interface_name.

   Erläuterung

   Diese Meldung wird generiert, wenn ein Paket an der Schnittstelle der Sicherheits-Appliance eingeht, die über die Ziel-IP-Adresse 0.0.0.0 und die Ziel-MAC-Adresse der Schnittstelle der Sicherheits-Appliance verfügt. Darüber hinaus wird diese Nachricht generiert, wenn die Sicherheits-Appliance ein Paket mit einer ungültigen Quelladresse verworfen hat, die eine der folgenden oder eine andere ungültige Adresse enthalten kann:

   • Loopback-Netzwerk (127.0.0.0)

   • Broadcast (begrenzt, netzgerichtet, subnetzgerichtet und auf alle Subnetze gerichtet)

   • Der Zielhost (land.c)

   Um die Erkennung von Spoofing-Paketen weiter zu verbessern, verwenden Sie den Befehl icmp, um die Sicherheits-Appliance so zu konfigurieren, dass Pakete mit Quelladressen, die zum internen Netzwerk gehören, verworfen werden. Dies liegt daran, dass der Befehl access-list veraltet ist und nicht mehr garantiert wird, dass er ordnungsgemäß funktioniert.

   Empfohlene Aktion: Stellen Sie fest, ob ein externer Benutzer versucht, das geschützte Netzwerk zu kompromittieren. Suchen Sie nach falsch konfigurierten Clients.

5. %PIX|ASA-2-106017: Deny IP due to Land Attack from IP_address to 
   IP_address

   Erläuterung

   Die Sicherheits-Appliance hat ein Paket empfangen, dessen IP-Quelladresse dem IP-Ziel und dessen Zielport dem Quellport entspricht. Diese Meldung zeigt ein gefälschtes Paket an, das für Angriffe auf Systeme entwickelt wurde. Dieser Angriff wird als Landangriff bezeichnet.

   Empfohlene Aktion: Wenn diese Meldung weiterhin angezeigt wird, wird möglicherweise ein Angriff ausgeführt. Das Paket enthält nicht genügend Informationen, um den Ursprung des Angriffs zu ermitteln.

6. %PIX|ASA-1-106021: Deny protocol reverse path check from 
   source_address to dest_address on interface interface_name

   Erläuterung

   Ein Angriff wird ausgeführt. Jemand versucht, eine IP-Adresse für eine eingehende Verbindung zu fälschen. Unicast RPF, auch als Reverse-Route-Lookup bezeichnet, hat ein Paket erkannt, das keine Quelladresse aufweist, die durch eine Route dargestellt wird, und geht davon aus, dass es Teil eines Angriffs auf Ihre Sicherheits-Appliance ist.

   Diese Meldung wird angezeigt, wenn Sie Unicast RPF mit dem Befehl ip verify reverse path aktiviert haben. Diese Funktion funktioniert bei Paketen, die an eine Schnittstelle eingegeben werden. Wenn sie außen konfiguriert ist, überprüft die Sicherheits-Appliance die Pakete, die von außen eingehen.

   Die Sicherheits-Appliance sucht anhand der Quelladresse nach einer Route. Wenn kein Eintrag gefunden und keine Route definiert wurde, wird diese Systemprotokollmeldung angezeigt, und die Verbindung wird getrennt.

   Wenn eine Route vorhanden ist, prüft die Sicherheits-Appliance, welcher Schnittstelle sie entspricht. Wenn das Paket an einer anderen Schnittstelle eintraf, handelt es sich entweder um einen Spoof, oder es gibt eine asymmetrische Routing-Umgebung, die mehr als einen Pfad zu einem Ziel hat. Die Security Appliance unterstützt kein asymmetrisches Routing.

   Wenn die Sicherheits-Appliance auf einer internen Schnittstelle konfiguriert ist, überprüft sie die Befehlsanweisungen für statische Routen oder RIP. Wenn die Quelladresse nicht gefunden wird, manipuliert ein interner Benutzer seine Adresse.

   Empfohlene Aktion: Obwohl ein Angriff stattfindet, ist bei Aktivierung dieser Funktion keine Benutzeraktion erforderlich. Die Sicherheits-Appliance wehrt den Angriff ab.

   Hinweis: Der Befehl show asp drop zeigt die Pakete oder Verbindungen an, die über den beschleunigten Sicherheitspfad (asp) blockiert wurden. Dies kann Ihnen bei der Fehlerbehebung helfen. Außerdem wird angegeben, wann die ASP-Abwurfzähler zuletzt gelöscht wurden. Verwenden Sie den Befehl show asp drop rpf-violated, bei dem der Zähler inkrementiert wird, wenn ip verify reverse path auf einer Schnittstelle konfiguriert ist, und die Sicherheits-Appliance ein Paket empfängt, für das die Routensuche der Quell-IP nicht dieselbe Schnittstelle ergeben hat wie die, auf der das Paket empfangen wurde.

   ciscoasa#show asp drop frame rpf-violated
     Reverse-path verify failed                                  2

   Anmerkung:  Empfehlung: Verfolgen Sie die Quelle des Datenverkehrs auf der Basis der Quell-IP, die in dieser nächsten Systemmeldung ausgegeben wird, und untersuchen Sie, warum dieser gefälschten Datenverkehr sendet.

   Anmerkung:  Systemprotokollmeldungen: 106021

7. %PIX|ASA-1-106022: Deny protocol connection spoof from source_address 
   to dest_address on interface interface_name

   Erläuterung

   Ein Paket, das mit einer Verbindung übereinstimmt, kommt auf einer anderen Schnittstelle an als der Schnittstelle, mit der die Verbindung begann.

   Wenn beispielsweise ein Benutzer eine Verbindung auf der internen Schnittstelle startet, die Sicherheits-Appliance jedoch dieselbe Verbindung erkennt, die auf einer Perimeterschnittstelle eingeht, verfügt die Sicherheits-Appliance über mehr als einen Pfad zu einem Ziel. Dies wird als asymmetrisches Routing bezeichnet und von der Security Appliance nicht unterstützt.

   Ein Angreifer versucht möglicherweise auch, Pakete von einer Verbindung an eine andere anzuhängen, um in die Sicherheits-Appliance einzudringen. In beiden Fällen zeigt die Sicherheits-Appliance diese Meldung an und beendet die Verbindung.

   Empfohlene Aktion: Diese Meldung wird angezeigt, wenn der Befehl ip verify reverse path nicht konfiguriert wurde. Stellen Sie sicher, dass das Routing nicht asymmetrisch ist.

8. %PIX|ASA-4-106023: Deny protocol src 
   [interface_name:source_address/source_port] dst 
   interface_name:dest_address/dest_port [type {string}, code {code}] by 
   access_group acl_ID

   Erläuterung

   Ein IP-Paket wurde von der ACL abgelehnt. Diese Meldung wird auch angezeigt, wenn die Protokolloption für eine ACL nicht aktiviert ist.

   Empfohlene Aktion: Wenn Nachrichten von derselben Quelladresse stammen, kann dies auf einen Fußabdruck- oder Port-Scanversuch hinweisen. Wenden Sie sich an die Administratoren des Remote-Hosts.

9. %PIX|ASA-3-210011: Connection limit exceeded cnt/limit for dir packet 
   from sip/sport to dip/dport on interface if_name.

10. %ASA-4-419002: Received duplicate TCP SYN from 
    in_interface:src_address/src_port to out_interface:dest_address/dest_port with 
    different initial sequence number.

    Erläuterung

    Diese Systemprotokollmeldung zeigt an, dass das Herstellen einer neuen Verbindung über das Firewall-Gerät dazu führt, dass mindestens einer der konfigurierten maximalen Verbindungsgrenzwerte überschritten wird. Die Systemprotokollmeldung gilt sowohl für Verbindungslimits, die mit einem statischen Befehl konfiguriert wurden, als auch für solche, die mit dem Cisco Modular Policy Framework konfiguriert wurden. Die neue Verbindung wird erst durch das Firewall-Gerät zugelassen, wenn eine der vorhandenen Verbindungen getrennt wird. Dadurch wird die aktuelle Verbindungsanzahl unter den konfigurierten Höchstwert gebracht.

    • cnt - Aktuelle Verbindungsanzahl

    • limit - konfiguriertes Verbindungslimit

    • dir - Richtung des ein- oder ausgehenden Datenverkehrs

    • sip - Quell-IP-Adresse

    • sport - Quellport

    • dip - Ziel-IP-Adresse

    • dport: Zielport

    • if_name: Der Name der Schnittstelle, von der die Datenverkehrseinheit empfangen wird, entweder Primary oder Secondary.

    Empfohlene Aktion: Da die Verbindungsgrenzwerte aus gutem Grund konfiguriert sind, kann diese Systemprotokollmeldung auf einen möglichen DoS-Angriff hinweisen. In diesem Fall kann es sich bei der Quelle des Datenverkehrs wahrscheinlich um eine gefälschte IP-Adresse handeln. Wenn die Quell-IP-Adresse nicht zufällig ausgewählt wird, kann es hilfreich sein, die Quelle zu identifizieren und mithilfe einer Zugriffsliste zu blockieren. In anderen Fällen können Sniffer-Traces und die Analyse der Quelle des Datenverkehrs dazu beitragen, unerwünschten Datenverkehr vom legitimen Datenverkehr zu isolieren.

Grundlegende Funktion zur Erkennung von Sicherheitsrisiken in ASA 8.x

Die Cisco Security Appliance ASA/PIX unterstützt die Funktion zur Erkennung von Sicherheitsrisiken ab Softwareversion 8.0. Mithilfe der grundlegenden Bedrohungserkennung überwacht die Sicherheits-Appliance aus den folgenden Gründen die Rate der verworfenen Pakete und Sicherheitsereignisse:

• Verweigerung durch Zugriffslisten

• Ungültiges Paketformat (wie invalid-ip-header oder invalid-tcp-hdr-length)

• Die Verbindungsgrenzwerte wurden überschritten (systemweite Ressourcengrenzwerte und in der Konfiguration festgelegte Grenzwerte).

• DoS-Angriff erkannt (z. B. ungültiger SPI, Fehler bei Prüfung der Stateful Firewall)

• Grundlegende Prüfungen der Firewall fehlgeschlagen (Diese Option ist eine kombinierte Rate, die alle Firewall-bezogenen Paketverluste in dieser Aufzählung berücksichtigt. Dies beinhaltet keine nicht Firewall-bezogenen Drops, wie z. B. Überlastung der Schnittstellen, bei der Anwendungsinspektion fehlgeschlagene Pakete und erkannte Scanning-Angriffe.)

• Verdächtige ICMP-Pakete erkannt

• Fehler bei der Anwendungsprüfung.

• Schnittstellenüberlastung

• Scan-Angriff erkannt (Diese Option überwacht Scan-Angriffe; Beispiel: Das erste TCP-Paket ist kein SYN-Paket, oder die TCP-Verbindung hat den Drei-Wege-Handshake nicht bestanden. Die vollständige Bedrohungserkennung (weitere Informationen finden Sie unter Konfigurieren der Bedrohungserkennung) verarbeitet diese Informationen zur Angriffsrate und reagiert darauf, indem Hosts als Angreifer klassifiziert und beispielsweise automatisch gemieden werden.)

• Unvollständige Sitzungserkennung, z. B. ein TCP-SYN-Angriff oder kein UDP-Datensitzungsangriff erkannt.

Wenn die Security Appliance eine Bedrohung erkennt, sendet sie sofort eine Systemprotokollmeldung (730100).

Die grundlegende Bedrohungserkennung beeinträchtigt die Leistung nur, wenn es Verwerfungen oder potenzielle Bedrohungen gibt. Selbst in diesem Szenario sind die Auswirkungen auf die Leistung unerheblich.

Der Befehl show threat-detection rate wird verwendet, um potenzielle Angriffe zu identifizieren, wenn Sie bei der Sicherheits-Appliance angemeldet sind.

ciscoasa#show threat-detection rate
                          Average(eps)    Current(eps) Trigger      Total events
  10-min ACL  drop:                  0               0       0                16
  1-hour ACL  drop:                  0               0       0               112
  1-hour SYN attck:                  5               0       2             21438
  10-min  Scanning:                  0               0      29               193
  1-hour  Scanning:                106               0      10            384776
  1-hour Bad  pkts:                 76               0       2            274690
  10-min  Firewall:                  0               0       3                22
  1-hour  Firewall:                 76               0       2            274844
  10-min DoS attck:                  0               0       0                 6
  1-hour DoS attck:                  0               0       0                42
  10-min Interface:                  0               0       0               204
  1-hour Interface:                 88               0       0            318225

Weitere Informationen zum Konfigurationsteil finden Sie im Abschnitt Configuring Basic Threat Detection (Konfigurieren der grundlegenden Bedrohungserkennung) im ASA 8.0-Konfigurationsleitfaden.

Syslog-Meldung 733100

Fehlermeldung:

%ASA-4-733100: Object drop rate rate_ID exceeded. Current burst rate 
is rate_val per second, max configured rate is rate_val; 
Current average rate is rate_val per second, max configured rate is 
rate_val; Cumulative total count is total_cnt

Das angegebene Objekt in der Systemprotokollmeldung hat die angegebene Burst-Schwellenwertrate oder die durchschnittliche Schwellenwertrate überschritten. Bei dem Objekt kann es sich um die Löschaktivität eines Hosts, eines TCP/UDP-Ports, eines IP-Protokolls oder um verschiedene Löschvorgänge aufgrund potenzieller Angriffe handeln. Sie zeigt an, dass das System potenziell angegriffen wird.

Hinweis: Diese Fehlermeldungen mit der Auflösung gelten nur für ASA 8.0 und höher.

1. Object (Objekt): Die allgemeine oder bestimmte Quelle für eine Zählung der Verlustrate, die Folgendes umfassen kann:

   • Firewall

   • Fehlerhafte Pakete

   • Durchsatzbegrenzung

   • DoS-Angriff

   • ACL-Verlust

   • Verbindungslimit

   • ICMP-Angriff

   • Scannen

   • SYN-Angriff

   • Inspizierung

   • Schnittstelle

2. rate_ID: Die konfigurierte Rate, die überschritten wird. Die meisten Objekte können mit bis zu drei verschiedenen Raten für verschiedene Intervalle konfiguriert werden.

3. rate_val: Ein bestimmter Wert für die Rate.

4. total_cnt - Die Gesamtanzahl seit dem Erstellen oder Löschen des Objekts.

Diese drei Beispiele zeigen, wie diese Variablen auftreten:

• Bei einem Schnittstellenverlust aufgrund einer CPU- oder Bus-Einschränkung:

  %ASA-4-733100: [Interface] drop rate 1 exceeded. Current burst rate is 1 per 
      second, 
  max configured rate is 8000; Current average rate is 2030 per second, 
  max configured rate is 2000; Cumulative total count is 3930654

• Ein Scanverlust aufgrund potenzieller Angriffe kann wie folgt aussehen:

  ASA-4-733100: [Scanning] drop rate-1 exceeded. Current burst rate is 10 per 
      second_
  max configured rate is 10; Current average rate is 245 per second_
  max configured rate is 5; Cumulative total count is 147409 (35 instances received)

• Bei fehlerhaften Paketen aufgrund potenzieller Angriffe:

  %ASA-4-733100: [Bad pkts] drop rate 1 exceeded. Current burst rate is 0 per 
      second, 
  max configured rate is 400; Current average rate is 760 per second, 
  max configured rate is 100; Cumulative total count is 1938933

Empfohlene Aktion:

Führen Sie diese Schritte gemäß dem angegebenen Objekttyp aus, der in der Meldung angezeigt wird:

1. Wenn die Syslog-Meldung eines der folgenden Objekte enthält:

   • Firewall

   • Fehlerhafte Pakete

   • Durchsatzbegrenzung

   • DoS-Angriff

   • ACL-Verlust

   • Verbindungslimit

   • ICMP-Angriff

   • Scannen

   • SYN-Angriff

   • Inspizierung

   • Schnittstelle

   Überprüfen Sie, ob die Abwurfrate für die laufende Umgebung akzeptabel ist.

2. Passen Sie die Schwellenwertrate des jeweiligen Drops an, indem Sie den Befehl rate xxx zur Bedrohungserkennung ausführen, wobei xxx einer der folgenden Werte ist:

   • ACL-Drop

   • Paketverlust

   • conn-limit-drop

   • DOS-Drop

   • fw-drop

   • ICMP-Drop

   • inspect-drop

   • Interface-Drop

   • Scanning-Bedrohung

   • Syn-Angriff

3. Wenn es sich bei dem Objekt in der Syslog-Nachricht um einen TCP- oder UDP-Port, ein IP-Protokoll oder einen Host-Drop handelt, überprüfen Sie, ob die Drop-Rate für die laufende Umgebung akzeptabel ist.

4. Passen Sie die Schwellenwertrate des jeweiligen Drops an, indem Sie den Befehl "Threat-Detection rate bad-packet-drop" ausführen. Weitere Informationen finden Sie im Abschnitt Configuring Basic Threat Detection (Konfigurieren der grundlegenden Bedrohungserkennung) im ASA 8.0-Konfigurationsleitfaden.

Hinweis: Wenn Sie nicht möchten, dass die Warnmeldung "Drop-Rate überschreitet" angezeigt wird, können Sie sie deaktivieren, indem Sie den Befehl no threat-detection basic-Befehl ausführen.

Zugehörige Informationen

• Support-Seite für Cisco Adaptive Security Appliances der Serie 5500
• Cisco Serie 500 - Support-Seite für PIX
• Definieren von Strategien zum Schutz vor TCP-SYN-Denial-of-Service-Angriffen
• Cisco Applied Mitigation Bulletin: Modul zur Identifikation und Beseitigung von Denial-of-Service-Schwachstellen in Content Switching
• Cisco Applied Mitigation Bulletin: Identifizierung und Beseitigung der verschiedenen Schwachstellen im Modul für Cisco PIX- und ASA-Appliances und -Firewall-Services
• Technischer Support und Dokumentation für Cisco Systeme