IPv6-Missbrauch per /64-Präfix drosseln und blockieren

Fast jeder Rate Limiter, jede Login-Drosselung und jede IP-Sperrliste in Produktion wurde für IPv4 entworfen, wo das Denkmodell einfach ist: eine Adresse, ungefähr ein Nutzer. Anfragen pro Adresse zählen, die Adresse sperren, weiter. Dieses Modell ist unbemerkt falsch geworden. Sobald Ihr Traffic IPv6 enthält (und ein großer und wachsender Anteil tut das), entspricht die Einheit, die Sie zählen, keiner Person mehr, und jede Abwehr, die auf „einer Adresse“ beruht, bekommt ein Leck.

Das ist kein subtiler Sonderfall. Es ist der Unterschied zwischen einem Rate Limiter, der funktioniert, und einem, durch den ein Angreifer einfach hindurchspaziert, während Ihre Dashboards eine ordentliche Reihe von Adressen mit je einer Anfrage zeigen. Die Lösung sind nicht mehr Regeln. Es geht darum, das Richtige zu zählen. Dieselbe Gewohnheit steckt hinter dem Verifizieren von KI-Crawlern und Bots anhand von IP-Bereichen, wo der veröffentlichte CIDR-Block mehr zählt als jede einzelne Adresse. Das Zählen nach Präfix ist eine Ebene der Bot-Erkennung anhand der IP-Adresse; die anderen sagen Ihnen, zu welcher Art von Netzwerk das Präfix gehört.

Die IPv4-Gewohnheit, die bei IPv6 versagt

Bei IPv4 hat Ihnen die Adressknappheit einen Gefallen getan. Es gibt nur etwa 4,3 Milliarden Adressen, sie sind teuer, und weit überwiegend erhält ein Anschlussinhaber jeweils eine einzige öffentliche Adresse. „Anfragen von diesem /32“ und „Anfragen von diesem Nutzer“ lagen also nah genug beieinander, um sie gleichzusetzen. Sperren Sie das /32, treffen Sie höchstens den Haushalt oder das NAT dahinter.

IPv6 beseitigt die Knappheit und damit auch die Annahme. Die Adresse hat 128 statt 32 Bit (acht Gruppen aus vier Hexadezimalziffern), und die Designphilosophie ist das Gegenteil von sparsam. Statt einzelne Adressen zu rationieren, gibt IPv6 jedem Kunden einen Block davon. Der kleinste Block, den jemand erhält, ist riesig, und dieser Block, nicht die einzelne Adresse, ist die eigentliche Identität des Nutzers.

Wenn Ihr Limiter bei IPv6 noch pro vollständiger Adresse zählt, braucht ein Angreifer kein Botnetz und keinen Proxy-Pool. Er braucht eine gewöhnliche IPv6-Zuweisung und eine for-Schleife.

Ein Anschlussinhaber, 18 Trillionen Adressen

Hier ist die Zahl, die das ganze Problem in ein neues Licht rückt. Der kleinste routbare Block, den ein IPv6-Endnutzer normalerweise erhält, ist ein /64: Die ersten 64 Bit sind das Netzwerk, die letzten 64 Bit kann der Nutzer beliebig füllen. Damit bleiben 2^64 nutzbare Adressen im Subnetz eines einzigen Anschlussinhabers:

2^64 = 18.446.744.073.709.551.616 Adressen: rund 18,4 Trillionen, alle gehören einem Nutzer, alle sind gleichermaßen routbar.

Zwei Tatsachen machen das unvermeidlich statt zu einer Eigenheit. Erstens erfordert die zustandslose Adressautokonfiguration (SLAAC), die Standardmethode, mit der IPv6-Hosts sich selbst Adressen zuweisen, ein volles /64 pro Subnetz; einem normalen LAN können Sie nichts Kleineres zuteilen. Zweitens weisen die Richtlinien zur Adressplanung, denen die RIRs folgen (RFC 6177 / BCP 157), ISPs an, jedem Endstandort eine großzügige Zuweisung zu geben, üblicherweise ein /56 oder /48 und nie weniger als ein /64. Überfluss ist der eigentliche Sinn des Protokolls.

Nun zur Seite des Angreifers. Diese Adressen durchzurotieren ist weder teuer noch raffiniert. Es ist eine eingebaute Socket-Option. Das Linux-Flag IP_FREEBIND erlaubt einem Prozess, sich an jede Adresse innerhalb eines lokal gerouteten Präfixes zu binden und von dort zu senden, ohne jede Adresse vorher auf einer Schnittstelle zu konfigurieren. Öffentliche Werkzeuge wie das vielzitierte Projekt freebind verpacken genau das zu „für jede Verbindung eine neue Quelladresse verwenden“. Geben Sie ihm ein geroutetes /64, und es erzeugt kostenlos Traffic von 18 Trillionen unterschiedlichen Quellen.

