Le t'ju tregojmë një histori interesante se si "palët e treta" u përpoqën të ndërhynin në punën e klientëve tanë dhe si u zgjidh ky problem.
Si filloi gjithçka
Gjithçka nisi në mëngjesin e 31 tetorit, ditën e fundit të muajit, kur shumë njerëz kanë nevojë të dëshpëruar të kenë kohë për të zgjidhur çështje urgjente dhe të rëndësishme.
Një nga partnerët, i cili mban disa makina virtuale të klientëve që ai shërben në renë tonë, raportoi se nga ora 9:10 deri në 9:20 disa serverë Windows që funksionojnë në faqen tonë të Ukrainës nuk pranuan lidhje me shërbimin e aksesit në distancë, përdoruesit nuk ishin në gjendje për t'u identifikuar në desktopët e tyre, por pas disa minutash problemi dukej se u zgjidh vetë.
Ne ngritëm statistikat për funksionimin e kanaleve të komunikimit, por nuk gjetëm rritje apo defekte të trafikut. Ne shikuam statistikat mbi ngarkesën në burimet kompjuterike - pa anomali. Dhe çfarë ishte kjo?
Pastaj një partner tjetër, i cili pret rreth njëqind serverë të tjerë në renë tonë, raportoi të njëjtat probleme që vunë re disa nga klientët e tyre, dhe doli që në përgjithësi serverët ishin të aksesueshëm (duke iu përgjigjur siç duhet testit të ping dhe kërkesave të tjera), por shërbimi i aksesit në distancë në këta serverë ose pranon lidhje të reja ose i refuzon ato, dhe po flisnim për serverë në faqe të ndryshme, trafiku në të cilët vjen nga kanale të ndryshme të transmetimit të të dhënave.
Le të shohim këtë trafik. Një paketë me një kërkesë për lidhje mbërrin 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 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 është i qartë se nuk është shkaktuar nga ndonjë problem në funksionimin e infrastrukturës, por nga diçka tjetër. Ndoshta të gjithë përdoruesit kanë probleme me licencimin e desktopit në distancë? Ndoshta një lloj malware arriti të depërtonte në sistemet e tyre, dhe sot ai u aktivizua, siç ishte me disa vjet më parë XData и Petja?
Ndërsa po e rregullonim, morëm kërkesa të ngjashme nga disa klientë dhe partnerë të tjerë.
Çfarë ndodh në të vërtetë në këto makina?
Regjistrat e ngjarjeve janë plot me mesazhe në lidhje me përpjekjet për të gjetur fjalëkalimin:
Në mënyrë tipike, përpjekje të tilla regjistrohen në të gjithë serverët ku porti standard (3389) përdoret për shërbimin e aksesit në distancë dhe qasja lejohet nga kudo. Interneti është plot me robotë që skanojnë vazhdimisht të gjitha pikat e disponueshme të lidhjes dhe përpiqen të marrin me mend fjalëkalimin (kjo është arsyeja pse ne rekomandojmë fuqimisht përdorimin e fjalëkalimeve komplekse në vend të "123"). Megjithatë, intensiteti i këtyre përpjekjeve atë ditë ishte shumë i lartë.
Cfare te bejme
Rekomandoni që klientët të kalojnë shumë kohë duke ndryshuar cilësimet për një numër të madh përdoruesish fundorë që të kalojnë në një port tjetër? Nuk është një ide e mirë, klientët nuk do të jenë të kënaqur. Rekomandoni lejimin e aksesit vetëm përmes VPN? Me nxitim dhe panik, ngritja e lidhjeve IPSec për ata që nuk i kanë të ngritura - ndoshta një lumturi e tillë nuk u buzëqesh as klientëve. Megjithëse, duhet të them, kjo është një gjë e perëndishme në çdo rast, ne gjithmonë rekomandojmë fshehjen e serverit në një rrjet privat dhe jemi të gatshëm të ndihmojmë me cilësimet, dhe për ata që duan ta kuptojnë vetë, ne ndajmë udhëzime për konfigurimin e IPSec/L2TP në cloud-in tonë në modalitetin site-to-site ose rrugë -warrior, dhe nëse dikush dëshiron të konfigurojë një shërbim VPN në serverin e tij Windows, ne jemi gjithmonë të gatshëm të ndajmë këshilla se si të konfigurojmë një RAS standarde ose OpenVPN. Por, sado të ftohtë të ishim, kjo nuk ishte koha më e mirë për të kryer punë edukative midis klientëve, pasi duhej ta rregullonim problemin sa më shpejt që të ishte e mundur me stres minimal për përdoruesit.
Zgjidhja që ne zbatuam ishte si më poshtë. Ne kemi vendosur një analizë të trafikut kalues në mënyrë të tillë që të monitorojmë të gjitha përpjekjet për të krijuar një lidhje TCP me portin 3389 dhe të zgjedhim prej saj adresat që, brenda 150 sekondave, përpiqen të krijojnë lidhje me më shumë se 16 serverë të ndryshëm në rrjetin tonë - këto janë burimet e sulmit ( Sigurisht, nëse një nga klientët ose partnerët ka një nevojë reale për të krijuar lidhje me kaq shumë serverë nga i njëjti burim, ju gjithmonë mund të shtoni burime të tilla në "listën e bardhë". nëse në një rrjet të klasës C për këto 150 sekonda janë identifikuar më shumë se 32 adresa, ka kuptim të bllokohet i gjithë rrjeti. Bllokimi vendoset për 3 ditë dhe nëse gjatë kësaj kohe nuk është kryer asnjë sulm nga një burim i caktuar, ky burim hiqet automatikisht nga "lista e zezë". Lista e burimeve të bllokuara përditësohet çdo 300 sekonda.
Kjo listë është e disponueshme në këtë adresë: , ju mund të ndërtoni ACL-të tuaja bazuar në të.
Ne jemi gati të ndajmë kodin burimor të një sistemi të tillë; nuk ka asgjë tepër komplekse në të (këto janë disa skripta të thjeshta të përpiluara fjalë për fjalë në disa orë në gju), dhe në të njëjtën kohë ai mund të përshtatet dhe përdoret jo vetëm për të mbrojtur kundër një sulmi të tillë, por edhe për të zbuluar dhe bllokuar çdo përpjekje për të skanuar rrjetin:
Përveç kësaj, ne kemi bërë disa ndryshime në cilësimet e sistemit të monitorimit, i cili tani monitoron më nga afër reagimin e një grupi kontrolli të serverëve virtualë në renë tonë ndaj një përpjekjeje për të krijuar një lidhje RDP: nëse reagimi nuk pason brenda një së dyti, kjo është një arsye për t'i kushtuar vëmendje.
Zgjidhja rezultoi mjaft efektive: nuk ka më ankesa si nga klientët, ashtu edhe nga partnerët dhe nga sistemi i monitorimit. Adresa të reja dhe rrjete të tëra shtohen rregullisht në listën e zezë, gjë që tregon se sulmi vazhdon, por nuk ndikon më në punën e klientëve tanë.
Ka siguri në numra
Sot mësuam se operatorë të tjerë kanë hasur në një problem të ngjashëm. Dikush ende beson se Microsoft bëri disa ndryshime në kodin e shërbimit të aksesit në distancë (nëse ju kujtohet, ne dyshuam të njëjtën gjë ditën e parë, por shumë shpejt e refuzuam këtë version) dhe premton të bëjë gjithçka që është e mundur për të gjetur një zgjidhje shpejt . Disa njerëz thjesht e injorojnë problemin dhe këshillojnë klientët të mbrohen vetë (ndryshojnë portën e lidhjes, fshehin serverin në një rrjet privat, etj.). Dhe që në ditën e parë, ne jo vetëm që e zgjidhëm këtë problem, por gjithashtu krijuam disa baza për një sistem më global të zbulimit të kërcënimeve që ne planifikojmë të zhvillojmë.
Falenderime të veçanta për klientët dhe partnerët që nuk heshtën dhe nuk u ulën në breg të lumit duke pritur që një ditë të notonte kufoma e një armiku përgjatë tij, por menjëherë na tërhoqën vëmendjen për problemin, i cili na dha mundësinë për të eliminuar atë në të njëjtën ditë.
Burimi: www.habr.com