Räägime teile külma loo sellest, kuidas "kolmandad isikud" püüdsid takistada meie klientide tööd ning kuidas see probleem lahendati.
Kuidas kõik algas
Kõik algas hommikul, 31. oktoobril, kuu viimasel päeval, mil paljudel oli kiiresti vaja lõpetada tähtsad ja kiireloomulised küsimused.
Üks meie partneritest, kes hoiab meie pilves mitmeid klientide virtuaalmasinaid, teatas, et ajavahemikul 9:10 kuni 9:20 ei võtnud mitu Windows-serverit, mis töötavad meie Ukraina andmekeskuses, vastu kaugjuurdepääsuteenuse ühendusi, kasutajad ei saanud oma töölauale sisse logida, kuid mõne minuti pärast näis probleem iseenesest kadunud olevat.
Uurisime sidekanalite töö statistikat, kuid ei leidnud mingeid liikluse tõusu ega languse märke. Vaatasime üle arvutustegevuse koormuse statistika - mingeid anomaaliaid ei olnud. Mis see siis oli?
Seejärel teatas veel üks partner, kes majutab meie pilves umbes sada serverit, samadest probleemidest, mille üle olid kurtnud mõned nende kliendid. Selgus, et üldiselt olid serverid kergesti ligipääsetavad (vastasid ping-testidele ja muudele päringutele), kuid nende serverite kaugjuurdepääsuteenuse puhul kas võeti uusi ühendusi vastu või neid lükati tagasi. Samas rääkisime serveritest, mis asusid erinevates andmekeskustes, kuhu liiklus voolas erinevate andmeedastuskanalite kaudu.
Vaatame seda liiklust. Pakett ühenduse loomise taotlusega jõuab serverisse:
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
Server saab selle paketi, kuid lükkab ühenduse tagasi:
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
See tähendab, et probleem ei ole kindlasti seotud infrastruktuuri talitlushäiretega, vaid milleski muus. Võib-olla on kõigil kasutajatel kaugjuurdepääsuteenuse litsentsimisega probleemid? Võib-olla on nende süsteemidesse jõudnud mõni pahavara, mis täna aktiveerus, nagu paar aastat tagasi juhtus XData ja Petya?
Seni, kuni saime probleemi selgitada, saime sarnaseid päringuid veel mitmelt kliendilt ja partnerilt.
Mis seal masinates üldse toimub?
Sündmuste logides on palju teateid parooli murdmise katsete kohta:
Tavaliselt registreeritakse sellised katsed kõigis serverites, kus kaugjuurdepääsuteenus kasutab standardset porti (3389) ja samal ajal on lubatud juurdepääs kõikjalt. Internetis on rohkelt boti, mis pidevalt skaneerivad kõiki kättesaadavaid ühenduspunkte ja püüavad parooli katsetada (just seetõttu soovitame tungivalt kasutada keerulisi paroole asemel "123"). Siiski oli sellel päeval nende katsete intensiivsus liiga kõrge.
Kuidas edasi tegutseda?
Kas soovitada klientidele palju aega kulutada, et muuta seadeid suure hulga lõppkasutajate jaoks, et vahetada teisele portile? Mitte just parim idee, kliendid ei oleks sellega rahul. Soovitada lubada juurdepääs ainult VPN-i kaudu? IPSec-ühenduste loomine, kus need olemas ei ole, kiirusest ja paanikast tingituna – ilmselt ei naudi kliendid ka sellist õnne. Kuigi tuleb öelda, et see on igal juhul jumalakartlik tegu, soovitame alati serverit peita privaatvõrku ja oleme valmis seadistustes aitama, ning neile, kes soovivad ise nuputada, jagame juhtnööre IPSec/L2TP seadistamiseks meie pilves režiimis site-to-site või road-warrior, ja kui keegi soovib üles seada VPN-teenust oma Windows-serveris – oleme alati valmis jagama vihjeid selle kohta, kuidas seadistada standardset RAS-i või OpenVPN-i. Aga covid-kuna me olime, ei olnud see parim aeg haridustööd klientide seas läbi viia, kuna probleem tuli võimalikult kiiresti lahendada, et kasutajatele oleks minimaalne pingutus.
Meie rakendatud lahendus hõlmas järgmist. Kehtestasime liikluse analüüsi, et jälgida kõiki katseid luua TCP-ühendust pordiga 3389 ja tuvastada need aadressid, mis püüavad 150 sekundi jooksul luua ühendusi rohkem kui 16 erineva serveriga meie võrgus – need on rünnaku allikad (loomulikult, kui mõnel meie kliendil või partneril on reaalsed vajadused luua ühendusi nii paljude serveritega ühelt jaolt, saab alati neid allikaid "valge nimekirja" lisada). Samas, kui ühe C-klassi võrgu piires tuvastatakse 150 sekundi jooksul rohkem kui 32 aadressi, on mõistlik blokeerida kogu võrk. Blokeering kehtestatakse 3 päevaks, ja kui selle ajavahemiku jooksul ei toimu rünnakuid antud allikast, eemaldatakse see allikas automaatselt "mustast nimekirjast". Blokeeritud allikate nimekiri uuendatakse iga 300 sekundi järel.
See nimekiri on saadaval järgmise aadressi kaudu: , saate selle põhjal luua oma ACL-e.
Oleksime valmis jagama selle süsteemi lähtekoodi, seal ei ole midagi ülemäära keerulist (need on mõned lihtsad skriptid, mis on koostatud sõna-sõnalt mõne tunni jooksul "kätetöös"), ja seda saab kohandada ja kasutada mitte ainult sellise rünnaku vastu kaitsmiseks, vaid ka igasuguste võrgu skaneerimise katsete tuvastamiseks ja blokeerimiseks:
Lisaks tegime mõned muudatused monitooringusüsteemi seadetes, mis nüüd jälgib tähelepanelikumalt meie pilves olevate virtuaalserverite kontrollgrupi reaktsiooni katsetele luua RDP-ühendust: kui reaktsioon ei järgnenud sekundi jooksul – on see põhjus tähelepanu pöörata.
Lahendus osutus üsna efektiivseks: kaebusi ei ole enam ei klientidelt ega partneritelt, samuti ei ole ka monitooringusüsteemilt. Musta nimekirja satuvad regulaarselt uued aadressid ja terved võrgud, mis näitab, et rünnak jätkub, kuid ei mõjuta enam meie klientide tööd.
Üks ei ole sõdalane.
Täna saime teada, et sarnaste probleemidega on kokku puutunud ka teised operaatorid. Mõned arvavad endiselt, et Microsoft tegi kaugjuhtimise teenuse koodis mingeid muudatusi (kui mäletate, kahtlesime samas esimesel päeval, kuid seda versiooni lükkasime varsti tagasi) ja lubab teha kõik endast oleneva, et leida lahendus võimalikult kiiresti. Mõned lihtsalt ignoreerivad probleemi ja soovitavad klientidel oma jõududega kaitsta (muuta ühendusporti, varjata serverit privaatvõrku jne). Me lahendasime selle probleemi mitte ainult esimesel päeval, vaid lõime ka aluse laiemale ohtude avastamise süsteemile, mida plaanime edasi arendada.
Eriline tänu klientidele ja partneritele, kes ei vaikinud ja ei istunud jõe ääres, oodates, et kunagi voolab seal viholane laip mööda, vaid pöördusid meie poole probleemide märkamiseks, mis andis meile võimaluse seda samal päeval lahendada.
Allikas: habr.com
