Traffico di bot dopo gli attacchi ai data center Yandex

Traffico di bot dopo gli attacchi ai data center Yandex

Osservazione qualitativa dei nostri operatori, non una misurazione. Dopo gli attacchi segnalati ai data center Yandex, chi legge i log dei server DCXV ha avuto l'impressione che il traffico di alcune reti di bot farm si fosse ridotto: meno richieste automatiche, meno tentativi di forza bruta, meno richieste HTTP POST sospette. Non pubblichiamo conteggi, percentuali, grafici né frequenze, perché non abbiamo fatto un confronto controllato. L'articolo spiega cosa guardiamo, come appaiono questi tipi di traffico nei log, come rinforzare un server qualunque sia l'origine e come verificare l'affermazione da soli.

Cosa è stato segnalato

A inizio ottobre Reuters ha riferito che droni hanno colpito data center Yandex in due giorni consecutivi, e Yandex ha dichiarato che diversi moduli della sua sede nella regione di Kaluga sono stati messi fuori uso e che alcuni servizi potrebbero avere disservizi (articolo Reuters su The Star). Non abbiamo confermato questi fatti in proprio e non prendiamo posizione su chi sia il responsabile. Questo articolo riguarda solo traffico e igiene dei server. Per il rischio lato fornitore vedi hosting con Yandex e in regioni ad alto rischio.

Cosa abbiamo guardato

Gli operatori DCXV leggono quattro fonti: log del web server e del WAF, log di autenticazione SSH, accessi ai nostri percorsi honeypot (URL che nessun visitatore reale apre) e il registro degli errori HTTP. Li seguono nel tempo come parte del lavoro normale. Non c'era una finestra fissa prima e dopo, né una baseline, né un gruppo di controllo. Quanto segue è l'impressione di persone che sanno come di solito appaiono questi log, niente di più forte.

Come appaiono questi tipi di traffico nei log

Contano tre schemi. Tutti gli esempi sono illustrativi: gli indirizzi vengono da intervalli di documentazione e i timestamp sono segnaposto.

• Richieste automatiche - gli stessi percorsi a ritmo serrato con uno user agent generico o vuoto, spesso a caccia di pannelli di amministrazione e vecchi script.
• Tentativi di forza bruta - molti login falliti con nomi diversi da una sola origine, o un solo nome provato da molte origini.
• Richieste POST sospette - POST ripetuti verso login, XML-RPC o form, di solito con risposta 200 o 401 e senza una visita alla pagina prima.

Righe di esempio (illustrative, non traffico reale):

sshd[1234]: Failed password for invalid user admin from 203.0.113.7 port 51234 ssh2
sshd[1235]: Failed password for invalid user test from 203.0.113.7 port 51240 ssh2
203.0.113.9 - - [DD/Mon/YYYY:hh:mm:ss +0000] "POST /wp-login.php HTTP/1.1" 200 5120 "-" "Mozilla/5.0"
203.0.113.9 - - [DD/Mon/YYYY:hh:mm:ss +0000] "POST /xmlrpc.php HTTP/1.1" 200 420 "-" "Mozilla/5.0"

Checklist di hardening valida per qualsiasi origine

Nessun passaggio dipende da dove arriva il client. Seguili in quest'ordine e tieni aperta una seconda sessione SSH mentre modifichi sshd, così un errore di battitura non ti chiude fuori. Più sulle chiavi nella nostra guida SSH per un nuovo server cloud.

1. SSH solo con chiave. Disattiva le password e il login root con password, poi verifica la configurazione prima del reload:

# /etc/ssh/sshd_config.d/10-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
MaxAuthTries 3
LoginGraceTime 20

sudo sshd -t && sudo systemctl reload ssh

2. fail2ban per sshd. Blocca una fonte dopo pochi fallimenti:

# /etc/fail2ban/jail.d/sshd.local
[sshd]
enabled = true
maxretry = 4
findtime = 10m
bantime = 1h

3. Rate limit sugli endpoint di login in nginx. Rallenta uno script senza disturbare una persona:

# http {} context
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

# server {} context
location = /login {
    limit_req zone=login burst=5 nodelay;
    limit_req_status 429;
    proxy_pass http://127.0.0.1:3000;
}

• Regole WAF - blocca percorsi di sondaggio noti e body POST troppo grandi o malformati; inizia in sola modalità log, poi applica.
• Protezione degli endpoint POST - richiedi un token CSRF, limita la dimensione del body, restituisci lo stesso errore per utente sbagliato e password sbagliata.
• CAPTCHA o challenge - mostralo solo dopo alcuni fallimenti, non a ogni visitatore.
• Monitoraggio e alert - avvisa su un salto di login falliti o di 4xx su POST e rivedi ogni settimana le fonti principali.

Perché bloccare un paese da solo è un controllo debole

La geolocalizzazione IP è una stima. VPN, proxy e server affittati portano un bot in qualsiasi paese, e una botnet di router domestici dirottati si trova dove stanno quei router. Un blocco per paese ferma anche clienti reali, viaggiatori e partner. Può essere un livello economico tra altri, ma non sostituisce SSH solo con chiave, rate limit e WAF, e invecchia male quando il traffico passa ad altre reti.

Come verificare l'affermazione sui tuoi server

Se vuoi prove invece di impressioni, fissa le regole prima di guardare i dati:

• Fissa le finestre - scegli periodi uguali prima e dopo, con gli stessi giorni della settimana, prima di aprire qualsiasi log.
• Filtri identici - stessi file di log, stessa regola di conteggio, stessi blocchi e limiti in entrambi i periodi.
• Prendi una baseline - confronta con un periodo tranquillo più lungo, perché le campagne vanno e vengono senza eventi esterni.
• Raggruppa per rete, non per paese - conta per rete di origine e annota a parte gli intervalli affittati o proxy.
• Annota i tuoi cambiamenti - una nuova regola firewall o un sito spostato può sembrare una tendenza.

Due punti di partenza da eseguire su ogni finestra con gli stessi filtri:

sudo journalctl -u ssh --since "24 hours ago" --no-pager | \
  grep "Failed password" | \
  awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head

awk '$6 == "\"POST"' /var/log/nginx/access.log | \
  awk '{print $7}' | sort | uniq -c | sort -rn | head

Limiti della nostra osservazione

Leggi questo come un'ipotesi di un operatore, non come un risultato:

• Correlazione non è causalità - due fatti vicini nel tempo non sono per forza collegati.
• L'attribuzione è imperfetta - geolocalizzazione IP e dati ASN confondono VPN, proxy, infrastruttura affittata e botnet di altri paesi.
• Il traffico si sposta - i bot possono essere passati ad altre reti; meno da un luogo non significa meno in totale.
• Una rete non è internet - vediamo solo ciò che arriva ai nostri server.
• Può essere temporaneo, e altre cause sono possibili: blocchi altrove, stagionalità, campagne concluse o il nostro filtraggio.

Prossimi passi

Parti da SSH solo con chiave e da un rate limit sul login: bastano pochi minuti e aiuta contro ogni origine. Se ti serve un server pulito per applicare questa checklist, guarda i nostri server cloud a Praga e Covilhã, e usa la checklist per la prova per testarne uno bene. Domande o osservazioni tue: sales@dcxv.com.