Rotazione Proxy per Pentest: Guida Completa per Ricercatori di Sicurezza Autorizzati

Perché la Rotazione Proxy è Critica nei Pentest Autorizzati

Ogni ricercatore di sicurezza ha vissuto questo scenario: stai eseguendo una ricognizione autorizzata su un target, e improvvisamente il WAF ti blocca. Il tuo IP viene rate-limited, le risposte tornano 403 Forbidden, e l'enumerazione si ferma. Non per un problema tecnico — ma perché il tuo traffico è troppo concentrato su un singolo indirizzo.

La rotazione proxy per pentest risolve questo problema distribuendo le richieste su pool di IP residenziali reali. Invece di bombardare un target da un datacenter riconoscibile, le tue richieste arrivano da migliaia di indirizzi IP che sembrano traffico legittimo. Questo non è un trucco per aggirare le difese — è una tecnica legittima per condurre ricognizione completa all'interno di un engagement autorizzato.

Questa guida copre come i proxy residenziali per bug bounty e la scoperta di asset web con proxy si integrano nel workflow di un pentester autorizzato, con frammenti di codice pronti all'uso e un quadro legale rigoroso.

Quadro Legale: Autorizzazione Esplicita e Scope Definito

Prima di qualsiasi tecnica: nessun test di sicurezza deve essere condotto senza autorizzazione esplicita. Questo non è un suggerimento — è un requisito legale e etico assoluto.

Tipi di Autorizzazione Validi

• Programmi Bug Bounty — piattaforme come HackerOne, Bugcrowd e Intigriti definiscono scope, regole e safe harbor. Attieniti rigorosamente al programma.
• Contratti di Pentest — engagement firmati con scope, regole di ingaggio (ROE), finestre temporali e contatti di emergenza.
• Safe Harbor — alcuni programmi offrono protezione legale per ricercatori che seguono le regole. Verifica sempre la giurisdizione applicabile.

Cosa Costituisce un Violazione

• Testare asset fuori dallo scope dichiarato, anche se appartengono alla stessa organizzazione.
• Continuare a scansionare dopo che il programma ha richiesto l'interruzione.
• Accedere a dati che non sono necessari per dimostrare la vulnerabilità.
• Usare tecniche distruttive o che causano denial of service, a meno che non siano esplicitamente autorizzate.

Attenzione: Il testing non autorizzato di sistemi informatici è un reato nella maggior parte delle giurisdizioni. Le tecniche descritte in questa guida sono intese esclusivamente per l'uso all'interno di engagement con autorizzazione scritta verificabile. ProxyHat non si assume responsabilità per uso improprio.

Scoperta di Sottodomini con Proxy Residenziali

La fase di enumerazione dei sottodomini è spesso la prima dove i rate limit colpiscono. Strumenti come amass e subfinder effettuano query DNS massive, richieste a certificate transparency log, e API calls che possono innescare blocchi.

Il Problema del Traffico Concentrato

Un singolo IP che esegue migliaia di query DNS in pochi minuti è un segnale anomalo. I resolver DNS pubblici (8.8.8.8, 1.1.1.1) rate-limitano i client aggressivi. Le API di CT log possono bloccare il tuo indirizzo. I WAF dei target possono registrare e bloccare l'IP del resolver.

Distribuire queste richieste su IP residenziali geograficamente diversificati riduce drasticamente il rischio di rate limiting, permettendo una ricognizione più completa e più rapida.

Configurare Amass con Proxy HTTP

Amass supporta la configurazione di proxy upstream tramite variabili d'ambiente o file di configurazione. Ecco come integrare ProxyHat:

# Impostare il proxy HTTP per amass tramite variabile d'ambiente
export HTTP_PROXY=http://user-country-US:PASSWORD@gate.proxyhat.com:8080
export HTTPS_PROXY=http://user-country-US:PASSWORD@gate.proxyhat.com:8080

# Eseguire amass in modalità passive con distribuzione geografica
amass enum -passive -d target.com -o subdomains_passive.txt

# Per enumerazione attiva con rotazione manuale degli IP,
# eseguire in batch con sessioni sticky diverse
for i in $(seq 1 5); do
  export HTTP_PROXY=http://user-session-pentest$i-country-US:PASSWORD@gate.proxyhat.com:8080
  amass enum -brute -d target.com -o subdomains_active_batch$i.txt
done

# Unire i risultati
cat subdomains_*.txt | sort -u > all_subdomains.txt

La rotazione per sessione garantisce che ogni batch di brute-forcing utilizzi un IP residenziale diverso, riducendo la probabilità di blocchi senza sacrificare la risoluzione DNS.

Subfinder e API Multiple

Subfinder si affida a decine di API esterne. Ogni API ha il proprio rate limit. Configurare un proxy upstream permette di distribuire le chiamate:

# Configurazione subfinder con proxy
# In ~/.subfinder/provider-config.yaml, le chiavi API sono già configurate

