Rotation de proxies pour pentest et bug bounty : guide complet

Pourquoi la rotation de proxies est essentielle en pentest autorisé

Vous lancez amass sur un scope de bug bounty, et au bout de 200 requêtes DNS, le WAF de la cible vous bloque. Votre IP datacenter est flaguée, vos requêtes suivantes tombent en 403, et votre fenêtre de test se réduit à néant. Ce scénario, chaque pentester l'a vécu. La rotation de proxies pour pentest n'est pas un luxe — c'est la différence entre un engagement productif et un engagement bloqué.

Les proxies résidentiels permettent de distribuer votre trafic de reconnaissance sur des milliers d'IPs réelles, rendant chaque requête indiscernable du trafic légitime. Mais cette puissance impose une responsabilité : chaque requête doit rester dans le périmètre autorisé. Ce guide s'adresse exclusivement aux chercheurs en sécurité opérant dans un cadre légal — bug bounty, pentest contractuel, ou programme de safe harbor.

Avertissement légal : L'utilisation de techniques décrites ici en dehors d'un périmètre explicitement autorisé constitue une infraction pénale dans la plupart des juridictions. Testez uniquement sur des scopes validés par un programme de bug bounty, un contrat de pentest signé, ou une autorisation écrite du propriétaire. ProxyHat ne tolère ni ne facilite l'accès non autorisé à des systèmes.

Cadre légal et périmètre d'autorisation

Bug bounty et safe harbor

Les programmes de bug bounty (HackerOne, Bugcrowd, Intigriti) définissent un scope explicite — domaines, sous-domaines, types de vulnérabilités autorisés. Le concept de safe harbor vous protège juridiquement tant que vous restez dans ce périmètre. En sortir, même avec de bonnes intentions, vous expose à des poursuites.

Avant de configurer un proxy rotatif, vérifiez :

• Le scope technique : quels domaines/sous-domaines sont inclus ?
• Les limites de taux : de nombreux programmes spécifient un plafond de requêtes (ex. 100 req/min)
• Les exclusions : certains programmes interdisent le scanning automatisé ou l'OSINT passif hors scope
• Les règles de divulgation : comment rapporter les trouvailles

Contrats de pentest

Un contrat de pentest signé définit :

• Les cibles exactes (IPs, domaines, applications)
• La fenêtre temporelle
• Les types de tests autorisés (black box, grey box)
• Les règles d'engagement (DoS interdit, exfiltration de données limitée)

Gardez votre contrat accessible pendant l'engagement. Si un doute survient sur une cible, ne testez pas — demandez une clarification au client.

Découverte de sous-domaines distribuée avec proxies résidentiels

L'énumération de sous-domaines est la première étape de la reconnaissance. Les outils comme amass et subfinder interrogent des dizaines de sources publiques (certificats TLS, DNS passifs, moteurs de recherche). Le problème : ces sources elles-mêmes limitent les requêtes, et les résolveurs DNS des cibles peuvent bloquer les IPs de scanning connues.

Configuration d'amass avec proxy rotatif

Amass ne supporte pas nativement les proxies HTTP pour ses requêtes OSINT, mais vous pouvez utiliser proxychains pour acheminer tout le trafic via votre proxy résidentiel :

Installez et configurez proxychains :

# /etc/proxychains4.conf
[ProxyList]
http gate.proxyhat.com 8080 user-country-US YOUR_PASSWORD

Puis lancez amass à travers le tunnel :

# Énumération passive distribuée via proxy résidentiel
proxychains4 amass enum -passive -d example.com -o subs_passive.txt

# Pour une rotation par requête, utilisez le flag de session unique
# ProxyHat attribue une nouvelle IP résidentielle à chaque session
# Format username : user-session-$RANDOM
for i in $(seq 1 20); do
  SESS="$(head /dev/urandom | tr -dc a-z0-9 | head -c 12)"
  proxychains4 -q amass enum -passive \
    -d example.com \
    -o subs_batch_${i}.txt &
done
wait
cat subs_batch_*.txt | sort -u > subs_all.txt

Avec ProxyHat, chaque identifiant de session unique (user-session-abc123) obtient une IP résidentielle différente. En variant les sessions entre les lots, vous distribuez vos requêtes sur un large éventail d'IPs, évitant les blocages de rate-limit côté sources OSINT.

Subfinder avec rotation d'IP

Subfinder supporte les proxies via variable d'environnement :

