Incidente Yandex Cloud: i bot si sono trasferiti ad altri host in 24 ore. Cosa significa per il parsing

Dal 8 all'11 ottobre 2026, Yandex ha perso tre data center: Sasovo e Vladimir si sono fermati completamente, Kaluga ha lavorato con degrado. Yandex Cloud è passato in modalità di emergenza e ha direttamente consigliato ai clienti di attivare i propri piani di ripristino di emergenza. La cosa più interessante è successa dopo. Cloudflare ha analizzato cosa è successo ai bot che vivevano in quel cloud e ha visto: non sono scomparsi, ma in un giorno si sono trasferiti ad altri host. E sono rimasti riconoscibili dallo stesso fingerprint TLS JA4. Per tutti coloro che si occupano di scraping e automazione, questo è un raro esperimento naturale su due questioni: cosa fare quando l'infrastruttura crolla e perché il cambio di IP e hosting non cambia l'"identità" del bot.

Cosa è successo a Yandex

Secondo BleepingComputer, Yandex ha segnalato danni a tre data center a causa di attacchi di droni. Yandex non ha nominato il colpevole; i media, citando la BBC, collegano gli attacchi all'Ucraina. La cronologia è la seguente:

• 8 ottobre — Sasovo (regione di Riazan): incendio, il sito è stato completamente fermato;
• 9 ottobre — Kaluga: lavoro con degrado, non fermo totale;
• 11 ottobre — Vladimir: fermato completamente.

Alla pagina di stato di Yandex Cloud, parte dei servizi (console, API, IAM, database, S3, Kubernetes) è rimasta accessibile con problemi di prestazioni, Compute e AI Studio hanno lavorato parzialmente. L'azienda ha dichiarato di non poter fornire tempistiche affidabili per il ripristino, considera la configurazione rimanente delle risorse instabile e consiglia ai clienti di utilizzare piani alternativi di ripristino di emergenza. Non c'erano tempistiche di ripristino e chiarezza sulla possibile perdita di dati al momento della pubblicazione di BleepingComputer (12 ottobre).

Cosa ha visto Cloudflare: il traffico è calato, i bot no

Il 14 ottobre Cloudflare ha pubblicato un'analisi dell'incidente dalla sua rete. I numeri chiave:

• l'11 ottobre il traffico dalla rete di Yandex Search (AS13238) è calato del 99% rispetto alla norma, da Yandex.Cloud (AS200350) — del 90%;
• il 99,5% delle richieste da AS13238 prima dell'incidente erano automatiche, di cui il 93,6% delle richieste bot erano crawler verificati di Yandex. Questa rete forniva circa il 7% di tutte le richieste bot da IP russi;
• in Yandex.Cloud circa il 95% delle richieste stimate erano bot, e nessuna di esse era verificata. Questo rappresenta circa il 2% del traffico bot russo;
• il traffico bot da Yandex.Cloud è diminuito di circa il 40%, la scansione dei plugin di WordPress da questa rete — del 90%.

Ma poi arriva il punto principale. Quasi tutte le richieste bot da Yandex.Cloud erano dirette a un account cliente di Cloudflare nel settore del gioco d'azzardo. Subito dopo il guasto dell'8 ottobre, le richieste da Yandex.Cloud a quel cliente sono scese a zero — e subito dopo sono apparse richieste identiche da reti di altri host russi, Radist e Selectel. Con lo stesso fingerprint JA4 TLS, gli stessi percorsi e intestazioni rari e le stesse stringhe User-Agent non standard. Il risultato dopo una settimana: il traffico bot russo verso gli account di gioco d'azzardo non è diminuito, ma è aumentato — da 167,7 a 170,1 milioni di richieste (+1,4%).

La conclusione di Cloudflare è stata netta: l'infrastruttura fisica è statica, mentre l'automazione dannosa è costruita per spostarsi. La diminuzione del volume del traffico HTTP indica un incidente, ma non significa che i bot si siano fermati.

Versione rumorosa e dati: perché "i bot si sono zittiti" si è rivelato un'esagerazione

Parallelamente, il Centro ucraino di controinformazione (ЦПД) ha dichiarato che dopo l'attacco a Sasovo il numero di segnalazioni di account sospetti su Facebook e Telegram è calato dell'83,6% — da 4.032 a 660. Ma, come ha analizzato TechRadar, già il 10 ottobre l'attività è tornata a 4.585 segnalazioni, e l'11 ottobre ha superato il livello pre-attacco. Cloudflare non ha trovato uno spostamento significativo: il traffico bot da IP russi verso gli endpoint "post, risposta, like" di un social network è diminuito solo del 5,7%. Anche Graphika non ha visto perdite di account attivi nelle comunità monitorate. La ricercatrice Renée DiResta in Lawfare ha definito la storia affascinante, ma più simile a una finzione che a un fatto.

Una lezione separata per gli analisti: l'8 ottobre in tutta la Russia hanno avuto problemi banche, retail, operatori e media, quindi qualsiasi calo di "attività" in quel giorno non può essere attribuito senza riserve ai bot. Il traffico aggregato può facilmente fuorviare.

Lezione prima: IP e hosting non sono l'identità del bot

Cloudflare ha riconosciuto il legame "Yandex.Cloud → Radist/Selectel" non dagli indirizzi — gli indirizzi e ASN sono cambiati completamente. L'ha riconosciuto dal comportamento e dal fingerprint del client:

