Anti-Spoofing (Deutsch)

MANRS Implementation Guide

• Einführung
• Koordination
• Globale Validierung
• Anti-Spoofing
• Filterung
• Zusammenfassung und Checklisten
• Zusätzliche Informationen

4.3. Anti-Spoofing-Verhinderung von Datenverkehr mit gefälschten Quell-IP-Adressen

Relevante MANRS erwartete Aktionen:

• Der Netzbetreiber implementiert ein System, das die Validierung der Quelladressen für mindestens Single-Homed-Stub-Kundennetzwerke, ihre eigenen Endbenutzer und ihre Infrastruktur ermöglicht., Der Netzwerkbetreiber implementiert eine Anti-Spoofing-Filterung, um zu verhindern, dass Pakete mit falscher Quell-IP-Adresse in das Netzwerk gelangen und es verlassen.

Spoofing von IP-Quelladressen ist die Praxis, IP-Datagramme mit anderen Quelladressen als dem Ursprungshost zuzuweisen. In einfachen Worten gibt der Host vor, ein anderer Host zu sein. Dies kann auf verschiedene Arten ausgenutzt werden, insbesondere um Reflexionsverstärkungsangriffe (Denial of Service, DoS) auszuführen, die dazu führen, dass ein Reflektorhost Datenverkehr an die gefälschte Adresse sendet.,

Es gibt viele Empfehlungen, um IP-Spoofing durch Ingress-Filterung zu verhindern, z. B. Überprüfen der Quelladressen von IP-Datagrammen in der Nähe der Netzwerkkante. Die meisten Geräteanbieter unterstützen in irgendeiner Form die Ingress-Filterung. Seit 2005 ist der Einsatz von Anti-Spoofing-Techniken keine Einschränkung der Geräteleistung. Es war eine Einschränkung des Wunsches und der Bereitschaft, die Anti-Spoofing-Konfiguration bereitzustellen und aufrechtzuerhalten.

Ironischerweise können signifikante DoS-Verstärkungsangriffe für Dienstanbieter teuer sein., Die Kosten verletzen die Marke, schädigen den Kundenbetrieb und wirken sich auf andere Kunden aus. Diese DoS-amplification-Angriffe vermeidbar sind. Sie wären ohne Spoofing unmöglich.

Dies zeigt, dass die Ingress-Filterung definitiv nicht ausreichend bereitgestellt wird. Leider gibt es keine Vorteile für einen Dienstanbieter (SP), der die Ingress-Filterung bereitstellt. Es gibt auch eine weit verbreitete Überzeugung, dass die Ingress-Filterung nur hilft, wenn sie universell eingesetzt wird.,

Gängige Ansätze für dieses Problem betrafen Softwarefunktionen wie SAV (Source – Address Validation) in Kabelmodem-Netzwerken oder strikte uRPF (Unicast Reverse-Path Forwarding) – Validierung in Router-Netzwerken. Diese Methoden können den Verwaltungsaufwand in Fällen verringern, in denen Routing und Topologie relativ dynamisch sind. Ein anderer Ansatz könnte darin bestehen, eingehende Präfix-Filterinformationen zu verwenden, um einen Paketfilter zu erstellen, der nur Pakete mit Quell-IP-Adressen zulässt, für die das Netzwerk legitim für die Erreichbarkeit werben könnte.,

Für die meisten kleineren und einfacheren Netzwerkarchitekturen ist der einfachste Weg, Spoofing zu verhindern, die Verwendung von Unicast RPF (uRPF) im Strict-Modus. Zum Filtern von Quelladressen, die von Geräten in einer Layer-2-Domäne verwendet werden, kann das Source Address Validation Tool (SAVI) verwendet werden. Auf Geräten, auf denen keine automatischen Filterfunktionen verfügbar sind, können Sie Access Control Lists (ACLs) verwenden, um eine äquivalente Filterung manuell zu implementieren. Alle diese Technologien werden im Folgenden erläutert.

4.3.1., Leitprinzipien für Anti-Spoofing-Architekturen

Um so effektiv wie möglich zu sein, sollten Anti-Spoofing-Techniken so nah wie möglich an der Quelle angewendet werden. In Unternehmensnetzwerken werden die von jedem Gerät verwendeten Quelladressen häufig gesteuert und erzwungen, sodass Sicherheitsaudits genau bestimmen können, welches Gerät welches Paket gesendet hat.

