Residential Proxies umgehen IP-Blocking: Was noch wirkt

Rund ein Viertel der Residential-Proxy-Exit-Nodes, die große Anbieter verkaufen, laufen auf Geräten, deren Besitzer nicht wissen, dass sie Teil irgendeiner Infrastruktur sind. Diese Schätzung stammt aus jahrelanger akademischer Forschung zu diesen Netzwerken, und sie erklärt einiges, etwa warum eine Sicherheitsfirma kürzlich Residential-Proxy-Exits im IP-Raum entdeckt hat, der dem Executive Office of the President zugewiesen ist. Als Forscher den Traffic bemerkten, von dem die Hälfte zwischen 17 und 24 Uhr Eastern anfiel, tat das Internet, was es eben tut: Es machte Witze. Doch hinter den Scherzen steckt eine echte Lehre für den Rest von uns. Residential Proxies sind der wirksamste Weg, IP-basierte Abwehr zu umgehen. Und wer im Threat Model „residentielle IP“ noch als Vertrauenssignal behandelt, ist eine Generation hinterher.

Ich habe vier Jahre lang die Erkennung für ein mittelgroßes SaaS-Unternehmen betreut, und der Wandel war in unseren Dashboards in Echtzeit sichtbar. Als Credential-Stuffing-Crews von Datacenter-Proxies auf Residential Exits umstiegen, fiel unsere IP-Blockliste von 80 % erkanntem Angriffs-Traffic auf fast nichts. Gleiche Angriffe, gleiche Tools, nur ein anderer letzter Hop. Dieser Artikel handelt davon, warum das passiert und was tatsächlich funktioniert, wenn IP-Reputation nicht mehr greift.

Wie Residential Proxies tatsächlich funktionieren

Ein Residential Proxy ist im Grunde nur ein Exit-Node auf einem Verbrauchergerät, etwa einem Smartphone, einem Smart-TV, einer Set-Top-Box oder einem Heimrouter. Der Kunde des Proxy-Netzwerks zahlt für Traffic, der über diese Geräte ausgeleitet wird, und die Aufgabe des Anbieters ist es, Millionen davon in jeder Region verfügbar zu haben. Das Angebot stammt aus drei Quellen, absteigend nach Seriosität.

1. Opt-in-SDKs. Kostenlose Apps wie VPNs, Wetter-Widgets, Mobilspiele oder Apps mit dem Versprechen „Verdiene Geld durch das Teilen deiner Bandbreite“ bündeln ein Proxy-SDK. Die Zustimmung steckt in AGB, die niemand liest, aber formal existiert sie. Dieses Modell führen die großen Anbieter gern an, wenn es um Ethik geht.
2. Kompromittierte Firmware und Malware. Botnetze verdienen seit Jahren durch den Weiterverkauf von Proxys Geld. Eine billige Android-Streaming-Box mit zweifelhafter Firmware ab Werk ist ein Proxy-Node, sobald sie sich verbindet. Der Besitzer glaubt, er habe einen Mediaplayer gekauft.
3. Reines Botnetz-Vermieten. Das untere Ende des Marktes tut nicht einmal so. Wenn ein Anbieter fünfzig Millionen rotierende IPs ohne dokumentierte Beschaffungsrichtlinie anbietet, kann man selbst rechnen.

Entscheidend ist, wie das aus Sicht der Verteidiger aussieht. Der Traffic kommt aus einem Residential-ASN von Comcast, BT oder der Deutschen Telekom. Die IP lokalisiert auf eine plausible Stadt. Das Reverse DNS liefert etwa pool-96-225-14-7.nycmny.fios.verizon.net. Jede Heuristik, die wir in den 2010ern gebaut haben, sagt: Das ist ein Mensch zu Hause. Ist es nicht. Es ist ein Relais für 3 Dollar pro Gigabyte, und der Mensch zu Hause weiß nichts davon.