• JA4 — hash TLS ClientHello: insieme di cifrari, estensioni, versioni del protocollo. Descrive il programma, non la rete. Lo stesso script Python su un nuovo server dà lo stesso JA4;
• percorsi e intestazioni rari — ordine e insieme di intestazioni HTTP che non si trovano nei normali browser;
• User-Agent personalizzato — stringa unica che funge da etichetta.

Conclusione pratica per lo scraping legittimo: cambiare data center o pool di IP non ti rende "nuovo" per un anti-bot, se l'intero stack client rimane lo stesso. E viceversa: se il tuo crawler si presenta onestamente, si comporta in modo accurato e non colpisce endpoint sensibili, un fingerprint stabile non è un problema. Il problema sorge quando lo stack appare come qualcosa che non si trova tra gli utenti reali: un Chrome dichiarato con un fingerprint TLS della libreria requests, un UA esotico, intestazioni non standard. Abbiamo scritto in dettaglio su come funziona questo strato di rilevamento nella nostra analisi JA4 e TLS fingerprinting nello scraping.

Notate un altro dettaglio: i bot si sono trasferiti da un data center ad altri data center. Per Cloudflare, si tratta sempre della stessa categoria di ASN di hosting, a cui molti siti hanno un pregiudizio di sfiducia. La rete è diversa — il profilo di rischio è lo stesso.

Lezione seconda: l'infrastruttura deve poter essere trasferita in poche ore

Gli aggressori si sono trasferiti in un giorno perché la loro automazione è intrinsecamente portatile. Anche i team onesti che raccolgono prezzi, monitorano i risultati o conducono analisi hanno bisogno di questa portabilità non meno. La raccomandazione di Yandex Cloud "utilizzare piani alternativi di ripristino di emergenza" è valida solo se un piano del genere esiste già. Ecco un minimo di checklist:

1. Codice e configurazioni — fuori dal cloud. Il repository, le immagini dei container, le variabili d'ambiente devono essere organizzati in modo da poter distribuire il parser su un altro host con un solo comando.
2. Secondo host in anticipo. Un account, pagamento e server di test presso un fornitore alternativo in un'altra giurisdizione e regione. Registrarsi e passare la verifica il giorno dell'incidente è troppo tardi.
3. Layer di uscita separato dai calcoli. Se le richieste ai siti target passano attraverso un provider di proxy, e non direttamente dall'IP del server, il trasferimento dei calcoli non cambia né la geo né il tipo di IP, né la storia delle sessioni. Il server può essere trasferito, ma per il sito rimani lo stesso cliente.
4. Dati e code — con replica. I risultati dello scraping e lo stato dei task vengono copiati in un altro storage, altrimenti dopo un incidente dovrai ricominciare da capo.
5. Provider di riserva — davvero diverso. L'hosting di riserva o il provider di proxy non devono rivelarsi la stessa infrastruttura sotto un altro marchio. Come verificare se un proxy è lo stesso, lo abbiamo analizzato nel materiale su perché un provider di proxy di riserva può rivelarsi lo stesso pool.
6. Allerta di addestramento. Una volta al trimestre, avvia il parser su un sito di riserva e esegui un task reale. Un piano che non è mai stato eseguito di solito non funziona nella pratica.

Quale tipo di proxy risolve cosa in questa situazione

I proxy non salvano da un cattivo fingerprint — questo è evidente dall'esempio dell'analisi di Cloudflare. Tuttavia, scollegano "il volto" delle tue richieste da dove il codice gira fisicamente:

• Proxy residenziali — per siti dove gli ASN di hosting vengono bloccati in anticipo o ricevono captcha. Durante il trasferimento del server, l'uscita rimane su IP domestici del paese desiderato.
• Proxy di data center — per API e siti leali, dove la velocità e il prezzo sono importanti. Anche questi dovrebbero essere mantenuti presso un fornitore indipendente dal tuo cloud, affinché un incidente di hosting non porti via anche gli IP di uscita.

Inoltre, i proxy sono solo uno strato. Se lo stack TLS, le intestazioni e il comportamento del tuo client si distinguono, verranno riconosciuti su qualsiasi IP, proprio come sono stati riconosciuti i bot trasferitisi a Radist e Selectel.

Cosa significa questo per i proprietari di siti

Cloudflare trae anche una conclusione opposta: ASN e volume di traffico sono indicatori inaffidabili di un bot. Il blocco di una rete "cattiva" funziona fino al primo trasferimento. È più affidabile osservare il comportamento: fingerprint JA4 comuni tra diverse reti, frequenze anomale di richieste e regole WAF su endpoint sensibili, indipendentemente da dove provenga la richiesta. C'è anche un rovescio della medaglia: il 40,5% dei clienti di Cloudflare ha risposto al crawler di Yandex con codice 403, e il traffico dalle reti di Yandex verso i siti di notizie durante l'incidente è diminuito del 44% — il che significa che la legittima indicizzazione ha subito principalmente danni.

Conclusione

Il guasto di Yandex è stata una verifica vivente di due semplici verità. Prima: l'infrastruttura può scomparire in un giorno, e vince chi sa trasferirla in poche ore — con codice fuori dal cloud, un secondo host e uno strato di uscita non legato al server. Seconda: per un anti-bot tu sei il tuo stack client, non il tuo IP. Un nuovo data center con lo stesso JA4 e lo stesso User-Agent è lo stesso bot a un nuovo indirizzo. Progetta lo scraping in modo che possa sopportare il cambio di piattaforma e sembrare comunque accurato su qualsiasi IP.