Techniken zur Umgehung durch Angreifer

Unabhängig davon, ob er Informationen sammelt oder einen Angriff startet, wird im Allgemeinen erwartet, dass der Angreifer nicht entdeckt wird. Obwohl einige IP-Adressen- und Port-Scans offensichtlich und leicht zu erkennen sind, verwenden gerissenere Angreifer eine Vielzahl von Mitteln, um ihre Aktivitäten zu verbergen. Techniken wie die Verwendung von FIN-Scans anstelle von SYN-Scans – von denen Angreifer wissen, dass die meisten Firewalls und Intrusion Detection-Programme sie erkennen – deuten auf eine Entwicklung der Aufklärungs- und Exploit-Techniken hin, um sich der Erkennung zu entziehen und ihre Aufgaben erfolgreich zu erfüllen.

Ein FIN-Scan sendet TCP-Segmente mit gesetztem FIN-Flag, um eine Antwort zu provozieren (ein TCP-Segment mit gesetztem RST-Flag) und dadurch einen aktiven Host oder einen aktiven Port auf einem Host zu entdecken. Angreifer könnten diesen Ansatz verwenden, anstatt einen Adress-Sweep mit ICMP-Echo-Anfragen oder einen Adressscan mit SYN-Segmenten durchzuführen, da sie wissen, dass viele Firewalls in der Regel vor den beiden letztgenannten Ansätzen schützen, aber nicht unbedingt vor FIN-Segmenten. Die Verwendung von TCP-Segmenten mit gesetztem FIN-Flag kann sich der Erkennung entziehen und so den Angreifern helfen, ihre Aufklärungsbemühungen erfolgreich durchzuführen.

Standardmäßig prüft Junos OS im ersten Paket einer Sitzung auf SYN-Flags und lehnt alle TCP-Segmente mit Nicht-SYN-Flags ab, die versuchen, eine Sitzung zu initiieren. Sie können diesen Paketfluss unverändert lassen oder ihn so ändern, dass Junos OS vor dem Erstellen einer Sitzung keine SYN-Flag-Prüfung erzwingt. Abbildung 1 veranschaulicht Paketflusssequenzen sowohl bei aktivierter als auch bei deaktivierter SYN-Flag-Prüfung.

Abbildung 1: Überprüfung des SYN-Flags

Wenn Junos OS mit aktivierter SYN-Flag-Prüfung ein Nicht-SYN-TCP-Segment empfängt, das nicht zu einer vorhandenen Sitzung gehört, wird das Paket verworfen. Standardmäßig sendet Junos OS beim Empfang des Nicht-SYN-Segments keine TCP-RST an den Quellhost. Sie können das Gerät so konfigurieren, dass TCP-RST an den Quellhost gesendet wird, indem Sie den set security zones security-zone trust tcp-rst Befehl verwenden. Wenn das Codebit des anfänglichen Nicht-SYN-TCP-Pakets RST ist, sendet das Gerät kein TCP-RST.

Wenn in den ersten Paketen nicht nach dem SYN-Flag gesucht wird, haben Sie folgende Vorteile:

• NSRP mit asymmetrischem Routing: In einer Aktiv/Aktiv-NSRP-Konfiguration in einer dynamischen Routing-Umgebung sendet ein Host möglicherweise das anfängliche TCP-Segment mit dem SYN-Flag an ein Gerät (Gerät-A), aber das SYN/ACK kann an das andere Gerät im Cluster (Gerät-B) weitergeleitet werden. Wenn dieses asymmetrische Routing erfolgt, nachdem Gerät A seine Sitzung mit Gerät B synchronisiert hat, ist alles in Ordnung. Wenn andererseits die SYN/ACK-Antwort Gerät-B erreicht, bevor Gerät-A die Sitzung synchronisiert und die SYN-Prüfung aktiviert ist, lehnt Gerät-B die SYN/ACK ab, und die Sitzung kann nicht eingerichtet werden. Wenn die SYN-Prüfung deaktiviert ist, akzeptiert Gerät-B die SYN/ACK-Antwort – obwohl keine Sitzung vorhanden ist, zu der es gehört – und erstellt einen neuen Sitzungstabelleneintrag dafür.