Für eine erfolgreiche Implementierung von MANRS ist eine solche feine Granularität auf Geräteebene nicht erforderlich, da MANRS sich auf Routingsicherheit und Anti-Spoofing auf Netzwerkebene konzentriert., Daher konzentrieren sich gängige Anti-Spoofing-Architekturen darauf, sicherzustellen, dass Kunden keine Pakete mit den falschen Quelladressen senden.

Das Erzwingen der Verwendung gültiger Quelladressen auf Kundenebene hat den Vorteil, dass Kunden die Adressen des anderen nicht fälschen können, wodurch verhindert wird, dass sie Probleme miteinander verursachen, die schwer zu debuggen sind.

Wenn es aus irgendeinem Grund nicht möglich ist, die Verwendung der Quelladresse pro Kunde zu erzwingen, besteht eine Alternative darin, sie an Aggregationspunkten zu erzwingen, sodass die Kunden zumindest begrenzt sind, an welchen Adressen sie fälschen können., Zumindest sollte es Anti-Spoofing auf ISP-Ebene geben, damit Kunden Adressen anderer Organisationen nicht fälschen und Probleme im internetweiten Maßstab verursachen können.

4.3.2. Unicast RPF

BCP38 uRPF Strict-Modus mit RFC1998++ – Stil von multihoming (ein BCP für multihoming) ist ein Konzept, das funktioniert in symmetrische (single-homed) und asymmetrische (mehrfach vernetzten BGP) Konfigurationen und wurde erstmals operativ eingesetzt in 2002. Ja, es gibt viele, die denken, dass „uRPF wegen Routing-Asymmetrie nicht funktioniert“, aber das ist nicht wahr., Dokumentation aus dem Jahr 2001, das ISP Essentials Whitepaper (Google für Version 2.9) und das ISP Essentials Book (ISBN 1587050412) sowie Bereitstellungen in mehreren wichtigen SPs haben gezeigt, dass der uRPF Strict Mode eine praktikable Technik ist.

Es gibt vier Algorithmen für den uRPF-Strict-Modus (Quell-IP und Adjazenz prüfen), den Loose-Modus (nur Quell-IP prüfen), den realisierbaren Pfad (Quell-IP mit den Alternativen der FIB prüfen) und den VRF-Modus (Quell-Prüfung in einer separaten Tabelle von der FIB zulassen/verweigern)., Jede dieser uRPF-Optionen ist für bestimmte „Anti-Spoofing“ – Funktionen in verschiedenen Teilen des Netzwerks ausgelegt.

• uRPF Strict Mode-BCP38 am Kunden-SP edge. Jedes eingehende Paket wird gegen die FIB getestet und wenn die eingehende Schnittstelle nicht der beste umgekehrte Pfad ist, wird das Paket gelöscht.
• uRPF Losen Modus-sRTBH überall im Netzwerk-aber nur prüfen, ob die Route in der FIB ist. Wenn nicht in der FIB, dann fallen. Wenn es in der FIB ist, dann pass. Gut für sRTBH und mildert etwas gefälschten Verkehr am Peering Edge.,
• uRPF Machbarer Pfad-sRTBH überall im Netzwerk und BCP38 für Multihomed-Kunden und asymmetrische Routen. Im realisierbaren Modus verwaltet die FIB alternative Routen zu einer bestimmten IP-Adresse. Wenn die eingehende Schnittstelle mit einer der Routen übereinstimmt, die der IP-Adresse zugeordnet sind, wird das Paket weitergeleitet. Andernfalls wird das Paket gelöscht.
• uRPF VRF-Modus – BGP-Peering basiert Durchsetzung von Richtlinien oder detailliertere sRTBH (HINWEIS VRF-Modus kann verwendet werden als BCP38, aber wurde nicht operativ bewährt)

uRPF kann nützlich sein, in vielen Orten im Netz., Es wird am häufigsten an den Rändern der Netzwerke verwendet, in denen Kunden, Server und/oder Clients verbunden sind, da der strikte Modus dort gut funktioniert. Netzbetreiber zögern, uRPF im Kern ihrer Netzwerke zu verwenden, da sie befürchten, versehentlich gültigen Datenverkehr fallen zu lassen, der einen unerwarteten Weg durch ihr Netzwerk eingeschlagen hat. Der Urpfadpfadmodus sollte solche Probleme lösen.

Sowohl Cisco als auch Juniper implementieren sowohl den strikten Modus als auch den losen Modus. Wir zeigen, wie man den strikten Modus verwendet., Konfigurieren Sie den strengen uRPF-Modus für Schnittstellen zu Kunden mit:

