Povejmo vam hladno zgodbo o tem, kako so »tretje osebe« poskušale ovira delo naših strank in kako smo to težavo rešili.
Kako se je vse začelo
Vse se je začelo zjutraj 31. oktobra, na zadnji dan v mesecu, ko je bilo številnim nujno potrebno zaključiti nujne in pomembne zadeve.
Eden od partnerjev, ki v naši oblaku gosti več virtualnih strojev strank, ki jih oskrbuje, je poročal, da od 9:10 do 9:20 več Windows strežnikov, ki delujejo na naši ukrajinski lokaciji, ni sprejemalo povezav z oddaljeno namizno storitvijo, uporabniki niso mogli dostopati do svojih namizij, a po nekaj minutah se je težava sama od sebe odpravila.
Povišali smo statistiko delovanja komunikacijskih kanalov, a nismo opazili nobenih nenavadnih povečanih prometov ali padcev. Oglejali smo si tudi obremenitev računalniških virov – brez anomalij. In kaj je to bilo?
Nato je še en partner, ki gosti še okoli sto strežnikov v našem oblaku, poročal o podobnih težavah, ki so jih opazili nekateri njihovi kupci; razjasnilo se je, da so v splošnem strežniki dostopni (pravilno odgovarjajo na ping teste in druge zahteve), vendar oddaljena dostopna storitev na teh strežnikih občasno sprejema nove povezave, občasno jih zavrača, pri čemer so bili strežniki na različnih lokacijah, promet do njih pa je prihajal iz različnih komunikacijskih kanalov.
Oglejmo si ta promet. Paket s prošnjo za vzpostavitev povezave pride na strežnik:
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
Strežnik prejme ta paket, a povezavo zavrne:
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
To pomeni, da težava očitno ni posledica kakšnih napak v delovanju infrastrukture, temveč nečesa drugega. Morda so imeli vsi uporabniki težave z licenciranjem oddaljenih delovnih namizij? Morda se je v njihove sisteme uspelo vdreti kakšno zlonamerno programsko opremo, ki se je danes aktivirala, kot pred nekaj leti z XData in Petya?
Medtem ko smo se ukvarjali s tem, smo prejeli podobne klice od še nekaj strank in partnerjev.
Kaj se sploh dogaja na teh napravah?
V dnevnikih dogodkov je polno sporočil o poskusih ugibanja gesel:
Običajno so taki poskusi zabeleženi na vseh strežnikih, kjer se za oddaljen dostop uporablja standardna vrata (3389) in je dostop dovoljen od povsod. Na internetu je polno botov, ki nenehno skenirajo vse dostopne povezave in poskušajo uganiti geslo (prav zato priporočamo, da uporabljate zapletena gesla namesto "123"). Vendar pa je bila intenzivnost teh poskusov tistega dne preprosto previsoka.
Kaj storiti?
Priporočati strankam, naj namenijo veliko časa za spreminjanje nastavitev pri ogromnem številu končnih uporabnikov, da preklopijo na druga vrata? To ni najboljša ideja, stranke ne bodo zadovoljne. Priporočiti omogočanje dostopa samo prek VPN? V naglici in paniki postaviti IPSec povezave, kjer teh ni, – verjetno to prav tako ne bi prineslo sreče strankam. Kljub temu pa je vsekakor plemenito delati na tem, vedno priporočamo skritje strežnika v privatno omrežje in smo pripravljeni pomagati pri nastavitvah, prav tako pa delimo navodila za nastavitev IPSec/L2TP v našem oblaku v načinu site-to-site ali road-warrior, in če želi kdo vzpostaviti VPN storitev na svojem lastnem Windows strežniku – vedno smo pripravljeni deliti nasvete o tem, kako nastaviti standardni RAS ali OpenVPN. A ne glede na to, kako odlični smo, to ni bil najboljši trenutek za izobraževanje strank, saj je bilo potrebno čim hitreje odpraviti težavo z minimalnim naporom za uporabnike.
Rešitev, ki smo jo uvedli, je bila naslednja. Uredili smo analizo prehajajočega prometa tako, da smo sledili vsem poskusom vzpostavitve TCP-povezave na vrata 3389 in izbrali naslove, ki v 150 sekundah poskušajo vzpostaviti povezave z več kot 16 različnimi strežniki v naši mreži – to so vira napada (seveda, če ima kdo od naših strank ali partnerjev resnično potrebo po vzpostavitvi povezav s tako številnimi strežniki iz istega vira, se ti viri lahko vedno dodajo na „beli seznam“. Hkrati, če je v eni C-klasi v teh 150 sekundah odkritih več kot 32 naslovov, ima smisel blokirati celo mrežo. Blokada se vzpostavi za 3 dni, in če ob tem času iz tega vira ni bilo napadov, se ta vir samodejno odstrani iz „črnega seznama“. Seznam blokiranih virov se posodablja na 300 sekund.
Ta seznam je dostopen na tej povezavi: , lahko na njegovi osnovi zgradite svoje ACL.
Izvorno kodo takšne sistema smo pripravljeni deliti, v njej ni nič pretirano zapletenega (to je nekaj preprostih skript, zbranih doslovno v nekaj urah „na kolenu“), in ob tem jo lahko prilagodite in uporabljate ne le za zaščito pred tovrstnim napadom, temveč tudi za odkrivanje in blokiranje vseh poskusov skeniranja omrežja:
Poleg tega smo uvedli nekatere spremembe v nastavitvah sistema za spremljanje, ki zdaj bolj pozorno spremlja odziv kontrolne skupine virtualnih strežnikov v našem oblaku na poskus vzpostavitve RDP-povezave: če odziv ne pride v eni sekundi – je to razlog za pozornost.
Rešitev se je izkazala za dovolj učinkovito: pritožb tako s strani strank in partnerjev kot s strani sistema za spremljanje ni več. Na „črni seznam“ redno prihajajo novi naslovi in cele mreže, kar pomeni, da napad še vedno traja, a zdaj ne vpliva na delovanje naših strank.
Eden na bojišču ni vojvoda.
Danes smo izvedeli, da se z enakimi težavami soočajo tudi drugi ponudniki. Nekateri še vedno menijo, da je Microsoft spremenil kodo storitve oddaljenega dostopa (če se spomnite, smo v prvem dnevu tudi to posumili, a to različico smo kmalu zavrnili) in obljubljajo, da bodo naredili vse, kar je v njihovi moči, da čim hitreje najdejo rešitev. Nekateri preprosto ignorirajo težavo in strankam svetujejo, naj se zaščitijo sami (z menjavo priključnega porta, skrivanjem strežnika v privatno omrežje itd.). Mi pa smo že prvi dan ne le rešili to težavo, ampak smo tudi ustvarili temelje za bolj globalni sistem zaznavanja groženj, ki ga nameravamo razvijati.
Posebna zahvala strankam in partnerjem, ki niso molčali in niso sedeli ob reki v pričakovanju, da bo nekoč mimo plavalo truplo sovražnika, temveč so takoj opozorili na težavo, kar nam je omogočilo, da smo jo odpravili še isti dan.
Izvor: habr.com
