🔁 IPSpinner

IPSpinner ist ein lokaler Proxy, mit dem alle eingehenden Anfragen über verschiedene ausgewählte Anbieter umgeleitet werden können. Der Zweck besteht darin, einen Durchgangs-Proxy zu erstellen, der die Quell-IP-Adresse jeder Anfrage rotiert. Wenn Sie beispielsweise eine Brute-Force-Operation über IPSpinner ausführen, können Sie vermeiden, erkannt zu werden, da der Server die Anfragen von Hunderten verschiedener IP-Adressen erhält.

IPSpinner unterstützt derzeit AWS (API Gateway), Azure (Cloud Shell) und GitHub (GitHub Actions).

Inhaltsverzeichnis

1. Wie funktioniert es?
   1. Allgemeines
   2. Pro Anbieter & Launcher
      1. AWS API Gateway
      2. Azure Cloud Shell
      3. GitHub Actions
   3. Vergleich der Launcher
2. Wie installieren?
   1. Go installieren
   2. IPSpinner klonen und erstellen
   3. Builds bereinigen
3. Wie verwenden?
   1. Allgemeines
      1. Befehlszeilenargumente
      2. Konfigurationsdatei
   2. Pro Anbieter
      1. AWS
      2. Azure
      3. GitHub
4. Wie ...?
   1. HTTP/2-Unterstützung?

I/ Wie funktioniert es?

1) Allgemeines

Abbildung 1: IPSpinner – Gesamtdiagramm

IPSpinner fungiert als lokaler Proxy, der Anfragen über externe Dienste umleitet. Zu diesem Zweck nutzt IPSpinner Anbieter (Provider) und Launcher.

Ein Anbieter entspricht einem Cloud-Anbieter oder einem Online-Dienstanbieter (AWS, Azure, GitHub usw.), der verschiedene Dienste – sogenannte Launcher – anbietet, die zum Weiterleiten der Anfragen des Benutzers genutzt werden können (AWS API Gateway, GitHub Actions, Azure Cloud Shells usw.).

Um IPSpinner zu starten, muss der Benutzer daher Anmeldedaten für die gewünschten Anbieter sowie zusätzliche Konfigurationen für die Launcher bereitstellen. Mehrere Launcher-Typen können gleichzeitig verwendet werden; IPSpinner wählt für jede Anfrage zufällig einen der verfügbaren Launcher aus.

Darüber hinaus implementiert IPSpinner eine Preload-Funktion. Einige Launcher können vorgeladen werden, um die Verzögerung durch die Neukonfiguration zu vermeiden, falls der Proxy einen neuen Host sieht. Für diese Launcher wird die Preload-Prozedur empfohlen, ist aber nicht verpflichtend. Für die anderen ist kein Preloading erforderlich.

2) Pro Anbieter und Launcher

i. AWS API Gateway

Einführung

IPSpinner kann AWS API Gateway zum Senden von Anfragen nutzen. Diese Implementierung basiert auf FireProx, das ein REST-API-Gateway erstellt, um eingehende Anfragen umzuleiten. FireProx wurde daher angepasst, um mehrere Hosts pro API-Gateway zu unterstützen und neue Funktionen zu implementieren. Wenn IPSpinner eine Anfrage erhält, wählt oder erstellt es die passende API-Gateway-Instanz und sendet die Anfrage an diese. Anschließend sammelt es die Antwort und gibt sie an den Benutzer zurück. Der Zielserver empfängt die Anfrage also vom API-Gateway und nicht direkt vom Benutzer. Da das API-Gateway seine ausgehende IP bei jeder Anfrage rotiert, nutzt IPSpinner diese Funktion, um die IP-Adresse zu rotieren.

Abbildung 2: AWS API Gateway – Gesamtdiagramm

Die nächste Grafik (erstellt im Oktober 2024) zeigt die Anzahl der verfügbaren eindeutigen IP-Adressen pro AWS-Region in Abhängigkeit von der Anzahl der gesendeten Anfragen. Die meisten Regionen bieten mehr als 100 IP-Adressen, und es können mehrere Regionen gleichzeitig verwendet werden, sodass der Benutzer seine Anfragen über Tausende weltweiter Adressen proxifizieren kann.

Abbildung 3: AWS API Gateway – Verfügbare IP-Adressen pro Region

Schließlich zeigt Abbildung 4 mit einer logarithmischen Grünfärbung, wie viele Adressen pro Land verfügbar sind. Sie verdeutlicht, dass der Benutzer die Möglichkeit hat, seine Quell-IP-Adresse mit Adressen auf jedem Kontinent zu fälschen.

Abbildung 4: AWS API Gateway – IP-Adressen pro Land

Wissenswertes

