Wenn die Konversion von mobilem Traffic plötzlich gesunken ist und das Registrierungs- oder Zahlungsformular bei echten Kunden einen Fehler 403 anzeigt, liegt das wahrscheinlich nicht an einem Hacker, sondern an Ihrem eigenen WAF. Die Firewall sieht Tausende von Anfragen von einer IP-Adresse des Mobilfunkanbieters und interpretiert dies als DDoS oder Brute Force. Tatsächlich sitzen hinter dieser IP Hunderte oder Tausende von normalen Menschen – das ist die CGNAT-Technologie. Wir klären, wie man dies erkennen und beheben kann, ohne dabei eine Lücke für echte Angriffe zu öffnen.
Was ist CGNAT und warum verursacht es Probleme
CGNAT (Carrier-Grade NAT) ist eine Technologie, die Mobilfunkanbieter aufgrund des Mangels an IPv4-Adressen verwenden. Anstatt jedem Abonnenten eine einzigartige öffentliche IP zuzuweisen, "versteckt" der Anbieter Tausende von Nutzern hinter einer oder mehreren gemeinsamen Adressen. Für die Website sieht das so aus: Von einer IP kommt gleichzeitig Traffic von Hunderten verschiedener Personen – verschiedene Geräte, verschiedene Browser, unterschiedliches Verhalten, aber dieselbe externe Adresse.
Für einen normalen Webserver ist das kein Problem – er verarbeitet einfach die Anfragen. Aber für Schutzsysteme, die Anfragen pro Zeiteinheit von einer IP zählen, sieht das wie eine Anomalie aus. Stellen Sie sich vor: In einer Minute kommen von einer Adresse 200 Anfragen zur Login-Seite. Für WAF ist das ein klassisches Muster von Brute Force oder Scraping. Tatsächlich könnten das 150 echte Kunden eines Mobilfunkanbieters in Ihrer Region sein, die einfach gleichzeitig die Website nach einer Werbeaktion oder einem Beitrag in sozialen Medien geöffnet haben.
Besonders ausgeprägt ist das Problem in Ländern mit einer hohen Dichte an mobilem Internet – Anbieter bündeln eine riesige Anzahl von Abonnenten hinter einer minimalen Anzahl von externen IPs. Deshalb ist es notwendig, das Verhalten der Website nicht von einer normalen Rechenzentrums-IP, sondern von mobilen Proxys zu testen, die tatsächlich durch die CGNAT-Infrastruktur des Anbieters gehen – nur so kann das gleiche Bild reproduziert werden, das WAF bei echten Nutzern sieht.
Warum WAF CGNAT als Bedrohung sieht
Die meisten WAF-Lösungen – Cloudflare, AWS WAF, Imperva, integrierte Module von Nginx/ModSecurity – verwenden Rate-Limiting pro IP-Adresse als grundlegenden Schutzmechanismus gegen Bots und DDoS. Die Logik ist einfach: Wenn von einer IP mehr als N Anfragen in T Sekunden kommen – blockieren oder zeigen ein Captcha an. Diese Regel funktioniert hervorragend für klassische Angriffe von einem Gerät, bricht aber vollständig bei CGNAT-Traffic zusammen.
Es gibt mehrere typische Szenarien, in denen dies problematisch ist:
- Rate-Limiting pro IP. Ein Limit von "100 Anfragen pro Minute von einer IP" ist für Rechenzentrums-Traffic normal, aber katastrophal für eine mobile Region mit einer Million Abonnenten hinter einer Adresse.
- Verhaltensbewertung. Wenn das System "Reputation" für IPs basierend auf der Anfragehistorie aufbaut, kann ein "schlechter" Nutzer hinter CGNAT die Reputation der Adresse für Tausende nachfolgender ehrlicher Kunden ruinieren.
- Geografische Heuristik. WAF markiert manchmal IPs als verdächtig, wenn es plötzliche Aktivitätsspitzen sieht, die für einen "normalen" Nutzer untypisch sind – und das Verhalten einer CGNAT-Adresse ist genau so: Spitzenlasten zu den Zeiten, in denen die Zielgruppe aktiv ist.
- Blockierung nach ASN des Anbieters. Einige WAF-Regeln blockieren ganze ASN-Bereiche von Mobilfunkanbietern, wenn zuvor Angriffe von diesen Bereichen kamen – betroffen sind alle Kunden des Anbieters im Land.
Fazit: Je strenger der WAF "out of the box" konfiguriert ist, desto höher ist die Wahrscheinlichkeit, dass er nicht Bots, sondern Ihre echte mobile Zielgruppe blockiert – insbesondere wenn das Geschäft auf Länder mit einem entwickelten mobilen Internet und einem hohen Anteil an CGNAT-Traffic ausgerichtet ist.
Was das für Unternehmen bedeutet: verlorene Kunden und Geld
Das Problem der CGNAT-Blockierungen ist selten in der Standardanalyse sichtbar. Google Analytics und Yandex.Metrica erfassen einfach nicht diejenigen, die einen Fehler 403 auf WAF-Ebene erhalten haben – solche Besuche gelangen oft nicht einmal zum Zähler. Infolgedessen sieht der Marketer einen Rückgang der Konversion, versteht aber nicht die Ursache und beginnt, Kreative und Landing Pages zu optimieren, obwohl das Problem in der Infrastruktur liegt.
Echte Konsequenzen für verschiedene Geschäftssegmente:
- E-Commerce. Ein Käufer aus dem mobilen Internet kann den Bestellvorgang nicht abschließen – das Zahlungsformular zeigt einen Fehler an, der Warenkorb geht verloren. Direkte Verluste im Umsatz, besonders auffällig nach dem Start von Werbung in TikTok Ads oder Facebook Ads, wo der Haupttraffic mobil ist.
- SaaS und Registrierungen. Ein Nutzer versucht, sich zu registrieren oder in sein persönliches Konto einzuloggen, erhält bei jedem Schritt ein Captcha oder wird blockiert – er wechselt zu einem Konkurrenten.
- Inhalte und Werbung. Werbetraffic von mobilen Geräten "bricht massenhaft" auf der Landing Page ab, das Werbebudget wird ausgegeben, aber es gibt keine Konversion – die Algorithmen der Werbeplattformen interpretieren dies als geringe Qualität des Publikums und erhöhen die Kosten pro Klick.
- Kundendienst. Die Anzahl der Anfragen "Ihre Website öffnet sich nicht", "Ich kann mich nicht registrieren" steigt – der Support sieht das Problem nicht, weil er selbst über Desktop über das Büro-Wi-Fi ohne CGNAT zugreift.
Das Unangenehmste ist, dass solche Blockierungen nachträglich schwer zu diagnostizieren sind, da das WAF-Log eine "verdächtige" IP mit einer riesigen Anzahl von Anfragen zeigt, und der Administrator sieht darin eine Bestätigung der Richtigkeit der Blockierung, nicht ein Fehlalarm.
6 Prüfungen mit mobilen IPs, um das Problem zu finden
Um zu verstehen, ob Ihr WAF ehrliche mobile Kunden blockiert, müssen Sie die realen Bedingungen von CGNAT reproduzieren – das heißt, die Website von echten mobilen IPs verschiedener Anbieter und Regionen zu testen. Hier ist eine praktische Checkliste mit 6 Prüfungen.
Prüfung 1: Massenanmeldung von einer mobilen IP
Richten Sie mehrere parallele Sitzungen über dieselbe mobile IP ein (das ist natürlich für Proxys mit CGNAT-Anbieter) und führen Sie 50-100 normale Aktionen aus – Seiten öffnen, in den Warenkorb legen, zwischen Abschnitten wechseln. Wenn nach einem bestimmten Schwellenwert ein Captcha oder 403 erscheint – das ist das erste Signal für ein Problem.
Prüfung 2: Wechsel des User-Agent bei einer IP
Eine CGNAT-Adresse bedient verschiedene Geräte – iPhone, Android, verschiedene Browser. Starten Sie Anfragen mit verschiedenen User-Agent-Strings über eine IP und prüfen Sie, ob die WAF-Regel "verdächtige Variabilität der Geräte von einer Adresse" aktiviert wird.
Prüfung 3: Test an kritischen Formularen
Durchlaufen Sie den gesamten Kundenweg – Registrierung, Autorisierung, Bestellabwicklung, Zahlung – genau über die mobile IP des Anbieters. Oft ist WAF aggressiver auf Formularen mit Dateneingabe (Login, Zahlung), wo das Risiko von Brute Force höher ist, und das ist der erste Ort, an dem echte Kunden verloren gehen.
Prüfung 4: Prüfung bei verschiedenen Anbietern und Regionen
Das Verhalten von CGNAT unterscheidet sich bei verschiedenen Anbietern und in verschiedenen Ländern – wo hinter einer IP 50 Abonnenten verborgen sind, sind es woanders 5000. Testen Sie die Website von mobilen IPs mehrerer Anbieter in für das Geschäft wichtigen Geos, um zu verstehen, ob es regionale Spezifika bei den Blockierungen gibt.
Prüfung 5: Analyse der Serverantwort nach Codes und Headern
Dokumentieren Sie nicht nur die Tatsache der Blockierung, sondern auch den genauen HTTP-Code und die Antwort-Header (zum Beispiel cf-mitigated: challenge bei Cloudflare). Das hilft zu verstehen, welcher Schutzmechanismus ausgelöst wurde – Rate-Limit, Bot-Detection oder geografische Regel.
Prüfung 6: Langfristige Überwachung der IP-Reputation
Wiederholen Sie den Test über dieselbe mobile IP über mehrere Tage. Wenn der Zugang im Laufe der Zeit ohne sichtbare Gründe von Ihrer Seite aus schlechter wird – bedeutet das, dass das System der kumulativen Bewertung die Reputation der Adresse aufgrund der Aktivität anderer Abonnenten hinter demselben CGNAT "ruiniert", und das ist ein systemisches, kein einmaliges Problem.
Wichtig zu verstehen:
Für solche Tests sind genau echte mobile IPs erforderlich, keine Rechenzentrums- oder normalen Wohnadressen – nur der Traffic, der durch die Infrastruktur des Anbieters gegangen ist, reproduziert genau das CGNAT-Muster, das Ihr WAF bei echten Nutzern sieht.
Wie man WAF so konfiguriert, dass ehrliche Kunden nicht blockiert werden
Nach der Diagnose müssen die Schutzregeln so angepasst werden, dass das Sicherheitsniveau nicht verloren geht, aber echte mobile Nutzer nicht mehr blockiert werden. Hier sind die wichtigsten Ansätze.
| Problem | Lösung im WAF |
|---|---|
| Strenges Rate-Limit pro IP | Erhöhen Sie das Limit für bekannte ASN von Mobilfunkanbietern oder wechseln Sie zu einem Limit pro Sitzung/Cookie anstelle einer reinen IP |
| Kumulative Bewertung der IP-Reputation | Die "Speicherzeit" der Reputation für CGNAT-Bereiche verkürzen, Whitelist für bekannte ASN von Anbietern hinzufügen |
| Blockierung nach Geo/ASN insgesamt | Ersetzen Sie die vollständige Blockierung durch eine sanfte Herausforderung (JS-Prüfung) anstelle von 403 |
| Strenges Captcha auf Login-Formularen | Captcha adaptiv aktivieren – nur bei echten Anzeichen von Brute Force (mehrere fehlgeschlagene Versuche von einem Konto), nicht aufgrund der CGNAT-IP |
Eine gute Praxis ist es, eine eigene Liste bekannter Bereiche von Mobilfunkanbietern für Ihre Schlüsselgeos zu führen und ihnen separate, mildere Regeln im Vergleich zu normalem Internet-Traffic zu geben. Dies erfordert Zeit für die Einrichtung, reduziert aber drastisch die Anzahl der falschen Blockierungen.
Werkzeuge für Tests mit mobilen Proxys
Für regelmäßige Audits des Website-Schutzes ist es praktisch, eine Kombination aus Anti-Detect-Browser und mobilen Proxys zu verwenden. Anti-Detect-Browser (Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) ermöglichen es, isolierte Profile mit unterschiedlichen Geräte-Fingerabdrücken zu erstellen, während mobile Proxys echten CGNAT-Traffic von Anbietern bereitstellen.
Schritt-für-Schritt-Ansatz für Tests:
- Erstellen Sie mehrere Profile im Anti-Detect-Browser mit unterschiedlichen Geräteeinstellungen (verschiedener User-Agent, Bildschirmauflösung, Zeitzone).
- Verbinden Sie zu jedem Profil mobile Proxys der benötigten Region und des Anbieters – das gibt echtes CGNAT-Verhalten.
- Durchlaufen Sie wichtige Benutzerszenarien: Registrierung, Login, Warenkorb hinzufügen, Zahlung.
- Dokumentieren Sie alle Fälle von Captcha, 403 und anderen Blockierungen und vergleichen Sie sie mit den WAF-Einstellungen.
- Wiederholen Sie den Test mit Wohnproxys zum Vergleich – das hilft zu verstehen, ob das Problem spezifisch für mobilen Traffic ist.
Für parallele Tests in verschiedenen Geos sind auch residential Proxys nützlich – sie helfen zu bewerten, wie aggressiv WAF für normalen Heimtraffic und mobilen CGNAT ist. Wenn Sie Lasttests von der Serverinfrastruktur ohne Bindung an den Anbieter planen, können Sie für Kontrollprüfungen ohne CGNAT-Effekt Rechenzentrums-Proxys anschließen – sie geben eine saubere Basislinie ohne Verzerrungen, die für mobile Netzwerke typisch sind.
Dieser umfassende Ansatz – mobile, residential und datacenter IPs in einem Test – bietet ein vollständiges Bild: Sie sehen genau, wo der Schutz anspricht und für welche Art von Traffic, und raten nicht anhand indirekter Hinweise in den Logs.
Häufige Fragen
Kann man CGNAT-Bereiche vollständig aus den WAF-Regeln ausschließen?
Wird nicht empfohlen – das würde den Schutz vor echten Angriffen verringern, die ebenfalls über mobile Netzwerke erfolgen können. Richtig ist es, die Schwellenwerte zu mildern und zu einem sanften Challenge anstelle einer strengen Blockierung überzugehen.
Wie oft sollten solche Prüfungen durchgeführt werden?
Mindestens einmal im Monat und unbedingt nach jeder Änderung der WAF-Regeln oder dem Start einer neuen Werbekampagne für die mobile Zielgruppe.
Hat das Einfluss auf SEO?
Ja – wenn Suchbots oder echte Nutzer von mobilen Geräten einen 403 erhalten, erhöht das die Absprungrate und kann sich negativ auf die Verhaltensmetriken des Rankings auswirken.
Fazit
CGNAT ist keine Bedrohung, sondern eine Besonderheit des mobilen Internets, mit der praktisch jedes Unternehmen mit einer mobilen Zielgruppe konfrontiert ist. Das Problem liegt nicht in der Technologie selbst, sondern darin, dass die Standard-WAF-Einstellungen ihre Spezifik nicht berücksichtigen und ehrliche Nutzer für ein Verhalten bestrafen, das für normale mobile Netzwerke typisch ist. Die sechs Prüfungen aus diesem Artikel helfen schnell zu diagnostizieren, ob Sie Kunden aufgrund falscher Blockierungen verlieren, und eine gezielte Anpassung der WAF-Regeln kann die Konversion zurückgewinnen, ohne das Sicherheitsniveau zu senken.
Wenn Sie planen, das Verhalten der Website und der Verkaufstrichter regelmäßig so zu testen, wie es echte mobile Kunden sehen, empfehlen wir die Verwendung von mobilen Proxys – sie bieten echten CGNAT-Traffic von Anbietern und helfen, falsche Blockierungen zu finden, bevor sie Ihre Kunden finden.