Zusammenfassung

  • RFC 2267 legte eine Prüfung des Quellpräfixes an die Schnittstelle, über die ein Kundennetz in das Netz seines Providers gelangt; die erlaubten Präfixe konnten dort lokal bekannt sein.
  • BCP 38 erhob den Vorschlag 2000 zur Best Current Practice. Ein passender Präfix grenzt die Netzseite ein, identifiziert aber weder den sendenden Rechner noch die Person dahinter.

Das Opfer sah die Adresse, nicht den Absender

Ein Server erhält Verbindungsversuche, die von unerreichbaren Adressen zu kommen scheinen. Seine Antworten verlaufen ins Leere, während der Absender das Quellfeld fortlaufend ändert. Ein anderes Paket kann eine echte Adresse eines Netzes tragen, das mit dem Angriff nichts zu tun hat. Sperrt das Opfer diese scheinbare Quelle, kann es zugleich legitime Verbindungen des unschuldigen Netzes unterbrechen.

Diesen blinden Fleck beschreibt RFC 2267. Der Empfänger liest die im Paket eingetragene Quelladresse, kann aber nicht unmittelbar prüfen, wer sie ausgewählt hat. Verbesserungen am Host helfen einem Server, mehr Versuche auszuhalten; sie verraten einem entfernten Ziel nicht, ob die Quelle gefälscht war. Das Memo sah Host-Schutz als Teil der Antwort und schlug zusätzlich eine Prüfung näher am Netz vor, das den Verkehr eingespeist hat.

Der Provider kannte den Kundenanschluss

Ein Anbieter bündelt Routen mehrerer nachgelagerter Netze. An der Routerschnittstelle zu einem bestimmten Kunden kann er eine konkrete Frage beantworten: Welche Quellpräfixe dürfen über genau diesen Anschluss kommen? Das Beispiel in RFC 2267 lässt Pakete mit dem Präfix des Kunden passieren und verwirft solche, die eine andere Herkunft behaupten. Außerdem empfiehlt der Text, verworfene Pakete zu protokollieren, damit Administratoren verdächtige Aktivität prüfen können.

Dafür braucht es keine weltweite Abfrage eines Adressregisters. Die Regel beruht auf einer lokalen Zuordnung: dieser Kundenanschluss, diese erlaubte Quellpräfixmenge. Bevor das Paket das größere Providernetz erreicht, vergleicht die Schnittstelle seine Quelle mit dieser Zuordnung. Liegt das Präfix außerhalb der erlaubten Menge, kann der Anbieter den Verkehr nahe am Eintrittspunkt stoppen, statt dem Opfer ein weiteres mehrdeutiges Signal zu überlassen.

Der Ort der Prüfung verändert die Abwehrlast. Ohne Filter beim Provider muss das Opfer ein Feld auswerten, das der Absender kontrolliert, und riskiert, den unschuldigen Inhaber der scheinbaren Adresse zu treffen. Mit einer Prüfung am Kundeneingang kann das Netz, das den Kundenverkehr trägt, Quellen zurückweisen, die nicht zu diesem Anschluss gehören. Verwendet ein Angriff dennoch ein erlaubtes Präfix, beginnt die Untersuchung zumindest bei einem kleineren Netzbereich als dem gesamten Internet.

Ein Präfix ist keine Rückwegprüfung

RFC 2267 trennt den Vorschlag von einer anderen Prüfung, die leicht damit verwechselt wird: Würde die Rückroute zur Quelladresse über dieselbe Schnittstelle führen, über die das Paket angekommen ist? Die Autoren rieten von einer allgemeinen Vorgabe ab, weil asymmetrische Routen im Internet sie problematisch machten. Im Mittelpunkt ihrer Empfehlung steht stattdessen, ob das Quellpräfix zum nachgelagerten Netz an dieser Schnittstelle gehört.

Beide Prüfungen erfolgen am Eingang, beantworten aber unterschiedliche Fragen. Ein Rückwegtest folgt der Richtung, die sich aus der Routingtabelle ergibt. Ein Kundenfilter vergleicht die Quelle mit den Präfixen, die für das angeschlossene Netz erlaubt sind. RFC 3704 befasste sich später mit Filtermechanismen für multihomed Netze und aktualisierte RFC 2827. Die dort behandelten strikten, machbaren und losen RPF-Verfahren samt ihren Abwägungen sind ein eigenes Thema und werden hier nicht erneut erklärt.

