Ab welchem IP-Fraud-Score sollten Sie sperren?

Es gibt nicht den einen IP-Fraud-Score-Schwellenwert, ab dem Sie sperren: Derselbe Score kann einen Login durchlassen, eine Registrierung zur Prüfung markieren und einen Checkout an 3-D Secure schicken. Die Skala von 0 bis 100 von GeoIPHub lässt standardmäßig bis 25 zu (allow), prüft bis 50 (review), verlangt bis 75 eine zusätzliche Authentifizierung (step_up) und sperrt oberhalb von 75 (block), und dieser Leitfaden verschiebt diese Grenzen pro Aktion, getestet an fünf öffentlichen Adressen am 22. Oktober 2026.

Ein Score, drei Türen: fünf IPs, die wir durch die Schwellenwerte geschickt haben

Dasselbe Urteil der API wirkt an jeder Tür anders, und zwei Score-Deckelungen entscheiden, was eine geteilte Adresse überhaupt erreichen kann. Am 22. Oktober 2026 um 04:56 UTC haben wir fünf öffentliche Adressen mit der API ohne Schlüssel abgefragt und jedes Ergebnis auf die Ausgangsschwellenwerte im nächsten Abschnitt abgebildet. Die letzten beiden Zeilen sind keine Abfragen. Es sind die Obergrenzen aus unserer Scoring-Konfiguration.

Vier Punkte in dieser Tabelle verdienen eine Reaktion.

• Die beiden 100er haben unterschiedliche Gründe. Die Methoden des Tor-Exit-Nodes sind tor_exit, datacenter_blocklisted, no_ptr_datacenter und known_spammer: ein Anonymisierer mit Spam-Historie. Die des Mullvad-Servers sind known_vpn_server, wireguard_open, datacenter_with_vpn_proxy und no_ptr_datacenter, mit threat.is_spammer false und ohne Eintrag in einer DNS-Blocklist. Wenn Ihre Kunden VPNs nutzen, ist eine Login-Regel vertretbar, die eine reine VPN-Sperre in MFA umwandelt, und beim Tor-Exit-Node würde sie nie greifen.
• In der mittleren Zeile zahlen sich Schwellenwerte pro Aktion aus. AhrefsBot mit 35 kommt beim Login durch, wird bei der Registrierung markiert und geht am Checkout an 3-D Secure. Dabei hat ein verifizierter SEO-Crawler keinen Grund, eines dieser Formulare abzuschicken, und das sagt Ihnen der Score allein nicht.
• Diese mittlere Zeile hat sich innerhalb von zwei Wochen verändert. Dieselbe Adresse erhielt am 8. Oktober 23 Punkte und am 19. Oktober 59, step_up, mit abusive_listed unter ihren Methoden. Am 22. Oktober war diese Methode verschwunden und der Score lag bei 35, der Login fiel also von MFA auf eine einfache Anmeldung zurück. Wir gehen diese Adresse in wie Sie eine IP-Adresse untersuchen durch. Speichern Sie Score, Methoden und Datum bei jeder Entscheidung und wiederholen Sie die Abfrage, bevor Sie nach einem alten Urteil handeln.
• Geteilte Adressen können block nicht erreichen. Private Relay ist bei 60 gedeckelt (relay_max_score) und kann die Standard-Sperrgrenze von 76 daher nie überschreiten. CGNAT ist bei 50 gedeckelt (cgnat_max_score), dem oberen Ende des Review-Bands. Unsere strengste Sperrgrenze, 66 am Checkout, liegt bewusst über beiden. Bei 60 oder darunter könnte ein gedeckelter Relay-Nutzer abgelehnt werden, nur weil er eine Adresse teilt.

Die beiden allow-Zeilen zeigen, dass das Scoring additiv ist. Das Signal relay_ip des Relays sind 10 Punkte bei einer Konfidenz von 0,85, gerundet 9. Das datacenter_ip des Linode-Servers sind 20 Punkte bei 0,5, also 10. Hosting ist ein Grund, hinzusehen, nicht zu sperren, und Relays sollten durchkommen, wie wir in wie Sie Private-Relay- und WARP-Traffic erkennen erklären.

