synacktiv/ipspinnerIPSpinner works as a local proxy that redirects requests through external services.
IPSpinner est un proxy local qui peut être utilisé pour rediriger toutes les requêtes entrantes via différents fournisseurs choisis. L'objectif est de créer un proxy de transit qui fait varier l'adresse IP source de chaque requête. Par exemple, lancer une opération de force brute via IPSpinner aidera à éviter d'être détecté, car le serveur recevra les requêtes depuis des centaines d'adresses IP différentes.
IPSpinner prend actuellement en charge AWS (API Gateway), Azure (Cloud Shell) et GitHub (GitHub Actions).
Figure 1 : IPSpinner - Schéma global
IPSpinner fonctionne comme un proxy local qui redirige les requêtes via des services externes. Pour cela, IPSpinner s'appuie sur des fournisseurs et des lanceurs.
Un fournisseur correspond à un fournisseur de cloud ou à un fournisseur de services en ligne (AWS, Azure, GitHub, etc.) qui propose différents services, appelés lanceurs, pouvant être utilisés pour relayer les requêtes de l'utilisateur (AWS API Gateway, GitHub Actions, Azure Cloud Shell, etc.).
Ainsi, pour lancer IPSpinner, l'utilisateur devra fournir les identifiants des fournisseurs qu'il souhaite utiliser ainsi que des configurations supplémentaires pour les lanceurs. Plusieurs types de lanceurs peuvent être utilisés en même temps ; IPSpinner choisira aléatoirement l'un de ceux disponibles pour chaque requête.
De plus, IPSpinner implémente une fonctionnalité de préchargement. Certains lanceurs peuvent être préchargés pour éviter le délai de reconfiguration lorsqu'un nouvel hôte est vu par le proxy. Pour ces lanceurs, la procédure de préchargement est recommandée mais pas obligatoire. Pour les autres, aucun préchargement n'est nécessaire.
IPSpinner peut utiliser AWS API Gateway pour envoyer des requêtes. Cette implémentation est basée sur FireProx, qui crée une API Gateway REST pour rediriger les requêtes entrantes. FireProx a donc été adapté pour gérer plusieurs hôtes par API Gateway et pour implémenter de nouvelles fonctionnalités. En résumé, lorsqu'IPSpinner reçoit une requête, il sélectionne ou crée l'instance API Gateway appropriée et lui envoie la requête. Ensuite, il recueille la réponse et la renvoie à l'utilisateur. Ainsi, le serveur ciblé a reçu la requête depuis l'API Gateway et non directement de l'utilisateur. Comme l'API Gateway fait varier son IP sortante pour chaque requête, IPSpinner utilise cette fonctionnalité pour faire varier l'adresse IP.
Figure 2 : AWS API Gateway - Schéma global
Le graphique suivant, réalisé en octobre 2024, montre le nombre d'adresses IP uniques disponibles par région AWS en fonction du nombre de requêtes envoyées. La plupart des régions offrent plus de 100 adresses IP et plusieurs régions peuvent être utilisées en même temps, permettant à l'utilisateur de faire transiter ses requêtes par des milliers d'adresses dans le monde entier.
Figure 3 : AWS API Gateway - Adresses IP disponibles par région
Enfin, la figure 4 montre, avec un niveau de couleur verte logarithmique, combien d'adresses sont disponibles par pays. Elle démontre que l'utilisateur a la possibilité de falsifier son adresse IP source avec des adresses sur n'importe quel continent.
Figure 4 : AWS API Gateway - Adresses IP par pays
IPSpinner implémente une fonctionnalité de rotation qui supprime et renouvelle régulièrement les instances FireProx créées. Comme le montre le graphique suivant, faire tourner une instance FireProx peut fournir un nouveau sous-ensemble d'IP. Cependant, chaque région AWS dispose d'un ensemble limité d'IP et, par conséquent, à un moment donné, les rotations ne fourniront plus de nouvelles IP.
Figure 5 : AWS API Gateway - Processus de rotation
Ce lanceur implémente une procédure de préchargement. Comme indiqué précédemment, elle n'est pas obligatoire, mais peut éviter certains délais de reconfiguration ou des erreurs de synchronisation durant les premières secondes après une reconfiguration.
De plus, les API Gateway définissent par défaut un en-tête X-Forwarded-For qui ne peut pas être supprimé mais peut être remplacé. Ainsi, l'utilisateur peut spécifier dans la configuration d'IPSpinner une plage d'adresses IP à partir de laquelle une IP aléatoire sera choisie pour chaque requête (plage IPv4 ou IPv6).
IPSpinner utilise Azure Cloud Shell pour envoyer des requêtes. Azure Cloud Shell est un terminal interactif, authentifié et accessible via navigateur pour gérer les ressources Azure. Cloud Shell s'exécute sur un hôte temporaire fourni par session et par utilisateur.
Ainsi, IPSpinner utilise plusieurs utilisateurs Azure pour lesquels une session Cloud Shell est préparée. Ensuite, chaque requête est redirigée vers un Cloud Shell initialisé, avant d'être renouvelé pour réinitialiser son adresse IP.
Figure 6 : Azure Cloud Shell - Schéma global
Comme le montre le graphique suivant, les différentes régions disponibles pour déployer des sessions Cloud Shell offrent chacune des dizaines d'adresses IP. L'utilisateur peut configurer plusieurs régions en même temps pour augmenter son pool d'IP.
Figure 7 : Azure Cloud Shell - Adresses IP disponibles par région
Cependant, les adresses IP sont plus concentrées que pour AWS API Gateway. Comme l'illustre la carte suivante, la plupart d'entre elles se situent aux États-Unis, en Europe et en Inde.
Figure 8 : Azure Cloud Shell - Adresses IP par pays
En raison du délai du processus de renouvellement de Cloud Shell, nous conseillons de limiter le débit des requêtes. Plus d'informations dans la sous-section comparaison des lanceurs.
IPSpinner peut également tirer parti de GitHub Actions pour envoyer des requêtes. Cette implémentation s'inspire de git-rotate mais a été entièrement modifiée et adaptée pour se passer du serveur récepteur.
Il crée un dépôt avec un modèle de workflow prédéfini. Ensuite, pour chaque requête, il exécute le workflow en fournissant les informations de la requête via les variables d'environnement. Toutes les données sont chiffrées afin d'éviter qu'elles soient lisibles par un utilisateur externe. IPSpinner collecte enfin les données de réponse à partir des journaux du workflow.
Figure 9 : GitHub Actions - Schéma global
La figure suivante montre que GitHub Actions offre des milliers d'adresses IP différentes.
Figure 10 : GitHub Actions - Adresses IP disponibles par région
Cependant, la carte suivante illustre que GitHub Actions n'offre que des adresses IP américaines. Après analyse, leurs workers semblent être déployés sur une infrastructure Azure.
Figure 11 : GitHub Actions - Adresses IP par pays
⚠️ De plus, « GitHub prend très au sérieux les abus et le spam liés à Actions, et dispose d'une équipe dédiée pour suivre les “utilisateurs spammeurs”. » Ainsi, l'utilisateur NE DOIT PAS utiliser ce fournisseur avec son propre compte ou avec le compte de l'entreprise pour éviter tout risque de fermeture de compte.
En raison de la limite horaire de l'API REST GitHub, le débit maximal des requêtes doit être limité pour éviter toute perturbation. Plus d'informations dans la sous-section comparaison des lanceurs.
Ce projet a été testé avec une version de Go >= 1.21 mais peut fonctionner avec une version inférieure.
Voir documentation d'installation de Go
Après l'installation, assurez-vous que le binaire go par défaut est le bon :
$ go version
go version go1.21.1 linux/amd64
$ 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
L'exécutable sera nommé par défaut "ipspinner" sur Linux ou "ipspinner.exe" sur Windows.
À la fin de l'utilisation, vous pouvez nettoyer les compilations en exécutant :
$ make clean
Pour obtenir de l'aide sur l'utilisation d'IPSpinner, vous pouvez exécuter la commande sans aucun argument :
$ ./ipspinner -h
Help will be displayed
Toutes les informations (à l'exception des redirections de requêtes) sont journalisées dans le fichier ipspinner.log.
Certaines options courantes sont disponibles en tant qu'arguments, et les autres informations de configuration doivent être fournies dans un fichier de configuration INI.
L'utilisateur peut spécifier certains arguments de ligne de commande :
Certains paramètres globaux et de fournisseurs doivent être spécifiés dans un fichier de configuration INI. Le fichier de configuration doit être préparé avant d'exécuter IPSpinner. Son contenu sera expliqué dans les sous-sections suivantes. Par défaut, IPSpinner recherche un fichier de configuration nommé config.ini.
Pour traiter les requêtes https, IPSpinner a besoin d'un certificat d'autorité de certification (CA) et d'une clé. Si l'utilisateur ne fournit pas de certificat, IPSpinner générera son propre certificat auto-signé et sa clé. L'utilisateur peut demander à récupérer le certificat généré avec --export-ca-cert (par exemple pour l'importer dans le navigateur). Sinon, l'utilisateur peut fournir son propre certificat CA et sa clé dans le fichier de configuration (voir les prochaines sections).
L'utilisateur peut spécifier l'hôte et le port d'écoute avec --host et --port.
Enfin, trois modes verbeux sont disponibles :
Ensuite, un modèle pour le fichier de configuration INI est disponible dans le dépôt du projet.
Dans la section proxy, l'utilisateur peut spécifier certains paramètres :
Toutes les autres sections seront décrites dans le chapitre correspondant au fournisseur.
Il est important de noter qu'un utilisateur peut activer plusieurs fournisseurs et lanceurs en même temps. IPSpinner choisira alors un lanceur aléatoire parmi tous ceux disponibles pour chaque requête.
Paramètres de configuration pour AWS, dans la section aws :
Paramètres de configuration pour les API Gateway, dans la section aws :
Paramètres de configuration pour Azure, dans la section azure :
Paramètres de configuration pour Azure Cloud Shell, dans la section azure :
Paramètres de configuration pour GitHub, dans la section github :
| Paramètre | Obligatoire | Valeur par défaut | Description |
|---|---|---|---|
| username | ✅ | Nom d'utilisateur GitHub | |
| token | ✅ | Jeton GitHub associé au nom d'utilisateur fourni |
Paramètres de configuration pour GitHub Actions, dans la section github :
| Paramètre | Obligatoire (si ga_enabled=true) | Valeur par défaut | Description |
|---|---|---|---|
| ga_enabled | / | Activer le lanceur GitHub Actions |
IPSpinner ne prend pas en charge le protocole HTTP/2. Comme le proxy termine la première connexion TLS, les avantages du protocole sont perdus et la connexion apparaît comme une connexion HTTP/1.1 classique.
Ainsi, pour éviter les problèmes HTTP/2 lors de l'utilisation d'IPSpinner avec Burp Suite, veuillez désactiver la prise en charge du client HTTP/2 : Settings > Network > HTTP > HTTP/2 > décochez la case HTTP/2.
| AWS API Gateway | Azure Cloud Shell | GitHub Actions |
|---|
| Adresses IP disponibles | ≈ 12,418 | ≈ 276 | > 6,000 |
| Temps de réponse moyen | 0.46s | 13.04s | 21.42s |
| Temps de reconfiguration moyen | Aucun | 20s | Aucun |
| Débit théorique maximal | 4 000 à 16 000 req/h | 107 req/h/instance Cloud Shell | 1 000 req/h |
| Peut/doit être préchargé ? | ✅ | ❌ | ❌ |
| Utilisation : navigation | ✅ | ❌ | ❌ |
| Utilisation : pulvérisation de mots de passe | ✅ | ✅ | ✅ |
| Paramètre | Obligatoire | Valeur par défaut |
|---|
| --config | ❌ | config.ini |
| --export-ca-cert | ❌ | |
| --host | ❌ | |
| --port | ❌ | 8080 |
| --v, --vv, --vvv | ❌ |
| Paramètre | Obligatoire | Valeur par défaut | Description |
|---|
| preload_hosts_file | ❌ | une liste d'URL/hôtes à précharger, pour les fournisseurs qui peuvent précharger des hôtes | |
| whitelist_hosts_file | ❌ | une liste d'URL/hôtes autorisés (tous les autres seront bloqués par défaut) | |
| blacklist_hosts_file | ❌ | une liste d'URL/hôtes bloqués (ignorée si la liste blanche est définie) | |
| ca_cert_file & ca_cert_key_file | ❌ | un certificat CA fourni par l'utilisateur (si l'utilisateur souhaite remplacer celui généré par défaut) | |
| user_agents_file | ❌ | une liste de user agents qui seront choisis aléatoirement pour les requêtes | |
| debug_response_headers | ❌ | false | ajoute deux en-têtes de débogage dans les réponses du proxy : X-IPSpinner-Provider et X-IPSpinner-Provider-NbTotalReqSent |
| wait_for_launcher_available_timeout | ❌ | 60 | nombre de secondes avant l'expiration d'une requête si aucun lanceur ne devient disponible |
| Paramètre | Obligatoire | Valeur par défaut | Description |
|---|
| regions | ✅ | Liste des régions, séparées par des virgules, où les ressources peuvent être déployées | |
| profile | ❌ | Profil AWS CLI à utiliser | |
| access_key | ✅ (ou profil) | Clé d'accès de l'utilisateur AWS | |
| secret_key | ✅ (ou profil) | Clé secrète de l'utilisateur AWS | |
| session_token | ❌ | Jeton de session de l'utilisateur AWS |
| Paramètre | Obligatoire (si ag_enabled=true) | Valeur par défaut | Description |
|---|
| ag_enabled | / | Activer le lanceur API Gateway | |
| ag_max_instances | ❌ | 5 | Nombre maximal d'instances API Gateway pouvant être déployées (maximum global, pas par région) |
| ag_rotate_nb_requests | ❌ | 5,000 | Nombre de requêtes avant rotation d'une API Gateway |
| ag_forwarded_for_range | ❌ | 35.180.0.0/16 | Plage d'adresses IP pour l'en-tête X-Forwarded-For (plage IPv4 ou IPv6) |
| ag_instance_title_prefix | ❌ | fpr | Personnalisation des informations de l'API Gateway |
| ag_instance_deployment_description | ❌ | IPSpinner FireProx Prod | Personnalisation des informations de l'API Gateway |
| ag_instance_deployment_stage_description | ❌ | IPSpinner FireProx Prod Stage | Personnalisation des informations de l'API Gateway |
| ag_instance_deployment_stage_name | ❌ | 3 mots anglais aléatoires | Personnalisation des informations de l'API Gateway |
| Paramètre | Obligatoire | Valeur par défaut | Description |
|---|
| admin_email | ✅ (ou accounts_file) | E-mail de l'administrateur Azure | |
| admin_password | ✅ (ou accounts_file) | Mot de passe de l'administrateur Azure | |
| tenant_id | ✅ | ID du locataire | |
| subscription_id | ✅ | ID de l'abonnement | |
| accounts_file | ❌ | Une liste de comptes pré-créés (e-mail et mot de passe, une information par ligne) qui remplace admin_email et admin_password |
| Paramètre | Obligatoire (si cs_enabled=true) | Valeur par défaut | Description |
|---|
| cs_enabled | / | Activer le lanceur Cloud Shell | |
| cs_preferred_locations | ✅ | Emplacements pour déployer les instances Cloud Shell | |
| cs_nb_instances | ❌ | 5 | Nombre d'instances Cloud Shell à déployer |