Dieser letzte Punkt verdient Betonung, denn er betrifft dich auch dann, wenn du nie Proxys kaufst oder bekämpfst. Das SDK, das Bandbreite weiterleitet, ist Software unter fremder Fernsteuerung, die innerhalb deines Netzwerkperimeters läuft. Heute verkauft sie Bandbreite. Architektonisch hindert nichts den Betreiber, oder wen auch immer, der den Betreiber kompromittiert, daran, diese Nodes für Schlimmeres einzusetzen. Ein Proxy-SDK auf einem Gerät in einem sensiblen Netzwerk ist kein Bandbreitenproblem. Es ist ein Fußabdruck mit einer Abrechnungsabteilung.

Warum IP-basierte Abwehr tot ist

IP-Reputation hatte Sinn, solange Missbrauch aus Orten kam, die nach Missbrauch aussahen: Bulletproof-Hosting, gekaperte Datacenter-Bereiche, offene Proxys auf vergessenen VPS-Instanzen. Man konnte die schlechten Viertel aufzählen. Residential Proxies haben diese Ära beendet, indem sie den schlechten Traffic in die guten Viertel verlagert haben, ein kompromittiertes Wohnzimmer nach dem anderen.

Die Wirtschaftlichkeit macht es noch schlimmer. Datacenter-IP-Raum ist begrenzt und wird stark überwacht. Verbrennt man ein /24, steht es binnen eines Tages auf jeder Blockliste. Residential-Exit-Nodes sind praktisch unbegrenzt und heilen sich selbst. Ein einziger Credential-Stuffing-Lauf kann Zehntausende verschiedene Haushalts-IPs durchrotieren, jede mit zwei oder drei Anfragen, und löst dabei nie Rate-Limits pro IP aus. Dein WAF sieht zehntausend verschiedene „Nutzer“. Eine einzelne IP zu sperren bringt nichts, und den ganzen ASN zu sperren heißt, deine echten Kunden auszusperren.

Deshalb braucht auch „der Traffic kam aus dem Weißen Haus“ einen Vorbehalt, und die Skeptiker in jeder Diskussion dieser Geschichte haben recht, ihn anzusprechen. IP-Raum zu besitzen heißt nicht, dass jede Ankündigung davon einem physischen Ort entspricht. Große Organisationen kündigen Bereiche von vielen Standorten aus an, betreiben Gastnetze, Labore und Carrier-NAT-Overlays. Eine Exit-IP im Bereich einer Organisation sagt dir, auf wen der Raum registriert ist, nicht, an welchem Schreibtisch die Pakete entstanden sind. Wenn du diese Analyse für dein eigenes Netzwerk durchführst, und das solltest du, behandle die Zuordnung als Hypothese, die du gegen interne Flow-Logs prüfst, nicht als Schlussfolgerung.

Die Erkennungssignale, die noch funktionieren

IP-Reputation ist tot, aber der Traffic ist nicht unsichtbar. Proxy-Exits hinterlassen Fingerabdrücke. Keines dieser Signale reicht allein aus, denn jedes hat legitime Erklärungen. Zusammen sind sie aber erstaunlich wirksam. Das ist der Standardansatz moderner Detection Engineering: Nicht nach der rauchenden Waffe suchen, sondern aus schwachen Signalen einen Score aufbauen. Dieselbe Philosophie steckt in verhaltensbasiertem Fingerprinting obfuskierter Skripte. Du musst den Code nicht lesen, wenn du beschreiben kannst, wie er sich verhält.

ASN- und Verbindungsform-Analyse

Fang beim ASN an, hör aber nicht bei „ist es residentiell?“ auf. Die nützliche Frage ist, ob der ASN zum behaupteten Client passt. Eine Anfrage mit Desktop-Chrome-User-Agent aus einem Consumer-5G-Bereich eines Mobilfunkanbieters ist verdächtig. Ebenso Traffic aus einem ASN eines Verbraucher-ISP, der deine API mit datacenter-artiger Parallelität trifft. Einzelne Proxy-Nodes sind echte Haushalte, und echte Haushalte haben echte Grenzen: Consumer-Upload-Bandbreite, NAT-Tabellen, Carrier-Grade-NAT mit geteilten Adressen. Eine Exit-IP, die in einer Stunde vierzig verschiedene Proxy-Kunden bedient, erzeugt Verbindungsmuster, die kein Haushalt erzeugt.

