Do t'ju tregojmë një histori interesante se si "palët e treta" tentuan të pengonin punën e klientëve tanë dhe si u zgjidh ky problem.
Si filloi gjithçka
E gjitha filloi në mëngjesin e 31 tetorit, në ditën e fundit të muajit, kur shumë njerëz patën nevojë të mbyllnin çështje urgjente dhe të rëndësishme.
Një nga partnerët tanë, i cili mban në cloud-in tonë disa makineri virtuale të klientëve të tij, raportoi se nga ora 9:10 deri në 9:20, disa servera Windows që funksiononin në platformën tonë ukrainase, nuk pranuan lidhje me shërbimin e qasjes në distancë, dhe përdoruesit nuk mund të hynin në desktopet e tyre, por pas disa minutash problemi duket se u zgjidh vetë.
Ne analizuam statistikat e punës së kanaleve të komunikimit, por nuk gjetëm asnjë shpërthim trafiku, as dështime. Kontrolluam statistikat e ngarkesës në burimet llogaritëse – nuk kishte anomali. Dhe çfarë ishte kjo?
Pastaj një partner tjetër, i cili ka në cloud-in tonë disa dhjetëra servera, raportoi për të njëjtat probleme që kishin vërejtur disa nga klientët e tyre, duke u zbuluar se përgjithësisht serverat ishin të aksesueshëm (përgjigjeshin saktësisht ndaj testit ping dhe kërkesave të tjera), por shërbimi i qasjes në distancë në këta servera herë priste lidhje të reja, herë i refuzonte ato, megjithatë flitej për servera në platforma të ndryshme, për të cilat trafiku vinte nga kanale të ndryshme përcjellëse.
Le të shohim këtë trafik. Paketa me kërkesën për krijimin e lidhjes arrin në 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
Serveri merr këtë paketë, por e refuzon lidhjen:
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
Kjo do të thotë se problemi qartë nuk është shkaktuar nga ndonjë defekt në punën e infrastrukturës, por nga diçka tjetër. A mund të ketë ndodhur që të gjithë përdoruesit të kishin probleme me licencimin e desktopëve të largët? A mund të ketë ndodhur që ndonjë malware të jetë futur në sistemet e tyre, dhe sot është aktivizuar, ashtu siç ndodhi disa vite më parë me XData dhe Petya?
Ndërkohë që po merreshim me këtë, morëm kërkesa të ngjashme nga disa klientë e partnerë të tjerë.
Çfarë po ndodh në këto mjete?
Në regjistrat e ngjarjeve ka shumë mesazhe për përpjekjet për të krijuar fjalëkalim:
Këto përpjekje regjistrohen zakonisht në të gjitha serverët ku përdoret porta standarde (3389) për shërbimin e qasjes në distancë dhe në të njëjtën kohë lejohet qasja nga të gjitha anët. Në internet ka një sërë botësh që skanojnë vazhdimisht të gjitha piketat e qasjes dhe përpiqen të gjejnë fjalëkalime (pikërisht për këtë arsye, ne këshillojmë me ngulm përdorimin e fjalëkalimeve të komplikuara në vend të '123'). Megjithatë, intensiteti i këtyre përpjekjeve në atë ditë ishte mjaft i lartë.
Çfarë të bëjmë?
A duhet t'u rekomandojmë klientëve të kalojnë një sasi të madhe kohe për të ndryshuar konfigurimet për një numër të madh të përdoruesve për të kaluar në një port tjetër? Nuk është një ide shumë e mirë, klientët nuk do të jenë të kënaqur. A duhet të rekomandojmë lejen e aksesit vetëm përmes VPN? Në nxehje dhe panik për të ngritur lidhje IPSec për ata që nuk i kanë ngritur, - ndoshta, një kënaqësi e tillë nuk do të jetë e arritshme për klientët. Megjithatë, duhet të themi se, në çdo rast, është një punë e mirë, ne gjithmonë rekomandojmë të fshehim serverin në një rrjet privat dhe jemi të gatshëm të ndihmojmë me konfigurimet, dhe për ata që preferojnë të merren me këtë vetë, ne ndajmë udhëzime për konfigurimin e IPSec/L2TP në rrjetin tonë në mënyrën site-to-site ose road-warrior, dhe nëse ndokush dëshiron të ngritë një shërbim VPN në serverin e tij Windows, jemi gjithmonë të gatshëm të ndajmë këshilla për si të ngremë RAS standard ose OpenVPN. Por, përsa kohë çdo gjë është e bukur, nuk ishte koha më e mirë për të bërë punë edukative ndërmjet klientëve, duke e ditur se duhej të zgjidhej problemi sa më shpejt të ishte e mundur me sa më pak shqetësim për përdoruesit.
Zgjidhja që implementuam ishte si vijon. Përcaktuam analizën e trafikut të kalueshëm në një mënyrë që mund të monitorojmë të gjitha përpjekjet për të vendosur një lidhje TCP në portin 3389 dhe të dallojmë adresat që brenda 150 sekondash përpiqen të krijojnë lidhje me më shumë se 16 servera të ndryshëm në rrjetin tonë – këto janë burimet e sulmit (natyrisht, nëse ndonjë nga klientët apo partnerët tanë ka nevojë reale për të krijuar lidhje me kaq shumë servera nga një burim i vetëm, gjithmonë mund të shtohen këto burime në "listën e bardhë". Megjithatë, nëse në një rrjet C klase gjatë këtyre 150 sekondave identifikohen më shumë se 32 adresa, ka kuptim të bllokohet e gjithë rrjeta. Bllokimi vendoset për 3 ditë, dhe nëse gjatë këtyre kohëve nuk ka pasur sulme nga ky burim, ky burim hiqet automatikisht nga "lista e zezë". Lista e burimeve të bllokuara përditësohet çdo 300 sekonda.
Kjo listë është e aksesueshme në adresën e mëposhtme: , mund të ndërtoni bazuar në të ACL-të tuaja.
Ne jemi të gatshëm të ndajmë kodin burimor të këtij sistemi, nuk ka asgjë tejet të komplikuar (këto janë disa skripte të thjeshta, të krijuara në realitet për disa orë "në gjunjë"), dhe gjithashtu mund të adaptohet dhe përdoret jo vetëm për mbrojtjen nga ky sulm, por edhe për identifikimin dhe bllokimin e çdo përpjekjeje për skanimin e rrjetit:
Për më tepër, ne bëmë disa ndryshime në konfigurimin e sistemit të monitorimit, i cili tani ndiqet më me kujdes përgjigjen e grupit të kontrollit të serverëve virtualë në cloud-in tonë ndaj përpjekjeve për të vendosur një lidhje RDP: nëse nuk ka pasur reagim brenda një sekonde – kjo është një arsye për të zgjuar vëmendjen.
Zgjidhja u tregua mjaft efektive: nuk ka më ankesa për nga klientët dhe partnerët, ashtu edhe për nga sistemi i monitorimit. Adresat dhe të gjithë rrjetet e reja rregullisht bien në "listën e zezë", gjë që tregon se sulmi vazhdon, por tashmë nuk ndikon në funksionimin e klientëve tanë.
Një në fushë nuk është luftëtar.
Sot, mësuam se edhe operatorë të tjerë janë përballur me një problem të ngjashëm. Disa ende besojnë se Microsoft bëri disa ndryshime në kodin e shërbimit të qasjes në distancë (nëse e mbani mend, ne në ditën e parë e dyshuam të njëjtën gjë, por këtë version e hodhëm poshtë shumë shpejt) dhe premton të bëjë gjithçka që është e mundur për të gjetur një zgjidhje sa më shpejt. Disa thjesht e injorojnë problemin dhe u këshillojnë klientëve të mbrohen vetë (duke ndryshuar portin e lidhjes, fshehur serverin në një rrjet privat dhe kështu me radhë). Ndërsa ne që në ditën e parë jo vetëm që e zgjidhëm këtë problem, por gjithashtu krijuam një bazë për një sistem më global të zbuluar të kërcënimeve që planifikojmë ta zhvillojmë.
Një falënderim të veçantë për klientët dhe partnerët që nuk qëndruan të heshtur dhe nuk pr waiting të kalonte ndonjëherë trupi i armikut, por menjëherë na i drejtuan vëmendjen ndaj problemit, duke na dhënë mundësinë ta zgjidhnim atë në të njëjtën ditë.
Burimi: habr.com