Ausgangsschwellenwerte für den IP-Fraud-Score bei Login, Registrierung und Checkout

Die Ausgangsschwellenwerte ziehen die Sperrgrenze enger, je teurer ein fälschliches Zulassen wird: 76 beim Login, 71 bei der Registrierung, 66 am Checkout. Behandeln Sie sie als Ausgangspunkte und justieren Sie sie anhand Ihrer eigenen Betrugsdaten nach.

Kombinieren Sie den Score für die eindeutigen Fälle mit einigen Regeln auf den Signalen:

• Sperren Sie jede Aktion, wenn detection.is_tor true ist. Das ist der eine Fall, in dem der Grund allein eine Ablehnung rechtfertigt.
• Sperren Sie nie hart aufgrund des Scores, wenn detection.is_relay oder threat.is_cgnat true ist. Die Deckelungen setzen das hier bereits durch; die Regel schützt Sie, falls jemand später eine Sperrgrenze senkt.
• Behandeln Sie review am Checkout als step_up. Unser Tutorial zur IP-Betrugserkennungs-API enthält getesteten Node- und Python-Code für genau diese Übersteuerung sowie eine fehlertolerante Behandlung, wenn eine Abfrage in ein Timeout läuft.

Was jede Art von Adresse bei der Registrierung zurückgibt und welche Velocity-Limits pro Präfix erfassen, was ein Score durchlässt, lesen Sie in Erkennung gefälschter Konten bei der Registrierung.

Was jedes Band bedeutet und wie ein einzelner Score entsteht, erfahren Sie zuerst in wie Sie einen IP-Fraud-Score lesen.

Ein Tor-Exit-Node erhält 100, und die Methoden sagen, warum

Hier ist eine gekürzte Kopie der echten Antwort für 185.220.101.1, abgefragt am 22. Oktober 2026 um 04:56 UTC:

Ein fraud_score von 100 überschreitet jede Sperrgrenze in der Tabelle, Login, Registrierung und Checkout lehnen ihn also alle ab. Drei Gründe bringen ihn allein dorthin: tor_exit (45 Punkte bei 0,99), known_spammer (40 bei 0,9) und datacenter_blocklisted (30 bei 0,75) ergeben zusammen 103, bevor bei 100 gedeckelt wird. detection.is_vpn ist false, weil Tor separat markiert wird; Sie können also bei detection.is_tor hart sperren und gewöhnliche VPN-Nutzer trotzdem nur herausfordern.

Der vierte Grund ist eine Lücke auf unserer Seite. no_ptr_datacenter besagt, dass die Adresse kein Reverse DNS hat, doch dig -x 185.220.101.1 lieferte an jenem Morgen um 04:57 UTC einen Hostnamen für einen Tor-Exit-Node. In unserer Datenbank fehlt dieser gespeicherte Eintrag, und die Korrektur ist erfasst. Das Urteil steht auch auf den anderen drei Signalen, aber es ist ein guter Grund, Regeln auf Signale zu schreiben, denen Sie vertrauen, und nicht auf die rohe Summe.

Warum ein einziger globaler Grenzwert scheitert

Ein einziger Grenzwert scheitert, weil jeder Endpunkt einem anderen Angriff ausgesetzt ist. Login-Seiten fangen Credential Stuffing ab: Der Verizon 2025 DBIR stellte fest, dass es im Median 19 % aller Authentifizierungsversuche pro Tag ausmachte, am schlimmsten Tag 44 %. Checkouts sind mit Kartentests konfrontiert und Registrierungen mit Fake-Konten. Und am 2. Dezember 2025 erzeugten Menschen laut dem Cloudflare Radar 2025 Year in Review nur 47 % der HTML-Anfragen.

