Grenzen der VPN-Erkennung: Was ein Netzwerk-Flag aussagen kann

Wie listenbasierte Erkennung funktioniert

Watch-IP prüft eine verbindende IPv4- oder IPv6-Adresse gegen separat gepflegte Listen für Tor-Exit-Knoten, kommerzielle VPN-Anbieter, Rechenzentrums-/Hosting-Netzwerke, bekannte Bedrohungsbereiche oder ASNs sowie staatlich sanktionierte Netzwerkbetreiber. Eine Übereinstimmung setzt das entsprechende Feld (isTor, isVpn, isDatacenter, isThreat, isSanctionedNetwork) auf true. Das funktioniert nur für Netzwerke, die auf einer von Watch-IP geladenen Liste erscheinen — ein VPN oder ein Proxy-Dienst, der auf keiner Liste steht, kann so nicht erkannt werden, wie gut er technisch auch funktioniert.

False, ausgelassen und true bedeuten unterschiedliche Dinge

Ein ausgelassenes security-Objekt bedeutet, dass Ihr Tarif diese Daten überhaupt nicht enthält — nicht, dass die Verbindung geprüft und als sauber befunden wurde. Ein false-Wert bei einem enthaltenen Feld bedeutet keine Übereinstimmung in den aktuell geladenen Listen, was eine schwächere Aussage ist als „sicher“: Die Listenabdeckung ist grundsätzlich unvollständig, und ein brandneuer oder kleiner VPN-Anbieter ist möglicherweise noch nicht gelistet. Stellen Sie ein nicht ausgewertetes oder falsches Ergebnis niemals als „Sauber“, „Sicher“ oder „Verifiziert“ dar — diese Begriffe beanspruchen mehr Gewissheit, als ein Listenabgleich stützen kann.

IPv6 hat eine echte Abdeckungslücke

IPv4-Verbindungen werden gegen alle fünf Kategorien geprüft. IPv6-Verbindungen werden gegen alles außer Tor geprüft — es gibt derzeit keine kostenlose IPv6-Tor-Exit-Listenquelle, sodass isTor für eine IPv6-Verbindung immer false ist, unabhängig davon, ob es sich tatsächlich um einen Tor-Exit handelt. Wenn Ihre Prüflogik nach isTor verzweigt, erhält eine IPv6-Besucherin oder ein IPv6-Besucher eine strukturell andere (schwächere) Prüfung als eine IPv4-Besucherin oder ein IPv4-Besucher, nicht nur ein anderes Ergebnis.

Was diese Listen nicht abdecken

Residente Proxy-Dienste — die Traffic über echte private IP-Adressen leiten statt über ein Rechenzentrum — sind ein deutlich schwierigeres Erkennungsproblem als kommerzielle VPNs oder Tor, und aktuelle Listen decken sie nicht ab. Die Endpoints zur Abfrage beliebiger IPs (GET/POST /v1/lookup) liefern diesen Block überhaupt nicht; es ist eine Fähigkeit von GET /v1/geo, gebunden an den verbindenden Browser, nicht etwas, das Sie für eine gespeicherte oder angegebene IP anfordern können.

Eine vorsichtige Prüfrichtlinie

Behandeln Sie isVpn oder isDatacenter als eine Eingabe für eine manuelle Prüfwarteschlange neben Kontohistorie und anderen Signalen — nicht als alleinige Grundlage für eine automatische Sperre. Legitime Nutzerinnen und Nutzer verwenden VPNs und gemeinsam genutzte Netzwerke aus gewöhnlichen Gründen (Datenschutzpräferenz, Firmennetzwerk, Reisen), sodass eine Richtlinie, die allein aufgrund eines einzelnen Flags rundweg sperrt, echte Kundinnen und Kunden ablehnen wird. Ein Netzwerk-Flag mit einem zweiten Signal desselben Ereignisses zu kombinieren, etwa einer Wegwerf-E-Mail-Übereinstimmung, ist eine besser vertretbare Grundlage für die Weiterleitung zur Prüfung als jedes der beiden Signale für sich.

Was dieser Artikel nicht behauptet

Dies beschreibt die eigene listenbasierte Implementierung von Watch-IP, keine allgemeine Aussage darüber, was VPN-Erkennung branchenweit leisten kann. Watch-IP erkennt keine residenten Proxys, verifiziert keine Identität, und seine Listen werden nach einem Zeitplan aktualisiert (im eigenen Speicher abgelegt), nicht fortlaufend — eine langsame oder fehlgeschlagene Aktualisierung führt zu veralteten oder leeren Daten, was sich wie „keine Übereinstimmung“ liest.

Quellen

• Tor Project — Bulk-Exit-Liste