Do t'ju tregojmë një histori interesante në lidhje me mënyrën se si "palët e treta" përpiqeshin të pengonin punën e klientëve tanë dhe si u zgjidh problemi.
Si filloi gjithçka
I gjithë kjo filloi në mëngjesin e 31 tetorit, në ditën e fundit të muajit, kur shumë njerëz kishin nevojë të mbyllnin çështje të rëndësishme dhe urgjente.
Një nga partnerët tanë, i cili mban disa makina virtuale për klientët që ai shërben në re, njoftoi se nga ora 9:10 deri në 9:20 disa serverë Windows që punonin në qendrën tonë në Ukrainë nuk pranuan lidhje me shërbimin e aksesit të largët; përdoruesit nuk ishin në gjendje të hynin në desktopet e tyre, por pas disa minutash problemi duket se u zgjidh vetvetiu.
Ne analizuam statistikën e punës së kanaleve të komunikimit, por nuk zbuluam asnjë rritje të trafikut, as rënie. Shikuan statistikën e ngarkesës së burimeve kompjuterike - asnjë anomaldi. Çfarë ishte kjo?
Më pas, një partner tjetër, i cili hoston rreth njëqind serverë në re, njoftoi për probleme të ngjashme që disa nga klientët e tyre kishin vërejtur; megjithatë, u zbulua se në përgjithësi serverët ishin në dispozicion (përgjigjeshin normalisht në ping-test dhe kërkesa të tjera), por shërbimi i aksesit të largët në këto serverë ndonjëherë priste lidhje të reja, ndonjëherë i refuzonte ato, meqenëse bëhej fjalë për servera në qendra të ndryshme, të cilët pranonin trafik nga kanale të ndryshme transmetimi.
Le ta shikojmë këtë trafik. Një paketë me një kërkesë për lidhje vjen 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ë që problemi padyshim nuk është i lidhur me ndonjë defekt në infrastrukturë, por me diçka tjetër. A mund të kenë pasur probleme për licencimin e desktopëve të largët për të gjithë përdoruesit? A ka pasur ndonjë malware që ka depërtuar në sistemet e tyre, dhe sot ka aktivizuar si çfarë ndodhi disa vjet më parë me XData dhe Petya?
Ndërsa ishim duke u marrë me këtë, morëm ankesat e ngjashme nga disa klientë dhe partnerë të tjerë.
Po çfarë ndodh në këto makina?
Në regjistrat e ngjarjeve kishte shumë mesazhe për përpjekjet për të gjetur fjalëkalimin:
Zakonisht, përpjekjet e tilla regjistrohen në të gjitha serverët ku për shërbimin e aksesit të largët përdoret porta standarde (3389) dhe kur lejohet akses nga kudo. Në internet ka plot bota që skanojnë vazhdimisht të gjitha pikat e lidhjes dhe përpiqen të gjejnë fjalëkalime (për këtë arsye ne rekomandojmë të përdoren fjalëkalime të komplikuara në vend të "123"). Megjithatë, intensiteti i këtyre përpjekjeve atë ditë ishte tepër i lartë.
Çfarë të bëjmë?
A duhet të rekomandojmë klientëve që të kalojnë shumë kohë për të ndryshuar cilësimet për një numër të madh përdoruesish fundorë, për të kaluar në një portë tjetër? Nuk është ndonjë ide e mirë, klientët nuk do të ishin të kënaqur. A duhet të rekomandojmë që të lejohet akses vetëm përmes VPN? Në një nxitim dhe panik për të krijuar lidhjet IPSec, për ata që nuk i kanë ngritur – ndoshta kjo kënaqësi nuk do t'u bjerë as atyre. Megjithatë, duhet të themi se kjo gjithsesi është një punë e mirë, ne gjithmonë rekomandojmë të fshehim serverin në një rrjet privat dhe jemi të gatshëm të ndihmojmë me konfigurimet; për ata që dëshirojnë të merren me këtë vetë, ne ndajmë udhëzimet për konfigurimin e IPSec/L2TP në re tonë në mënyrë site-to-site ose road-warrior, dhe nëse dikush dëshiron të ngrisë një shërbim VPN në serverin e vet Windows – gjithmonë jemi të gatshëm të ndajmë këshilla se si të ngrisim një RAS standard ose OpenVPN. Por, pavarësisht se sa të shkëlqyer jemi, kjo nuk ishte kohë e mirë për të bërë edukimin e klientëve, pasi duhet të shpejtojmë për të zgjidhur problemin me sa më pak pengesa për përdoruesit.
Zgjidhja që ne implementuam ishte si më poshtë. Ne organizuam analizën e trafikut në mënyrë që të monitorojmë të gjitha përpjekjet për të vendosur një lidhje TCP në portin 3389 dhe të përzgjedhim nga ato adresat që brenda 150 sekondave përpiqen të vendosin 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 ose partnerët tanë ka një nevojë reale për të vendosur lidhje me një numër kaq të madh serverash nga e njëjta burim, gjithmonë mund të shtojmë këto burime në "listën e bardhë". Në të njëjtën kohë, nëse në një rrjet të klasës C gjatë këtyre 150 sekondave identifikohen më shumë se 32 adresa, ka kuptim të bllokosh të gjithë rrjetin. Bllokimi vendoset për 3 ditë, dhe nëse gjatë kësaj kohe nuk ka pasur sulme nga ky burim, ky burim eliminohet automatikisht nga "lista e zezë". Lista e burimeve të bllokuara përditësohet çdo 300 sekonda.
Kjo listë është e aksesueshme në këtë adresë: , mund të ndërtoni mbi bazën e saj ACL-të tuaja.
Ne jemi të gatshëm të ndajmë kodin burimor të një sistemi të tillë, nuk ka asgjë tepër të komplikuar në të (janë disa skripta të thjeshta, të krijuara për vetëm disa orë "në gjunjë"), dhe gjithashtu mund të adaptohet dhe përdoret jo vetëm për mbrojtjen nga një sulm të tillë, 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ë konfigurimet e sistemit të monitorimit, i cili tani monitoron më me kujdes reagimin e grupit të kontrollit të serverëve virtual në qëllim të lidhjes RDP: nëse nuk ka pasur reagim brenda një sekonde – kjo është një arsye për t'u shqetësuar.
Zgjidhja rezultoi të ishte mjaft efektive: nuk ka më ankesa nga klientët dhe partnerët, ashtu si nga sistemi i monitorimit. Adresa dhe rrjete të reja rregullisht bien në "listën e zezë", që tregon se sulmi vazhdon, por tashmë nuk ndikon në punën e klientëve tanë.
Një në fushë nuk është luftëtar
Sot mësuam se edhe operatorë të tjerë u përballën me probleme të ngjashme. Disa ende mendojnë se Microsoft ka bërë disa ndryshime në kodin e shërbimit të aksesit të largët (nëse e mbani mend, në ditën e parë ne dyshuam se ishte kështu, por këtë version e refutuam shumë shpejt) dhe premtojnë të bëjnë gjithçka të mundshme për të gjetur një zgjidhje sa më shpejt. Disa thjesht e injorojnë problemin dhe i këshillojnë klientët të mbrohen nga forcat e tyre (të ndryshojnë portin e lidhjes, të fshehin serverin në një rrjet privat etj). Dhe ne në ditën e parë jo vetëm që zgjidhëm këtë problem, por krijuam gjithashtu një bazë për një sistem më shumë gjithnjë në zhvillim të identifikimit të kërcënimeve.
Një falënderim të veçantë për klientët dhe partnerët, që nuk e mbajtën gojën mbyllur dhe nuk qëndruan në bregun e lumit duke pritur që ndonjëherë të kalojë kufiri i armikut, por menjëherë i tërhoqën vëmendjen tonë për problemin, që na dha mundësinë për ta zgjidhur atë në të njëjtën ditë.
Burimi: habr.com