# Eseguire con proxy per distribuire le richieste API
export HTTP_PROXY=http://user-country-US:PASSWORD@gate.proxyhat.com:8080

subfinder -d target.com -all -o subfinder_results.txt

# Per target multipli in un programma bug bounty
# con rotazione geografica per evitare pattern di traffico
for domain in $(cat scope_domains.txt); do
  export HTTP_PROXY=http://user-country-US:PASSWORD@gate.proxyhat.com:8080
  subfinder -d "$domain" -all -o "subfinder_${domain}.txt"
done

Asset Discovery e Content Discovery con Rotazione IP

Una volta identificati i sottodomini, la fase di content discovery — trovare directory, file e endpoint nascosti — è la più sensibile al rate limiting. Strumenti come ffuf e gobuster generano migliaia di richieste HTTP, e i WAF le rilevano rapidamente.

Perché i Proxy Datacenter Non Funzionano

I WAF moderni mantengono database di IP datacenter noti. Se il tuo traffico proviene da un range AWS o DigitalOcean, viene automaticamente classificato come sospetto. I proxy residenziali usano IP assegnati a ISP reali, rendendo il traffico indistinguibile da quello di un utente legittimo.

ffuf con Proxy Residenziale

ffuf supporta proxy HTTP direttamente tramite flag:

# Content discovery con ffuf tramite proxy residenziale ProxyHat
# Rotazione per-request per massima distribuzione

ffuf -u https://target.com/FUZZ \
  -w /usr/share/wordlists/seclists/Discovery/Web-Content/raft-medium-directories.txt \
  -x http://user-country-US:PASSWORD@gate.proxyhat.com:8080 \
  -t 50 \
  -rate 100 \
  -mc 200,301,302,403 \
  -o ffuf_results.json

# Per enumerazione di parametri con rotazione IP
ffuf -u "https://api.target.com/endpoint?param=FUZZ" \
  -w /usr/share/wordlists/seclists/Discovery/Web-Content/burp-parameter-names.txt \
  -x http://user-country-US:PASSWORD@gate.proxyhat.com:8080 \
  -t 30 \
  -rate 50 \
  -mc 200,403,500 \
  -o param_results.json

# Per vhost discovery — qui la rotazione è critica
# perché il target vede tutte le richieste sullo stesso IP
ffuf -u https://target.com \
  -H "Host: FUZZ.target.com" \
  -w vhost_wordlist.txt \
  -x http://user-country-US:PASSWORD@gate.proxyhat.com:8080 \
  -t 20 \
  -mc 200,403 \
  -o vhost_results.json

Il flag -rate è essenziale: anche con rotazione IP, rispettare i limiti di richiesta del target è un obbligo etico e spesso contrattuale nei programmi bug bounty.

Brute-forcing DNS con Rotazione

Il DNS brute-forcing genera un volume enorme di query. Senza distribuzione, i resolver DNS bloccano rapidamente l'IP sorgente:

• Usa dnsx con proxy per risolvere grandi liste di sottodomini
• Distribuisci le query su IP di paesi diversi per evitare pattern riconoscibili
• Imposta timeout e retry ragionevoli — non bombardare i resolver

Blending del Traffico Scanner: Burp Suite + Proxy Residenziali

Burp Suite è lo strumento centrale per la maggior parte dei pentester. Configurare un proxy residenziale upstream in Burp permette di distribuire il traffico di scanning attivo su IP diversi, riducendo il rischio di blocchi durante test autorizzati.

Configurazione Burp Suite con Proxy Upstream

1. Apri Project Options → Connections → Upstream Proxy
2. Configura l'host proxy: gate.proxyhat.com
3. Porta: 8080
4. Autenticazione: inserisci le credenziali ProxyHat nel formato user-country-US / PASSWORD
5. Per SOCKS5: usa porta 1080 e seleziona il protocollo SOCKS

Strategie di Rotazione per Burp

• Per-request rotation: ideale per lo Scanner attivo. Ogni richiesta parte da un IP diverso, simulando traffico organico distribuito.
• Sticky sessions: meglio per il testing manuale in Proxy. Mantieni la stessa sessione IP per mantenere lo stato dell'applicazione, poi ruota per il passo successivo.
• Geo-targeting: se il target ha CDN regionali, usa IP del paese pertinente per testare la configurazione specifica di quella regione.

Configurazione con FoxyProxy o SwitchyOmega

Per il testing manuale nel browser, configura un profilo proxy che instrada il traffico attraverso ProxyHat:

• Protocollo: HTTP o SOCKS5
• Host: gate.proxyhat.com
• Porta: 8080 (HTTP) o 1080 (SOCKS5)
• Autenticazione con le credenziali ProxyHat

Questo ti permette di testare manualmente le applicazioni web con IP residenziali, verificando come il target risponde a traffico che sembra provenire da utenti reali.

Etica del Rate Limiting nei Programmi Bug Bounty

I programmi bug bounty definiscono esplicitamente i limiti di richiesta accettabili. Ignorarli non è solo scortese — è una violazione delle regole del programma che può portare alla squalifica e potenzialmente a conseguenze legali.

