Fehlalarme bei der VPN-Erkennung reduzieren: Praxisleitfaden
Fehlalarme bei der VPN-Erkennung entstehen, wenn eine IP-Adresse als VPN, Proxy oder Anonymisierer markiert wird, obwohl die Person dahinter ein gewöhnlicher Nutzer ist. Die häufigsten Ursachen sind geteilte Adressen, in der Cloud gehostete Egress-Punkte und veraltete Listendaten. Sie zu verringern ist vor allem eine Frage des Verständnisses, was ein Flag tatsächlich bedeutet, und der Entscheidung, was Ihre Anwendung damit tut.
Warum legitimer Traffic markiert wird
VPN-Erkennung ist Schlussfolgerung, keine Beobachtung. Ein Dienst sieht nur eine Quelladresse und muss aus ihr erraten, zu welcher Art von Netz sie gehört. Zwei grobe Verfahren sind im Spiel: den Abgleich der Adresse mit veröffentlichten Listen bekannter VPN- und Tor-Exit-Knoten und den Blick darauf, wer das Netz betreibt, in dem die Adresse liegt. Beide können auf vorhersehbare Weise falsch liegen.
Die erste Fehlerquelle ist das Teilen von Adressen. Carrier-Grade NAT erlaubt es einem ISP, Tausende Teilnehmer hinter einem kleinen Pool öffentlicher Adressen zu platzieren, und viele Unternehmen, Universitäten und Hotels tun dasselbe mit gewöhnlichem NAT. Von außen erzeugt eine Adresse ein großes Volumen nicht zusammenhängender Sitzungen vieler Menschen, genau das, wonach ein kommerzieller VPN-Exit aussieht, wenn man nur Request-Logs hat. Verhaltensheuristiken, die bei Volumen oder vielen verschiedenen Konten pro Adresse auslösen, schlagen daher bei völlig normalen Netzen fehl.
Die zweite Quelle ist Hosting. Unternehmensnutzer erreichen das Internet häufig über ein Secure Web Gateway, einen Cloud-Proxy oder einen Zero-Trust-Dienst, dessen Egress-Adressen in einem Datacenter-Netz liegen. Remote-Mitarbeiter in einem Firmen-VPN, ein legitimes und verbreitetes Arrangement, scheinen aus diesem Rechenzentrum zu kommen. Eine Regel, die jede Datacenter-Adresse als verdächtig behandelt, trifft diese Menschen zusammen mit den Missbrauchern. Die dritte Quelle ist die Zeit: Ein VPN-Anbieter gibt eine Adresse auf, ein anderer Mieter erbt sie, und eine nicht aktualisierte Liste meldet weiterhin den alten Status.
Lesen Sie das Netz, nicht nur das Flag
Ein Boolean ist der am wenigsten aussagekräftige Teil einer Abfrage. Die IP-Abfrage von ipto liefert is_vpn, is_tor, is_abuser, is_datacenter sowie die Felder bogon und bogon_type, zusammen mit der ASN und der Organisation, die die Adresse betreiben. Diese Felder sind dazu gedacht, gemeinsam gelesen zu werden. Eine Adresse mit is_datacenter true und is_vpn false gehört zu einem Hosting-Netz, passte aber zu keiner bekannten VPN-Quelle; das ist eine andere Situation als ein Treffer auf einer veröffentlichten Exit-Liste, und Ihre Richtlinie kann beide unterschiedlich behandeln.
Der VPN-, Tor- und Proxy-Checker zeigt dieselben Belege für eine einzelne Adresse, einschließlich des Netzes und der Quelle, die den Treffer erzeugt hat, was nützlich ist, wenn Sie einer konkreten Beschwerde eines Nutzers nachgehen, der sagt, er sei zu Unrecht blockiert worden. Für die Inhaberseite verrät Ihnen eine ASN-Abfrage, ob der Betreiber ein Endkunden-ISP, ein Mobilfunkanbieter, eine Universität oder ein Cloud-Anbieter ist. Löst sich Ihre markierte Adresse zu einem Endkunden-ISP auf, verdient ein VPN-Urteil mehr Skepsis als dasselbe Urteil bei einem Hosting-Anbieter.
Zum Hintergrund, wie Listen- und ASN-Signale kombiniert werden, geht der Beitrag So funktioniert VPN-Erkennung die Mechanik durch.
Richtlinien entwerfen, die Fehler verkraften
Die größte Verringerung von Fehlalarmen ergibt sich meist daraus, was ein positives Ergebnis auslöst, nicht aus dem Feintuning des Detektors. Ein VPN zu nutzen ist legal und alltäglich; viele nutzen eines im öffentlichen WLAN oder für die Arbeit. Hartes Blockieren allein wegen eines VPN-Flags trifft immer einige legitime Nutzer, reservieren Sie das Blockieren also für Situationen mit konkretem Risiko, etwa eine Zahlung von einem neuen Konto, und nutzen Sie anderswo mildere Reaktionen.
- Stufen Sie hoch, statt zu blockieren. Verlangen Sie einen zusätzlichen Verifizierungsschritt, fügen Sie ein CAPTCHA hinzu oder verzögern Sie eine Aktion mit hohem Wert, statt die Anfrage glatt abzulehnen.
- Kombinieren Sie unabhängige Signale. Ein VPN-Flag plus eine Wegwerf-E-Mail-Domain plus eine nicht passende Telefonregion bedeutet mehr als jedes einzelne. Der Fraud-Score-Checker kombiniert dafür IP-, E-Mail-, Telefon- und User-Agent-Signale zu einem einzigen Wert von 0 bis 100.
- Setzen Sie Bekanntes auf eine Allowlist. Wird Ihr eigenes Büro, ein Partner oder das bekannte Gateway eines Kunden markiert, erfassen Sie den Bereich und nehmen Sie ihn aus. Prüfen Sie die Liste regelmäßig, weil Adressen neu zugewiesen werden.
- Protokollieren Sie den Grund. Speichern Sie, welches Feld die Entscheidung ausgelöst hat, damit der Support sie erklären kann und Sie messen können, wie oft ein Flag überstimmt wurde.
- Prüfen Sie nach Zeitplan neu. Die Threat Feeds von ipto werden alle 6 Stunden aktualisiert und die IP- und ASN-Datensätze täglich, ein zwischengespeichertes Urteil, das älter ist, kann also bereits überholt sein.
Kennen Sie die Grenzen jedes Detektors
Keine Liste ist vollständig, ein negatives Ergebnis bedeutet daher „nicht bekannt“, nie „definitiv kein VPN“. ipto erkennt keine Residential Proxys, die Traffic über gewöhnliche Heimanschlüsse leiten und konstruktionsbedingt schwer von echten Nutzern zu trennen sind. Die Messung Ihrer eigenen Fehlalarmquote ist deshalb wichtig: Ziehen Sie eine Stichprobe markierter Sitzungen, prüfen Sie, wie viele legitime Kunden waren, und passen Sie die Aktion an, die Sie mit jedem Signal verknüpfen. Die Seite Threat Feeds zeigt die VPN-, Tor- und Hochrisikolisten selbst, was hilft, wenn Sie bestätigen wollen, ob eine Adresse wirklich auf einer veröffentlichten Liste steht oder aus einem anderen Grund markiert wurde.
All das können Sie ohne Anmeldung ausprobieren: Der kostenlose Tarif erlaubt 1.000 Anfragen pro Tag, und die API-Dokumentation listet den Lookup-Endpunkt und die Antwortfelder auf.