IPSpinner implementiert eine Rotationsfunktion, die erstellte FireProx-Instanzen regelmäßig löscht und erneuert. Wie die folgende Grafik zeigt, kann die Rotation einer FireProx-Instanz eine neue Teilmenge von IPs liefern. Allerdings verfügt jede AWS-Region über einen begrenzten IP-Bestand, sodass Rotationen ab einem bestimmten Punkt keine neuen IPs mehr liefern.

Abbildung 5: AWS API Gateway – Rotationsprozess

Dieser Launcher implementiert eine Preload-Prozedur. Wie bereits erwähnt, ist sie nicht verpflichtend, kann aber einige Neukonfigurationsverzögerungen oder Synchronisationsfehler in den ersten Sekunden nach der Neukonfiguration verhindern.

Darüber hinaus setzen API-Gateways standardmäßig einen X-Forwarded-For-Header, der nicht gelöscht, aber überschrieben werden kann. Der Benutzer kann daher in der IPSpinner-Konfiguration einen IP-Adressbereich angeben, aus dem für jede Anfrage eine zufällige IP ausgewählt wird (IPv4- oder IPv6-Bereich).

ii. Azure Cloud Shell

Einführung

IPSpinner nutzt Azure Cloud Shell zum Senden von Anfragen. Eine Azure Cloud Shell ist ein interaktives, authentifiziertes, über den Browser zugängliches Terminal zur Verwaltung von Azure-Ressourcen. Cloud Shell läuft auf einem temporären Host, der pro Sitzung und pro Benutzer bereitgestellt wird.

IPSpinner verwendet daher mehrere Azure-Benutzer, für die eine Cloud-Shell-Sitzung vorbereitet wird. Anschließend wird jede Anfrage an eine initialisierte Cloud Shell umgeleitet, bevor diese erneuert wird, um ihre IP-Adresse zurückzusetzen.

Abbildung 6: Azure Cloud Shell – Gesamtdiagramm

Wie die folgende Grafik zeigt, bieten die verschiedenen Regionen, die für die Bereitstellung von Cloud-Shell-Sitzungen zur Verfügung stehen, jeweils Dutzende von IP-Adressen. Der Benutzer kann mehrere Regionen gleichzeitig konfigurieren, um seinen IP-Pool zu vergrößern.

Abbildung 7: Azure Cloud Shell – Verfügbare IP-Adressen pro Region

Die IP-Adressen sind jedoch stärker konzentriert als bei AWS API Gateway. Wie die folgende Karte zeigt, befinden sich die meisten in den USA, in Europa und in Indien.

Abbildung 8: Azure Cloud Shell – IP-Adressen pro Land

Wissenswertes

Aufgrund der Verzögerung beim Erneuerungsprozess der Cloud Shell empfehlen wir, die Anfrageflussrate zu begrenzen. Weitere Informationen finden Sie im Abschnitt Vergleich der Launcher.

iii. GitHub Actions

Einführung

IPSpinner kann auch GitHub Actions zum Senden von Anfragen nutzen. Diese Implementierung ist von git-rotate inspiriert, wurde jedoch vollständig modifiziert und angepasst, um den Catcher-Server zu eliminieren.

Es erstellt ein Repository mit einer vordefinierten Workflow-Vorlage. Für jede Anfrage führt es dann den Workflow aus, indem die Anfrageinformationen über die Umgebungsvariablen übergeben werden. Alle Daten werden verschlüsselt, um zu verhindern, dass sie von einem externen Benutzer gelesen werden können. IPSpinner sammelt schließlich die Antwortdaten aus den Workflow-Logs.

Abbildung 9: GitHub Actions – Gesamtdiagramm

Die folgende Abbildung zeigt, dass GitHub Actions Tausende verschiedener IP-Adressen bietet.

Abbildung 10: GitHub Actions – Verfügbare IP-Adressen pro Region

Die folgende Karte zeigt jedoch, dass GitHub Actions nur amerikanische IP-Adressen anbietet. Nach der Analyse scheinen ihre Worker auf einer Azure-Infrastruktur bereitgestellt zu sein.

Abbildung 11: GitHub Actions – IP-Adressen pro Land

Wissenswertes

⚠️ Darüber hinaus: „GitHub nimmt Missbrauch und Spam von Actions ernst und verfügt über ein eigenes Team, um „Spammer“ aufzuspüren.“ Daher darf der Benutzer diesen Anbieter NICHT mit seinem eigenen Konto oder dem Firmenkonto verwenden, um eine Kontosperrung zu vermeiden.

Aufgrund des stündlichen Limits der GitHub-REST-API muss die maximale Anfrageflussrate begrenzt werden, um Unterbrechungen zu vermeiden. Weitere Informationen finden Sie im Abschnitt Vergleich der Launcher.