TLS- und TCP-Fingerprints

Hier erwischst du die schlampigen Betreiber. Die meisten Proxy-Kunden leiten ihren Traffic über die Client-Software des Anbieters oder über Standard-HTTP-Bibliotheken wie Python requests, Gos net/http oder Node. Jede hat einen eigenen TLS-ClientHello: Reihenfolge der Cipher-Suites, Extension-Listen, unterstützte Gruppen. JA3- und JA4-Hashes erlauben dir, zu vergleichen, was der TLS-Handshake über den Client aussagt, mit dem, was der User-Agent behauptet. Ein „Chrome 126 auf Windows“, das einen Go-TLS-Fingerprint sendet, ist ein Bot im Kostüm. Manche ausgefeilten Proxy-Netzwerke leiten TLS vollständig vom Rechner des Kunden durch, was die Lüge bewahrt. Viele tun das aber nicht, und selbst die guten lecken auf TCP-Ebene. Ein angeblicher Windows-Client mit TTL und Fenstergröße, die auf Linux deuten, ist ein weiterer Punkt im Score.

Latenz- und Timing-Muster

Jeder Residential Proxy fügt einen Hop über Consumer-Hardware auf Consumer-Uplinks hinzu. Dieser Hop kostet etwas. Wenn dein Dienst außerdem die tatsächliche Latenz des Clients sieht, etwa über WebRTC, eine CDN-Edge-Messung oder die Timing-Verteilung der Anfragen innerhalb einer Session, kannst du die Netzwerk-RTT mit der behaupteten Geografie vergleichen. Ein „Nutzer in Denver“ mit 4 ms RTT zu deinem Rechenzentrum in Virginia ist nicht in Denver. Auch das Timing innerhalb von Sessions zählt: Menschliches Surfen hat Lesepausen, Mausbewegungen und unregelmäßigen Takt. Traffic, der über einen Proxy aus einem Automatisierungsskript kommt, hat dagegen eine metronomartige Gleichmäßigkeit mit konstanten Abständen zwischen Anfragen, ohne Leerlaufdrift und mit sofortigen Formularabsendungen. Selbst wenn Angreifer Jitter hinzufügen, stammt dieser aus einer Verteilung, die ein Mensch nie erzeugen würde.

Verhaltensheuristiken

Das stärkste Signal ist, was der Client tut, nicht was er ist. Echte Nutzer schweifen ab. Bots führen Pläne aus. Eine Session, die sich einloggt, direkt über eine URL zur Einstellungsseite springt, die kein UI-Pfad erreicht, die E-Mail-Adresse ändert und in neunzig Sekunden eine Auszahlung anfordert, ist kein Mensch, egal was ihre IP behauptet. Verfolge die Sequenzentropie: Durchlaufen Sessions deine App so, wie dein Frontend sie tatsächlich steuert, oder treffen sie Endpunkte in Reihenfolgen, die nur jemand wählt, der deine API-Doku gelesen hat? Die sitzungsübergreifende Aggregation ist hier das entscheidende Feature. Eine Residential-IP mit drei Anfragen wirkt harmlos. Dreihundert Residential-IPs mit je drei Anfragen, identischen TLS-Fingerprints, identischen Bildschirmauflösungen und derselben Endpunktsequenz sind eine Operation mit dreihundert Kostümen.

Threat Hunting nach Proxy-SDKs im eigenen Netzwerk

Das Inbound-Problem bekommt die Aufmerksamkeit, aber die Geschichte, die das ausgelöst hat, ist eigentlich eine Outbound-Geschichte: Ein Gerät in einem Netz, das es besser wissen sollte, leitete fremden Traffic weiter. Dieses Szenario kannst du tatsächlich beeinflussen, weil du den Perimeter kontrollierst. Geh davon aus, dass irgendein Nutzer irgendwann eine kompromittierte Streaming-Box anschließt oder auf einem Diensttelefon einen „kostenlosen VPN“ installiert. Deine Aufgabe ist es, dieses Ereignis laut zu machen.

