VPNs beim Login erkennen: Sicherheit und Nutzererlebnis richtig austarieren

Security-Teams bewegen sich beim Login fast immer in einem Spannungsfeld: Der Schutz soll robust sein, der Zugang für legitime Nutzer aber möglichst reibungslos bleiben. VPNs, Proxys und TOR-Exit-Nodes zu erkennen, gehört in vielen Unternehmen inzwischen zum Standard – etwa aus Gründen der Compliance, zur Betrugsprävention oder zur Durchsetzung geografischer Beschränkungen. Zu harte Regeln führen jedoch schnell zu Frust, abgebrochenen Logins und unnötigen Support-Tickets.

Dieser Beitrag zeigt praxisnahe technische Ansätze, mit denen sich solche Dienste beim Login identifizieren lassen – mit Fokus auf belastbare Signale, weniger False Positives und ein besseres Nutzererlebnis.

Why Detect VPNs at Login?

Bevor es um die Erkennung selbst geht, lohnt sich der Blick auf das Warum. Typische Gründe sind:

• Betrugsprävention: Angreifer nutzen häufig Proxys, VPNs und TOR, um ihre Herkunft zu verschleiern, Rate Limits zu umgehen oder Schutzmechanismen gegen Account Takeover auszuhebeln. Solche Verbindungen sind daher ein starkes Signal für auffälliges Verhalten.
• Compliance & Geo-Restrictions: Manche Dienste müssen Lizenzvorgaben oder regulatorische Anforderungen nach Region einhalten. Dann reicht es nicht, dass ein Nutzer eine bestimmte Region angibt – der Zugriff muss plausibel von dort erfolgen.
• Security Posture: VPN-Traffic ist nicht automatisch bösartig. Bestimmte VPN-Typen, etwa kommerzielle Anbieter oder sogenanntes Bulletproof Hosting, können aber auf ein erhöhtes Risiko hinweisen – besonders, wenn weitere verdächtige Signale dazukommen.

Core Principles for Login-Time Detection

Um echte Nutzer nicht unnötig zu stören, sollte die Erkennung mehrstufig aufgebaut sein – nicht als grober Ein/Aus-Schalter. Bewährt haben sich diese Prinzipien:

• Passive Erkennung: IP-Intelligence im Hintergrund abfragen, ohne dass der Nutzer aktiv etwas tun muss.
• Kontextuelle Bewertung: Das IP-Risiko gemeinsam mit anderen Login-Signalen betrachten, etwa Geräte-ID, bisherigem Verhalten oder der Gültigkeit von Nutzername und Passwort.
• Abgestufte Reaktion: Statt sofort zu blockieren, können bei Grenzfällen Step-up-Authentifizierung per MFA, CAPTCHA-Prüfungen oder zusätzliche Verhaltensanalysen sinnvoller sein.
• High-Confidence-Signale priorisieren: Auf eindeutige Hinweise für Missbrauch sollte konsequent reagiert werden. Bei unscharfen Flags ist Zurückhaltung oft die bessere Entscheidung.

IP Intelligence Signals for VPN/Proxy Detection

Moderne IP-Intelligence-APIs führen große Datenmengen zusammen, um IP-Adressen einzuordnen. Die folgenden Signale sind besonders relevant:

1. Hosting Provider / Datacenter IP

• Was es ist: Eine IP-Adresse, die zu einem Cloud-Anbieter wie AWS, Azure oder Google Cloud, einem Dedicated-Server-Hoster oder einem Colocation-Rechenzentrum gehört – und nicht zu einem privaten oder mobilen Internetanbieter.
• Wie es hilft: Die meisten legitimen Nutzer greifen über private Breitbandanschlüsse oder Mobilfunknetze zu. Login-Versuche aus Rechenzentrumsnetzen sind daher vor allem bei Endkundendiensten häufig verdächtig. Kostenlose VPNs, kommerzielle VPNs und Proxys laufen oft genau über solche IP-Bereiche.
• Grenzen: Auch legitime Business-Nutzer verbinden sich über Unternehmens-VPNs, die in Rechenzentren betrieben werden. Bei manchen Diensten, etwa API-Clients oder bestimmten Enterprise-Tools, sind Datacenter-IPs sogar erwartbar. Kontext ist hier entscheidend.

2. TOR Exit Node

• Was es ist: Eine IP-Adresse, die als bekannter Exit Node des TOR-Anonymisierungsnetzwerks identifiziert wurde.
• Wie es hilft: TOR wird in erster Linie genutzt, um Anonymität herzustellen. Es gibt legitime Anwendungsfälle, gleichzeitig ist TOR aber auch ein verbreitetes Werkzeug für Umgehung und Verschleierung durch Angreifer. Ein TOR-Exit-Node ist daher ein recht belastbares Signal für Anonymisierung.
• Grenzen: Wer sämtlichen TOR-Traffic blockiert, trifft auch datenschutzbewusste Nutzer. Je nach Dienst und Bedrohungsmodell kann ein kompletter Block sinnvoll sein – oder lediglich ein deutlich erhöhter Risikoscore.