Das Rate Limit pro /128 bremst das also um keinen Faktor. Jede Anfrage sieht aus wie eine brandneue Adresse, die einmal auftaucht. Die Zähler Ihres Limiters kommen nie über eins hinaus, Ihre Sperrliste füllt sich mit Millionen Einträgen mit je einem Treffer und greift nie, und der Angriff läuft mit voller Geschwindigkeit weiter, während er auf dem Papier perfekt verteilt aussieht.

Die IPv6-Zuweisungshierarchie und was jede Ebene bedeutet

Um die richtige Einheit zu drosseln, müssen Sie wissen, wofür jede Präfixlänge tatsächlich steht. IPv6-Präfixe sind einfach CIDR-Blöcke (dieselbe /n-Notation wie bei IPv4, bei der eine kleinere Zahl mehr Adressen abdeckt), aber die üblichen Grenzen sagen etwas darüber aus, wer auf der anderen Seite sitzt.

Die Form der Entscheidung ergibt sich aus der Tabelle. Das /128 ist nie die Einheit. Das /64 ist die Untergrenze: der engste Geltungsbereich, der noch einem Akteur entspricht, und damit der Standard. Alles Breitere ist eine Eskalation, zu der Sie nur greifen, wenn Sie Belege dafür haben, dass die größere Zuweisung als Ganzes das Problem ist.

Regel eins: IPv6 nach Präfix drosseln, beginnend beim /64

Die eine Änderung, die den Großteil des Schadens behebt: Hören Sie auf, pro Adresse zu zählen, und zählen Sie pro /64. Konkret leiten Sie für jede eingehende IPv6-Anfrage das /64 ab, indem Sie die ersten vier Hextets (64 Bit) behalten, und verwenden das als Schlüssel für Rate-Limit-Zähler, Zählungen von Anmeldeversuchen und Abfragen der Sperrliste.

Jedes gängige Edge-Werkzeug unterstützt das bereits, Sie müssen es also selten selbst bauen:

• nginx: Bilden Sie den Limit-Schlüssel aus einem map/geo-Block, der IPv6 auf /64 maskiert, und übergeben Sie ihn an limit_req_zone / limit_conn_zone statt $binary_remote_addr.
• HAProxy: Setzen Sie beim Erstellen der Stick-Table-Schlüssel eine 64-Bit-Maske auf die Quelle, damit src auf das /64 statt auf die vollständige Adresse aggregiert wird.
• Cloudflare und die meisten CDNs / WAFs: Behandeln IPv6 für ihr eigenes Rate Limiting und ihre Challenge-Logik bereits in /64-Blöcken; übernehmen Sie diese Granularität in Ihre Origin-Regeln, damit beide Ebenen übereinstimmen.
• Ihr eigener Limiter in der Anwendung: Ersetzen Sie die rohe remote_addr durch den obigen /64-Schlüssel, bevor sie Redis, den Token Bucket oder den Zähler überhaupt erreicht.

Tun Sie nur das, und der Angriff mit kostenloser Rotation schrumpft auf das, was er sein sollte: Aus 18 Trillionen Adressen wird ein Zähler, und der Angreifer wird genau so gedrosselt, als wäre er eine einzige IPv4-Adresse. Das ist die wertvollste Codezeile des ganzen Themas.

Regel zwei: Bei Hartnäckigkeit auf /56 und /48 eskalieren

Das Schlüsseln auf das /64 erledigt den Angreifer, der Adressen innerhalb eines Subnetzes rotiert. Die nächste Stufe ist der Angreifer, der Subnetze rotiert, denn ein Anschlussinhaber besitzt oft nicht ein /64, sondern ein ganzes /56 oder /48 voller /64, und Werkzeuge nach Art von freebind können auch darüber hinweglaufen.

Das Signal zum Ausweiten ist Hartnäckigkeit: neue /64, die sich immer wieder danebenbenehmen und ein gemeinsames übergeordnetes Präfix teilen. Wenn Sie das sehen, ist die gesamte Zuweisung eine Einheit und sollte als solche behandelt werden.