Principi per Rate Limiting Responsabile

• Leggi sempre il policy del programma: molti programmi specificano un numero massimo di richieste per minuto o per ora.
• Usa il throttling negli strumenti: ffuf (-rate), gobuster (-t con delay), nuclei (-rate-limit).
• Non scansionare durante l'orario di picco: se possibile, programma le scansioni intensive fuori dagli orari di traffico massimo del target.
• Monitora le risposte 429: se il target risponde con 429 Too Many Requests, ferma la scansione e riduci il rate.
• La rotazione IP non sostituisce il rispetto dei limiti: distribuire il traffico su IP diversi non ti autorizza a superare i limiti complessivi del programma.

Calcolare il Rate Corretto

Se il programma permette 100 richieste/minuto e hai 5 IP in rotazione, non fare 500 richieste/minuto. Il limite è 100 per l'intero engagement, non per IP. La rotazione IP serve a evitare falsi positivi nei sistemi anti-abuse, non a moltiplicare la tua quota.

Quando il Target Non Ha Policy Esplicita

Se il programma non specifica un rate limit, adotta un approccio conservativo:

• Massimo 5-10 richieste/secondo per scansione attiva
• Pausa di almeno 1 secondo tra richieste durante testing manuale
• Fermati immediatamente se noti degrado delle performance del target

Confronto: Tipi di Proxy per Ricerca di Sicurezza

Caratteristica	Residenziali	Datacenter	Mobile
Rilevabilità WAF	Bassa — IP di ISP reali	Alta — range IP noti	Molto bassa — IP mobili reali
Velocità	Media	Alta	Bassa-media
Rotazione IP	Per-request o sticky	Limitata	Per-request naturale
Costo	Medio-alto per GB	Basso	Alto per GB
Ideale per	Content discovery, scanning distribuito	Testing ad alta velocità su target permissivi	Testing app mobile, bypass anti-bot aggressivi
Rischio di blocco	Basso	Alto	Molto basso

Per la maggior parte dei pentest con rotazione proxy, i proxy residenziali offrono il miglior equilibrio tra rilevabilità bassa e prestazioni adeguate. I proxy mobile sono ideali per target con protezioni anti-bot particolarmente aggressive, come app mobile e piattaforme di e-commerce.

Casi d'Uso Avanzati per Ricercatori Autorizzati

OSINT e Raccolta Intelligence

I proxy residenziali sono fondamentali per l'OSINT perché prevengono l'attribuzione del ricercatore al target. Quando raccogli intelligence pubblica su un'organizzazione, non vuoi che i log del target mostrino il tuo IP personale o aziendale. I proxy residenziali con rotazione garantiscono che la raccolta passiva sia anonima e distribuita.

Testing di Configurazioni CDN Regionali

Molte organizzazioni servono contenuti diversi basandosi sulla posizione geografica. Con il geo-targeting di ProxyHat, puoi testare come il target risponde da diversi paesi:

• user-country-US — testare la configurazione Nord America
• user-country-DE — verificare la conformità GDPR nell'EU
• user-country-JP — controllare le localizzazioni asiatiche

Verifica di WAF e Rate Limiting

Testare se il WAF del target implementa il rate limiting correttamente è parte legittima di un pentest autorizzato. Usando proxy residenziali, puoi verificare se il rate limiting è per-IP (facilmente aggirabile) o per-sessione/account (più robusto), e riportare questa debolezza nel tuo report.

Punti Chiave

• Autorizzazione sempre: nessuna tecnica descritta qui è applicabile senza autorizzazione esplicita e verificabile.
• La rotazione proxy previene i falsi positivi: non serve a superare i limiti del programma, ma a evitare che il WAF blocchi traffico legittimo.
• Proxy residenziali > datacenter: per la sicurezza, l'IP residenziale è indistinguibile dal traffico organico.
• Rispetta i rate limit del programma: la distribuzione su IP multipli non moltiplica la tua quota di richieste.
• Usa il throttling negli strumenti: configura sempre -rate in ffuf, -t in gobuster, e limiti simili.
• Geo-targeting per test regionali: verifica configurazioni CDN e conformità normativa da diverse giurisdizioni.
• Documenta tutto: mantieni log dettagliati di scope, autorizzazione, e richieste effettuate.

Prossimi Passi

Se sei un ricercatore di sicurezza autorizzato che cerca di condurre ricognizione completa senza innescare blocchi WAF non necessari, i proxy residenziali ProxyHat offrono l'infrastruttura necessaria. Con rotazione per-request, sessioni sticky per il testing stateful, e geo-targeting a livello di paese e città, hai il controllo granulare che il security testing professionale richiede.

Esplora i piani ProxyHat per trovare l'opzione adatta al tuo engagement, o consulta le locazioni disponibili per verificare la copertura geografica per i tuoi target. Per approfondire le tecniche di web scraping per la sicurezza, leggi la nostra guida su web scraping e sicurezza.