Räägime teile külmast loost sellest, kuidas «kolmandad isikud» üritasid meie klientide tööd takistada ja kuidas see probleem lahendati.
Kuidas kõik algas
Kõik algas 31. oktoobri hommikul, kuu viimasel päeval, mil paljud pidid kiirelt lahendama tähtsad küsimused.
Üks meie partneritest, kes peab meie pilves mitut kliendi virtuaalset masinat, teatas, et kella 9:10 kuni 9:20 ei saanud mitmed Windows-serverid, mis töötavad meie Ukraina andmekeskuses, ühendust kaugjuurdepääsu teenusega, ning kasutajad ei saanud oma töölauale sisse logida, kuid mõne minuti pärast näis probleem iseenda ära lahenenud.
Uurime sidekanalite tööstatistikat, kuid ei leidnud mingeid liikluspiike ega katkestusi. Vaatasime ka arvutusressursside koormuse statistikat – mingisuguseid anomaaliaid polnud. Mis see siis oli?
Siis veel üks partner, kes paigaldab meie pilve veel tosin serverit, teatas samadest probleemidest, mida märkasid mõned nende kliendid. Tuli välja, et serverid on üldiselt kergesti ligipääsetavad (vastavad õigesti ping-testi ja muudele päringutele), kuid nende serverite kaugjuurdepääsuteenused aegu vastavad uutele ühendustele, siis keelavad need neid. Juttu oli serveritest eri asukohtades, kuhu liiklus sissetulevalt allkatkestustest.
Vaadakem seda liiklust. Pakett ühenduse loomiseks 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 loobub ühendusest:
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 riketega, vaid millegagi muuga. Võib-olla on kõigil kasutajatel olnud probleeme kauglaudade litsentsimisega? Võib-olla on nende süsteemidesse tunginud mingisugune pahavara, mis täna aktiveerus, nagu paar aastat tagasi juhtus XData ja Petya?
Kuna tegelesime sellega, saime sarnaseid pöördumisi veel mitmelt kliendilt ja partnerilt.
Mis porgandiga tegelikult nende masinate peal toimub?
Sündmuste logiraamatus on palju teateid parooli arvatava valimise katsetest:
Tavaliselt registreeritakse sellised katsed kõigil serveritel, kus kaugjuurdepääsuteenuse jaoks kasutatakse standardset porti (3389) ja kus ligipääs on lubatud kõikjalt. Internetis on palju robotite, mis pidevalt skaneerivad kõiki saadaolevaid ühenduskohti ja püüavad parole valida (just seetõttu soovitame tungivalt kasutada keerulisi paroole, mitte näiteks „123”). Siiski, nende katsete intensiivsus oli sel päeval liiga kõrge.
Kuidas edasi tegutseda?
Kas soovitada klientidele kulutada palju aega, et muuta seadistusi suure hulga lõppkasutajate jaoks, et üle minna teisele pordile? See ei ole sugugi hea idee, kliendid ei ole sellega rahul. Kas soovitada lubada juurdepääs ainult VPN-i kaudu? IPSec-ühenduste kiirus ja paanika tõstmine, kellel need pole üles seatud, ei too klientidele kindlasti nõutavat õnne. Kuigi tuleb öelda, et see on igaühe jaoks õigustatud tegevus, soovitame alati serverit varjata privaatvõrku ja oleme valmis seadistusi aitama, ning neile, kes eelistavad iseseisvalt tegutseda, jagame juhiseid IPSec/L2TP seadistamiseks meie pilves site-to-site või road-warrior režiimis, ning kui keegi soovib üles tõsta VPN-teenust oma Windows-serveris – oleme alati valmis jagama nippe, kuidas paigaldada standardset RAS-i või OpenVPN-i. Kuid pole vahet, kui toredad me ka ei oleks, see ei olnud parim aeg teadlikkuse tõstmiseks klientide seas, kuna probleem tuli lahendada võimalikult kiiresti, tehes seda kasutajate jaoks minimaalse vaevaga.
Meie rakendatud lahendus hõlmas järgmist. Seadsime sisse liikluse analüüsi viisil, et jälgida kõiki katseid luua TCP-ühendus pordiga 3389 ja valida neist aadressid, mis katsetavad ühenduste loomist rohkem kui 16 erineva serveriga meie võrgus 150 sekundi jooksul – need on rünnaku allikad (loomulikult, kui mõnel meie kliendil või partneril on reaalne vajadus luua ühendusi nii paljude serveritega samast allikast, saab neid alati „valgesse nimekirja“ lisada). Samuti, kui ühes C-klassi võrkus on 150 sekundi jooksul tuvastatud rohkem kui 32 aadressi, on mõistlik blokeerida kogu võrku. Blokeering kehtib 3 päeva, ja kui selle aja jooksul ei ole sellest allikast rünnakuid toimunud, eemaldatakse see allikas automaatselt „mustast nimekirjast“. Blokeeritud allikate nimekiri uuendatakse iga 300 sekundi tagant.
See nimekiri on saadaval järgmise aadressi kaudu: , võite selle põhjal luua oma ACL-e.
Oleme valmis jagama selle süsteemi lähtekoodi, selles pole midagi üleliia keerulist (see on mitmeid lihtsaid skripte, mis on sõna-sõnalt kirjutatud paar tunni jooksul «põlve otsas»), ja sellega saab kohandada ja kasutada mitte ainult kaitseks selliste rünnakute eest, vaid ka igasuguste võrgu skaneerimiskatsete tuvastamiseks ja blokeerimiseks:
Lisaks oleme teinud mõningaid muudatusi jälgimissüsteemi seadetes, mis jälgib nüüd hoolikamalt meie pilves olevate virtuaalserverite kontrollgrupi reageeringut RDP-ühenduse loomise katsele: kui reageeringut ei järgnenud ühe sekundi jooksul – on see põhjus tähelepanu pöörata.
Lahendus osutus piisavalt tõhusaks: kaebusi nii klientidelt kui partneritelt ega jälgimissüsteemilt pole enam. Musta nimekirja lisanduvad regulaarselt uued aadressid ja terved võrgud, mis näitab, et rünnak jätkub, kuid ei mõjuta enam meie klientide tööd.
Ükski sõdur ei ole sõda võitnud.
Täna saime teada, et sarnaste probleemidega on kokku puutunud ka teised operaatorid. Keegi arvab endiselt, et Microsoft tegi kaugjuurdepääsu teenuse koodis mingeid muudatusi (kui mäletate, kahtlesime selles esimesel päeval, kuid seda versiooni lükkasime väga kiiresti tagasi) ja lubab teha kõik endast oleneva, et leida lahendus niipea kui võimalik. Keegi lihtsalt ignoreerib probleemi ja soovitab klientidel ennast kaitsta (vahetada ühendusporti, peita server privaatvõrku ja nii edasi). Me aga lahendasime selle probleemi mitte ainult esimesel päeval, vaid lõime ka aluse ulatuslikuma ohtude avastamise süsteemi jaoks, mida plaanime arendada.
Eriline tänu klientidele ja partneritele, kes ei vaikinud ja ei oodanud, et vaenlane kunagi voolaks, vaid tähelepanu probleemile kohe meie tähelepanu juhtisid, mis andis meile võimaluse selle samal päeval lahendada.
Allikas: habr.com