Stellen Sie es sich als Zähler vor, der sich nach oben aufsummiert. Führen Sie die /64-Zählung als Basiseinheit, erfassen Sie aber auch den auf jedes /56 und /48 aggregierten Missbrauch. Überschreitet ein übergeordnetes Präfix einen Schwellenwert, den kein einzelner legitimer Kunde erreichen würde (viele verschiedene untergeordnete /64, die alle in kurzer Zeit auffällig werden), wenden Sie das Limit auf der übergeordneten Ebene an und lassen es alle untergeordneten Präfixe auf einmal abdecken. So bleiben Sie einem Angreifer mit einer großen Zuweisung voraus, ohne diejenigen zu bestrafen, die eine kleine, unauffällige besitzen.

Regel drei: Nach Netzwerktyp ausweiten, nicht aus Reflex

Eskalation hat eine Fehlerart, und zwar die teure: Weiten Sie zu weit aus, löscht eine einzige Sperre Tausende unschuldiger Nutzer aus. Ein /48 kann ein einzelnes Unternehmen sein oder ein Teil eines Mobilfunkanbieters. Ein /32 ist fast nie ein einzelner Akteur; typischerweise ist es ein ganzer ISP oder Hosting-Anbieter. Das Hartnäckigkeitssignal sagt Ihnen, dass das übergeordnete Präfix beteiligt ist; es sagt Ihnen nicht, wie viele echte Menschen dahinterstehen. Dafür müssen Sie wissen, um welche Art von Netzwerk es sich bei dem Präfix handelt.

Genau hier verdient sich eine IP-Abfrage ihren Platz in der Pipeline. Ein Aufruf der IP-Lookup-API für eine repräsentative Adresse aus dem auffälligen Präfix sagt Ihnen, ob Sie gemietete Infrastruktur vor sich haben, die Sie offensiv aggregieren können, oder Privatkundenzugänge, die Sie behutsam behandeln müssen.

Die Felder, die bestimmen, wie weit Sie gefahrlos gehen dürfen:

Das liefert diese Abfrage für eine reale IPv6-Adresse, Google Public DNS unter 2001:4860:4860::8888, abgefragt am 05.10.2026 (gekürzt; Ergebnisse ändern sich, wenn sich Bereiche verschieben):

Die beiden Hälften der Antwort beantworten zwei verschiedene Fragen. asn_type: "hosting", connection_type: "datacenter" und is_hosting: true besagen, dass das Präfix Infrastruktur ist; eine Sperre über das /64 hinaus würde also keine Haushalte treffen. Aber scoring.fraud_score ist 15 und recommended_action ist allow: Die Adresse selbst hat kein VPN-, Tor- oder Missbrauchssignal, und detection_methods listet nur datacenter_ip und no_ptr_datacenter. Der Netzwerktyp sagt Ihnen, wie weit Sie ausweiten dürfen; den Grund, überhaupt auszuweiten, müssen Ihre eigenen Hartnäckigkeitszähler liefern. Ein Hosting-Präfix, das nie auffällig war, bleibt offen.

Die Lesart ist richtungsabhängig und folgt demselben Prinzip wie Gründe im Risikoscore, die addieren und subtrahieren: Manche Felder erlauben Ihnen, härter vorzugehen, andere sagen Ihnen, dass Sie sich zurückhalten sollen.

Google Ads zählt genauso: Seine API akzeptiert 2001:db8::/48 als einen IP-Ausschlusseintrag, also kostet ein /48 einen Ihrer 500 Ausschlussplätze in Google Ads.

Die Disziplin ist dieselbe, für die wir ausführlich in anonymisierten Traffic erkennen, ohne echte Kunden zu blockieren argumentieren: Bei einem hosting- oder datacenter-Präfix können Sie die Sperre mit Zuversicht ausweiten, denn ein Checkout oder eine Registrierung hat keinen ehrlichen Grund, aus einem Serverschrank zu kommen. Es ist dasselbe Merkmal, das wir in was eine Rechenzentrums-IP-Adresse ist erklären. Bei einem mobile- oder residential-Präfix halten Sie den Geltungsbereich eng und lassen den Risikoscore die Last tragen, nicht eine breite CIDR-Sperre. Ausweiten aus Reflex ist der Weg, auf dem ein Rate Limiter unbemerkt zum Ausfall für echte Nutzer wird.

Regel vier: Die Reputation von Präfixen abklingen lassen

