Wenn Sie schon einmal Proxys verwendet haben, ist Ihnen IP-Whitelisting wahrscheinlich vertraut: Sie registrieren die Adresse Ihres Servers beim Anbieter, und jede Verbindung von dieser Adresse wird ohne Zugangsdaten durchgelassen. Das ist ein gängiges Modell, und Nutzer, die von anderen Produkten kommen, suchen oft nach dieser Einstellung.
Die direkte Antwort für das Residential-Gateway lautet: Es gibt keine IP-Whitelist. Die Authentifizierung erfolgt bei jeder Anfrage über Benutzername und Passwort, und die Zugangsdaten sind der alleinige Authentifizierungsmechanismus. Das ist eine bewusste Design-Entscheidung und kein fehlendes Feature, und es lohnt sich zu verstehen, warum, weil es beeinflusst, wie Sie den Zugriff absichern. Whitelisting gibt es an anderer Stelle in der Produktpalette durchaus, bei ISP-Proxys und bei älteren port-basierten Plänen, und dieser Beitrag beschreibt, wie man es dort einrichtet.
Warum das Residential-Gateway Zugangsdaten statt Whitelisting verwendet
Das Residential-Produkt ist ein einziger Endpunkt, p.shifter.io:443, bei dem das gesamte Targeting im Benutzernamen steckt. Eine Anfrage für einen US-Exit mit einer Sticky Session verwendet denselben Host und Port wie eine Anfrage für einen rotierenden deutschen Exit; nur der Benutzername ändert sich. Dieses Design hat eine Konsequenz für die Authentifizierung: Die Zugangsdaten tragen bereits Informationen pro Anfrage, also müssen sie ohnehin bei jeder Anfrage vorhanden sein.
Authentifizierung über Zugangsdaten ist außerdem deutlich portabler, was mehr Gewicht hat, als es auf den ersten Blick scheint. Whitelisting bindet den Zugriff an eine feste Egress-Adresse, und ein großer Teil moderner Infrastruktur hat keine solche. Container erhalten bei einer Neuplanung neue Adressen, Autoscaling-Gruppen fügen Knoten hinzu und entfernen sie, Serverless-Funktionen laufen über gemeinsam genutzten Adressraum, der sich ohne Vorwarnung ändert, CI-Runner sind kurzlebig, und ein Entwickler an einem Laptop oder einer Heimverbindung hat eine dynamische Adresse, die sich über Nacht ändern kann. Bei Whitelisting bedeutet jeder dieser Fälle ein Support-Ticket. Mit Zugangsdaten in einem Secret Store funktioniert dieselbe Konfiguration von einem Laptop, einem Container, einem CI-Job und einem Produktionscluster aus, ohne dass jemand etwas registrieren muss.
Wenn Sie also nach der Whitelist-Einstellung für Residential-Proxys gesucht haben, ist das, was Sie stattdessen konfigurieren sollten, die Handhabung von Zugangsdaten, die unten behandelt wird.
Wo Whitelisting anwendbar ist
Zwei Produkte verwenden Quell-IP-Authentifizierung, und wenn Whitelisting für Sie ein zwingendes Erfordernis ist, sind das die Produkte, die Sie sich ansehen sollten.
ISP-Proxys unterstützen zwei Authentifizierungsmodi, und Sie wählen einen pro Plan im Panel. Im Modus “autorisierte Quell-IP” registrieren Sie die Adresse Ihres Servers und verbinden sich dann mit Ihren fest zugewiesenen IPs über Port 1337 ganz ohne Zugangsdaten. Im Modus “Benutzername und Passwort” verbinden Sie sich von überall mit Zugangsdaten, eine Zeile pro IP. Der Kompromiss ist genau der oben beschriebene: Whitelisting hält Zugangsdaten vollständig aus Ihrem Code heraus, auf Kosten dessen, dass es nur von registrierten Adressen aus funktioniert. ISP-Proxys sind ein anderes Produkt als rotierendes Residential, mit fest zugewiesenen statischen Adressen statt eines rotierenden Pools. Wenn Sie zwischen beiden wählen, finden Sie den Vergleich unter ISP versus residential proxies und what static residential proxies are.
Legacy-Port-Listen-Pläne authentifizieren ausschließlich per Quell-IP. Jeder Port in Ihrer Zuweisung hat seine eigene Subdomain, und Sie whitelisten die Adresse Ihres Servers im Panel oder verwalten die Liste über die Legacy-Management-API und verbinden sich dann mit jedem Port in Ihrer Liste. Wenn Sie einen dieser Pläne nutzen, ist Whitelisting nicht optional, sondern der einzige Authentifizierungsmechanismus. Der Hintergrund dazu, warum die Branche von diesem Modell abgekommen ist, findet sich unter why the per-port era is over.
Einrichten einer Whitelist bei ISP-Proxys
Die Mechanik ist unkompliziert, aber zwei Details verursachen die meisten Fehlschläge.
Registrieren Sie erstens Ihre Egress-Adresse, nicht eine lokale Adresse. Entscheidend ist die öffentliche Adresse, von der Ihr Traffic kommt, nicht Ihre LAN-Adresse, nicht die interne Adresse Ihres Containers und nicht das, was ifconfig auf der Maschine anzeigt. Ermitteln Sie sie von der Maschine aus, die tatsächlich die Anfragen stellen wird:
# run this ON the server that will connect to the proxies
curl -s https://ipinfo.io/ipWenn Ihre Infrastruktur über ein NAT-Gateway oder einen Load Balancer nach außen geht, ist diese gemeinsam genutzte Adresse diejenige, die Sie registrieren sollten, und es lohnt sich zu prüfen, ob sie stabil ist und nicht dynamisch zugewiesen wird.
Wählen Sie zweitens den Authentifizierungsmodus im Panel unter ISP Proxies bewusst aus, denn die beiden Modi sind Alternativen und kein geschichtetes System. Sobald Sie sich im Modus “autorisierte Quell-IP” befinden, verbinden Sie sich ohne Zugangsdaten:
# authorized source IP mode: no username or password
curl -x 185.199.108.153:1337 https://ipinfo.io/jsonWenn das einen Fehler zurückgibt und Sie sicher sind, dass die Adresse registriert ist, liegen die üblichen Ursachen darin, dass sich Ihre Egress-Adresse geändert hat, dass Sie eine IPv4-Adresse registriert haben, während Ihr Traffic über IPv6 läuft, oder umgekehrt, oder dass Anfragen von einem anderen Knoten kommen als dem, von dem aus Sie getestet haben.
Der Kompromiss, klar benannt
Whitelisting entfernt Geheimnisse aus Ihrem Code und Ihrer Konfiguration, was tatsächlich wertvoll ist: nichts, was in einem Repository durchsickern kann, nichts, was rotiert werden muss, nichts, was in einem Log landet. Seine Schwäche ist, dass es genau in dem Moment versagt, in dem sich Ihre Egress-Adresse ändert, und es kann keinen Zugriff von überall unterstützen, wo es keine stabile Adresse gibt.
Authentifizierung über Zugangsdaten ist portabel und funktioniert in jeder Umgebung, aber die Zugangsdaten sind ein Geheimnis, das jetzt Ihnen gehört, was bedeutet, dass sie in einen Secret Manager gehören statt in den Quellcode, und sie brauchen einen Rotationsplan.
Keines der beiden ist von Natur aus sicherer. Sie versagen unterschiedlich, und die richtige Wahl hängt davon ab, ob Ihre Infrastruktur eine stabile Egress-Adresse hat.
Absicherung von Residential-Zugangsdaten, da es keine Whitelist gibt
Wenn Sie das Residential-Gateway nutzen, ist dies der Abschnitt, der Whitelisting für Sie ersetzt.
Halten Sie Zugangsdaten aus der Versionskontrolle und aus Container-Images heraus, und laden Sie sie aus Umgebungsvariablen, die von einem Secret Manager unterstützt werden. Verwenden Sie wo möglich getrennte Zugangsdaten pro Umgebung, damit ein durchgesickerter Entwicklungswert nicht die Produktion gefährdet. Behandeln Sie Rotation als Deployment und nicht als Klick im Panel: Aktualisieren Sie zuerst den Secret Store, rollen Sie die Clients aus, und rotieren Sie dann den alten Wert, denn jeder Client, der noch das vorherige Passwort verwendet, wird in dem Moment, in dem es sich ändert, mit 407 antworten, was die häufigste selbstverschuldete Variante des Problems ist, das unter fixing 407 and credential errors behandelt wird.
Kontrollieren Sie dann die andere Seite. Auch ohne anbieterseitige Whitelist können Sie mit gewöhnlichen Egress-Regeln, Netzwerkrichtlinien oder einer Security Group einschränken, welche Ihrer eigenen Systeme das Gateway erreichen, sodass durchgesickerte Zugangsdaten von außerhalb Ihrer Infrastruktur weniger nützlich sind. Und überwachen Sie die Bandbreitennutzung, denn unerklärlicher Verbrauch ist das Signal, dass Zugangsdaten entkommen sind, was leichter zu erkennen ist, wenn Sie eine Baseline aus Ihrem eigenen pipeline monitoring haben.
Häufige Fehler
Das Registrieren einer privaten Adresse wie eines 10.x- oder 192.168.x-Wertes, die niemals übereinstimmen kann, da nur die öffentliche Egress-Adresse für den Anbieter sichtbar ist. Das Whitelisten eines Laptops oder einer Heimverbindung und die Überraschung, wenn es nach einem Router-Neustart, der die Adresse neu zuweist, aufhört zu funktionieren. Das Vergessen, dass Autoscaling Knoten hinter anderen Adressen hinzufügt. Das Registrieren von IPv4, während der Traffic tatsächlich über IPv6 läuft. Und die Annahme, dass ein Whitelist-Eintrag bei einem Produkt auch ein anderes abdeckt: Eine ISP-Proxy-Whitelist hat keine Auswirkung auf das Residential-Gateway, das weiterhin Zugangsdaten verlangt.
Fazit
Es gibt keine IP-Whitelist beim Residential-Gateway, und das ist Absicht: Das Targeting steckt im Benutzernamen, sodass Zugangsdaten ohnehin bei jeder Anfrage vorhanden sind, und Authentifizierung über Zugangsdaten funktioniert weiterhin über Container, Autoscaling, CI und dynamische Verbindungen hinweg, wo eine Whitelist versagen würde. Wenn Sie speziell Quell-IP-Authentifizierung benötigen, bieten ISP-Proxys diese als einen von zwei wählbaren Modi an, und Legacy-Port-Listen-Pläne verwenden sie ausschließlich, und in beiden Fällen ist es Ihre öffentliche Egress-Adresse, die Sie registrieren müssen, nicht irgendetwas Lokales. Ersetzen Sie bei Residential das Whitelisting durch diszipliniertes Handling von Zugangsdaten: Secret Manager, Werte pro Umgebung, ein Rotationsverfahren, das Clients aktualisiert, bevor das alte Passwort ungültig wird, sowie Egress-Kontrollen und Nutzungsüberwachung auf Ihrer Seite.
Die vollständige Authentifizierungsreferenz für jedes Produkt finden Sie in der authentication documentation, und die Gateway-Spezifika unter gateway and authentication. Das Produkt selbst ist residential proxies, ein Endpunkt und ein Zugangsdatenpaar über alle Länder und Sitzungsmodi hinweg, mit per-GB pricing.