Estorsione DDoS: cosa ferma davvero un attacco a un sito di annunci per adulti, e cosa non lo ferma

La mattina in cui la directory smette di caricarsi senza un motivo che riesci a trovare

Di solito comincia sempre nello stesso modo. Il sito è lento, poi non si carica più del tutto, poi torna su per dieci minuti e cade di nuovo. Il pannello di hosting non mostra niente di strano: nessun deploy fallito, nessun database al limite, nessun certificato scaduto. Un ticket di assistenza al provider riceve come risposta che dal loro lato tutto sembra a posto, il che è tecnicamente vero e completamente inutile, perché il problema non è dal loro lato, è sul filo tra internet e il loro lato.

Quello che succede davvero, nella grande maggioranza di questi casi, è un attacco di negazione del servizio distribuito: un'ondata di traffico, di solito da migliaia di dispositivi compromessi, pensata per impedire al sito di rispondere ai visitatori reali. Non è un evento raro o esotico. Il team di threat intelligence di Cloudflare ha riportato di aver mitigato circa 5.343 attacchi DDoS a livello di rete ogni ora sulla propria rete nella prima metà del 2026, una media di circa 128.000 al giorno. La maggior parte di questi attacchi è breve e piccola rispetto ai casi più estremi mai registrati: il 96,62% è rimasto sotto i 500 Mbps, e il 90,60% si è concluso in meno di dieci minuti. "Piccolo", però, è relativo: un attacco da 100 Mbps basta a mettere in ginocchio un server tipico senza protezione, una frazione di quello che si vede in una normale serata infrasettimanale contro siti di cui nessuno ha mai sentito parlare.

Il motivo di business dietro un attacco specifico conta quasi sempre meno di quanto gli operatori immaginino. Potrebbe essere una directory concorrente che cerca di mettere fuori gioco un rivale durante un weekend di traffico alto, un inserzionista bannato che si vendica con un servizio di attacco a pagamento economico, un opportunista annoiato che ha trovato il sito con una scansione casuale, o la prima mossa di un tentativo di estorsione. La risposta che protegge davvero il sito è quasi identica indipendentemente da quale sia, il che è una buona notizia, perché il motivo quasi non viene mai confermato.

Le directory di annunci sono un obiettivo più facile di quanto i loro proprietari tendano a pensare. Molte girano su un unico VPS economico scelto perché disposto ad accettare l'attività in primo luogo, con il DNS puntato direttamente su quel server perché nessuno ha pensato di fare altrimenti quando è stato impostato il dominio. I ricavi dipendono dall'uptime in un modo che un sito vetrina non conosce: ogni ora offline è un'ora di rinnovi scaduti, iscrizioni abbandonate, e inserzionisti che aprono la scheda di un concorrente invece di tornare a controllare se il sito originale si è rimesso in piedi.

La richiesta di riscatto, e perché pagarla non chiude niente

Alcuni attacchi arrivano con una richiesta allegata. Lo schema, noto nel settore della sicurezza come ransom DDoS o RDoS, di solito comincia con un breve attacco dimostrativo o una minaccia diretta per email, seguita dall'istruzione di pagare una somma, quasi sempre in criptovaluta, per fermare un attacco più grande o evitare che ne cominci uno del tutto. Gruppi costruiti esattamente su questo schema, DD4BC e la Armada Collective tra i primi, lo usano da circa il 2014, e attori più recenti ricorrono ancora alla stessa struttura perché continua a funzionare abbastanza spesso da valerne lo sforzo.

Pagare sembra la via più rapida quando ogni ora di inattività costa rinnovi reali, ed è esattamente la pressione che la richiesta è pensata per creare. Il problema è che niente nella transazione obbliga l'attaccante a fare qualcosa. Non c'è un contratto di assistenza dietro una richiesta di riscatto. Il caso più citato come avvertimento è quello di ProtonMail nel 2015, che pagò e vide gli attacchi continuare comunque, concludendo poi pubblicamente che il pagamento non aveva comprato nulla. I ricercatori di sicurezza che seguono questi gruppi riportano lo stesso schema abbastanza spesso da trattarlo come l'esito di default, non l'eccezione.