Die letzte Regel betrifft die Zeit. IPv4-Sperrlisten veralten ohnehin, weil Adressen neu vergeben werden; IPv6 verschärft das, denn ganze Präfixe werden delegiert, zurückgegeben und neu delegiert, und das /64, das letzten Monat auf Ihre Login-Seite eingehämmert hat, kann heute einem gewöhnlichen Haushalt gehören. Eine dauerhafte Sperrliste für rotierenden Adressraum wird langsam zu einer Liste von Orten, die Sie nicht mehr gefahrlos erreichen können.

Speichern Sie also kein dauerhaftes Urteil pro Präfix. Speichern Sie eine Reputation, die sich bewegt:

• Bei Missbrauch erhöhen. Jede auffällige Anfrage erhöht den Score des /64 und reicht eine kleinere Erhöhung an die übergeordneten /56 und /48 weiter.
• Mit der Zeit abklingen lassen. Bleibt ein Präfix ruhig, sinkt sein Score nach Zeitplan (Stunden für eine sanfte Drosselung, Tage für eine harte Sperre), bis er wieder unter Ihren Schwellenwert fällt und die Sperre sich selbst aufhebt.
• Nach dem aktuellen Score handeln, nicht nach der Vergangenheit. Drosseln, fordern Sie eine Challenge an oder blockieren Sie danach, wo die Reputation jetzt steht, damit sich ein gebessertes oder neu vergebenes Präfix automatisch erholt, statt auf einer Liste zu bleiben, die niemand bereinigt.
• Die Belege aufbewahren. Speichern Sie, welche Signale jede Score-Änderung ausgelöst haben (die detection_methods aus der Abfrage, das Hartnäckigkeitsmuster), damit eine breite Sperre eine Entscheidung ist, die Sie erklären können, kein rätselhafter Eintrag.

Das Abklingen hält das ganze System ehrlich. Eine aggressive Eskalation während eines Angriffs wird so nicht zur bleibenden Narbe, und Ihre Sperrliste zeigt, wer jetzt feindlich ist, nicht wer es einmal war.

Erste Schritte in dieser Woche

• Stellen Sie den Schlüssel des Limiters auf das /64 um. Überall, wo Sie derzeit pro Adresse zählen oder sperren, maskieren Sie IPv6 zuerst auf die ersten 64 Bit. Diese eine Änderung schließt die Lücke der kostenlosen Rotation und umfasst in nginx, HAProxy oder Ihrer Anwendung meist nur wenige Zeilen.
• Ergänzen Sie aufsummierte Zähler für /56 und /48. Erfassen Sie auf die übergeordneten Präfixe aggregierten Missbrauch, damit ein Angreifer, der Subnetze rotiert, ein breiteres Limit auslöst, ohne dass Sie standardmäßig ausweiten.
• Fragen Sie das Netzwerk ab, bevor Sie ausweiten. Prüfen Sie bei jeder Eskalation über das /64 hinaus asn_type / connection_type: bei Hosting frei aggregieren, bei Mobilfunk und Privatkunden eng bleiben, einen Bereich eines Mobilfunkanbieters oder CGNAT nie hart blockieren.
• Bewerten Sie die unklaren Fälle. Wo ein Präfix geteilt ist oder Privatkunden gehört, verwenden Sie den zusammengesetzten fraud_score und recommended_action pro Adresse statt einer pauschalen CIDR-Sperre.
• Geben Sie jeder Sperre ein Abklingen. Speichern Sie die Reputation von Präfixen mit einer Halbwertszeit, handeln Sie nach dem aktuellen Score und lassen Sie neu vergebenen Adressraum sich automatisch freigeben.

IPv6 hat die Missbrauchsprävention nicht so sehr erschwert, als vielmehr die Einheit verändert. Die Adresse ist nicht mehr der Nutzer; das /64 ist es. Zählen Sie das, eskalieren Sie anhand von Belegen, gewichten Sie nach Netzwerktyp und lassen Sie die Zeit vergeben. Dann funktioniert jede Abwehr, der Sie bei IPv4 bereits vertrauen, wieder.

Häufig gestellte Fragen

Warum kann man eine IPv6-Adresse nicht so drosseln wie eine IPv4-Adresse?

Weil die beiden Protokolle pro Nutzer sehr unterschiedlich viel Adressraum vergeben. Bei IPv4 erhält ein Anschlussinhaber meist eine Adresse, ein Limit pro /32 (eine einzelne Adresse) ist also ein Limit pro Nutzer. Bei IPv6 wird einem einzelnen Anschlussinhaber routinemäßig ein ganzes /64 zugewiesen. Das sind 2^64, rund 18,4 Trillionen Adressen, und Werkzeuge wie IP_FREEBIND erlauben einem Prozess, kostenlos Traffic von jeder Adresse in diesem Block zu senden. Ein Rate Limit oder Sperrlisteneintrag für ein /128 (eine einzelne IPv6-Adresse) hält daher nichts auf: Der Angreifer nimmt einfach die nächste von 18 Trillionen Adressen. Die richtige Einheit bei IPv6 ist das /64, nicht das /128.