Die Erkennungslogik ist unkompliziert, weil Proxy-SDKs eine charakteristische Haltung haben. Ein Node existiert, um Anweisungen zu empfangen und Traffic weiterzuleiten, was bedeutet:

• Dauerhafte Steuerkanal-Verbindungen. Langlebige TLS-Sessions zu unbekannten Domains oder IPs, oft mit winzigen periodischen Payloads. Baseline deine Egress-Ziele. Ein Client-Gerät mit einer sechsstündigen Verbindung zu einem Host in einem Land, in dem keiner deiner Software-Anbieter tätig ist, verdient einen genaueren Blick.
• Hoher Connection-Fan-out von einem Client-Gerät. Ein Arbeitsplatzrechner, der pro Stunde Verbindungen zu Hunderten verschiedener externer IPs aufbaut, verhält sich wie Infrastruktur, nicht wie ein Mensch. Laptops surfen, Relais leiten weiter.
• Eingehend initiierte Flows zu Client-Subnetzen. Viele Proxy-Frameworks öffnen eingehende Tunnel oder nutzen STUN-artiges NAT-Traversal. Wenn ein Gerät in deinem Gast- oder IoT-VLAN Verbindungen aus dem Internet empfängt, stimmt mit deiner Segmentierung etwas gewaltig nicht. Finde heraus, was.
• Asymmetrische Upload-Muster. Ein Telefon oder eine TV-Box, deren Upload-Volumen sich dem Download-Volumen annähert, liefert Inhalte aus oder leitet Traffic weiter. Keines von beidem ist bei Consumer-Geräten normal.
• Tageszeit-Baselines. Die Forscher, die die Exits im Regierungsnetz entdeckten, stützten sich genau darauf: Aktivität, die sich in den Abendstunden konzentriert, deutete auf ein Gerät in einem persönlichen statt Gastnetz hin. Deine eigene Version ist einfacher. Alarmiere, wenn sich der Traffic-Charakter eines Geräts ändert, nicht nur das Volumen.

Dafür braucht es keine Deep Packet Inspection, was wichtig ist, wenn dir ein Netzwerk wichtig ist, dem Menschen vertrauen können. Flow-Metadaten wie NetFlow, Zeek-Conn-Logs oder VPC-Flow-Logs tragen alle oben genannten Signale. Wenn du Egress-Flow-Daten noch nicht speicherst und baselinest, ist das die Lücke, die du schließen solltest, bevor du irgendetwas kaufst. Die blinden Flecken hier ähneln denen beim Logging von Cloud-Authentifizierung: Die Daten existieren, aber niemand schaut hin, bis ein Vorfall passiert.

# Quick-and-dirty hunt: client devices acting like relays
# Feed this Zeek-style conn logs; flag RFC1918 sources with
# high distinct-destination fan-out and heavy upload ratios.
awk -F'\t' '
$3 ~ /^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01]))/ {
src=$3; dst=$5
up[src]+=$10; down[src]+=$12
seen[src SUBSEP dst]=1
}
END {
for (k in seen) { split(k,a,SUBSEP); fanout[a[1]]++ }
for (s in fanout)
if (fanout[s] > 200 && up[s] > down[s] * 0.5)
printf "%s dsts=%d up=%d down=%d\n", s, fanout[s], up[s], down[s]
}' conn.log | sort -t= -k2 -nr | head -20

Das ist ein erster Durchgang, kein fertiges Produkt. Justiere den Fan-out-Schwellenwert an deinen eigenen Baselines, und rechne damit, dass deine Media-Server und Backup-Agenten Fehlalarme auslösen, bis du sie auf die Whitelist setzt. Der Punkt ist: Die Suche ist günstig. Eine Nachmittagsanalyse von Logs findet, was eine Appliance für sechsstellige Beträge findet.

