Povieme vám mrazivý príbeh o tom, ako sa „tretie strany“ snažili zasahovať do práce našich klientov a ako sa tento problém vyriešil.
Ako sa to všetko začalo
Všetko sa to začalo ráno 31. októbra, posledný deň v mesiaci, keď mnohí zúfalo potrebovali vyriešiť naliehavé a dôležité záležitosti.
Jeden z našich partnerov, ktorý hostuje niekoľko virtuálnych počítačov pre klientov, ktorým slúži v našom cloude, oznámil, že od 9:10 do 9:20 niekoľko WindowsServery bežiace na našej ukrajinskej stránke neprijímali pripojenia k službe vzdialeného prístupu a používatelia sa nemohli pripojiť k svojim počítačom. Po niekoľkých minútach sa však problém zdal byť sám vyriešený.
Skontrolovali sme štatistiky komunikačných kanálov, ale nenašli sme žiadne nárasty ani poklesy prevádzky. Skontrolovali sme aj štatistiky zaťaženia výpočtových zdrojov – žiadne anomálie. Čo to teda bolo?
Potom ďalší partner, ktorý v našom cloude hostuje takmer sto ďalších serverov, nahlásil rovnaké problémy, aké zaznamenali niektorí jeho klienti. Ukázalo sa, že servery boli vo všeobecnosti dostupné (správne reagovali na ping testy a iné požiadavky), ale služba vzdialeného prístupu na týchto serveroch niekedy prijímala nové pripojenia, niekedy ich odmietala. Týkalo sa to serverov na rôznych miestach s prevádzkou prichádzajúcou z rôznych kanálov prenosu dát.
Pozrime sa na túto prevádzku. Na server prichádza paket so žiadosťou o pripojenie:
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 prijme tento paket, ale odmietne pripojenie:
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 znamená, že problém zjavne nespôsobujú žiadne problémy s infraštruktúrou, ale niečo iné. Možno všetci používatelia majú problémy s licencovaním vzdialenej plochy? Možno sa do ich systémov dostal nejaký škodlivý softvér a dnes sa aktivoval, ako sa to stalo... pred pár rokmi. XData и Petya?
Počas nášho vyšetrovania sme dostali podobné žiadosti od niekoľkých ďalších klientov a partnerov.
Čo sa to vlastne s týmito strojmi deje?
Denníky udalostí sú plné správ o pokusoch o uhádnutie hesla:
Takéto pokusy sa zvyčajne zaznamenávajú na všetkých serveroch, ktoré používajú štandardný port (3389) pre vzdialený prístup a umožňujú prístup odkiaľkoľvek. Internet sa hemží botmi, ktoré neustále prehľadávajú všetky dostupné pripojenia a pokúšajú sa uhádnuť heslá (z tohto dôvodu dôrazne odporúčame používať zložité heslá namiesto „123“). Intenzita týchto pokusov však bola v ten deň extrémne vysoká.
Čo mám robiť?
Odporúčať klientom, aby strávili kopec času zmenou nastavení pre obrovské množstvo koncových používateľov len preto, aby prepli na iný port? Nie je to dobrý nápad; klienti nebudú spokojní. Odporúčať povoliť prístup iba cez VPN? Ponáhľať sa s nastavením IPSec pripojení v panike, keď ich nemajú spustené a funkčné – pravdepodobne by to nebolo ani pre klientov šťastné miesto. Treba však povedať, že je to v každom prípade dobrá vec. Vždy odporúčame skryť server v súkromnej sieti a sme pripravení pomôcť s konfiguráciou. Pre tých, ktorí si radšej veci riešia sami, zdieľame pokyny na nastavenie IPSec/L2TP v našom cloude v režime site-to-site alebo road-warrior. A ak si niekto chce nastaviť VPN službu sám, Windows-server – vždy pripravený podeliť sa o tipy, ako zvýšiť štandard RAS alebo OpenVPNAle bez ohľadu na to, akí sme boli šikovní, nebol to najlepší čas na vzdelávanie zákazníkov, pretože sme potrebovali problém vyriešiť čo najrýchlejšie s minimálnym narušením prevádzky používateľov.
Riešenie, ktoré sme implementovali, bolo nasledovné. Nakonfigurovali sme analýzu prevádzky tak, aby sledovala všetky pokusy o nadviazanie TCP pripojenia na port 3389 a identifikovala adresy, ktoré sa pokúšajú pripojiť k viac ako 16 rôznym serverom v našej sieti do 150 sekúnd – to sú zdroje útokov. (Samozrejme, ak niektorí z našich klientov alebo partnerov skutočne potrebujú nadviazať pripojenie k toľkým serverom z rovnakého zdroja, môžeme takéto zdroje vždy pridať na bielu listinu.) Okrem toho, ak sa v jednej sieti triedy C do týchto 150 sekúnd zistí viac ako 32 adries, má zmysel zablokovať celú sieť. Doba blokovania je nastavená na 3 dni a ak sa počas tejto doby nevykonajú žiadne útoky z daného zdroja, automaticky sa odstráni z čiernej listiny. Zoznam blokovaných zdrojov sa aktualizuje každých 300 sekúnd.
Tento zoznam je k dispozícii na nasledujúcej adrese: , môžete si na jeho základe vytvoriť vlastné ACL.
Radi sa s vami podelíme o zdrojový kód tohto systému. Nie je to nič príliš zložité (len niekoľko jednoduchých skriptov, ktoré sa dajú zostaviť za pár hodín) a dá sa prispôsobiť a použiť nielen na ochranu pred takýmito útokmi, ale aj na detekciu a blokovanie akýchkoľvek pokusov o skenovanie siete:
Okrem toho sme vykonali niekoľko zmien v nastaveniach nášho monitorovacieho systému, ktorý teraz dôkladnejšie monitoruje reakciu kontrolnej skupiny virtuálnych serverov v našom cloude na pokusy o nadviazanie RDP pripojenia: ak sa reakcia neobjaví do sekundy, je to dôvod na obavy.
Riešenie sa ukázalo ako celkom efektívne: už neexistujú žiadne sťažnosti od klientov, partnerov ani monitorovacieho systému. Na čiernu listinu sa pravidelne pridávajú nové adresy a celé siete, čo naznačuje, že útok pokračuje, ale už neovplyvňuje prevádzku našich klientov.
V číslach je bezpečnosť
Dnes sme sa dozvedeli, že s podobným problémom sa stretli aj iní operátori. Niektorí stále veria, že spoločnosť Microsoft vykonala nejaké zmeny v kóde služby vzdialeného prístupu (ak si spomínate, aj my sme mali to isté podozrenie prvý deň, ale túto teóriu sme rýchlo zavrhli) a sľubujú, že urobia všetko pre to, aby čo najskôr našli riešenie. Iní problém jednoducho ignorujú a radia klientom, aby sa chránili (zmenili port pripojenia, skryli server v súkromnej sieti atď.). Hneď v prvý deň sme tento problém nielen vyriešili, ale položili sme aj základy pre komplexnejší systém detekcie hrozieb, ktorý plánujeme vyvinúť.
Špeciálne poďakovanie patrí našim klientom a partnerom, ktorí nemlčali ani nesedeli na brehu rieky a nečakali, kým po nej jedného dňa spláva nepriateľská mŕtvola. Namiesto toho nás na problém okamžite upozornili, čo nám umožnilo ho vyriešiť ešte v ten istý deň.
Zdroj: hab.com