Pagare cambia anche come viene vista l'attività la volta successiva. Un obiettivo noto per pagare è un obiettivo più attraente, per lo stesso gruppo e per altri che lo scoprono tramite gli stessi mercati criminali che vendono servizi di attacco a pagamento. L'incentivo che crea va esattamente nella direzione sbagliata per un'attività che vorrebbe non vedersi ripetere la situazione.

Quello che aiuta davvero durante una richiesta attiva è noioso e procedurale: conservare il messaggio con tutte le sue intestazioni invece di limitarsi a leggerlo e cancellarlo, coinvolgere subito il team antiabuso o sicurezza del provider di hosting e della CDN, perché potrebbero già seguire lo stesso attaccante contro altri clienti, e presentare una denuncia all'unità di polizia competente per i reati informatici anche senza aspettarsi un seguito rapido, perché sono le denunce aggregate a permettere alle agenzie e ai fornitori di infrastruttura di agire, prima o poi, contro i gruppi ricorrenti. Niente di tutto questo ferma l'attacco da solo. La prossima sezione è ciò che lo ferma davvero.

Cosa ferma davvero il traffico prima che arrivi al server

La soluzione che funziona è architetturale, non negoziabile: mettere una content delivery network o un reverse proxy davanti al sito, così che il traffico d'attacco venga assorbito e filtrato ai margini della rete, attraverso la capacità globale di un fornitore, prima che arrivi al piccolo server che fa davvero girare il codice della directory. È lo stesso ruolo che una CDN già svolge per le prestazioni ordinarie, esteso a un traffico che è attivamente ostile e non solo semplicemente alto.

Il costo qui è un ostacolo minore di quanto gli operatori tendano a pensare. I grandi fornitori di CDN includono comunemente la mitigazione DDoS a livello di rete sempre attiva nel loro livello gratuito, come parte del servizio di base e non come componente a pagamento, proprio perché assorbire questo tipo di traffico su larga scala costa di meno farlo per tutti che revisionare e fatturare ogni attacco singolarmente. La protezione di base di cui una directory di annunci ha bisogno è spesso già disponibile senza costi aggiuntivi. Il problema quasi mai è il prezzo. È la configurazione.

L'errore di configurazione più comune è lasciare scoperto l'indirizzo IP reale del server d'origine anche dopo aver messo una CDN davanti al dominio principale. Un record del server di posta, un vecchio sottodominio di staging, un pannello di amministrazione sul proprio hostname, o un record DNS che nessuno si è ricordato di aggiornare quando è stata impostata la CDN possono ancora puntare direttamente all'origine. Un attaccante che trova quell'IP, spesso con nulla di più sofisticato di una ricerca nella storia DNS passiva, attacca direttamente il server vero e passa dritto oltre la CDN che avrebbe dovuto proteggerlo. La soluzione è un controllo completo di ogni record DNS del dominio, verificando che ognuno sia instradato attraverso la CDN oppure non debba davvero essere pubblico, e trattare poi l'IP d'origine come qualcosa da nascondere attivamente, non un dettaglio di sfondo a cui nessuno pensa più dopo il giorno della configurazione.

Questo assetto va testato prima di un attacco, non durante. Un operatore che non ha mai verificato davvero che ogni record sia instradato attraverso la CDN, o che non sa a memoria verso quale seconda CDN si sposterebbe l'attività se quella attuale andasse giù, scopre le lacune nel momento peggiore possibile. Ripassare la configurazione una volta, in un pomeriggio tranquillo, costa un'ora. Scoprire una lacuna nel mezzo di un attacco costa molto di più.

Scegliere un fornitore che vuole davvero tenersi l'account