Cisco:

 ip verify unicast source reachable-via rx ipv6 verify unicast source reachable-via rx

Juniper:

 family inet { rpf-check; } family inet6 { rpf-check; }

Dadurch kann der Kunde nur IP-Adressen verwenden, die Sie an sie weiterleiten. In Situationen, in denen Sie der Kunde eines anderen ISP sind, in denen Sie eine Standardroute haben, die auf diesen ISP zeigt, sollten Sie Folgendes verwenden:

Cisco:

 ip verify unicast source reachable-via rx allow-default ipv6 verify unicast source reachable-via rx allow-default

Juniper:

Juniper-Router passen ihre uRPF-Filterung automatisch an die Position an, auf die Standardrouten zeigen. Verwenden Sie einfach die gleichen Befehle wie oben.,

Die Option allow-default ist erforderlich, da die Quelladressen standardmäßig nur mit bestimmten Routen abgeglichen werden, wobei die Standardroute ignoriert wird. Es stellt sicher, dass Ihr Upstream Ihnen keinen Datenverkehr sendet, für den Sie andere spezifischere Routen haben, die in eine andere Richtung weisen, wie z. B. Ihre eigenen Netzwerke und die Netzwerke Ihrer Kunden. Dies schützt Sie vor gefälschtem Datenverkehr von anderen.

4.3.3., Dynamische Zugriffsliste (Radius & Durchmesser)

Die Standardmethode zum Festlegen von Zugriffslisten für Radius-authentifizierte Benutzer ist das Radius-Attribut 11 (Filter-Id). Mit diesem Attribut können Sie den Router anweisen, eine bereits vorhandene Zugriffsliste auf die Verbindung des Benutzers anzuwenden. Dies erfordert jedoch eine Out-of-Band-Methode, um allen Routern die richtigen Zugriffslisten bereitzustellen.

Einige Anbieter verfügen über zusätzliche Radius-Optionen, mit denen die Zugriffsliste selbst dynamisch über Radius bereitgestellt werden kann., Cisco bietet beispielsweise zusätzliche Funktionen über cisco-avpair-Attribute:

 cisco-avpair = "ip:inacl#5=permit ip 192.0.2.0 0.0.0.255 any" cisco-avpair = "ip:inacl#99=deny ip any any"

Dies würde nur Pakete vom Kunden zulassen, die eine Quelladresse im Bereich 192.0.2.0/24 haben.

4.3.4. SAVI

SAVI ist der Name der IETF-Arbeitsgruppe, die an Verbesserungen der Quelladressvalidierung arbeitet. Für die Validierung der Quelladresse eines Kunden wird üblicherweise die SAVI for DHCP-Lösung in RFC 7513 verwendet., Diese Version von SAVI verfolgt alle IP-Adressen, die jedem Gerät zugewiesen wurden, indem der DHCPv4-und DHCPv6-Nachrichtenaustausch auf dem Netzwerk-Switch, mit dem der Kunde verbunden ist, durchgeschnüffelt wird. Wenn ein Kunde eine nicht autorisierte Quelladresse verwendet, wird das Paket vom Switch gelöscht.

Anbieter verwenden häufig ihre eigene Terminologie, um SAVI-Funktionen zu beschreiben. Auf Cisco-Geräten werden diese Funktionen als DHCP-Snooping, Source Guard und Prefix Guard bezeichnet.

4.3.5., IP Verify Source

Ethernet-Netzwerke sind Broadcast-Domänen, und standardmäßig gibt es keine Validierung, wer Pakete mit welchen Adressen senden darf. Um Cisco Switches so zu konfigurieren, dass die von den angeschlossenen Geräten verwendeten Quelladressen überprüft werden, kann die Einstellung „ip verify source“ verwendet werden.,

Es gibt drei Varianten dieser Funktion:
● ip verify source
● ip verify source port-security
● ip verify source tracking port-security

Die erste Variante überprüft die Quell-IP-Adresse, die zweite Variante überprüft auch die Quell-MAC-Adresse und die dritte Variante verfolgt die Bindungen zwischen IP-Adresse und MAC-Adresse. Um zu verhindern, dass Kunden die MAC-Adresse eines anderen Kunden verwenden, wird die letzte Variante empfohlen. Alle diese stützen ihre Entscheidung auf schnüffelte DHCP-Daten.,

