Charakterisierung und Verfolgung von Paketfluten mit Cisco Routern

Einleitung

Denial-of-Service-Angriffe (DoS) sind im Internet weit verbreitet. Der erste Schritt, den Sie verwenden, um auf einen solchen Angriff zu reagieren, besteht darin, genau herauszufinden, um welche Art von Angriff es sich handelt. Viele der gebräuchlichen DoS-Angriffe basieren auf Paketfluten mit hoher Bandbreite oder auf anderen sich wiederholenden Paketströmen.

Pakete in vielen DoS-Angriffs-Streams können isoliert werden, wenn sie mit Einträgen in der Zugriffsliste der Cisco IOS® Software abgeglichen werden. Dies ist zum Herausfiltern von Angriffen nützlich. Es ist auch nützlich, wenn Sie unbekannte Angriffe charakterisieren und wenn Sie "gefälschte" Paket-Streams zu ihren tatsächlichen Quellen zurückverfolgen.

Cisco Router-Funktionen wie Debug-Protokollierung und IP-Abrechnung können manchmal für ähnliche Zwecke verwendet werden, insbesondere bei neuen oder ungewöhnlichen Angriffen. Mit den neuesten Versionen der Cisco IOS-Software sind Zugriffslisten und Zugriffslistenprotokollierung jedoch die wichtigsten Funktionen zur Charakterisierung und Nachverfolgung gängiger Angriffe.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Konventionen

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

Die häufigsten DoS-Angriffe

Dabei ist eine Vielzahl von DoS-Angriffen möglich. Selbst wenn Sie Angriffe ignorieren, die Software-Bugs verwenden, um Systeme mit relativ geringem Datenverkehr abzuschalten, bleibt die Tatsache bestehen, dass jedes IP-Paket, das über das Netzwerk gesendet werden kann, verwendet werden kann, um einen Flooding-DoS-Angriff auszuführen. Wenn Sie angegriffen werden, müssen Sie immer die Möglichkeit in Betracht ziehen, dass das, was Sie sehen, etwas ist, das nicht in die üblichen Kategorien fällt.

Vorbehaltlich dieses Vorbehalts ist es jedoch auch gut, sich daran zu erinnern, dass viele Angriffe ähnlich sind. Angreifer entscheiden sich für verbreitete Exploits, weil sie besonders effektiv und schwer zu verfolgen sind oder weil ihnen Tools zur Verfügung stehen. Vielen DoS-Angreifern fehlt es an den Fähigkeiten und Motivationen, eigene Tools zu entwickeln und im Internet verfügbare Programme zu nutzen. Diese Tools sind oft in und aus der Mode gekommen.

Zum Zeitpunkt der Verfassung dieses Dokuments, im Juli 1999, waren die meisten Kundenanfragen nach Unterstützung durch Cisco auf den "Schlumpf"-Angriff zurückzuführen. Dieser Angriff hat zwei Opfer: ein "letztendliches Ziel" und einen "Reflektor". Der Angreifer sendet einen Stimulus-Stream von ICMP-Echo-Anfragen ("Pings") an die Broadcast-Adresse des Reflektor-Subnetzes. Die Quelladressen dieser Pakete werden gefälscht, um die Adresse des endgültigen Ziels zu sein. Für jedes vom Angreifer gesendete Paket antworten viele Hosts im Reflektor-Subnetz. Dadurch wird das letztliche Ziel überflutet und Bandbreite für beide Opfer verschwendet.

Ein ähnlicher Angriff, der als "Fraggle" bezeichnet wird, verwendet auf die gleiche Weise gerichtete Broadcasts, verwendet jedoch UDP-Echo-Anfragen anstelle von ICMP-Echo-Anfragen (Internet Control Message Protocol). Fraggle erreicht normalerweise einen kleineren Verstärkungsfaktor als Schlumpf und ist viel weniger beliebt.

Schlumpf-Angriffe werden in der Regel bemerkt, weil eine Netzwerkverbindung überlastet wird. Eine vollständige Beschreibung dieser Angriffe und der Abwehrmaßnahmen finden Sie auf der Seitemit Informationen zu Denial-of-Service-Angriffen.

