Vă vom povesti o poveste captivantă despre cum „terții” au încercat să intervină în activitatea clienților noștri și cum a fost rezolvată această problemă.
Cum a început totul
Totul a început în dimineața zilei de 31 octombrie, în ultima zi a lunii, când mulți aveau nevoie urgentă să rezolve chestiuni importante.
Unul dintre parteneri, care deține în cloud-ul nostru mai multe mașini virtuale pentru clienții pe care-i deservește, a raportat că, între 9:10 și 9:20, mai multe servere Windows care funcționau pe platforma noastră din Ucraina nu acceptau conexiuni prin serviciul de acces la distanță, utilizatorii neputând accesa birourile lor, dar după câteva minute problema părea să fi fost rezolvată de la sine.
Am analizat statisticile canalelor de comunicație, dar nu am descoperit nicio explozie a traficului sau căderi. Ne-am uitat la statisticile de utilizare a resurselor de calcul – fără anomalii. Ce a fost asta?
Apoi, un alt partener, care găzduiește în cloud-ul nostru încă aproape o sută de servere, a raportat aceleași probleme, pe care le-au observat anumiți clienți, deși s-a dovedit că serverele sunt în general disponibile (răspund corect la testul ping și alte solicitări), dar serviciul de acces la distanță de pe aceste servere accepta uneori conexiuni noi, alteori le respingea, iar serverele erau distribuite pe platforme diferite, traficul către acestea venind din diverse canale de transmisie.
Să ne uităm la acest trafic. Un pachet cu o cerere de conectare ajunge pe 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
Serverul primește acest pachet, dar respinge conexiunea:
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
Aceasta înseamnă că problema nu este cauzată de niște defecțiuni în infrastructură, ci de altceva. Poate toți utilizatorii au avut probleme cu licențierea birourilor la distanță? Poate că un malware a reușit să se infiltreze în sistemele lor, iar astăzi s-a activat, așa cum s-a întâmplat acum câțiva ani cu XData și Petya?
Între timp, am primit solicitări similare de la încă câțiva clienți și parteneri.
Ce se întâmplă, de fapt, pe aceste mașini?
În jurnalele de evenimente sunt pline de mesaje despre încercări de spargere a parolelor:
De obicei, astfel de încercări sunt înregistrate pe toate serverele unde serviciul de acces la distanță folosește portul standard (3389) și unde este permis accesul din toate părțile. În rețeaua Internet există o mulțime de boți care scanează constant toate punctele de conectare disponibile și încearcă să ghicească parolele (exact din acest motiv, recomandăm cu tărie utilizarea unor parole complexe în loc de „123”). Cu toate acestea, intensitatea acestor încercări în acea zi a fost prea ridicată.
Ce să fac?
Să recomandăm clienților să dedice o mulțime de timp pentru a schimba setările unui număr mare de utilizatori finali pentru a se muta pe un alt port? Nu este o idee prea bună, clienții nu vor fi fericiți. Să recomandăm să permită accesul doar prin VPN? În grabă și panică să ridicăm conexiuni IPSec acolo unde nu sunt deja stabilite nu va fi o fericire nici pentru clienți. Totuși, trebuie spus că, oricum, este un lucru laudabil, întotdeauna recomandăm să ascundem serverul într-o rețea privată și suntem pregătiți să oferim ajutor cu setările, iar pentru cei care preferă să se descurce singuri, împărtășim instrucțiuni pentru configurarea IPSec/L2TP în norul nostru în modul site-to-site sau road-warrior, iar dacă cineva dorește să ridice un serviciu VPN pe propriul server Windows, suntem întotdeauna dispuși să împărtășim sugestii cu privire la cum să configurăm un RAS standard sau OpenVPN. Dar, oricât de grozavi am fi, nu a fost cel mai bun moment pentru a derula activități de educare a clienților, deoarece trebuia să rezolvăm problema cât mai repede, cu un efort minim pentru utilizatori.
Soluția pe care am implementat-o a fost următoarea. Am configurat analiza traficului pentru a urmări toate încercările de a stabili o conexiune TCP la portul 3389 și a selecta din acesta adresele care, timp de 150 de secunde, încearcă să stabilească conexiuni cu mai mult de 16 servere diferite din rețeaua noastră - acestea sunt sursele atacului (desigur, dacă unul dintre clienții sau partenerii noștri are o nevoie reală de a stabili conexiuni cu un număr atât de mare de servere din aceeași sursă, putem adăuga aceste surse în lista „albă”. În cazul în care, în aceeași rețea de clasă C, sunt identificate mai mult de 32 de adrese în decurs de 150 de secunde, are sens să blocăm întreaga rețea. Blocarea este setată pe 3 zile, iar dacă în acest timp nu au fost efectuate atacuri din această sursă, aceasta este eliminată automat din lista „neagră”. Lista surselor blocate este actualizată la fiecare 300 de secunde.
Această listă este disponibilă la următoarea adresă: , puteți construi pe baza ei propriile ACL-uri.
Suntem pregătiți să împărtășim codul sursă al acestui sistem, nu conține nimic foarte complicat (sunt câteva scripturi simple, realizate în câteva ore „la birou”), și în plus, poate fi adaptat și utilizat nu doar pentru a proteja împotriva unui astfel de atac, ci și pentru a identifica și bloca orice încercări de scanare a rețelei:
În plus, am efectuat unele modificări în setările sistemului de monitorizare, care acum monitorizează mai atent reacția grupului de control al serverelor virtuale din cloud-ul nostru la încercările de a stabili o conexiune RDP: dacă reacția nu a avut loc în termen de o secundă - este un motiv pentru a atrage atenția.
Soluția s-a dovedit a fi destul de eficientă: nu mai există plângeri din partea clienților și partenerilor, nici din partea sistemului de monitorizare. În lista „neagră” intră în mod regulat noi adrese și întregi rețele, ceea ce arată că atacul continuă, dar nu mai afectează activitatea clienților noștri.
Unul în câmp nu este războinic.
Astăzi am aflat că și alți operatori s-au confruntat cu aceeași problemă. Unii încă cred că Microsoft a făcut anumite modificări în codul serviciului de acces la distanță (dacă vă amintiți, noi am suspectat același lucru în prima zi, dar am respins această ipoteză foarte repede) și promit să facă tot posibilul pentru a găsi o soluție cât mai repede. Alții pur și simplu ignoră problema și le recomandă clienților să se protejeze singuri (schimbând portul de conectare, ascunzând serverul într-o rețea privată, și așa mai departe). Noi, în prima zi, nu doar că am rezolvat această problemă, dar am creat și un cadru pentru un sistem de detectare a amenințărilor mai global, pe care intenționăm să-l dezvoltăm.
Un mare mulțumesc clienților și partenerilor care nu au tăcut și nu au stat pe malul râului așteptând ca, într-o zi, să treacă cadavrul vrăjmașului, ci ne-au atras imediat atenția asupra problemei, ceea ce ne-a permis să o remediem încă din aceeași zi.
Sursa: habr.com