Segmentierung ist die eigentliche Lösung

Hier meine klare Meinung, auf die harte Tour gebildet: Das Wettrüsten bei der Erkennung kompromittierter Consumer-Geräte wirst du nie gewinnen. Das Angebot ist zu groß, und die Hersteller unsicherer Firmware haben keine Konsequenzen zu fürchten. Was du tun kannst, ist, ein kompromittiertes Gerät langweilig zu machen. Eine infizierte Streaming-Box in einem sauber segmentierten IoT-VLAN kann ihre Bandbreite an ein Proxy-Netzwerk verkaufen. Das ist lästig und möglicherweise peinlich, wenn dein IP-Bereich sensibel ist. Sie kommt aber nicht an deine Dateifreigaben, deine internen APIs oder irgendetwas, das aus einer Peinlichkeit einen Breach macht.

Das Muster in Incident-Reviews ist immer gleich. Die Organisation hatte ein flaches Netzwerk oder ein „Gast“-Netz, das interne DNS und Management-Oberflächen erreichen konnte, oder eine BYOD-Richtlinie, die nur durch einen Klick-durch-Vertrag durchgesetzt wurde. Dann kam eine billige Android-Box oder ein Telefon mit einem gebündelten SDK ins Netz, und die Egress-IP der Organisation tauchte in Inventaren von Proxy-Anbietern auf. Die nachträgliche Lösung ist das, was schon vorher hätte sein sollen: Client-Isolation in Gastnetzen, IoT-Geräte in einem VLAN mit nur ausgehendem Zugriff und verweigerten RFC1918-Zielen, private Geräte weit weg von Produktions-Vertrauenszonen. Defense in Depth ist nicht glamourös. Wie wir im Kontext von geschichteten Verteidigungen gegenüber einzelnen starken Kontrollen argumentiert haben, retten dich die Schichten, wenn eine Kontrolle versagt, und irgendeine versagt immer.

Es lohnt sich auch, intern eine Richtliniendiskussion zu führen. „Kostenlose“ Apps sind der Weg, auf dem diese SDKs ankommen. Wenn deine Mitarbeitenden beliebige Software auf Geräten installieren dürfen, die dein Netzwerk berühren, hast du deinen Perimeter an Mobile-Ad-Tech-Firmen delegiert. Manche Organisationen antworten mit MDM und App-Allowlists. Für die meisten erreicht Netzwerksegmentierung dieselbe Eindämmung mit weniger politischem Aufwand.

Was diese Geschichte tatsächlich zeigt

Entfernt man die politischen Spekulationen, ist die Geschichte eine saubere Demonstration zweier Fakten. Erstens: Die Erkennung von Residential Proxies ist zu einer eigenen Produktkategorie gereift. Forscher können Exit-Nodes inzwischen in großem Maßstab aufzählen und dem IP-Raum zuordnen, was echte, nützliche Telemetrie ist. Zweitens, und unbequemer: Jedes Netzwerk ist nur einen unachtsamen Gerätekauf davon entfernt, die Infrastruktur von jemand anderem zu sein. Selbst die bestbewachten Netzwerke der Welt bestehen aus Menschen, und Menschen stecken Dinge ein.

Wenn du nur eines mitnimmst: Prüfe, ob die Egress-IPs deiner eigenen Organisation in Inventaren von Residential Proxies auftauchen. Mehrere Dienste verraten dir das, und dein Threat-Intel-Feed enthält es womöglich bereits. Dass dein Bereich gelistet ist, beweist keine Kompromittierung, denn Carrier-Grade-NAT und geteilter Adressraum verwischen das Bild. Es ist aber ein günstiger, aussagekräftiger Ausgangspunkt für eine Suche. Schau dir dann deinen Egress-Fan-out an, deine langlebigen Verbindungen und dein VLAN-Design.

Die Angreifer sind vor Jahren in die guten Viertel gezogen. Die Verteidiger, die das bemerkt haben, sind diejenigen, die aufgehört haben, Adressen zu prüfen, und angefangen haben, Verhalten zu beobachten.