# Export du proxy pour subfinder
export HTTP_PROXY=http://user-country-US:PASSWORD@gate.proxyhat.com:8080
export HTTPS_PROXY=http://user-country-US:PASSWORD@gate.proxyhat.com:8080

# Lancer l'énumération
subfinder -d example.com -all -o subfinder_results.txt

Pour les cibles sensibles (WAF agressif type Cloudflare), alternez les pays de géo-ciblage pour simuler un trafic organique diversifié :

• user-country-US — trafic américain
• user-country-DE — trafic allemand
• user-country-JP — trafic japonais

Découverte d'assets et brute-forcing de contenu

Une fois les sous-domaines collectés, la deuxième phase est la découverte de contenu — répertoires cachés, endpoints API, fichiers de configuration. Les outils comme ffuf et gobuster sont les standards, mais leur trafic burst est immédiatement flagrant pour les WAF.

Pourquoi les IPs datacenter échouent

Les WAF modernes (Cloudflare, Akamai, Imperva) maintiennent des listes d'IPs datacenter connues. Une rafale de 500 requêtes depuis une IP OVH ou DigitalOcean est bloquée en quelques secondes. Les IPs résidentielles, en revanche, sont indiscernables des utilisateurs légitimes — parce qu'elles sont des utilisateurs légitimes.

ffuf avec proxy rotatif ProxyHat

ffuf supporte les proxies nativement via le flag -x :

# Découverte de contenu avec rotation d'IP résidentielle
# Chaque session = nouvelle IP, rotation automatique
ffuf -u https://target.example.com/FUZZ \
  -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt \
  -x http://user-country-US:PASSWORD@gate.proxyhat.com:8080 \
  -rate 50 \
  -mc 200,301,302,403 \
  -o ffuf_results.json

# Pour une rotation par requête (sticky session courte),
# utilisez le format session dans le username :
ffuf -u https://target.example.com/FUZZ \
  -w /usr/share/seclists/Discovery/Web-Content/common.txt \
  -x http://user-session-RANDOM1:PASSWORD@gate.proxyhat.com:8080 \
  -rate 30 \
  -mc all -fc 404

Le paramètre -rate 50 limite à 50 requêtes par seconde — un rythme raisonnable qui respecte la plupart des plafonds de bug bounty tout en restant efficace.

Brute-forcing DNS distribué

Pour le DNS brute-forcing, distribuez les requêtes sur plusieurs sessions proxy :

# Script de DNS brute-forcing distribué
#!/bin/bash
DOMAIN="example.com"
WORDLIST="subdomains-top1million-110000.txt"
PROXY_USER="user-country-US"
PROXY_PASS="YOUR_PASSWORD"

split -l 5000 $WORDLIST chunk_

for chunk in chunk_*; do
  SESS="$(head /dev/urandom | tr -dc a-z0-9 | head -c 10)"
  ffuf -u https://$DOMAIN -H "Host: FUZZ.$DOMAIN" \
    -w $chunk \
    -x http://${PROXY_USER}-session-${SESS}:${PROXY_PASS}@gate.proxyhat.com:8080 \
    -rate 20 \
    -mc 200,301,302,403 \
    -o dns_${chunk}.json &
done
wait

# Agréger les résultats
cat dns_chunk_*.json | jq -r '.results[].input' | sort -u > active_subs.txt
rm chunk_* dns_chunk_*

Camouflage du trafic de scanner avec Burp Suite

Burp Suite est l'outil central de tout pentester web. Configurer un proxy résidentiel en amont permet de :

• Masquer votre IP réelle pendant les tests manuels
• Distribuer le trafic du scanner automatique de Burp
• Éviter le blocage lors de l'exploration prolongée d'une application

Configuration Burp Suite + proxy résidentiel

Dans Burp Suite Professional/Community :

1. Accédez à Project Options → Connections → Upstream Proxy Servers
2. Ajoutez une règle pour toutes les destinations (*)
3. Configurez : hôte gate.proxyhat.com, port 8080, authentification Basic avec votre username/password ProxyHat
4. Pour la rotation, utilisez un username avec session : user-country-US-session-burp1

Pour le scanning automatisé, créez plusieurs règles upstream avec des sessions différentes, et alternez-les manuellement ou via l'API Burp :