Ein weiterer häufiger Angriff ist die SYN-Flut, bei der ein Zielcomputer mit TCP-Verbindungsanforderungen geflutet wird. Die Quelladressen und Quell-TCP-Ports der Verbindungsanforderungspakete sind randomisiert. Der Zweck besteht darin, den Ziel-Host zu zwingen, Zustandsinformationen für viele Verbindungen zu speichern, die nie abgeschlossen werden.

SYN-Flood-Angriffe werden in der Regel bemerkt, weil der Ziel-Host (häufig ein HTTP- oder SMTP-Server) extrem langsam wird, abstürzt oder abstürzt. Es ist auch möglich, dass der Datenverkehr, der vom Ziel-Host zurückkehrt, auf den Routern Probleme verursacht. Der Grund hierfür ist, dass dieser zurückgegebene Datenverkehr an die randomisierten Quelladressen der ursprünglichen Pakete geleitet wird, dass ihm die lokalen Eigenschaften des "echten" IP-Datenverkehrs fehlen und dass Routen-Caches überlaufen können. Bei Cisco Routern tritt dieses Problem häufig dadurch auf, dass dem Router nicht genügend Arbeitsspeicher zur Verfügung steht.

Zusammengenommen machen die Überflutungen durch Smurf- und SYN-Flood-Angriffe den Großteil der an Cisco gemeldeten DoS-Angriffe aus. Daher ist es sehr wichtig, sie schnell zu erkennen. Beide Angriffe (sowie einige "Second-Tier"-Angriffe, wie Ping-Floods) sind leicht zu erkennen, wenn Sie Cisco Zugriffslisten verwenden.

Eine Zugriffsliste für DoS-Merkmale

Stellen Sie sich einen Router mit zwei Schnittstellen vor. Ethernet 0 ist mit einem internen LAN eines Unternehmens oder eines kleinen ISP verbunden. Seriell 0 stellt eine Internetverbindung über einen Upstream-ISP bereit. Die Eingangspaketrate bei der seriellen 0 ist mit der vollen Verbindungsbandbreite "gekoppelt", und die Hosts im LAN laufen langsam, stürzen ab, hängen oder zeigen andere Anzeichen eines DoS-Angriffs. Der kleine Standort, an dem der Router eine Verbindung herstellt, verfügt über keinen Netzwerkanalysator, und die Menschen dort haben wenig oder keine Erfahrung mit dem Lesen von Analysatorspuren, selbst wenn diese vorhanden sind.

Nehmen Sie nun an, Sie wenden eine Zugriffsliste an, wie diese Ausgabe zeigt:

access-list 169 permit icmp any any echo
access-list 169 permit icmp any any echo-reply
access-list 169 permit udp any any eq echo
access-list 169 permit udp any eq echo any
access-list 169 permit tcp any any established
access-list 169 permit tcp any any
access-list 169 permit ip any any

interface serial 0
ip access-group 169 in

Diese Liste filtert keinen Datenverkehr heraus; alle Einträge sind Genehmigungen. Da Pakete jedoch auf sinnvolle Weise kategorisiert werden, kann die Liste verwendet werden, um alle drei Angriffstypen vorläufig zu diagnostizieren: Schlumpf, SYN-Überflutungen und Fraggle.

Schlumpf ultimatives Ziel

Wenn Sie den Befehl show access-list ausführen, wird eine Ausgabe ähnlich der folgenden angezeigt:

Extended IP access list 169
    permit icmp any any echo (2 matches)
    permit icmp any any echo-reply (21374 matches)
    permit udp any any eq echo
    permit udp any eq echo any
    permit tcp any any established (150 matches)
    permit tcp any any (15 matches)
    permit ip any any (45 matches)

Der Großteil des Datenverkehrs, der an der seriellen Schnittstelle eingeht, besteht aus ICMP-Echoantwortpaketen. Das ist wahrscheinlich die Signatur eines Schlumpf-Angriffs, und unsere Seite ist das ultimative Ziel, nicht der Reflektor. Wenn Sie die Zugriffsliste überarbeiten, können Sie weitere Informationen über den Angriff sammeln, wie die folgende Ausgabe zeigt:

interface serial 0
no ip access-group 169 in

no access-list 169
access-list 169 permit icmp any any echo
access-list 169 permit icmp any any echo-reply log-input
access-list 169 permit udp any any eq echo
access-list 169 permit udp any eq echo any
access-list 169 permit tcp any any established
access-list 169 permit tcp any any
access-list 169 permit ip any any

