So prüfen Sie Schritt für Schritt, ob eine IP-Adresse zu einem Proxy gehört

Das Problem der Proxy-Erkennung verstehen

Zu erkennen, ob eine eingehende Verbindung über einen Proxy läuft, gehört im Alltag vieler Security- und Infrastrukturteams dazu: etwa bei Abuse-Analysen, beim Absichern von Login-Endpunkten oder wenn auffälliger Netzwerkverkehr untersucht werden muss. Proxies treten dabei in sehr unterschiedlichen Formen auf – als offene HTTP/SOCKS-Forwarder, kommerzielle VPN-Server, Scraping-Relays in Rechenzentren, Tor-Exit-Nodes oder als Residential-Proxy-Netzwerke.

Weil jede dieser Architekturen anders mit IP-Routing und Transportprotokollen zusammenspielt, liefert kein einzelner manueller Befehl ein endgültiges Ja oder Nein. Zuverlässige Erkennung entsteht erst, wenn mehrere voneinander unabhängige Netzwerksignale gemeinsam bewertet werden. Dieser Leitfaden zeigt, wie Sie eine IP-Adresse manuell untersuchen – und wie sich Proxy-Erkennung im großen Maßstab umsetzen lässt.

Step 1: Reverse DNS (rDNS) und PTR-Records prüfen

Reverse-DNS-Lookups ordnen einer IP-Adresse den konfigurierten Domainnamen zu. Viele Hosting-Anbieter, Breitband-ISPs und Mobilfunkprovider nutzen in ihren PTR-Records wiedererkennbare Namensschemata, die Hinweise auf den operativen Kontext einer IP geben.

Den PTR-Record können Sie zum Beispiel mit dig abfragen:

bash dig -x 198.51.100.42 +short

Was dieses Signal verrät

• Privater Anschluss oder Breitband-ISP: Hostnamen mit Bestandteilen wie pool, cable, fiber, dhcp oder dynamischen Oktett-Formaten (z. B. 198-51-100-42.dyn.exampleisp.net) deuten meist auf normale Endkundenanschlüsse hin.
• Rechenzentrum oder VPS: Muster wie vps, server, compute, hosted-by, linode, ovh oder rohe Cloud-Hostnamen (z. B. ec2-198-51-100-42.compute-1.amazonaws.com) sprechen für Infrastruktur in einem Rechenzentrum. Reguläre Nutzer rufen Websites nur selten direkt von einem VPS aus auf – es sei denn, der Traffic läuft über ein selbst betriebenes VPN oder einen Proxy.
• Fehlender oder generischer PTR: Viele Proxy-Betreiber nutzen günstige VPS-Instanzen und konfigurieren kein Forward-confirmed Reverse DNS (FCrDNS).

Grenzen

Angreifer, die Residential-Proxy-Netzwerke verwenden, leiten ihren Traffic über kompromittierte oder angemietete Verbrauchergeräte. Der PTR-Record zeigt dann einen ganz normalen Privatkunden-ISP – rDNS-Prüfungen laufen in solchen Fällen ins Leere.

Step 2: Autonomous System Number (ASN) und Routing-Daten abfragen

Jede IP-Adresse gehört zu einem Autonomous System (AS). Die AS-Registrierung zeigt, welche Organisation den IP-Block hält und ihn per BGP ankündigt. Klassische Privatnutzer erhalten ihre IP-Adressen über Telekommunikations-ASNs für Endkunden, während kommerzielle Proxies und VPN-Server fast immer in Hosting-, Cloud- oder Colocation-ASNs liegen.

ASN-Details lassen sich etwa über die DNS- oder WHOIS-Dienste von Team Cymru abfragen:

bash whois -h whois.cymru.com " -v 198.51.100.42"

Alternativ können Sie direkt die regionalen Internet Registries (ARIN, RIPE, APNIC) befragen:

bash whois 198.51.100.42 | grep -iE "origin|org-name|descr|nettype"

ASN-Signale bewerten

• Gehört die IP zu DigitalOcean, Hetzner, OVH, AWS oder M247 und gibt sich der Nutzer als interaktiver Webbesucher aus, läuft der Zugriff sehr wahrscheinlich über eine Zwischenstation – also ein VPN, einen kommerziellen Forwarder oder ein automatisiertes Skript.
• Prüfen Sie außerdem NetType und die Art der Zuweisung. Reallozierte oder portable IP-Blöcke, die mit Proxy-Aggregatoren verbunden sind, verraten häufig Unternehmensnamen, die nicht zum eigentlichen Telekommunikationsanbieter passen.

Grenzen

ASN-Prüfungen erkennen keine Residential Proxies, wenn der zugrunde liegende Carrier weiterhin AT&T, Comcast oder ein internationaler Mobilfunkanbieter ist.

Step 3: Bekannte Tor-Exit-Nodes und Threat-Listen prüfen

Das Tor-Netzwerk veröffentlicht eine autoritative, dynamische Liste aktiver Exit-Node-IP-Adressen. Da Tor-Exit-Relays öffentlich sind, liefert ein Abgleich mit dieser Liste ein sehr belastbares Signal.