3) Vergleich der Launcher

II/ Wie installieren?

1) Go installieren

Dieses Projekt wurde mit einer Go-Version >= 1.21 getestet, funktioniert aber möglicherweise auch mit niedrigeren Go-Versionen.

Siehe Go-Installationsdokumentation

Stellen Sie nach der Installation sicher, dass die Standard-Go-Binärdatei die richtige ist:

$ go version
go version go1.21.1 linux/amd64

2) IPSpinner klonen und erstellen

$ git clone https://github.com/synacktiv/IPSpinner.git
$ cd IPSpinner
$ go mod tidy

$ make build-linux # For Linux AMD64 arch
$ make build-windows # For Windows AMD64 arch

Die ausführbare Datei heißt standardmäßig „ipspinner“ unter Linux bzw. „ipspinner.exe“ unter Windows.

3) Builds bereinigen

Nach der Verwendung können Sie die Builds bereinigen, indem Sie Folgendes ausführen:

$ make clean

III/ Wie verwenden?

1) Allgemeines

Um Hilfe zur Verwendung von IPSpinner zu erhalten, können Sie den Befehl ohne Argumente ausführen:

$ ./ipspinner -h
    Help will be displayed

Alle Informationen (mit Ausnahme der Anfrageumleitungen) werden in die Datei ipspinner.log protokolliert.

Einige allgemeine Optionen stehen als Argumente zur Verfügung; die übrigen Konfigurationsinformationen müssen in einer INI-Konfigurationsdatei angegeben werden.

i. Befehlszeilenargumente

Der Benutzer kann einige Befehlszeilenargumente angeben:

Einige globale Parameter und Anbieterparameter müssen in einer INI-Konfigurationsdatei angegeben werden. Die Konfigurationsdatei muss vor dem Start von IPSpinner vorbereitet werden. Ihr Inhalt wird in den nächsten Unterabschnitten erläutert. Standardmäßig sucht IPSpinner nach einer Konfigurationsdatei namens config.ini.

Für die Verarbeitung von HTTPS-Anfragen benötigt IPSpinner ein Zertifikat einer Zertifizierungsstelle (CA) und einen Schlüssel. Wenn der Benutzer kein Zertifikat bereitstellt, generiert IPSpinner ein eigenes selbstsigniertes Zertifikat und einen Schlüssel. Der Benutzer kann das generierte Zertifikat mit --export-ca-cert abrufen (z. B. für den Import in den Browser). Alternativ kann der Benutzer in der Konfigurationsdatei ein eigenes CA-Zertifikat und einen Schlüssel angeben (siehe folgende Abschnitte).

Der Benutzer kann den Listening-Host und -Port mit --host und --port angeben.

Schließlich stehen drei ausführliche Modi (Verbose-Modi) zur Verfügung:

• --v: gibt Erstellungsprotokolle aus
• --vv: wie --v und zeigt Anfrageumleitungen an
• --vvv: wie --vv und zeigt detaillierte Anfrageinformationen an

ii. Konfigurationsdatei

Eine Vorlage für die INI-Konfigurationsdatei ist im Projektrepository verfügbar.

Im Abschnitt proxy kann der Benutzer einige Parameter angeben:

Alle weiteren Abschnitte werden im entsprechenden Anbieterkapitel beschrieben.

Es ist wichtig zu beachten, dass ein Benutzer mehrere Anbieter und Launcher gleichzeitig aktivieren kann. IPSpinner wählt dann für jede Anfrage zufällig einen Launcher aus allen verfügbaren aus.

2) Pro Anbieter

i. AWS

Konfigurationsparameter für AWS im Abschnitt aws:

Konfigurationsparameter für die API-Gateways im Abschnitt aws:

ii. Azure

Konfigurationsparameter für Azure im Abschnitt azure:

Konfigurationsparameter für Azure Cloud Shell im Abschnitt azure:

iii. GitHub

Konfigurationsparameter für GitHub im Abschnitt github:

Konfigurationsparameter für GitHub Actions im Abschnitt github:

IV/ Wie ...?

1) HTTP/2-Unterstützung?

IPSpinner unterstützt das HTTP/2-Protokoll nicht. Da der Proxy die erste TLS-Verbindung terminiert, gehen die Vorteile des Protokolls verloren und es erscheint als einfache HTTP/1.1-Verbindung.

Um HTTP/2-Probleme bei der Verwendung von IPSpinner mit Burp Suite zu vermeiden, entfernen Sie bitte die HTTP/2-Clientunterstützung: Einstellungen > Netzwerk > HTTP > HTTP/2 > Deaktivieren Sie das Kontrollkästchen HTTP/2.