Ausgereifte Systeme handeln bereits in Bändern. Der Bot-Score von Cloudflare reicht von 1 bis 99, und Kunden schreiben darauf Regeln zum Sperren, Herausfordern oder Zulassen (Cloudflare-Bot-Scores). OWASP sagt, IP-Sperren sollten „wegen der leichten Umgehbarkeit nicht als einzige oder primäre Abwehr eingesetzt werden“ (OWASP Credential Stuffing Cheat Sheet). Dieselbe Seite zitiert Microsofts Analyse, wonach MFA 99,9 % der Kontokompromittierungen verhindert hätte. Das macht das Step-up-Band beim Login zu einer günstigen Versicherung. NIST SP 800-63B sagt, eine unerwartete Geolokalisierung oder ein unerwarteter IP-Adressblock „könnte den Einsatz zusätzlicher risikobasierter Kontrollen auslösen“ und sei „kein Ersatz für einen Authentifizierungsfaktor“ (NIST SP 800-63B).

GeoIPHub bildet seinen erklärbaren Risikoscore von 0 bis 100 aus 36 gewichteten Gründen und nennt jeden, der ausgelöst hat, in scoring.detection_methods. Manche senken den Score: Ein Grund für einen Privatkunden-ISP zieht 17 Punkte ab (minus 20 bei einer Konfidenz von 0,85) und ein verifizierter Crawler 28,5 (minus 30 bei 0,95).

Ein niedriger Grenzwert bestraft geteilte und private Adressen

Eine Sperrgrenze, die „zur Sicherheit“ niedrig angesetzt wird, weist Kunden ab, die ihre Adresse aus ganz gewöhnlichen Gründen teilen oder verbergen:

• VPN-Nutzer. Im VPN-Report 2026 von Security.org, einer Umfrage unter 1.008 Erwachsenen in den USA im August 2026, gaben 42 % an, ein VPN privat oder beruflich zu nutzen. Allgemeine Privatsphäre (56 %) und allgemeine Sicherheit (51 %) waren die wichtigsten Gründe.
• Carrier-Grade NAT. RFC 6598 reserviert 100.64.0.0/10 für CGNAT, und Cloudflare merkt an, dass dahinter „Hunderte oder sogar Tausende von Clients scheinbar von einer einzigen IP-Adresse stammen können“. Cloudflare stellte außerdem fest, dass CGNAT-IPs dreimal häufiger per Rate-Limit gedrosselt werden als andere IPs, obwohl die mediane Bot-Rate nahezu identisch ist: 4,8 % gegenüber 4,7 % (Cloudflare zu CGNAT).
• iCloud Private Relay. Cloudflare, das einen Relay-Hop betreibt, sagt, Websites, die IP-Adressen zur Betrugsprävention nutzen, „können“ Private-Relay-Verbindungen „vertrauen“, weil Apple Gerät und Konto validiert (Cloudflare zu Private Relay).

GeoIPHub liefert detection.is_mobile, detection.is_relay und threat.is_cgnat und wendet die CGNAT-Deckelung von 50 und die Relay-Deckelung von 60 an, bevor es den Score zurückgibt.

Bewerten Sie die richtige IP, sonst ist jeder Schwellenwert bedeutungslos

Wenn Sie einen gefälschten X-Forwarded-For-Wert bewerten, sind Ihre fein justierten Schwellenwerte ausgehebelt, bevor sie überhaupt greifen. RFC 7239 warnt, dass man sich nicht darauf verlassen kann, dass der Forwarded-Header „korrekt ist“, weil jeder Knoten auf dem Weg, einschließlich des Clients, ihn verändern kann (RFC 7239). Die Regel von MDN lautet, dass jede sicherheitsrelevante Verwendung von X-Forwarded-For „nur IP-Adressen verwenden darf, die von einem vertrauenswürdigen Proxy hinzugefügt wurden“, ermittelt, indem man vom äußersten rechten Eintrag um die Anzahl der eigenen Proxys zurückzählt (MDN: X-Forwarded-For). Wir bewerten jede IP, die Sie senden, leiten Sie sie also zuerst aus Ihrer vertrauenswürdigen Proxy-Kette ab.

Justieren Sie die Schwellenwerte anhand Ihrer eigenen Ergebnisse