Auf welche Präfixlänge sollte ich IPv6 drosseln?

Beginnen Sie beim /64. Das /64 ist der kleinste Block, der garantiert einem einzelnen Endnutzer gehört, denn SLAAC erfordert ein volles /64 pro Subnetz, und ISPs weisen jedem Kunden mindestens ein /64 zu. Schlüsseln Sie Zähler und Sperrlisten auf die ersten 64 Bit der Adresse und behandeln Sie das ganze /64 als einen Akteur. Hält der Missbrauch über viele /64 desselben Kunden an, erweitern Sie den Geltungsbereich auf das /56 (256 /64) und dann auf das /48 (65.536 /64), die typischen Größen der Zuweisung für einen ganzen Haushalt oder ein Unternehmen.

Kann man ein ganzes IPv6-/64 gefahrlos blockieren?

Fast immer ja, und gefahrloser als eine einzelne IPv4-Adresse. Ein /64 ist als Subnetz eines einzigen Anschlussinhabers gedacht, daher trifft eine Sperre selten Unbeteiligte, wie es bei einer geteilten IPv4-CGNAT-Adresse passiert. Das eigentliche Risiko liegt bei den breiteren Präfixen: Ein /48 oder /32 kann ein ganzer ISP, ein Mobilfunkanbieter oder ein Shared-Hosting-Bereich mit Tausenden voneinander unabhängiger Nutzer sein. Erweitern Sie den Geltungsbereich nur, wenn der Netzwerktyp es rechtfertigt: offensiv bei Hosting- und Rechenzentrumspräfixen, vorsichtig bei Mobilfunk- und Privatkundenpräfixen.

Woher weiß ich, wie weit ich eine Sperre ausweiten soll?

Lassen Sie zwei Dinge entscheiden: Hartnäckigkeit und Netzwerktyp. Hartnäckigkeit: Taucht Missbrauch immer wieder aus neuen /64 innerhalb desselben /56 oder /48 auf, ist die gesamte Zuweisung eine Einheit, und Sie erweitern auf sie. Netzwerktyp: Liefert eine Abfrage eine Hosting- oder Rechenzentrums-ASN, ist das Präfix Infrastruktur, und Sie können schnell aggregieren; bei einem Mobilfunkanbieter oder Privatkunden-ISP können viele echte Nutzer hinter dem breiteren Präfix stehen, also bleiben Sie eng und stützen sich auf einen Risikoscore statt auf eine harte Sperre.

Ändern CGNAT und Mobilfunknetze, wie ich mit IPv6 umgehen sollte?

Ja, am breiten Ende. Ein einzelnes IPv6-/64 ist auch im Mobilfunk normalerweise ein Anschlussinhaber, ein Limit pro /64 ist also weiterhin richtig. Mobilfunkanbieter und 464XLAT/NAT64-Bereitstellungen können aber viele Teilnehmer unter einem gemeinsamen breiteren Präfix bündeln, sodass eine Sperre auf /48 oder /32 für eine Mobilfunk-ASN einen großen Teil der Kunden eines Anbieters ausschließen kann. Die Regel ist dieselbe wie bei IPv4: Sperren Sie einen geteilten Bereich nie hart wegen eines einzelnen schlechten Akteurs. Bewerten Sie ihn und behalten Sie breite Sperren Infrastrukturpräfixen vor.

Wie lange sollte ein IPv6-Präfix gesperrt bleiben?

Nicht für immer. IPv6-Präfixe werden neu vergeben, und ein /64, das Sie letzten Monat angegriffen hat, kann nächsten Monat ein anderer Kunde sein. Verknüpfen Sie jedes Präfix mit einer abklingenden Reputation statt mit einem dauerhaften Eintrag: Erhöhen Sie den Score bei Missbrauch, lassen Sie ihn mit der Zeit sinken, wenn nichts Schlechtes passiert, und heben Sie die Sperre automatisch auf, sobald er unter Ihren Schwellenwert fällt. Eine dauerhafte Sperrliste für rotierenden Adressraum wird langsam zu einer Liste von Adressen, die Sie nicht mehr gefahrlos erreichen können.