interface serial 0
ip access-group 169 in

Die Änderung besteht darin, dass das Schlüsselwort log-input zum Eintrag in der Zugriffsliste hinzugefügt wird, der mit dem verdächtigen Datenverkehr übereinstimmt. (In Cisco IOS-Softwareversionen vor 11.2 fehlt dieses Schlüsselwort. Verwenden Sie stattdessen das Schlüsselwort "log".) Dadurch protokolliert der Router Informationen zu Paketen, die mit dem Listeneintrag übereinstimmen. Wenn Sie davon ausgehen, dass die gepufferte Protokollierung konfiguriert ist, können Sie die Meldungen anzeigen, die mit dem Befehl show log (es kann eine Weile dauern, bis die Meldungen aufgrund der Ratenbeschränkung akkumuliert werden) ausgegeben werden. Die Meldungen werden ähnlich wie in dieser Ausgabe angezeigt:

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.142 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.113 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.72 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.154 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.15 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.142 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.47 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.35 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.113 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.59 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.82 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.56 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.84 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.47 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.35 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.15 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.33 
(Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

Die Quelladressen der Echo-Antwort-Pakete sind in den Präfixen 192.168.212.0/24, 192.168.45.0/24 und 172.16.132.0/24 zusammengefasst. (Private Adressen in den Netzwerken 192.168.x.x und 172.16.x.x befinden sich nicht im Internet; dies ist eine Lab-Abbildung.) Dies ist sehr charakteristisch für einen Schlumpf-Angriff, und die Quelladressen sind die Adressen der Schlumpf-Reflektoren. Wenn Sie die Besitzer dieser Adressblöcke in den entsprechenden Internet-"Whois"-Datenbanken suchen, können Sie die Administratoren dieser Netzwerke finden und um ihre Hilfe bei der Bewältigung des Angriffs bitten.

An diesem Punkt ist es wichtig, sich bei einem Schlumpf-Vorfall daran zu erinnern, dass diese Reflektoren andere Opfer sind, keine Angreifer. Es ist äußerst selten, dass Angreifer ihre eigenen Quelladressen auf IP-Paketen in jeder DoS-Flut verwenden, und ihnen ist dies bei einem funktionierenden Schlumpf-Angriff nicht möglich. Jede Adresse in einem Flood-Paket sollte entweder als vollständig gefälscht oder als Adresse eines Opfers irgendeiner Art angesehen werden. Der produktivste Ansatz für das ultimative Ziel eines Schlumpf-Angriffs ist es, die Reflektoren zu kontaktieren, entweder um sie zu bitten, ihre Netzwerke neu zu konfigurieren, um den Angriff abzuschalten, oder um ihre Hilfe bei der Verfolgung des Reizstromes zu bitten.

Da der Schaden am ultimativen Ziel eines Schlumpf-Angriffs in der Regel durch Überlastung der eingehenden Verbindung aus dem Internet verursacht wird, gibt es oft keine andere Reaktion als die Reflektoren zu kontaktieren. Bis die Pakete unter der Kontrolle des Ziels an einem beliebigen Computer eintreffen, ist der größte Schaden bereits entstanden.

Eine provisorische Maßnahme besteht darin, den Upstream-Netzwerkanbieter zu bitten, alle ICMP-Echoantworten oder alle ICMP-Echoantworten von bestimmten Reflektoren herauszufiltern. Es wird nicht empfohlen, diese Art von Filter dauerhaft an Ort und Stelle zu lassen. Selbst für einen temporären Filter sollten nur Echoantworten gefiltert werden, nicht alle ICMP-Pakete. Eine weitere Möglichkeit besteht darin, den Upstream-Provider QoS- und Ratenbegrenzungsfunktionen nutzen zu lassen, um die für Echo-Antworten verfügbare Bandbreite einzuschränken. Eine sinnvolle Bandbreitenbeschränkung kann unbegrenzt bestehen bleiben. Beide Ansätze hängen davon ab, dass die Ausrüstung des vorgelagerten Anbieters über die erforderliche Kapazität verfügt, und manchmal steht diese Kapazität nicht zur Verfügung.

Schlumpf-Reflektor

Wenn der eingehende Datenverkehr aus Echo-Anfragen und nicht aus Echo-Antworten besteht (mit anderen Worten, wenn der erste Eintrag in der Zugriffsliste mehr Übereinstimmungen zählt als vernünftigerweise angenommen werden konnte), vermuten Sie einen Schlumpf-Angriff, bei dem das Netzwerk als Reflektor verwendet wird, oder möglicherweise eine einfache Ping-Flut. In jedem Fall, wenn der Angriff ein Erfolg ist, würden Sie erwarten, dass die ausgehende Seite der seriellen Linie überschwemmt wird, wie auch die eingehende Seite. Tatsächlich würde man aufgrund des Verstärkungsfaktors erwarten, dass die Ausgangsseite noch stärker überlastet ist als die Eingangsseite.

Es gibt mehrere Möglichkeiten, den Schlumpf-Angriff von der einfachen Ping-Flut zu unterscheiden:

• Schlumpf-Stimuluspakete werden an eine gerichtete Broadcast-Adresse anstatt an eine Unicast-Adresse gesendet, während normale Ping-Überschwemmungen fast immer Unicasts verwenden. Sie können die Adressen, die das log-input-Schlüsselwort verwenden, im entsprechenden Zugriffslisteneintrag sehen.

• Wenn Sie als Schlumpfreflektor verwendet werden, gibt es eine unverhältnismäßig große Anzahl von Ausgabesendungen in der Show-Interface-Anzeige auf der Ethernet-Seite des Systems, und in der Regel eine unverhältnismäßig große Anzahl von Sendungen, die in der Show-IP-Traffic-Anzeige gesendet werden. Eine Standard-Ping-Flood erhöht den Broadcast-Datenverkehr im Hintergrund nicht.

• Wenn Sie als Schlumpf-Reflektor verwendet werden, geht mehr Datenverkehr in Richtung Internet aus als Datenverkehr, der aus dem Internet eingeht. Im Allgemeinen gibt es mehr Ausgangspakete als Eingangspakete an der seriellen Schnittstelle. Selbst wenn der Reizstrom die Eingangsschnittstelle vollständig ausfüllt, ist der Antwortstrom größer als der Reizstrom, und Paketverluste werden gezählt.

Ein Schlumpf-Reflektor hat mehr Möglichkeiten als das ultimative Ziel eines Schlumpf-Angriffs. Wenn ein Reflektor beschließt, den Angriff abzuschalten, reicht in der Regel die angemessene Verwendung von IP-Directed-Broadcast (oder entsprechenden Nicht-IOS-Befehlen) aus. Diese Befehle gehören in jede Konfiguration, auch wenn kein aktiver Angriff stattfindet. Weitere Informationen zum Schutz Ihrer Cisco Geräte vor der Verwendung bei einem Smart Attack finden Sie unter Improving Security on Cisco Routers. Weitere allgemeine Informationen zu Smartphone-Angriffen im Allgemeinen und Informationen zum Schutz von Geräten anderer Hersteller als Cisco finden Sie auf der Seitemit Informationen zu Denial-of-Service-Angriffen.

Ein Schlumpf-Reflektor ist dem Angreifer einen Schritt näher als sein letztendliches Ziel und daher besser in der Lage, den Angriff zu verfolgen. Wenn Sie den Angriff verfolgen möchten, müssen Sie mit den beteiligten ISPs zusammenarbeiten. Wenn Sie Maßnahmen ergreifen lassen möchten, wenn Sie die Spur vervollständigen, müssen Sie mit den entsprechenden Strafverfolgungsbehörden zusammenarbeiten. Wenn Sie versuchen, einen Angriff zu verfolgen, wird empfohlen, dass Sie die Strafverfolgungsbehörden so schnell wie möglich einbeziehen. Im Abschnitt Tracing finden Sie technische Informationen zur Verfolgung von Überflutungsangriffen.

Fraggle

Der Fraggle-Angriff ist vergleichbar mit dem Schlumpf-Angriff, abgesehen davon, dass für den Stimulus-Stream UDP-Echo-Anfragen anstelle von ICMP-Echo-Anfragen verwendet werden. Die dritte und vierte Zeile der Zugriffsliste kennzeichnen Fraggle-Angriffe. Die angemessene Reaktion auf die Opfer ist dieselbe, abgesehen davon, dass das UDP-Echo in den meisten Netzwerken ein weniger wichtiger Dienst ist als das ICMP-Echo. Daher können Sie sie vollständig deaktivieren, mit weniger negativen Folgen.

SYN-Überschwemmungen

Die fünfte und sechste Zeile der Zugriffsliste lauten wie folgt:

access-list 169 permit tcp any any established
access-list 169 permit tcp any any

Die erste Zeile entspricht einem TCP-Paket mit dem ACK-Bitsatz. Für unsere Zwecke bedeutet dies, dass es mit jedem Paket übereinstimmt, das kein TCP SYN ist. Die zweite Zeile stimmt nur mit Paketen überein, die TCP-SYNs sind. Eine SYN-Flood kann anhand der Zähler in diesen Listeneinträgen leicht identifiziert werden. Im normalen Datenverkehr übersteigt die Anzahl der Nicht-SYN-TCP-Pakete die der SYNs um mindestens den Faktor zwei, in der Regel sogar um mehr als vier oder fünf. Bei einer SYN-Flood übersteigt die Anzahl der SYNs in der Regel die Anzahl der Nicht-SYN-TCP-Pakete um ein Vielfaches.

Die einzige Bedingung ohne Angriff, die diese Signatur erzeugt, ist eine massive Überlastung echter Verbindungsanforderungen. Im Allgemeinen kommt eine solche Überlastung nicht unerwartet und erfordert nicht so viele SYN-Pakete wie eine echte SYN-Flood. Außerdem enthalten SYN-Floods häufig Pakete mit völlig ungültigen Quelladressen. Mithilfe des Schlüsselworts log-input kann man sehen, ob Verbindungsanfragen von solchen Adressen stammen.

Es gibt einen Angriff, der als "Process Table Attack" bezeichnet wird und eine gewisse Ähnlichkeit mit der SYN-Flood aufweist. Bei dem Angriff in der Prozesstabelle werden die TCP-Verbindungen abgeschlossen und anschließend ohne weiteren Protokollverkehr ein Timeout zugelassen, während bei der SYN-Flood nur die ursprünglichen Verbindungsanforderungen gesendet werden. Da ein Prozesstabellen-Angriff den Abschluss des anfänglichen TCP-Handshakes erfordert, muss er in der Regel unter Verwendung der IP-Adresse eines echten Systems gestartet werden, auf das der Angreifer Zugriff hat (in der Regel gestohlener Zugriff). So lassen sich mittels Paketprotokollierung leicht von SYN-Flood-Angriffen unterscheiden. Alle SYNs in einem Process Table-Angriff stammen von einer oder mehreren Adressen oder höchstens von einem oder mehreren Subnetzen.

Die Reaktionsmöglichkeiten für die Opfer der SYN-Überschwemmungen sind sehr begrenzt. Das angegriffene System ist in der Regel ein wichtiger Dienst, und durch die Blockierung des Zugriffs auf das System wird in der Regel erreicht, was der Angreifer will. Viele Router- und Firewall-Produkte, darunter auch die von Cisco, verfügen über Funktionen, mit denen die Auswirkungen von SYN-Überschwemmungen reduziert werden können. Die Wirksamkeit dieser Funktionen hängt jedoch von der Umwelt ab. Weitere Informationen finden Sie in der Dokumentation zum Feature-Set der Cisco IOS Firewall, der Dokumentation zur Cisco IOS TCP Intercept-Funktion und Improving Security on Cisco Routers.

SYN-Überflutungen können verfolgt werden, aber der Verfolgungsprozess erfordert die Unterstützung jedes ISPs auf dem Weg vom Angreifer zum Opfer. Wenn Sie eine SYN-Überschwemmung aufspüren möchten, wenden Sie sich frühzeitig an die Strafverfolgungsbehörden, und arbeiten Sie mit Ihrem eigenen Service Provider zusammen. Im Abschnitt zur Ablaufverfolgung dieses Dokuments finden Sie weitere Informationen zur Ablaufverfolgung bei Verwendung von Cisco Geräten.

Andere Angriffe

Wenn Sie glauben, dass Sie sich einem Angriff ausgesetzt sehen, und wenn Sie diesen Angriff anhand von IP-Quell- und Zieladressen, Protokollnummern und Portnummern charakterisieren können, können Sie Ihre Hypothese mithilfe von Zugriffslisten testen. Erstellen Sie einen Zugriffslisteneintrag, der mit dem verdächtigen Datenverkehr übereinstimmt, wenden Sie ihn auf eine geeignete Schnittstelle an, und beobachten Sie entweder die Übereinstimmungszähler, oder protokollieren Sie den Datenverkehr.

Protokollierung und Gegenargumente

Der Leistungsindikator eines Zugriffslisteneintrags zählt alle Übereinstimmungen mit diesem Eintrag. Wenn Sie eine Zugriffsliste auf zwei Schnittstellen anwenden, sind die angezeigten Zählungen aggregierte Zählungen.

Bei der Zugriffslistenprotokollierung werden nicht alle Pakete angezeigt, die mit einem Eintrag übereinstimmen. Die Protokollierung ist auf die Übertragungsrate beschränkt, um eine CPU-Überlastung zu vermeiden. Die Protokollierung zeigt eine ausreichend repräsentative Stichprobe, jedoch keine vollständige Paketverfolgung. Denken Sie daran, dass es Pakete gibt, die Sie nicht sehen können.

Bei einigen Softwareversionen funktioniert die Zugriffslistenprotokollierung nur in bestimmten Schaltmodi. Wenn ein Zugriffslisteneintrag viele Übereinstimmungen zählt, aber nichts protokolliert, versuchen Sie, den Routen-Cache zu löschen, um das Verarbeiten von Paketen zu erzwingen. Seien Sie vorsichtig, wenn Sie dies auf stark ausgelasteten Routern mit vielen Schnittstellen tun. Ein großer Teil des Datenverkehrs kann verloren gehen, während der Cache neu erstellt wird. Verwenden Sie nach Möglichkeit Cisco Express Forwarding.

Zugriffslisten und Protokollierung wirken sich auf die Leistung aus, sind jedoch nicht sehr umfangreich. Gehen Sie bei Routern mit einer CPU-Auslastung von mehr als 80 Prozent sorgfältig vor, oder wenn Sie Zugriffslisten auf Hochgeschwindigkeits-Schnittstellen anwenden.

Verfolgung

Die Quelladressen von DoS-Paketen sind fast immer auf Werte gesetzt, die nichts mit den Angreifern selbst zu tun haben. Daher sind sie für die Identifizierung der Angreifer nicht von Nutzen. Die einzige zuverlässige Methode zur Identifizierung der Quelle eines Angriffs besteht darin, ihn Hop für Hop durch das Netzwerk zu verfolgen. Dieser Prozess umfasst die Neukonfiguration von Routern und die Überprüfung von Protokollinformationen. Es ist die Zusammenarbeit aller Netzbetreiber auf dem Weg vom Angreifer zum Opfer erforderlich. Um diese Zusammenarbeit sicherzustellen, müssen in der Regel Strafverfolgungsbehörden beteiligt werden, die ebenfalls beteiligt sein müssen, wenn Maßnahmen gegen den Angreifer ergriffen werden sollen.

Der Prozess zur Rückverfolgung von DoS-Überschwemmungen ist relativ einfach. Ausgehend von einem Router (mit dem Namen "A"), der bekanntermaßen Datenverkehr überträgt, wird der Router (mit dem Namen "B") identifiziert, von dem A den Datenverkehr empfängt. Anschließend meldet man sich bei B an und findet den Router (mit dem Namen "C"), von dem B den Datenverkehr empfängt. Dies geht so lange, bis die endgültige Quelle gefunden ist.

Diese Methode weist mehrere Komplikationen auf, die in dieser Liste beschrieben werden:

• Die "ultimative Quelle" kann ein Computer sein, der zwar vom Angreifer kompromittiert wurde, sich aber im Besitz eines anderen Opfers befindet und von diesem betrieben wird. In diesem Fall ist die Nachverfolgung der DoS-Überschwemmung nur der erste Schritt.

• Angreifer wissen, dass sie zurückverfolgt werden können und setzen ihre Angriffe in der Regel nur für eine begrenzte Zeit fort. Es ist vielleicht nicht genug Zeit, um die Überschwemmung tatsächlich zu verfolgen.

• Angriffe können aus mehreren Quellen stammen, insbesondere wenn der Angreifer relativ komplex ist. Es ist wichtig, so viele Quellen wie möglich zu identifizieren.

• Kommunikationsprobleme verlangsamen den Verfolgungsprozess. Häufig verfügen ein oder mehrere der beteiligten Netzbetreiber nicht über ausreichend qualifiziertes Personal.

• Aufgrund rechtlicher und politischer Bedenken kann es schwierig sein, gegen Angreifer vorzugehen, selbst wenn man einen findet.

Die meisten Bemühungen zur Verfolgung von DoS-Angriffen scheitern. Aus diesem Grund versuchen viele Netzwerkbetreiber nicht einmal, einen Angriff zu verfolgen, wenn sie nicht unter Druck gesetzt werden. Viele andere verfolgen nur "ernste" Angriffe, mit unterschiedlichen Definitionen von "ernsten". Einige helfen nur dann mit einer Spur, wenn es sich um die Strafverfolgung handelt.

Verfolgung mit "log-input"

Wenn Sie einen Angriff verfolgen möchten, der über einen Cisco Router läuft, können Sie am effektivsten einen Zugriffslisteneintrag erstellen, der mit dem Angriffsverkehr übereinstimmt, das log-input-Schlüsselwort anhängen und die ausgehende Zugriffsliste auf die Schnittstelle anwenden, über die der Angriffs-Stream an sein endgültiges Ziel gesendet wird. Die von der Zugriffsliste erzeugten Protokolleinträge geben die Router-Schnittstelle an, über die der Datenverkehr eingeht. Handelt es sich bei der Schnittstelle um eine Multipoint-Verbindung, geben Sie die Layer-2-Adresse des Geräts an, von dem sie empfangen wird. Mit der Layer-2-Adresse kann dann der nächste Router in der Kette identifiziert werden, z. B. mit dem Befehl show ip arp mac-address.

SYN-Flood

Um eine SYN-Flood zu verfolgen, können Sie eine Zugriffsliste ähnlich dieser erstellen:

access-list 169 permit tcp any any established
access-list 169 permit tcp any host victim-host log-input
access-list 169 permit ip any any

Dabei werden alle für den Ziel-Host bestimmten SYN-Pakete einschließlich legitimer SYNs protokolliert. Um den wahrscheinlichsten Pfad zum Angreifer zu identifizieren, untersuchen Sie die Protokolleinträge im Detail. Im Allgemeinen ist die Quelle der Flut die Quelle, von der die größte Anzahl übereinstimmender Pakete eingeht. Die IP-Quelladressen selbst bedeuten nichts. Sie suchen nach Quellschnittstellen und Quell-MAC-Adressen. Manchmal ist es möglich, Flood-Pakete von legitimen Paketen zu unterscheiden, weil Flood-Pakete ungültige Quelladressen haben können. Jedes Paket, dessen Quelladresse ungültig ist, ist wahrscheinlich Teil der Flut.

Die Überschwemmungen können aus mehreren Quellen stammen, obwohl dies bei SYN-Überschwemmungen relativ ungewöhnlich ist.

Schlumpf-Reiz

Um einen Schlumpf-Stimulus-Stream zu verfolgen, verwenden Sie eine Zugriffsliste wie diese:

access-list 169 permit icmp any any echo log-input
access-list 169 permit ip any any

Beachten Sie, dass sich der erste Eintrag nicht auf Pakete beschränkt, die für die Reflektoradresse bestimmt sind. Der Grund dafür ist, dass die meisten Schlumpfangriffe mehrere Reflektornetzwerke nutzen. Wenn Sie nicht in Kontakt mit dem ultimativen Ziel sind, kennen Sie möglicherweise nicht alle Reflektoradressen. Wenn Ihre Spur näher an die Quelle des Angriffs herankommt, können Sie Echo-Anfragen an immer mehr Ziele sehen. Das ist ein gutes Zeichen.

Wenn Sie jedoch mit einem großen Teil des ICMP-Verkehrs zu tun haben, kann dies zu viele Protokollierungsinformationen generieren, die Sie nicht so einfach lesen können. In diesem Fall können Sie die Zieladresse auf einen der Reflektoren beschränken, die bekanntermaßen verwendet werden. Eine weitere nützliche Taktik ist es, einen Eintrag zu verwenden, der die Tatsache ausnutzt, dass Netzmasken von 255.255.255.0 im Internet sehr häufig vorkommen. Und da Angreifer Schlumpf-Reflektoren finden, ist es noch wahrscheinlicher, dass die tatsächlich für Schlumpf-Angriffe verwendeten Reflektor-Adressen mit dieser Maske übereinstimmen. Hostadressen, die auf .0 oder .255 enden, sind im Internet sehr ungewöhnlich. Daher können Sie einen relativ spezifischen Erkenner für Schlumpf-Stimulusströme erstellen, wie diese Ausgabe zeigt:

access-list 169 permit icmp any host known-reflector echo log-input
access-list 169 permit icmp any 0.0.0.255 255.255.255.0 echo log-input
access-list 169 permit icmp any 0.0.0.0 255.255.255.0 echo log-input
access-list 169 permit ip any any

Mit dieser Liste können Sie viele der "Rauschpakete" aus Ihrem Protokoll entfernen, während Sie noch eine gute Chance haben, zusätzliche Reizströme zu entdecken, wenn Sie näher an den Angreifer herankommen.

Verfolgung ohne "log-Eingabe"

Das Schlüsselwort log-input steht in den Cisco IOS Software-Versionen 11.2 und höher sowie in bestimmten 11.1-basierten Softwareversionen zur Verfügung, die speziell für den Service Provider-Markt entwickelt wurden. Ältere Software unterstützt dieses Keyword nicht. Wenn Sie einen Router mit älterer Software verwenden, haben Sie drei praktikable Optionen:

• Erstellen Sie eine Zugriffsliste ohne Protokollierung, jedoch mit Einträgen, die dem verdächtigen Datenverkehr entsprechen. Wenden Sie die Liste nacheinander auf der Eingabeseite jeder Schnittstelle an, und beobachten Sie die Zähler. Suchen Sie nach Schnittstellen mit hohen Übereinstimmungsraten. Diese Methode hat einen sehr geringen Performance-Overhead und eignet sich gut zur Identifizierung von Quellschnittstellen. Der größte Nachteil ist, dass es keine Link-Layer-Quelladressen gibt und daher vor allem für Point-to-Point-Leitungen nützlich ist.

• Erstellen Sie Zugriffslisteneinträge mit dem log-Schlüsselwort (im Gegensatz zu log-input). Wenden Sie die Liste wiederum auf die Eingangsseite jeder Schnittstelle an. Diese Methode gibt immer noch keine Quell-MAC-Adressen aus, kann aber für die Anzeige von IP-Daten nützlich sein. So können Sie z. B. überprüfen, ob ein Paket-Stream wirklich Teil eines Angriffs ist. Die Auswirkungen auf die Leistung können mäßig bis hoch sein, und neuere Software ist leistungsfähiger als ältere Software.

• Verwenden Sie den Befehl debug ip packet detail, um Informationen über Pakete zu sammeln. Diese Methode stellt MAC-Adressen zur Verfügung, kann jedoch schwerwiegende Auswirkungen auf die Leistung haben. Mit dieser Methode kann leicht ein Fehler gemacht und ein Router unbrauchbar gemacht werden. Wenn Sie diese Methode verwenden, stellen Sie sicher, dass der Router den Angriffsverkehr im schnellen, autonomen oder optimalen Modus umschaltet. Verwenden Sie eine Zugriffsliste, um das Debuggen auf die wirklich benötigten Informationen zu beschränken. Protokollieren Sie Debugging-Informationen im lokalen Protokollpuffer, deaktivieren Sie jedoch die Protokollierung von Debugging-Informationen in Telnet-Sitzungen und in der Konsole. Wenn möglich, arrangieren Sie, dass sich jemand in der Nähe des Routers befindet, damit dieser bei Bedarf aus- und wieder eingeschaltet werden kann.

  Denken Sie daran, dass der Befehl debug ip packet keine Informationen über Fast-Switched-Pakete anzeigt. Sie müssen den Befehl clear ip cache eingeben, um Informationen zu erfassen. Mit jedem clear-Befehl erhalten Sie ein oder zwei Pakete mit Debug-Ausgabe.

Zugehörige Informationen

• Kerberos
• Technischer Support und Dokumentation für Cisco Systeme