Bevor der Switch Quelladressen überprüfen kann, muss er so konfiguriert sein, dass er DHCP-Datenverkehr schnüffelt, um Daten zu sammeln, auf denen seine Entscheidungen basieren ip dhcp snooping. Um zu verfolgen, welcher Ethernet-Port eine Verbindung zu jedem DHCP-Client herstellt, verwenden Sie die DHCP-Option 82 mit ip dhcp snooping information option. Dies ist notwendig, da der Switch bei verify port-security erst dann MAC-Adressen lernt, wenn der DHCP-Server dem angeschlossenen Gerät eine IP-Adresse zugewiesen hat. Option 82 ist daher notwendig, den Switch daran zu erinnern, wo der Client angeschlossen war.,

Es sind mehrere Schritte erforderlich, um die sichere Verfolgung von Geräten zu ermöglichen und deren Quelladressen zu überprüfen. Der erste Schritt besteht darin,“ ip Device Tracking “ global auf dem Switch zu aktivieren. Dadurch wird sichergestellt, dass der Switch verfolgen kann, welche IP-Adresse zu welcher MAC-Adresse gehört. Definieren Sie dann auf jeder Schnittstelle die Anzahl der Geräte, die eine Verbindung mit ip device tracking maximum num herstellen dürfen, wobei num eine Zahl von 1 bis 10 sein kann. Aktivieren Sie nun switchport port-security auf jeder Schnittstelle, um sicherzustellen, dass nur zulässige MAC-Adressen verwendet werden., Und schließlich aktivieren Sie die Verifizierungsfunktion, die all diese zusammen mit ip verify source tracking port-securityverknüpft.

Jetzt verfügt der Switch über alle Informationen, die er benötigt, um DHCP-Datenverkehr zu erfassen, die IP-Adressen mit MAC-Adressen zu verknüpfen und zu überprüfen, ob alle über den Switch gesendeten Pakete dem gesammelten Status entsprechen, der auf Antworten des DHCP-Servers basiert. Pakete, die nicht den vom DHCP-Server zugewiesenen Anforderungen entsprechen, werden gelöscht.

4.3.6. Kabelquelle-Verify

Kabelmodem-Netzwerke ähneln in vielerlei Hinsicht Ethernet-Netzwerken., Sofern nicht anders konfiguriert, können Benutzer Quelladressen fälschen oder die Adressen anderer Benutzer im Kabelnetzwerk stehlen. Mit der Cisco Cable Source-Verify-Funktion kann der CMTS-Operator begrenzen, welche Quelladressen ein Benutzer verwenden darf.

Es gibt zwei Varianten dieser Funktion:

● cable source-verify
● cable source-verify dhcp

Beide Varianten beeinflussen, welche Adressen aus dem Subnetz des Kabelnetzes verwendet werden dürfen. Die erste Variante verhindert nur, dass Benutzer die Adressen des anderen stehlen, und reicht daher für MANRS nicht aus., Wir werden uns die zweite Variante ansehen.

Konfigurieren cable source-verify dhcp teilt dem CMTS mit, dass alle Quelladressen gegen DHCP-Leases überprüft werden müssen, die das CMTS gesehen hat. Wenn ein Paket mit einer anderen Quelle gesendet wird, wird es vom CMTS gelöscht. Dadurch wird verhindert, dass Benutzer Adressen verwenden, die ihnen nicht über DHCP zugewiesen wurden .

Probleme können auftreten, wenn das CMTS neu geladen wird. In einem solchen Fall kennt das CMTS nicht alle DHCP-Leases seiner Benutzer und kann legitimen Datenverkehr löschen. Um dies zu lösen, können die CMTS so konfiguriert werden, dass sie das DHCP-LeaseQuery-Protokoll verwenden., Auf diese Weise können die CMTS den DHCP-Server nach Leases für den angezeigten Datenverkehr fragen. Sobald der DHCP-Server bestätigt, dass ein legitimer Lease für diese Adresse vorhanden ist, fügt der CMTS ihn seinem Cache hinzu und lässt den Datenverkehr durch.

Um die CMTS so zu konfigurieren, dass Sie ARP im Kabelnetz nicht vertrauen, konfigurieren Sie sie mit no cable arp. Dadurch wird sichergestellt, dass nur Informationen, die von DHCP und LeaseQuery gelernt wurden, bei der Überprüfung von Quelladressen vertrauenswürdig sind.