• Unterbrechungsfreie Sitzungen: Wenn Sie das Gerät zurücksetzen oder sogar eine Komponente im Kernbereich einer Richtlinie ändern und die SYN-Prüfung aktiviert ist, werden alle vorhandenen Sitzungen oder die Sitzungen, für die die Richtlinienänderung gilt, unterbrochen und müssen neu gestartet werden. Durch das Deaktivieren der SYN-Prüfung werden solche Unterbrechungen des Netzwerkdatenverkehrsflusses vermieden.

  Hinweis:

  Eine Lösung für dieses Szenario besteht darin, das Gerät so zu installieren, dass die SYN-Prüfung zunächst deaktiviert ist. Aktivieren Sie dann nach einigen Stunden, wenn eingerichtete Sitzungen über das Gerät ausgeführt werden, die SYN-Überprüfung. Der Kernabschnitt einer Richtlinie enthält die folgenden Hauptkomponenten: Quell- und Zielzonen, Quell- und Zieladressen, einen oder mehrere Services und eine Aktion.

Die bisherigen Vorteile erfordern jedoch die folgenden Sicherheitsopfer:

• Reconnaissance Holes – Wenn ein anfängliches TCP-Segment mit einem Nicht-SYN-Flag (z. B. ACK, URG, RST, FIN) an einem geschlossenen Port ankommt, antworten viele Betriebssysteme (z. B. Windows) mit einem TCP-Segment, für das das RST-Flag festgelegt ist. Wenn der Port offen ist, generiert der Empfänger keine Antwort.

  Durch die Analyse dieser Reaktionen oder deren Fehlen kann ein Geheimdienstsammler Aufklärung im geschützten Netzwerk und auch im Junos OS-Richtliniensatz durchführen. Wenn ein TCP-Segment mit einem Nicht-SYN-Flag gesendet wird und die Richtlinie es durchlässt, kann der Zielhost, der ein solches Segment empfängt, es verwerfen und mit einem TCP-Segment antworten, für das das RST-Flag gesetzt ist. Eine solche Antwort informiert den Täter über das Vorhandensein eines aktiven Hosts an einer bestimmten Adresse und darüber, dass die Zielportnummer geschlossen ist. Der Informationssammler erfährt auch, dass die Firewall-Richtlinie den Zugriff auf diese Portnummer auf diesem Host zulässt.

  Durch Aktivieren der SYN-Flag-Prüfung löscht Junos OS TCP-Segmente ohne SYN-Flag, wenn sie nicht zu einer vorhandenen Sitzung gehören. Es wird kein TCP-RST-Segment zurückgegeben. Folglich erhält der Scanner keine Antworten, unabhängig davon, welche Richtlinie festgelegt ist oder ob der Port auf dem Zielhost offen oder geschlossen ist.

• Session Table Floods: Wenn die SYN-Prüfung deaktiviert ist, kann ein Angreifer die SYN-Flood-Schutzfunktion von Junos OS umgehen, indem er ein geschütztes Netzwerk mit einer Flut von TCP-Segmenten überflutet, für die Nicht-SYN-Flags festgelegt sind. Obwohl die anvisierten Hosts die Pakete verwerfen und möglicherweise TCP-RST-Segmente als Antwort senden, kann eine solche Flut die Sitzungstabelle des Geräts von Juniper Networks füllen. Wenn die Sitzungstabelle voll ist, kann das Gerät keine neuen Sitzungen für legitimen Datenverkehr verarbeiten.

  Durch die Aktivierung der SYN-Prüfung und des SYN-Flood-Schutzes können Sie diese Art von Angriff vereiteln. Wenn Sie überprüfen, ob das SYN-Flag für das erste Paket in einer Sitzung festgelegt ist, wird erzwungen, dass alle neuen Sitzungen mit einem TCP-Segment beginnen, für das das SYN-Flag festgelegt ist. Der SYN-Flood-Schutz begrenzt dann die Anzahl der TCP-SYN-Segmente pro Sekunde, damit die Sitzungstabelle nicht überlastet wird.

Wenn die SYN-Prüfung nicht deaktiviert ist, empfiehlt Juniper Networks dringend, sie zu aktivieren (der Standardzustand für eine Erstinstallation von Junos OS). Sie können es mit dem set flow tcp-syn-check Befehl aktivieren. Wenn die SYN-Prüfung aktiviert ist, lehnt das Gerät TCP-Segmente ab, für die Nicht-SYN-Flags gesetzt sind, es sei denn, sie gehören zu einer eingerichteten Sitzung.

