CGNAT erklärt: Warum eine IP-Adresse nicht gleich ein Nutzer ist

Erstaunlich viele Abuse-Regeln beruhen noch immer auf einer Annahme, die seit Jahren nicht mehr zuverlässig stimmt: Eine IP-Adresse identifiziert einen Nutzer. Carrier-grade NAT (CGNAT) ist einer der Hauptgründe dafür.

Was CGNAT ist

IPv4-Adressen sind knapp geworden. Statt für jeden Anschluss knappen Adressraum zu kaufen, setzen Mobilfunkanbieter und viele Festnetz-ISPs ihre Kunden hinter einen gemeinsamen Pool öffentlicher Adressen und übersetzen ausgehende Verbindungen über Ports. Eine einzige öffentliche Adresse kann dadurch gleichzeitig für Hunderte oder Tausende Haushalte oder Smartphones stehen.

Aus Sicht Ihres Servers sieht all dieser Traffic wie ein einzelner Client aus.

Was dadurch kaputtgeht

Blocking. Sperren Sie nach einem Brute-Force-Versuch die Adresse, haben Sie im Zweifel einen ganzen Häuserblock in einem Mobilfunknetz ausgesperrt. Der Angreifer verbindet sich neu, bekommt binnen Sekunden eine andere Adresse aus dem Pool und macht weiter.

Rate Limiting. Ein Limit von 10 Requests pro Minute und IP ist für eine einzelne Person großzügig. Für 2,000 Teilnehmende, die denselben Ausgang teilen, ist es absurd eng. In Spitzenzeiten drosseln Sie legitime Nutzer – und merken es oft nicht einmal, weil diese schlicht abspringen.

Attribution. „Zwei Accounts von derselben IP“ ist in einem Carrier-Netz nur ein sehr schwaches Indiz für Multi-Accounting. Bei einem privaten Glasfaseranschluss kann es etwas bedeuten. Bei CGNAT bedeutet es fast nichts.

Analytics. Unique-Visitor-Zahlen auf Basis von IP-Adressen werden im Mobilfunk komprimiert und in Netzen mit häufig rotierenden Adressen künstlich aufgebläht. Beide Fehler bleiben im Dashboard meist unsichtbar.

Woran Sie CGNAT erkennen

Diese Signale sollten aufmerksam machen:

• Der Verbindungstyp wird als mobile gemeldet, oder die ASN gehört zu einem Mobilfunkanbieter.
• Sehr hohe Vielfalt bei Requests von einer Adresse: viele User Agents, viele Accounts, viele Locales.
• Adressen aus dem Shared-Transition-Space (100.64.0.0/10), die in Forwarded Headers auftauchen.

Ein IP-Intelligence-Lookup liefert die ersten beiden Punkte direkt. Das reicht oft schon, um die Policy zur Request-Zeit anzupassen.

Was Sie stattdessen tun sollten

• Limits nach Netzklasse skalieren. Für Residential-Traffic kann ein enges Per-IP-Limit sinnvoll sein. Mobile- und Business-Ranges brauchen deutlich großzügigere IP-Limits, ausgeglichen durch strengere Limits pro Account und Gerät.
• Identität eine Ebene tiefer verankern. Begrenzen Sie, wo immer möglich, nach Account ID, Session oder einem Device-Signal. Die IP-Adresse sollte ein sekundärer Schlüssel sein, nicht der primäre.
• Challenges statt Blocks bevorzugen. Eine Challenge ist für ein geteiltes Netz lästig. Ein Block bestraft es kollektiv.
• Sperren kurz halten. Wenn Sie eine geteilte Adresse sperren müssen, denken Sie in Minuten, nicht in Tagen. Der Angreifer ist längst weitergezogen, bevor Ihre Sperre ausläuft.
• Auf Kollateralschäden achten. Wenn eine einzelne Sperre mehr als eine Handvoll aktiver Accounts betreffen würde, ist das ein klares Zeichen: Die Adresse wird geteilt, und die Sperre ist das falsche Werkzeug.

Das Grundprinzip

Eine IP-Adresse beschreibt den Weg, nicht die Person. Sie ist ein starkes Risikosignal, aber ein miserabler Identifier. Systeme, die diesen Unterschied ernst nehmen, blockieren deutlich mehr Missbrauch pro False Positive als Systeme, die ihn ignorieren. Und auch IPv6, das wieder mehr adressbezogene Trennschärfe pro Anschluss bringt, löst das Problem nicht, solange mobiler Traffic weiter wächst.