Non tutti i fornitori di CDN o anti-DDoS trattano i contenuti per adulti legali nello stesso modo, e vale la pena verificarlo prima di costruire un assetto attorno a uno, non dopo. Alcuni dei più grandi fornitori di infrastruttura gestiscono il proprio servizio di sicurezza e instradamento del traffico in modo davvero neutrale rispetto ai contenuti, servendo quasi qualsiasi materiale legale senza isolare per categoria i contenuti per adulti, il che è parte del motivo per cui di tanto in tanto attirano critiche pubbliche per la manciata di siti che finiscono per proteggere. Altri scrivono un divieto netto su materiale "osceno o pornografico" direttamente nella loro acceptable use policy standard, lo stesso tipo di clausola che compare nei contratti di hosting e di registrazione dei domini per questa categoria. La reputazione di un fornitore come orientato alla sicurezza piuttosto che ai contenuti non dice a un operatore in quale categoria rientri; solo leggere la politica effettiva lo dice.

È la stessa discrezionalità che già governa se un host, una CDN o un registrar decidono che un'attività di annunci non è benvenuta sulla loro infrastruttura, un livello più vicino alla domanda specifica della mitigazione DDoS piuttosto che all'hosting in generale. Un fornitore che accetta l'account oggi sotto una clausola vaga o non ancora messa alla prova può comunque agire su quella clausola più avanti, e un operatore che scopre solo dopo un avviso di chiusura con quale tipo di fornitore ha a che fare ha già perso la possibilità di scegliere con calma un'alternativa.

Il controllo pratico è semplice e richiede pochi minuti: cercare nella acceptable use policy o nei termini di servizio del fornitore le parole adult, pornographic, obscene ed escort prima di firmare, invece di assumere che un fornitore di sicurezza sia neutrale per definizione solo perché non è un processore di pagamento o una banca. Se la politica è silenziosa, quel silenzio non è comunque una garanzia, solo una clausola che nessuno ha ancora messo alla prova. Tenere a mente un secondo fornitore, e un assetto DNS che possa puntare verso di lui in un'ora e non in un giorno, conta qui esattamente come conta per l'hosting in generale.

Quanto costa davvero un blackout una volta finito

Anche un attacco mitigato rapidamente lascia costi che emergono dopo che il traffico si è fermato. Un sito instabile per qualche ora, piuttosto che completamente giù, può comunque rompere i processi silenziosi di sfondo che tengono in piedi un'attività ad abbonamento: un circuito di carte che cerca di raggiungere un webhook di fatturazione durante un'interruzione intermittente si comporta come un tentativo di rinnovo che non arriva mai al circuito della carta, e l'inserzionista dall'altra parte vede solo una carta rifiutata, senza idea che la causa reale fosse un attacco che non aveva niente a che fare con lui.

I motori di ricerca sono altrettanto spietati nel distinguere tra "sotto attacco" e "fuori attività". Un dominio irraggiungibile per un tratto prolungato viene trattato da un crawler allo stesso modo in cui verrebbe trattato in entrambi i casi, e le pagine che si posizionavano bene prima dell'interruzione non tornano necessariamente alla stessa posizione una volta che il sito è di nuovo su, aggiungendo un secondo costo più lento sopra le ore effettivamente perse.

Un avviso breve e chiaro agli inserzionisti non costa niente e previene un esito peggiore dell'attacco stesso: un inserzionista che vede errori intermittenti senza spiegazione tende a pensare che l'attività sia silenziosamente fallita e comincia a guardare un concorrente, mentre lo stesso inserzionista, informato chiaramente che il sito è sotto attacco, che la fatturazione è in pausa durante l'interruzione e che il servizio tornerà entro una finestra indicata, in genere aspetta invece di andarsene.

La versione utile di questo articolo è quella letta prima che succeda tutto questo, non durante. Verifica, oggi, che ogni record DNS che punta al sito sia instradato attraverso una CDN invece di esporre direttamente l'origine. Verifica che la mitigazione DDoS di livello base della CDN sia davvero attivata e non solo presunta tale, perché alcuni fornitori la lasciano disattivata di default su certi piani. Scrivi, in un posto che sopravviva al sito principale che va giù, i contatti reali di assistenza e antiabuso dell'host e della CDN, con i numeri di account accanto. Niente di tutto questo è costoso o tecnico al punto da richiedere uno specialista. Deve solo succedere prima che arrivi la prima richiesta, perché non esiste una versione di questo problema che diventi più facile da risolvere mentre sta già succedendo.