Eine Methode, um Zugriff auf einen eingeschränkten Bereich des Netzwerks zu erhalten, besteht darin, eine falsche Quelladresse in den Paket-Header einzufügen, um den Anschein zu erwecken, dass das Paket von einer vertrauenswürdigen Quelle stammt. Diese Technik wird als IP-Spoofing bezeichnet. Der Mechanismus zur Erkennung von IP-Spoofing beruht auf Routing-Tabelleneinträgen. Wenn beispielsweise ein Paket mit der Quell-IP-Adresse 10.1.1.6 bei ge-0/0/1 eintrifft, Junos OS aber über eine Route zu 10.1.1.0/24 über ge-0/0/0 verfügt, wird bei einer Überprüfung auf IP-Spoofing festgestellt, dass diese Adresse bei einer ungültigen Schnittstelle angekommen ist, wie in der Routing-Tabelle definiert. Ein gültiges Paket von 10.1.1.6 kann nur über ge-0/0/0 ankommen, nicht über ge-0/0/1. Daher kommt Junos OS zu dem Schluss, dass das Paket eine gefälschte Quell-IP-Adresse hat, und verwirft diese. Junos OS erkennt und verwirft sowohl gefälschte IPv4- als auch IPv6-Pakete.

In diesem Beispiel wird gezeigt, wie ein Bildschirm zum Blockieren von IP-Spoof-Angriffen konfiguriert wird.

Bei einem IP-Spoofing-Angriff verschafft sich der Angreifer Zugriff auf einen geschützten Bereich des Netzwerks und fügt eine falsche Quelladresse in den Paket-Header ein, um den Anschein zu erwecken, dass das Paket von einer vertrauenswürdigen Quelle stammt. IP-Spoofing wird am häufigsten bei Denial-of-Service-Angriffen (DoS) eingesetzt. Wenn Firewalls der SRX-Serie im transparenten Modus arbeiten, verwendet der IP-Spoof-Prüfmechanismus Adressbucheinträge. Adressbücher sind nur in der Routing-Engine vorhanden. IP-Spoofing im transparenten Layer-2-Modus wird auf der Packet Forwarding Engine ausgeführt. Adressbuchinformationen können nicht jedes Mal von der Routing-Engine abgerufen werden, wenn ein Paket von der Paketweiterleitungs-Engine empfangen wird. Daher müssen Adressbücher, die an die Layer-2-Zonen angehängt sind, an die Paketweiterleitungs-Engine übertragen werden.

Wenn ein Paket von der Paketweiterleitungs-Engine empfangen wird, wird die Quell-IP-Adresse des Pakets überprüft, um festzustellen, ob es sich im Adressbuch der eingehenden Zone befindet. Wenn sich die Quell-IP-Adresse des Pakets im Adressbuch der Eingangszone befindet, wird diese IP-Adresse auf der Schnittstelle zugelassen, und der Datenverkehr wird weitergeleitet.

Wenn die Quell-IP-Adresse nicht im Adressbuch der eingehenden Zone vorhanden ist, aber in anderen Zonen vorhanden ist, wird die IP-Adresse als gefälschte IP-Adresse betrachtet. Dementsprechend können je nach Bildschirmkonfiguration Aktionen wie Drop und Logging durchgeführt werden (Alarm-ohne-Drop).

Wenn die Quell-IP-Adresse eines Pakets nicht im Adressbuch der eingehenden Zone oder in anderen Zonen vorhanden ist, können Sie nicht feststellen, ob die IP-Adresse gefälscht ist oder nicht. In solchen Fällen wird das Paket übergeben.

Junos OS berücksichtigt bei der Suche nach Quell-IP-Adressen im Adressbuch die folgenden Übereinstimmungsbedingungen:

• Host-match—Die im Adressbuch gefundene IP-Adressenübereinstimmung ist eine Adresse ohne Präfix.

• Prefix-match—Die im Adressbuch gefundene IP-Adressenübereinstimmung ist eine Adresse mit einem Präfix.

• Any-match—Die im Adressbuch gefundene IP-Adressenübereinstimmung ist "any", "any-IPv4" oder "any-IPv6".

• No-match—Es wurde keine Übereinstimmung mit der IP-Adresse gefunden.

Das Quellrouting wurde entwickelt, um Benutzern an der Quelle einer IP-Paketübertragung die Möglichkeit zu geben, die IP-Adressen der Geräte (auch als "Hops" bezeichnet) entlang des Pfads anzugeben, den ein IP-Paket auf seinem Weg zu seinem Ziel nehmen soll. Der ursprüngliche Zweck der IP-Quellroutenoptionen bestand darin, Routing-Steuerungstools zur Unterstützung der Diagnoseanalyse bereitzustellen. Wenn z. B. die Übertragung eines Pakets an ein bestimmtes Ziel unregelmäßig erfolgreich ist, können Sie zunächst entweder die Datensatzroute oder die IP-Option mit Zeitstempel verwenden, um die Adressen von Geräten entlang des Pfads oder der Pfade zu ermitteln, die das Paket nimmt. Sie können dann entweder die lose oder die strikte Quellroutenoption verwenden, um den Datenverkehr entlang eines bestimmten Pfads zu leiten, indem Sie die Adressen verwenden, die Sie aus den Ergebnissen ermittelt haben, die die Datensatzroute oder die Zeitstempeloptionen erzeugt haben. Indem Sie Geräteadressen ändern, um den Pfad zu ändern, und mehrere Pakete über verschiedene Pfade senden, können Sie Änderungen feststellen, die die Erfolgsquote entweder verbessern oder verringern. Durch die Analyse und den Prozess der Beseitigung können Sie möglicherweise ableiten, wo das Problem liegt. Siehe Abbildung 2.