Die Funktion cable source-verify schützt nur das Subnetz des Kabelnetzes selbst., Um zu verhindern, dass Benutzer andere Adressen fälschen, und um Datenverkehr von Kunden zuzulassen, die über ein geroutetes Subnetz verfügen, das sie verwenden dürfen, konfigurieren Sie auch ip verify unicast source reachable-via rx, um den uRPF Strict-Modus im Kabelnetzwerk zu aktivieren. Dadurch werden alle Quelladressen überprüft, die sich nicht direkt im Kabelnetz befinden, und beispielsweise statische Routen für geroutete Subnetze gegenüber Kunden validiert.

4.3.7., Access Control List (ACLs)

ACLs werden üblicherweise an der Grenze Provider Edge (PE) – Customer Edge (CE) bereitgestellt, sind aber auch an anderen Orten wie auf dem Weg zum eigenen Server -, Client-und Infrastrukturnetzwerk des Anbieters sehr nützlich, um zu verhindern, dass sich Geräte dort schlecht verhalten. Eine optimierte ACL-Strategie besteht darin, einen expliziten Genehmigungsfilter auf der Kundenschnittstelle zu platzieren. Explizite Erlaubnisfilter erlauben bestimmte Adressbereiche und verweigern dann alles andere. Wenn beispielsweise dem Kunden des Betreibers 192.0.2.0/24 zugewiesen wird, würde die BCP 38 ACL alle Quelladressen von 192.0.2 zulassen.,0/24 und verweigern Sie dann alle Pakete, deren Quelladresse nicht 192.0.2.0 / 24 ist.

Auf den Downstream-Schnittstellen des ISP sollten Filter vorhanden sein, die die von seinen Kunden verwendeten Quelladressen überprüfen. Wenn uRPF nicht verwendet werden kann, sind manuelle ACLs erforderlich. Nehmen wir den ersten Kunden aus dem obigen Beispieldiagramm:

Cisco:

Juniper:

4.3.7.1., Aggregationspunkte

Wenn ACLs an der PE-CE-Grenze nicht möglich sind, z. B. weil mehrere Kunden mit einem einzelnen Layer-2-Netzwerk verbunden sind und die Layer-2-Geräte nicht über die Funktionen zum Filtern von Layer-3-Informationen verfügen, ist das Filtern an einem Aggregationspunkt die zweitbeste Lösung.

In diesem Beispiel ist es (aus einem nicht spezifizierten Grund) nicht möglich, für jeden Kunden nach /24 zu filtern. In diesem Fall Filterung auf 192.0.2.0 / 23 und 198.51.100.,0/23 (und ähnlich für IPv6) an einem Aggregationspunkt in der Nähe der Kundenverbindungen würde zumindest die Spoofing-Möglichkeiten für diese Kundengruppe auf einen kleinen Adressbereich beschränken.

Die Konfiguration erfolgt wie im vorherigen Abschnitt gezeigt, außer jetzt auf einem anderen Router an einem zentraleren Ort im Netzwerk.

4.3.8. Carrier Grade NAT – Ist NAT ein Anti-Spoof-Tool?

Standardmäßig filtern viele NAT-Implementierungen nicht die Quelladresse der Clients., Nehmen wir zum Beispiel eine einfache NAT-Konfiguration auf einem Cisco-Router wie:

 ip nat inside source list INSIDE pool OUTSIDE overload

Diese NAT-Regel übersetzt Pakete mit einer Quelladresse in der Zugriffsliste und ändert die Quelladresse in eine Adresse im Pool AUßERHALB. Pakete mit einer gefälschten Quelladresse, die nicht in der INTERNEN Zugriffsliste enthalten ist, werden jedoch ohne Übersetzung weitergeleitet, was zu gefälschten Paketen im Internet führt., Wenn ein gefälschtes Paket mit der Zugriffsliste übereinstimmt, wird es mit dem angegebenen Pool übersetzt, sodass die Außenwelt keine gefälschte Quelladresse sieht, aber es ist für den NAT-Operator unmöglich, die gefälschten Pakete an ihren Urheber zurückzuverfolgen.

Dies zeigt, dass NAT kein Anti-Spoofing-Tool ist. Selbst bei Verwendung von NAT müssen die von Kunden verwendeten Quelladressen so nah wie möglich am Kunden überprüft werden, genau wie in den Fällen ohne NAT, die zuvor in diesem Kapitel gezeigt wurden. Nur dann können gefälschte und/oder nicht nachverfolgbare Pakete verhindert werden, um das Internet zu erreichen.

4.3.9., Weiterführende Literatur