Paramètre	Valeur	Notes
Proxy hôte	gate.proxyhat.com	Gateway ProxyHat
Port HTTP	8080	Proxy HTTP par défaut
Port SOCKS5	1080	Pour les outils supportant SOCKS
Username (rotation)	user-session-$ID	Chaque session = IP différente
Username (géo-ciblage)	user-country-US	Simule le trafic US
Username (ville)	user-country-DE-city-berlin	Ciblage ville-level

Scanner Burp : limiter le débit

Le scanner Burp peut générer des milliers de requêtes en quelques minutes. Configurez les limites dans Intruder → Resource Pool :

• Maximum concurrent requests : 5-10
• Delay between requests : 100-500ms
• Utilisez un resource pool dédié pour les scans en scope bug bounty

Proxy résidentiel vs datacenter vs mobile pour le pentest

Chaque type de proxy a un rôle dans un engagement de sécurité :

Critère	Résidentiel	Datacenter	Mobile
Discrétion WAF	★★★★★	★★	★★★★★
Vitesse	★★★	★★★★★	★★
Coût	★★★	★★★★★	★★
Rotation IP	Automatique	Manuelle	Automatique
Cas d'usage principal	Recon, scanning, OSINT	Brute-force rapide, fuzzing	Mobile API testing
Détection par cible	Très faible	Élevée	Quasi nulle

En pratique, l'approche hybride est optimale : résidentiel pour la reconnaissance et l'OSINT, datacenter pour les phases de fuzzing intensif où la vitesse prime, mobile pour les APIs et applications mobiles dans le scope.

Étiquette du rate-limit : respecter les plafonds du scope

Les programmes de bug bounty sérieux spécifient souvent des limites de requêtes. Les ignorer, c'est risquer l'exclusion du programme — ou pire, un impact opérationnel sur la cible.

Bonnes pratiques de rate-limiting

• Lisez les règles du programme avant de lancer un scan. Si le plafond est 100 req/min, configurez vos outils en conséquence.
• Utilisez le flag -rate de ffuf ou le throttle de Burp pour respecter les limites.
• Surveillez vos métriques : comptez les requêtes, pas seulement les réponses. Les timeouts comptent.
• Évitez les scans pendant les heures de pointe de la cible si possible — c'est une marque de professionnalisme.
• Documentez votre trafic : en cas de contestation, pouvoir montrer que vous respectiez les limites est crucial.

Calcul du débit optimal

Si le programme autorise 100 requêtes/minute :

• ffuf : -rate 1.5 (90 req/min, marge de sécurité)
• nuclei : -rl 80 (80 req/min)
• Burp Intruder : resource pool à 80 req/min avec delay de 750ms

La rotation de proxies ne vous donne pas le droit de dépasser les plafonds — elle vous permet de rester sous le radar tout en restant dans les limites.

OSINT et collecte de renseignements avec proxies résidentiels

L'OSINT (Open Source Intelligence) est par nature passive, mais les outils modernes d'OSINT font des requêtes actives qui peuvent révéler votre identité. Les proxies résidentiels sont essentiels pour :

• Éviter l'attribution : votre IP réelle ne doit jamais apparaître dans les logs de la cible
• Accéder au contenu géo-restreint : certains sites servent des versions différentes selon la localisation
• Collecter des données de certificats TLS sans être bloqué par crt.sh ou Censys
• Interroger les moteurs de recherche (SERP scraping) sans CAPTCHA

Pour en savoir plus sur l'utilisation des proxies pour le scraping web à grande échelle, consultez notre guide dédié.

Scanning de vulnérabilités distribué et tolérant aux rate-limits

Les scanners de vulnérabilités comme nuclei peuvent bénéficier de la distribution via proxies résidentiels :

# Nuclei avec proxy résidentiel
export HTTP_PROXY=http://user-country-US:PASSWORD@gate.proxyhat.com:8080
export HTTPS_PROXY=http://user-country-US:PASSWORD@gate.proxyhat.com:8080

nuclei -l subs_all.txt \
  -t cves/ -t vulnerabilities/ \
  -rl 50 \
  -o nuclei_results.txt

Pour les scans massifs, découpez votre liste de cibles et distribuez sur plusieurs sessions :

• Batch 1 : user-session-batch1-country-US
• Batch 2 : user-session-batch2-country-DE
• Batch 3 : user-session-batch3-country-GB

Cette distribution réduit la charge par IP, diminue les faux positifs liés aux blocages WAF, et simule un trafic organique mondial.