Abbildung 2: IP-Quell-Routing

Obwohl die Verwendung von IP-Quellroutenoptionen ursprünglich harmlos war, haben Angreifer gelernt, sie für hinterhältigere Zwecke zu nutzen. Sie können IP-Quellroutenoptionen verwenden, um ihre wahre Adresse zu verbergen und auf eingeschränkte Bereiche eines Netzwerks zuzugreifen, indem sie einen anderen Pfad angeben. Ein Beispiel, das zeigt, wie ein Angreifer beide Täuschungen einsetzen kann, finden Sie im folgenden Szenario, das in Abbildung 3 dargestellt ist.

Abbildung 3: Lose IP-Quellroutenoption für Täuschung

Junos OS lässt Datenverkehr 2.2.2.0/24 nur zu, wenn er über Ethernet1 kommt, eine an zone_external gebundene Schnittstelle. Die Geräte 3 und 4 erzwingen Zugriffskontrollen, die Geräte 1 und 2 jedoch nicht. Darüber hinaus prüft Gerät 2 nicht auf IP-Spoofing. Der Angreifer fälscht die Quelladresse und leitet das Paket mithilfe der Option "Loose Source Route" über Gerät 2 zum Netzwerk 2.2.2.0/24 und von dort aus Gerät 1 weiter. Gerät 1 leitet sie an Gerät 3 weiter, das sie wiederum an das Gerät von Juniper Networks weiterleitet. Da das Paket aus dem Subnetz 2.2.2.0/24 stammt und eine Quelladresse aus diesem Subnetz hat, scheint es gültig zu sein. Ein Überbleibsel der früheren Schikane bleibt jedoch bestehen: die Option der losen Quellroute. In diesem Beispiel haben Sie die Bildschirmoption "IP-Quellroute verweigern" für zone_external aktiviert. Wenn das Paket bei ethernet3 eintrifft, lehnt das Gerät es ab.

Sie können das Gerät aktivieren, um entweder Pakete mit losen oder strikten Quellroutenoptionen zu blockieren oder solche Pakete zu erkennen und das Ereignis dann in der Zählerliste für die Eingangsschnittstelle aufzuzeichnen. Die Bildschirmoptionen lauten wie folgt:

• Option "IP-Quellroute verweigern": Aktivieren Sie diese Option, um den gesamten IP-Datenverkehr zu blockieren, der die Option "Loose" oder "Strict Source Route" verwendet. Quellroutenoptionen können es einem Angreifer ermöglichen, mit einer falschen IP-Adresse in ein Netzwerk einzudringen.

• Detect IP Loose Source Route Option: Das Gerät erkennt Pakete, bei denen die IP-Option 3 ist (Loose Source Routing), und zeichnet das Ereignis in der Liste der Bildschirmzähler für die Eingangsschnittstelle auf. Diese Option gibt eine Teilroutenliste für ein Paket an, das auf seiner Reise von der Quelle zum Ziel verwendet werden soll. Das Paket muss in der Reihenfolge der angegebenen Adressen fortgesetzt werden, darf jedoch andere Geräte zwischen den angegebenen Geräten passieren.

• Detect IP Strict Source Route Option: Das Gerät erkennt Pakete, bei denen die IP-Option 9 (Strict Source Routing) ist, und zeichnet das Ereignis in der Bildschirmzählerliste für die Eingangsschnittstelle auf. Diese Option gibt die vollständige Routenliste für ein Paket an, das auf seiner Reise von der Quelle zum Ziel genommen werden soll. Die letzte Adresse in der Liste ersetzt die Adresse im Zielfeld. Derzeit ist diese Bildschirmoption nur für IPv4 verfügbar.

In diesem Beispiel wird gezeigt, wie Pakete blockiert werden, wenn entweder eine lose oder eine strikte Quellroutenoption festgelegt ist.

Dieses Beispiel zeigt, wie Pakete erkannt werden, für die entweder eine lose oder eine strikte Quellroutenoption festgelegt ist.