Mobile IP machte den Ausnahmefall sichtbar

Eine Adresse kann für einen mobilen Knoten gültig sein und im Netz, an das er sich gerade angeschlossen hat, trotzdem unerwartet wirken. RFC 2267 nennt Mobile IP: Ein aus einem besuchten Netz gesendetes Paket kann die Heimatadresse des Knotens als Quelle tragen. Ein Filter, der dort nur den lokalen Kundenpräfix zulässt, könnte es verwerfen. Das Memo verweist auf umgekehrtes Tunneln, das später in RFC 2344 beschrieben wurde: Das ausgehende Paket wird erst zum Home Agent gebracht und danach ins Internet weitergeleitet.

Der Filter beurteilt keine Absicht. Er setzt eine lokale Aussage darüber um, welche Präfixe eine bestimmte Kundenschnittstelle passieren dürfen. Ein legitimer Dienst, der eine andere Quelle braucht, benötigt einen Pfad oder eine ausdrückliche Regel, die mit dieser Grenze vereinbar ist. Die RFCs behaupten weder, dass jede Mobilität scheitert, noch dass alle Sonderfälle entfallen müssen. Sie zeigen, dass Ausnahmen mit der Eingangsregel abgestimmt werden müssen.

Vom Informationsmemo zu BCP 38

RFC 2267 erschien im Januar 1998 als Informational Memo und legte keinen Internetstandard fest. Im Mai 2000 löste RFC 2827 das Dokument ab. Es behielt den Titel „Network Ingress Filtering“ und erhielt als Best Current Practice die Nummer BCP 38. Der Kern blieb derselbe: Anbieter sollten Kundenverkehr am Eingang filtern und Quellen zurückweisen, die das Kundennetz nicht rechtmäßig verwendete.

Der Dokumentstatus änderte sich; ein Nachweis für den Betrieb ist das nicht. RFC 2827 empfiehlt eine Praxis, zählt aber weder die Provider und Kunden noch die Anschlüsse auf, an denen ein Filter installiert war. RFC 2267 erwähnt, dass einzelne Anbieter mit der Umsetzung begannen, enthält aber keine Erhebung und keine Abdeckungsmessung. Veröffentlichung, Providerregel, installierte Schnittstellenkonfiguration, verworfenes Paket und erfolgreiche Untersuchung sind unterschiedliche Tatsachen.

Auch die Wirkung des Filters ist begrenzt. Er kann gefälschte Quellpräfixe außerhalb der erlaubten Menge abweisen. Er verhindert nicht, dass ein Angreifer die Adresse eines anderen Hosts innerhalb derselben Menge verwendet, und stoppt keine Flut mit gültigen Quelladressen. Er identifiziert weder Gerät noch Person und belegt keine Absicht. Ein Verwerfungsprotokoll kann zeigen, an welcher Netzgrenze eine Entscheidung fiel; es ist kein Geständnis des Absenders.

Der historische Schritt war bescheiden und greifbar. Nicht mehr allein das Opfer sollte eine möglicherweise gefälschte Adresse deuten müssen. RFC 2267 setzte eine überprüfbare Präfixprüfung an die Grenze zwischen Provider und Kunde, wo die Zuordnung zwischen Anschluss und Präfixen verwaltet und angewendet werden konnte. BCP 38 gab dieser Betriebspraxis einen gemeinsamen Namen. Ob sie auf einer bestimmten Verbindung wirkte, hing weiter davon ab, ob die lokale Regel richtig, installiert und aktiv war.

Quellen

  1. RFC 2267 — Network Ingress Filtering
  2. RFC 2827 — Network Ingress Filtering (BCP 38)
  3. RFC 1812 — Requirements for IP Version 4 Routers
  4. RFC 2002 — IP Mobility Support
  5. RFC 2344 — Reverse Tunneling for Mobile IP
  6. RFC 3704 — Ingress Filtering for Multihomed Networks (BCP 84)