3. Commercial VPN / Proxy Service

• Was es ist: Eine IP-Adresse, die eindeutig einem bekannten kommerziellen VPN-Anbieter wie NordVPN, ExpressVPN oder ähnlichen Diensten zugeordnet ist – oder einem offenen beziehungsweise privaten Proxy-Netzwerk.
• Wie es hilft: Hier geht es um Dienste, die ausdrücklich darauf ausgelegt sind, Standort oder Identität zu verschleiern. Die direkte Zuordnung zu einem VPN- oder Proxy-Service ist deshalb ein starkes Signal.
• Grenzen: Diese Listen aktuell zu halten, ist anspruchsvoll, weil Anbieter ihre Infrastruktur laufend verändern. In der Praxis ist deshalb der Einsatz spezialisierter IP-Intelligence-Anbieter besonders wichtig.

4. rDNS Hostname and ASN Information

• Was es ist:

rDNS (reverse DNS) hostname: Der Domainname, der einer IP-Adresse zugeordnet ist und häufig Hinweise auf den Provider liefert, zum Beispiel `ec2-xx-xx-xx-xx.compute-1.amazonaws.com`. ASN (Autonomous System Number): Eine weltweit eindeutige Kennung für ein Netzwerk, etwa ASN 16509 für Amazon.com, Inc.

• Wie es hilft: Diese Netzwerkdetails bestätigen oft, um welche Art von IP-Adresse es sich handelt. Ein rDNS-Hostname, der klar auf einen Cloud-Provider oder VPN-Dienst verweist, kombiniert mit einem ASN außerhalb typischer Privatkunden-ISPs, stärkt andere Risikosignale.
• Grenzen: rDNS-Einträge können generisch sein oder ganz fehlen. Und ein ASN allein erzählt selten die ganze Geschichte – ohne zusätzlichen Kontext bleibt die Aussagekraft begrenzt.

5. IP Risk Score

• Was es ist: Ein numerischer Wert, häufig auf einer Skala von 0-100, der das Gesamtrisiko einer IP-Adresse beschreibt. Er wird aus mehreren Signalen abgeleitet und kann zusätzlich historische Missbrauchsdaten, Botnet-Zuordnungen oder Spam-Aktivität berücksichtigen.
• Wie es hilft: Der Score liefert eine konsolidierte Kennzahl. Statt jedes einzelne Flag separat zu verarbeiten, lassen sich Schwellenwerte definieren. Ein Score >70 könnte beispielsweise MFA auslösen, während ein Score >90 zu einer temporären Sperre führt.
• Grenzen: Die Bewertung eines Risikoscores muss zur eigenen Anwendung und Nutzerbasis passen. Was für einen Dienst bereits hochriskant ist, kann für einen anderen lediglich moderat sein.

Implementing Detection without Annoying Users

Ein pragmatisches Vorgehen sieht schrittweise so aus:

• Passive IP Lookup: Bei jedem Login-Versuch wird im Hintergrund eine IP-Intelligence-Abfrage durchgeführt. Diese sollte sehr schnell sein – idealerweise unter 100 ms –, damit der Nutzer keine Verzögerung bemerkt.
• Initial Triage (Low Friction):

Hohes Risiko, etwa TOR-Exit, bekannte bösartige IP oder sehr hoher Risk Score: Sofort MFA oder ein CAPTCHA anfordern. Ist MFA ohnehin Pflicht, sollte der Login zusätzlich geprüft werden. Mittleres Risiko, etwa generischer kommerzieller VPN, Datacenter-IP bei einem Consumer-Dienst oder moderater Risk Score: Das Ereignis für spätere Analysen protokollieren. Kommen weitere verdächtige Verhaltenssignale hinzu, etwa ein neues Gerät, ein ungewöhnlicher Standort oder mehrere fehlgeschlagene Login-Versuche, wird auf MFA oder CAPTCHA eskaliert. Niedriges Risiko, etwa privater ISP oder niedriger Risk Score:* Den Login ohne Unterbrechung fortsetzen.

• Adaptive Responses: Wenn ein Nutzer sich nach einem High-Risk-IP-Flag erfolgreich per MFA authentifiziert, ist das ein starkes positives Signal. Für diese Kombination aus Nutzer und Gerät können IP-Prüfungen für einen definierten Zeitraum etwas gelockert werden – solange keine neuen, klar negativen Signale auftreten.