Die aktuelle Exit-Liste können Sie direkt abrufen:

bash curl -s https://check.torproject.org/torbulkexitlist | grep -x "198.51.100.42"

Auch eine DNS-basierte Prüfung gegen die DNSBL des Tor Project ist möglich:

bash # Ziel-IP-Oktette umdrehen und die dnsel-Zone abfragen dig 42.100.51.198.ip-port.exitlist.torproject.org A +short

Wenn diese Abfrage 127.0.0.2 zurückliefert, ist die IP ein aktiver Tor-Exit-Node.

Grenzen

Tor ist nur eine Unterkategorie von Anonymisierungswerkzeugen. Öffentliche Blocklisten für allgemeine Open Proxies sind notorisch flüchtig: Sie erfassen offene Proxies, die oft schon nach wenigen Minuten wieder offline sind. Werden IP-Bereiche später neu vergeben, entstehen zudem schnell False Positives.

Step 4: Passive und aktive Port-Analyse

Proxies lauschen häufig auf Standard- oder Nebenports für Proxy-Software. Einen invasiven Portscan gegen jede einzelne Client-Verbindung durchzuführen, wäre allerdings aufdringlich, langsam und rechtlich oft heikel. Bei der manuellen Triage im Rahmen einer konkreten Incident-Analyse kann die Prüfung gängiger Ports dennoch sinnvoll sein.

bash nc -zv -w 2 198.51.100.42 8080 3128 1080 8888 80

• Port 1080: Standard-Port für SOCKS-Proxies.
• Port 3128: Standard-Port für den HTTP-Proxy Squid.
• Ports 8080, 8888: Häufig genutzte Alternativen für HTTP-Forwarder.

Wenn eine Verbindung zu diesen Ports einen HTTP-Header wie Proxy-Agent, Via: 1.1 squid zurückgibt oder einen unerwarteten SOCKS-Handshake abbricht, spricht das dafür, dass der Host als Proxy-Server arbeitet.

Grenzen

Professionelle kommerzielle VPNs, Reverse Proxies und Residential-Proxy-Daemons lauschen in der Regel nicht öffentlich auf clientseitigen Interfaces. Stattdessen bauen sie ausgehende Reverse Tunnels zu einem Orchestrierungsserver auf – nach außen sind dann keine offenen eingehenden Ports sichtbar.

Manuelle Prüfungen vs. Realität

| Technique | Primary Signal | Major Blind Spot | | :--- | :--- | :--- | | Reverse DNS | Hostnamen aus Rechenzentren, fehlender PTR | Residential Proxies tarnen sich als Endkunden-ISPs | | ASN Lookup | Klassifizierung als Hosting- oder Cloud-Anbieter | Erkennt keinen weitergeleiteten Traffic aus privaten Subnetzen | | Tor Exit Lists | Deterministische Liste aktiver Tor-Exits | Blind gegenüber VPNs, SOCKS und kommerziellen Proxies | | Port Probing | Offen erreichbare Proxy-Daemons (Squid, SOCKS) | Moderne Tunnel nutzen ausgehende Reverse-Verbindungen |

Step 5: Automatisierte IP Intelligence zur Laufzeit

Manuelle Prüfungen eignen sich gut für die nachträgliche Analyse eines Vorfalls. Interaktive Anwendungen brauchen jedoch Prüfungen im Subsekundenbereich – etwa beim Login, im Checkout oder während der Registrierung. Die größte Herausforderung auf dieser Ebene ist die Erkennung von Residential Proxies: Also die Frage, ob eine IP-Adresse, die eigentlich zu einem legitimen Verbraucher-ISP gehört, für einen Backconnect-Proxy-Tunnel genutzt wird.

Dafür müssen BGP-Ankündigungen, Telemetriedaten aus aktiven Probes, Honeypots und Verhaltensmuster von Verbindungen in einem einzigen Lookup zusammengeführt werden. Ein IP-Intelligence-Dienst wie guarda.net bündelt diese Signale in einer einheitlichen JSON-Antwort:

bash curl -s "https://api.guarda.net/v1/ip/198.51.100.42" \ -H "Authorization: Bearer YOUR_API_KEY"

Eine typische Antwort liefert einzelne boolesche Klassifizierungen zusammen mit einem zusammengesetzten Risikowert:

{ "ip": "198.51.100.42", "is_proxy": true, "is_vpn": false, "is_tor": false, "is_datacenter": true, "asn": { "number": 16276, "org": "OVH SAS" }, "risk_score": 88 }

Mit strukturierten Feldern kann Ihre Firewall oder Anwendung sehr präzise Richtlinien durchsetzen: etwa Registrierungen aus Rechenzentrums-IP-Adressen ablehnen, Unternehmens-VPNs aber zulassen – oder eine stärkere Authentifizierung nur dann anfordern, wenn is_proxy wahr ist oder der gesamte risk_score einen definierten Schwellenwert überschreitet.

Wenn Sie eine IP sofort prüfen möchten, ohne eigene Skripte einzurichten, können Sie direkt auf der Startseite von guarda.net einen kostenlosen IP-Check ausführen. Dort wurden bereits mehr als 594,400 Lookups verarbeitet.