Vi racconteremo una storia interessante su come dei "terzi" hanno cercato di ostacolare il lavoro dei nostri clienti e come questo problema sia stato risolto.
Come tutto è cominciato
Tutto è iniziato la mattina del 31 ottobre, l'ultimo giorno del mese, quando molti avevano assolutamente bisogno di risolvere questioni urgenti e importanti.
Uno dei partner, che gestisce nel nostro cloud diverse macchine virtuali per i clienti che assiste, ha segnalato che tra le 9:10 e le 9:20 diversi server Windows sulla nostra piattaforma ucraina non accettavano connessioni del servizio di desktop remoto, impedendo agli utenti di accedere ai propri desktop, ma dopo alcuni minuti il problema sembrava essersi risolto da solo.
Abbiamo esaminato le statistiche dei canali di comunicazione, ma non abbiamo riscontrato né picchi di traffico né perdite. Abbiamo controllato anche le statistiche di carico delle risorse di calcolo – nessuna anomalia. E cos'era?
Poi un altro partner, che ospita nel nostro cloud quasi un centinaio di server, ha segnalato problemi simili riscontrati da alcuni dei loro clienti; si è scoperto che, in realtà, i server erano accessibili (rispondevano correttamente ai ping e ad altre richieste), ma il servizio di desktop remoto su questi server accettava e rifiutava le nuove connessioni in modo casuale, e si trattava di server su diverse piattaforme, con traffico proveniente da diversi canali di trasmissione dati.
Diamo un'occhiata a questo traffico. Un pacchetto con una richiesta di connessione arriva al server:
xx:xx:xx.xxxxxx IP xxx.xxx.xxx.xxx.58355 > 192.168.xxx.xxx.3389: Flags [S], seq 467744439, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
Il server riceve questo pacchetto, ma rifiuta la connessione:
xx:xx:xx.xxxxxx IP 192.168.xxx.xxx.3389 > xxx.xxx.xxx.xxx.58355: Flags [R.], seq 0, ack 467744440, win 0, length 0
Ciò significa che il problema chiaramente non era dovuto a guasti nell'infrastruttura, ma a qualcos'altro. Forse tutti gli utenti avevano problemi con la licenza dei desktop remoti? Forse un malware era riuscito a infiltrarsi nei loro sistemi, attivandosi oggi, come era successo qualche anno fa con XData e Petya?
Mentre indagavamo, abbiamo ricevuto segnalazioni simili da altri clienti e partner.
Cosa sta succedendo, in realtà, su queste macchine?
Nei registri degli eventi ci sono molti messaggi riguardanti tentativi di accesso non autorizzato:
Di solito, tali tentativi vengono registrati su tutti i server dove il servizio di desktop remoto utilizza la porta standard (3389) e consente l'accesso da ovunque. Su Internet ci sono moltissimi bot che scansiscono continuamente tutti i punti di accesso disponibili e cercano di indovinare le password (per questo motivo raccomandiamo vivamente di utilizzare password complesse invece di "123"). Tuttavia, l'intensità di questi tentativi quel giorno era davvero troppo alta.
Cosa fare?
Consigliare ai clienti di dedicare tempo a modificare le impostazioni di un gran numero di utenti finali per passare a un'altra porta? Non è una buona idea, i clienti non saranno contenti. Suggerire di consentire l'accesso solo tramite VPN? In fretta e nel panico stabilire connessioni IPSec, per coloro che non le hanno – beh, anche questo non farà felici i clienti. Anche se, va detto, in ogni caso è un'ottima pratica, e raccomandiamo sempre di nascondere il server in una rete privata e siamo pronti ad aiutare con le configurazioni; inoltre, per coloro che amano risolvere autonomamente, condividiamo guide per configurare IPSec/L2TP nel nostro cloud in modalità site-to-site o road-warrior, e se qualcuno desidera avviare un servizio VPN sul proprio server Windows – siamo sempre pronti a fornire suggerimenti su come impostare RAS o OpenVPN. Ma, per quanto siamo utili, non era il momento migliore per una campagna educativa tra i clienti, poiché era necessario risolvere rapidamente il problema con il minimo disagio per gli utenti.
La soluzione che abbiamo implementato è stata la seguente. Abbiamo configurato l'analisi del traffico in transito in modo da monitorare tutti i tentativi di stabilire una connessione TCP alla porta 3389 e selezionare gli indirizzi che, nell'arco di 150 secondi, tentano di connettersi a più di 16 server diversi nella nostra rete; questi sono le fonti dell'attacco (naturalmente, se uno dei nostri clienti o partner ha realmente bisogno di stabilire connessioni con così tanti server da una sola fonte, è sempre possibile aggiungerli alla 'lista bianca'. Tuttavia, se in una rete di classe C, in questi 150 secondi, vengono identificati più di 32 indirizzi, è opportuno bloccare l'intera rete. Il blocco viene imposto per 3 giorni e se durante questo tempo non ci sono stati attacchi da quella fonte, essa viene automaticamente rimossa dalla 'lista nera'. La lista delle fonti bloccate viene aggiornata ogni 300 secondi.
Questa lista è disponibile al seguente indirizzo: , puoi costruire le tue ACL basandoti su di essa.
Siamo pronti a condividere il codice sorgente di un tale sistema, non contiene nulla di particolarmente complesso (si tratta di alcuni semplici script, realizzati letteralmente in poche ore 'in fretta'), ed è possibile adattarlo e utilizzarlo non solo per proteggere contro tale attacco, ma anche per identificare e bloccare qualsiasi tentativo di scansione della rete:
Inoltre, abbiamo apportato alcune modifiche alle impostazioni del sistema di monitoraggio, che ora tiene d'occhio più attentamente la reazione del gruppo di controllo dei server virtuali nel nostro cloud ai tentativi di stabilire una connessione RDP: se la reazione non avviene entro un secondo, questo è motivo di attenzione.
La soluzione si è rivelata abbastanza efficace: non ci sono più lamentele né da parte dei clienti né dei partner, e nemmeno dal sistema di monitoraggio. Nuovi indirizzi e intere reti vengono regolarmente aggiunti alla 'lista nera', il che indica che l'attacco continua, ma non influisce più sul lavoro dei nostri clienti.
Un uomo da solo non può combattere
Oggi abbiamo scoperto che anche altri operatori hanno affrontato un problema simile. Alcuni credono ancora che sia Microsoft a aver apportato modifiche al codice del servizio di accesso remoto (se ti ricordi, il primo giorno abbiamo sospettato lo stesso, ma abbiamo presto scartato questa ipotesi) e promettono di fare il possibile per trovare una soluzione il prima possibile. Altri semplicemente ignorano il problema e consigliano ai clienti di proteggersi da soli (cambiando la porta di connessione, nascondendo il server in una rete privata, ecc.). Noi, il primo giorno, non solo abbiamo risolto questo problema, ma abbiamo anche creato una base per un sistema di rilevamento delle minacce più globale, che intendiamo sviluppare.
Un ringraziamento speciale va ai clienti e ai partner che non sono rimasti in silenzio e non hanno aspettato sulla riva del fiume, sperando che prima o poi passando ci sarebbe stato il cadavere del nemico, ma hanno subito attirato la nostra attenzione sul problema, permettendoci di risolverlo lo stesso giorno.
Fonte: habr.com
