Ti racconteremo una storia interessante su come 'terze parti' hanno tentato di ostacolare il lavoro dei nostri clienti e come questo problema è stato risolto.
Come è tutto iniziato
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 di cui si occupa, ha segnalato che dalle 9:10 alle 9:20 diversi server Windows, operanti sulla nostra piattaforma ucraina, non accettavano connessioni al servizio di accesso remoto, gli utenti non riuscivano ad accedere ai loro desktop, ma dopo qualche minuto il problema sembrava essersi risolto da solo.
Abbiamo controllato le statistiche dei canali di comunicazione, ma non abbiamo riscontrato né picchi di traffico né cali. Abbiamo esaminato le statistiche di carico delle risorse di calcolo - nessuna anomalia. E che cos'era?
Poi un altro partner, che ospita nel nostro cloud quasi un centinaio di server, ha riferito di problemi simili, segnalati da alcuni dei loro clienti. È emerso che, in generale, i server erano accessibili (rispondevano correttamente ai test ping e ad altre richieste), ma il servizio di accesso remoto su questi server accettava talvolta nuove connessioni e talvolta le rifiutava, a fronte di server situati su diverse piattaforme, il cui traffico proveniva 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
Questo significa che il problema non è affatto causato da malfunzionamenti nell'infrastruttura, ma da qualcos'altro. Forse tutti gli utenti hanno avuto problemi con la licenza degli accessi remoti? Forse qualcosa di malevolo è riuscito a infiltrarsi nei loro sistemi, e oggi si è attivato, proprio come era successo un paio di anni fa con XData e Petya?
Nel frattempo, abbiamo ricevuto segnalazioni simili da altri clienti e partner.
E cosa sta succedendo effettivamente su queste macchine?
Nei registri degli eventi ci sono molti messaggi riguardanti i tentativi di indovinare la password:
Di solito, questi tentativi vengono registrati su tutti i server in cui per il servizio di accesso remoto viene utilizzata la porta standard (3389) e dove è consentito l'accesso da ovunque. Internet è pieno di bot che scansionano continuamente tutti i punti di connessione disponibili e cercano di indovinare le password (proprio 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 molto tempo a modificare le impostazioni di un numero enorme di utenti finali per passare a un'altra porta? Non è affatto una buona idea, i clienti non saranno felici. Raccomandare di consentire l'accesso solo tramite VPN? In fretta e nel panico, avviare collegamenti IPSec dove non sono stati attivati, probabilmente non rende felici nemmeno i clienti. Tuttavia, va detto che, in ogni caso, è un compito utile, raccomandiamo sempre di nascondere il server in una rete privata e siamo pronti ad aiutare con le impostazioni; per coloro che amano risolvere le cose da soli, condividiamo istruzioni per configurare IPSec/L2TP nel nostro cloud in modalità site-to-site o road-warrior, e se qualcuno desidera attivare un servizio VPN sul proprio server Windows - siamo sempre pronti a condividere suggerimenti su come avviare RAS o OpenVPN. Ma, per quanto sia interessante quello che facciamo, non era il momento migliore per svolgere un lavoro di sensibilizzazione tra i clienti, poiché doveva essere risolta il prima possibile la questione con il minimo sforzo per gli utenti.
La soluzione che abbiamo implementato era la seguente. Abbiamo impostato un'analisi del traffico in modo da monitorare tutti i tentativi di stabilire una connessione TCP alla porta 3389 e selezionare quegli indirizzi che, nell'arco di 150 secondi, tentano di connettersi a più di 16 server diversi nella nostra rete; queste sono le fonti dell'attacco (naturalmente, se uno dei nostri clienti o partner ha realmente bisogno di stabilire connessioni con un numero così elevato di server da una stessa fonte, è sempre possibile aggiungere tali fonti alla "lista bianca". In ogni caso, se in una sola rete di classe C, in questi 150 secondi, vengono identificati più di 32 indirizzi, ha senso bloccare l'intera rete. Il blocco è impostato per 3 giorni, e se durante questo periodo non ci sono attacchi da questa fonte, questa viene rimossa automaticamente dalla "lista nera". L'elenco delle fonti bloccate viene aggiornato ogni 300 secondi.
Questo elenco è accessibile al seguente indirizzo: , puoi costruire le tue ACL su questa base.
Siamo pronti a condividere il codice sorgente di tale sistema, non contiene nulla di particolarmente complesso (si tratta di alcuni semplici script realizzati in poche ore "sul campo"), e può essere adattato e utilizzato non solo per proteggersi da tale attacco, ma anche per rilevare e bloccare qualsiasi tentativo di scansione della rete:
In aggiunta, abbiamo apportato alcune modifiche alle impostazioni del sistema di monitoraggio, che ora tiene d'occhio più da vicino la reazione di un gruppo di controllo di server virtuali nel nostro cloud rispetto a un tentativo di stabilire una connessione RDP: se non c'è risposta entro un secondo, è un motivo per prestare attenzione.
La soluzione si è rivelata abbastanza efficace: non ci sono più lamentele da parte di clienti e partner, né dalla parte del sistema di monitoraggio. Nuovi indirizzi e intere reti finiscono regolarmente nella "lista nera", il che indica che l'attacco continua, ma non influisce più sul lavoro dei nostri clienti.
Uno è solo nel campo
Oggi abbiamo appreso che anche altri operatori hanno affrontato un problema simile. Alcuni continuano a credere che sia stata Microsoft a apportare delle modifiche al codice del servizio di accesso remoto (se ricordi, abbiamo sospettato lo stesso fin dal primo giorno, ma abbiamo rapidamente scartato questa teoria) e promettono di fare tutto 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 e così via). E noi, fin dal primo giorno, non solo abbiamo risolto questo problema, ma abbiamo anche creato una base per un sistema di rilevamento delle minacce molto più globale, che intendiamo sviluppare.
Un ringraziamento speciale ai clienti e ai partner che non sono rimasti in silenzio e non hanno aspettato sulla riva del fiume, sperando che un giorno passasse il cadavere del nemico, ma ci hanno subito segnalato il problema, il che ci ha permesso di risolverlo lo stesso giorno.
Fonte: habr.com