Beginnen Sie mit der Tabelle und verschieben Sie dann jede Grenze auf Grundlage von Belegen. Protokollieren Sie bei jeder Entscheidung den Score, recommended_action, detection_methods und das Datum, und vergleichen Sie sie nach einigen Wochen mit bestätigtem Betrug und Chargebacks. Wenn Ihre Checkout-Grenze von 66 bei 55 bis 65 Chargebacks durchlässt, senken Sie sie, aber nicht auf 60 oder darunter, solange Sie Nutzer von Private Relay bedienen. Wenn die Registrierungsverifizierung bei 51 bis 70 selten ein schlechtes Konto erwischt, heben Sie die Grenze an.

Der kostenlose Tarif umfasst 1.500 Abfragen pro Tag mit allen Feldern. Um eine einzelne Adresse von Hand zu prüfen, zeigt der IP-Fraud-Score-Checker denselben Score und dieselben Gründe ohne Code.

Für das breitere Spektrum an Signalen lesen Sie unsere Leitfäden zu anonymisierten Traffic erkennen, ohne echte Kunden zu sperren, Betrug über Residential- vs. Rechenzentrums-Proxys, Kontoübernahmen und Credential Stuffing stoppen, Promo- und Gutscheinmissbrauch beim Einlösen erkennen und wo IP-Signale in einem Stack zur Zahlungsbetrugserkennung sitzen.

Häufig gestellte Fragen

Ab welchem IP-Fraud-Score sollte man sperren?

Es gibt keinen einzigen universellen Grenzwert. Die Standardbänder von GeoIPHub sperren ab 76. Unsere Ausgangsschwellenwerte behalten das für den Login bei, senken den Wert für die Registrierung auf 71 und für den Checkout auf 66, denn eine betrügerische Card-not-present-Bestellung kostet weit mehr als eine erneute Passwortabfrage. Die Skalen anderer Anbieter unterscheiden sich, lesen Sie jeden Grenzwert also anhand der Bänder seines eigenen Anbieters.

Was bedeutet ein IP-Fraud-Score von 75?

Auf der Skala von 0 bis 100 von GeoIPHub ist 75 das obere Ende des step_up-Bands. Block beginnt bei 76. Fordern Sie die Anfrage heraus, statt sie stillschweigend zuzulassen, und lesen Sie scoring.detection_methods, denn eine 75 aus VPN-Signalen und eine aus Blocklisten-Historie verlangen unterschiedliche Reaktionen. Ein echter Tor-Exit-Node liegt gar nicht bei 75: 185.220.101.1 erhielt in unserer Abfrage vom 22. Oktober 2026 den Score 100, block.

Sollte ich VPN- und Proxy-Nutzer automatisch sperren?

Nein. In der Umfrage von Security.org unter 1.008 Erwachsenen in den USA im August 2026 gaben 42 % an, ein VPN privat oder beruflich zu nutzen, und Privatsphäre und Sicherheit waren die wichtigsten Gründe. Behandeln Sie ein VPN-Flag als Grund für eine zusätzliche Authentifizierung, nicht für eine automatische Ablehnung, und behalten Sie harte Sperren für Tor-Exit-Nodes und Adressen mit Spam- oder Blocklisten-Historie vor.

Kann ein Nutzer von iCloud Private Relay oder CGNAT allein aufgrund des Scores gesperrt werden?

Mit den Standardwerten von GeoIPHub nicht. Private-Relay-Adressen sind bei 60 gedeckelt und Carrier-Grade-NAT-Adressen bei 50, beides unterhalb der Standard-Sperrgrenze von 76. Halten Sie jeden Sperrschwellenwert über 60, dann kann eine geteilte Adresse allein aufgrund des Scores immer nur herausgefordert, nie abgelehnt werden.

Warum liegt der Sperrschwellenwert am Checkout niedriger als beim Login?

Ein fälschliches Zulassen am Checkout verschickt Waren auf eine gestohlene Karte und kommt als Chargeback zurück, während ein fälschliches Zulassen beim Login immer noch das Passwort und einen eventuellen zweiten Faktor überwinden muss. Deshalb sperrt der Checkout ab 66 und der Login erst ab 76.