Povedzme vám zaujímavý 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 to všetko začalo
Všetko sa to začalo ráno 31. októbra, posledný deň v mesiaci, kedy mnohí zúfalo potrebujú mať čas na vyriešenie naliehavých a dôležitých záležitostí.
Jeden z partnerov, ktorý má v našom cloude niekoľko virtuálnych strojov klientov, ktorým obsluhuje, oznámil, že od 9:10 do 9:20 niekoľko serverov Windows bežiacich na našej ukrajinskej stránke neprijímalo pripojenie k službe vzdialeného prístupu, používatelia nemohli aby sa prihlásili na ich plochy, ale po niekoľkých minútach sa zdalo, že sa problém vyriešil sám.
Zvýšili sme štatistiku prevádzky komunikačných kanálov, ale nenašli sme žiadne nárasty ani výpadky návštevnosti. Pozreli sme sa na štatistiky o zaťažení výpočtových zdrojov – žiadne anomálie. A čo to bolo?
Potom ďalší partner, ktorý v našom cloude hosťuje asi sto ďalších serverov, nahlásil rovnaké problémy, ktoré zaznamenali niektorí z ich klientov, a ukázalo sa, že servery boli vo všeobecnosti prístupné (správne reagovali na test ping a iné požiadavky), ale služba vzdialeného prístupu na tieto servery buď prijíma nové pripojenia, alebo ich odmieta, a to sme hovorili o serveroch na rôznych stránkach, ktorých prevádzka pochádza z rôznych kanálov prenosu údajov.
Pozrime sa na túto premávku. Na server dorazí 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 spojenie:
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 v prevádzke infraštruktúry, ale niečo iné. Možno majú všetci používatelia problémy s licencovaním vzdialenej pracovnej plochy? Možno sa nejakému škodlivému softvéru podarilo preniknúť do ich systémov a dnes bol aktivovaný, ako to bolo pred pár rokmi XData и Petya?
Kým sme to riešili, dostali sme podobné požiadavky od niekoľkých ďalších klientov a partnerov.
Čo sa vlastne na týchto strojoch deje?
Denníky udalostí sú plné správ o pokusoch uhádnuť heslo:
Zvyčajne sa takéto pokusy zaregistrujú na všetkých serveroch, kde sa pre službu vzdialeného prístupu používa štandardný port (3389) a prístup je povolený odkiaľkoľvek. Internet je plný robotov, ktorí neustále skenujú všetky dostupné body pripojenia a snažia sa uhádnuť heslo (preto dôrazne odporúčame používať zložité heslá namiesto „123“). Intenzita týchto pokusov však v ten deň bola príliš vysoká.
Čo mám robiť?
Odporúčate, aby zákazníci trávili veľa času zmenou nastavení pre veľké množstvo koncových používateľov pri prechode na iný port? Nie je to dobrý nápad, zákazníci nebudú spokojní. Odporúčate povoliť prístup iba cez VPN? V zhone a panike, zvyšovanie IPSec pripojení pre tých, ktorí ich nemajú zdvihnuté - možno sa takéto šťastie neusmieva ani na klientov. Aj keď musím povedať, že je to v každom prípade bohvieaká vec, vždy odporúčame skryť server v súkromnej sieti a sme pripravení pomôcť s nastaveniami a pre tých, ktorí na to chcú prísť sami, zdieľame návod na nastavenie IPSec/L2TP v našom cloude v režime site-to-site alebo road mode -warrior a ak si chce niekto nastaviť službu VPN na svojom vlastnom serveri Windows, je vždy pripravený podeliť sa o tipy, ako nastaviť štandardný RAS alebo OpenVPN. Ale bez ohľadu na to, akí sme boli v pohode, toto nebol najlepší čas na vzdelávaciu prácu medzi klientmi, pretože sme potrebovali vyriešiť problém čo najrýchlejšie s minimálnym stresom pre používateľov.
Riešenie, ktoré sme implementovali, bolo nasledovné. Analýzu prechádzajúcej prevádzky sme nastavili tak, aby sme monitorovali všetky pokusy o nadviazanie TCP spojenia na port 3389 a vybrali z neho adresy, ktoré sa do 150 sekúnd pokúsia nadviazať spojenie s viac ako 16 rôznymi servermi v našej sieti. - toto sú zdroje útoku ( Samozrejme, ak má jeden z klientov alebo partnerov skutočnú potrebu nadviazať spojenie s toľkými servermi z rovnakého zdroja, vždy môžete takéto zdroje pridať na „bielu listinu“. ak je v jednej sieti triedy C na týchto 150 sekúnd identifikovaných viac ako 32 adries, má zmysel zablokovať celú sieť. Blokovanie je nastavené na 3 dni a ak počas tejto doby nedošlo k žiadnemu útoku z daného zdroja, tento zdroj sa automaticky odstráni z „čiernej listiny“. Zoznam blokovaných zdrojov sa aktualizuje každých 300 sekúnd.
Tento zoznam je dostupný na tejto adrese: , môžete na ňom zostaviť zoznamy prístupových práv.
Sme pripravení zdieľať zdrojový kód takéhoto systému, nie je v ňom nič prehnane zložité (ide o niekoľko jednoduchých skriptov zostavených doslova za pár hodín na kolene) a zároveň sa dá prispôsobiť a použiť nie nielen na ochranu pred takýmto útokom, ale aj na detekciu a blokovanie akýchkoľvek pokusov o skenovanie siete:
Okrem toho sme urobili niekoľko zmien v nastaveniach monitorovacieho systému, ktorý teraz podrobnejšie sleduje reakciu riadiacej skupiny virtuálnych serverov v našom cloude na pokus o nadviazanie RDP spojenia: ak reakcia nenasleduje v rámci po druhé, toto je dôvod venovať pozornosť.
Riešenie sa ukázalo ako celkom efektívne: už nie sú žiadne sťažnosti zo strany klientov a partnerov ani zo strany monitorovacieho systému. Na čiernu listinu pravidelne pribúdajú nové adresy a celé siete, čo naznačuje, že útok pokračuje, ale už neovplyvňuje prácu našich klientov.
V číslach je bezpečnosť
Dnes sme sa dozvedeli, že s podobným problémom sa stretli aj ďalší operátori. Niekto stále verí, že Microsoft urobil nejaké zmeny v kóde služby vzdialeného prístupu (ak si pamätáte, prvý deň sme tušili to isté, ale túto verziu sme veľmi rýchlo zamietli) a sľubuje, že urobí všetko pre to, aby sme rýchlo našli riešenie. . Niektorí ľudia jednoducho ignorujú problém a radia klientom, aby sa chránili sami (zmenili port pripojenia, skryli server v súkromnej sieti atď.). A hneď v prvý deň sme nielen vyriešili tento problém, ale vytvorili sme aj základy pre globálnejší systém detekcie hrozieb, ktorý plánujeme vyvinúť.
Osobitné poďakovanie patrí klientom a partnerom, ktorí nezostali ticho a nesedeli na brehu rieky a nečakali, kým sa po nej jedného dňa bude vznášať mŕtvola nepriateľa, ale okamžite nás upozornili na problém, ktorý nám dal možnosť odstrániť to v ten istý deň.
Zdroj: hab.com