Ti raccontiamo una storia interessante su come "terze parti" hanno cercato di interferire con il lavoro dei nostri clienti e su come questo problema è stato risolto.
Com'è cominciato tutto
Tutto è iniziato la mattina del 31 ottobre, l'ultimo giorno del mese, quando molti hanno un disperato bisogno di tempo per risolvere questioni urgenti e importanti.
Uno dei partner, che mantiene nel nostro cloud diverse macchine virtuali dei clienti che serve, ha riferito che dalle 9:10 alle 9:20 diversi server Windows in esecuzione sul nostro sito ucraino non hanno accettato connessioni al servizio di accesso remoto, gli utenti non sono stati in grado per accedere ai propri desktop, ma dopo pochi minuti il problema sembrava risolversi da solo.
Abbiamo raccolto le statistiche sul funzionamento dei canali di comunicazione, ma non abbiamo riscontrato aumenti o interruzioni del traffico. Abbiamo esaminato le statistiche sul carico delle risorse informatiche: nessuna anomalia. E cos'era quello?
Poi un altro partner, che ospita circa un centinaio di server in più nel nostro cloud, ha segnalato gli stessi problemi notati da alcuni dei suoi clienti, e si è scoperto che in generale i server erano accessibili (rispondendo correttamente al test ping e ad altre richieste), ma il servizio di accesso remoto a questi server accetta nuove connessioni o le rifiuta, e stiamo parlando di server su siti diversi, il cui traffico proviene da diversi canali di trasmissione dati.
Diamo un'occhiata a questo traffico. Al server arriva un pacchetto con una richiesta di connessione:
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 chiaramente il problema non è causato da eventuali problemi nel funzionamento dell'infrastruttura, ma da qualcos'altro. Forse tutti gli utenti hanno problemi con le licenze del desktop remoto? Forse qualche tipo di malware è riuscito a penetrare nei loro sistemi e oggi si è attivato, come un paio di anni fa XDati и Petya?
Mentre stavamo risolvendo la questione, abbiamo ricevuto richieste simili da molti altri clienti e partner.
Cosa succede realmente su queste macchine?
I registri eventi sono pieni di messaggi sui tentativi di indovinare la password:
In genere, tali tentativi vengono registrati su tutti i server in cui viene utilizzata la porta standard (3389) per il servizio di accesso remoto e l'accesso è consentito da ovunque. Internet è piena di bot che scansionano costantemente tutti i punti di connessione disponibili e cercano di indovinare la password (per questo consigliamo vivamente di utilizzare password complesse invece di “123”). Tuttavia, l’intensità di questi tentativi quel giorno era troppo alta.
Cosa dovrei fare?
Consigliare ai clienti di dedicare molto tempo alla modifica delle impostazioni affinché un numero enorme di utenti finali passi a una porta diversa? Non è una buona idea, i clienti non saranno contenti. Consigli di consentire l'accesso solo tramite VPN? In fretta e nel panico, sollevando le connessioni IPSec per coloro che non le hanno sollevate, forse tale felicità non sorride nemmeno ai clienti. Anche se, devo dire, questa è in ogni caso una cosa divina, consigliamo sempre di nascondere il server in una rete privata e siamo pronti ad aiutare con le impostazioni, e per coloro a cui piace capirlo da soli, condividiamo le istruzioni per impostare IPSec/L2TP nel nostro cloud in modalità site-to-site o road -warrior, e se qualcuno vuole impostare un servizio VPN sul proprio server Windows, è sempre pronto a condividere suggerimenti su come impostare un RAS standard o OpenVPN. Ma, per quanto fossimo bravi, questo non era il momento migliore per condurre un lavoro educativo tra i clienti, poiché dovevamo risolvere il problema il più rapidamente possibile con il minimo stress per gli utenti.
La soluzione che abbiamo implementato è stata la seguente. Abbiamo impostato un'analisi del traffico in transito in modo tale da monitorare tutti i tentativi di stabilire una connessione TCP alla porta 3389 e selezionare da essa gli indirizzi che, entro 150 secondi, tentano di stabilire connessioni con più di 16 server diversi sulla nostra rete - queste sono le fonti dell'attacco (Naturalmente, se uno dei clienti o dei partner ha una reale necessità di stabilire connessioni con così tanti server dalla stessa fonte, è sempre possibile aggiungere tali fonti alla "lista bianca". Inoltre, se in una rete di classe C durante questi 150 secondi vengono identificati più di 32 indirizzi, è opportuno bloccare l'intera rete. Il blocco è fissato per 3 giorni e se durante questo periodo non sono stati effettuati attacchi da una determinata fonte, questa fonte viene automaticamente rimossa dalla “lista nera”. L'elenco delle fonti bloccate viene aggiornato ogni 300 secondi.
L'elenco è disponibile a questo indirizzo: , puoi creare i tuoi ACL in base ad essi.
Siamo pronti a condividere il codice sorgente di un tale sistema; non c'è nulla di eccessivamente complesso in esso (si tratta di diversi semplici script compilati letteralmente in un paio d'ore in ginocchio), e allo stesso tempo può essere adattato e utilizzato non solo per proteggersi da un simile attacco, ma anche per rilevare e bloccare qualsiasi tentativo di scansione della rete:
Inoltre, abbiamo apportato alcune modifiche alle impostazioni del sistema di monitoraggio, che ora monitora più da vicino la reazione di un gruppo di controllo di server virtuali nel nostro cloud al tentativo di stabilire una connessione RDP: se la reazione non segue entro un in secondo luogo, questo è un motivo per prestare attenzione.
La soluzione si è rivelata piuttosto efficace: non ci sono più reclami né da parte dei clienti e dei partner, né da parte del 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.
Nessun guerriero in campo
Oggi abbiamo appreso che altri operatori hanno riscontrato un problema simile. Qualcuno crede ancora che Microsoft abbia apportato qualche modifica al codice del servizio di accesso remoto (se ricordate, sospettavamo la stessa cosa il primo giorno, ma abbiamo subito rifiutato questa versione) e promette di fare tutto il possibile per trovare rapidamente una soluzione . Alcune persone semplicemente ignorano il problema e consigliano ai client di proteggersi da soli (cambiare la porta di connessione, nascondere il server in una rete privata e così via). E fin dal primo giorno, non solo abbiamo risolto questo problema, ma abbiamo anche creato le basi per un sistema di rilevamento delle minacce più globale che intendiamo sviluppare.
Un ringraziamento speciale ai clienti e ai partner che non sono rimasti in silenzio e non si sono seduti sulla riva del fiume aspettando che un giorno il cadavere di un nemico galleggiasse lungo di essa, ma hanno immediatamente attirato la nostra attenzione sul problema, che ci ha dato l'opportunità di eliminare lo stesso giorno.
Fonte: habr.com