Stratégies de rotation d'IP pour le pentest

Rotation par requête

Chaque requête HTTP utilise une IP résidentielle différente. Idéal pour :

• Le fuzzing de contenu (ffuf, gobuster)
• L'énumération DNS
• Le scanning nuclei massif

Avec ProxyHat, omettez le flag session dans le username pour une rotation automatique par requête.

Sticky sessions

Maintenez la même IP pour une durée définie. Essentiel pour :

• L'authentification sur une application (maintien de session)
• Les tests d'API avec state
• L'exploration manuelle dans Burp Suite

Avec ProxyHat : user-session-mysession123 maintient la même IP tant que la session est active (jusqu'à 30 minutes).

Géo-ciblage

Testez comment l'application se comporte pour différents utilisateurs géographiques :

• user-country-US — contenu US
• user-country-DE-city-berlin — contenu allemand localisé
• user-country-JP — contenu japonais

Cela peut révéler des vulnérabilités de logique métier (prix différenciés, contenu restreint, features geo-gated).

Gestion des CAPTCHA et défis anti-bot

Même avec des proxies résidentiels, certains sites déploient des CAPTCHA pour les comportements suspects. Stratégies d'atténuation :

• Réduisez votre débit : 5-10 req/s au lieu de 50+
• Imitez le comportement humain : ajoutez des délais aléatoires entre les requêtes
• Utilisez des headers réalistes : User-Agent, Accept, Accept-Language cohérents
• Rotation de sessions : changez de session/IP toutes les 50-100 requêtes
• Respectez les CAPTCHA : ne tentez pas de les contourner, c'est souvent hors scope

Considérations éthiques et légales

Ce point mérite une section dédiée car il est non négociable :

• Ne testez jamais hors scope. Si un sous-domaine n'est pas listé dans le programme, n'y allez pas — même si votre découverte OSINT l'a identifié.
• Ne causez pas de déni de service. La rotation de proxies augmente votre capacité de requêtage, mais ce n'est pas une licence pour DDOS.
• Ne tentez pas d'accéder à des données d'autres utilisateurs au-delà du strict nécessaire pour prouver une vulnérabilité.
• Documentez tout : timestamps, nombre de requêtes, outils utilisés, configuration proxy. En cas de litige, cette documentation vous protège.
• Conformité GDPR/CCPA : si vous accédez à des données personnelles pendant un test, traitez-les conformément aux réglementations applicables.

Métriques de performance pour le pentest avec proxies

Mesurez l'efficacité de votre setup proxy :

Métrique	Cible	Comment mesurer
Taux de succès HTTP	>95%	Comptez 200/301/302 vs 403/429
Latence moyenne	<3s	Time ffuf avec -v
Blocages WAF	<2%	Ratio 403/429 sur total
Requêtes/min effectives	Conforme au scope	Compteur interne
Couverture de scope	>90%	Sous-domaines testés / découverts

Points clés à retenir

• Autorisation d'abord : jamais de test sans scope validé — bug bounty, contrat, ou autorisation écrite.
• Résidentiel > datacenter pour la reconnaissance : les IPs résidentielles évitent les blocages WAF et simulent un trafic organique.
• Rotation par session : ProxyHat attribue une IP unique par session — variez les sessions pour distribuer votre empreinte.
• Respectez les rate-limits : la rotation ne vous donne pas le droit de dépasser les plafonds du programme.
• Proxychains + vos outils : amass, subfinder, nuclei — tout peut passer par proxychains si le proxy natif n'est pas supporté.
• Documentez tout : timestamps, requêtes, configuration — votre protection légale en cas de litige.
• Géo-ciblage stratégique : testez les différences de comportement par localisation pour découvrir des vulnérabilités de logique.

Prochaines étapes

Prêt à intégrer la rotation de proxies résidentiels dans votre workflow de pentest ? Commencez par :

1. Créez votre compte sur ProxyHat et récupérez vos identifiants.
2. Configurez proxychains avec gate.proxyhat.com:8080 comme décrit ci-dessus.
3. Testez sur un scope de bug bounty à faible risque pour valider votre setup.
4. Intégrez progressivement dans votre workflow Burp Suite, ffuf, et nuclei.

Pour les cas d'usage avancés comme le SERP tracking ou la surveillance de prix e-commerce, consultez nos guides spécialisés. Et pour explorer l'ensemble de nos localisations proxy, visitez notre page locations.