Naj vam povemo kul zgodbo o tem, kako so "tretje osebe" poskušale posegati v delo naših strank in kako je bil ta problem rešen.
Kako se je vse začelo
Vse se je začelo 31. oktobra zjutraj, zadnji dan v mesecu, ko mnogi nujno potrebujejo čas za reševanje nujnih in pomembnih zadev.
Eden od partnerjev, ki v našem oblaku hrani več virtualnih strojev strank, ki jim služi, je poročal, da od 9 do 10 več strežnikov Windows, ki se izvajajo na naši ukrajinski strani, ni sprejelo povezav s storitvijo oddaljenega dostopa, uporabniki niso mogli da se prijavijo v svoja namizja, vendar se je po nekaj minutah zdelo, da se je težava odpravila sama od sebe.
Povečali smo statistiko o delovanju komunikacijskih kanalov, vendar nismo ugotovili prometnih sunov ali izpadov. Pogledali smo statistiko o obremenitvi računalniških virov - brez anomalij. In kaj je bilo to?
Potem je drug partner, ki gosti še približno sto strežnikov v našem oblaku, poročal o enakih težavah, kot so jih opazile nekatere njihove stranke, in izkazalo se je, da so bili strežniki na splošno dostopni (pravilno so se odzivali na test ping in druge zahteve), vendar storitev oddaljenega dostopa na teh strežnikih sprejme nove povezave ali jih zavrne, pri čemer smo govorili o strežnikih na različnih mestih, na katere promet prihaja iz različnih kanalov prenosa podatkov.
Poglejmo ta promet. Na strežnik prispe paket z zahtevo za povezavo:
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, vendar zavrne povezavo:
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žave očitno ne povzročajo težave v delovanju infrastrukture, ampak nekaj drugega. Morda imajo vsi uporabniki težave z licenciranjem oddaljenega namizja? Morda je kakšna zlonamerna programska oprema uspela prodreti v njihove sisteme in se je danes aktivirala, kot se je pred nekaj leti XData и Petya?
Medtem ko smo to urejali, smo prejeli podobne zahteve še od več strank in partnerjev.
Kaj se dejansko dogaja na teh strojih?
Dnevniki dogodkov so polni sporočil o poskusih uganjanja gesla:
Običajno so takšni poskusi registrirani na vseh strežnikih, kjer se za storitev oddaljenega dostopa uporabljajo standardna vrata (3389) in je dostop dovoljen od vsepovsod. Internet je poln robotov, ki nenehno pregledujejo vse razpoložljive povezave in poskušajo uganiti geslo (zato toplo priporočamo uporabo zapletenih gesel namesto »123«). Vendar je bila intenzivnost teh poskusov tisti dan prevelika.
Kaj naj storim?
Strankam priporočate, da porabijo veliko časa za spreminjanje nastavitev za ogromno število končnih uporabnikov, da preklopijo na druga vrata? Ni dobra ideja, kupci ne bodo zadovoljni. Priporočate, da omogočite dostop samo prek VPN? V naglici in panično dvigovanje IPSec povezav za tiste, ki jih nimajo dvignjenih - morda se takšna sreča ne nasmehne tudi odjemalcem. Čeprav moram reči, da je to v vsakem primeru božja stvar, vedno priporočamo skrivanje strežnika v zasebnem omrežju in smo pripravljeni pomagati pri nastavitvah, za tiste, ki se radi sami znajdejo, pa delimo navodila za nastavitev IPSec/L2TP v našem oblaku v načinu od mesta do mesta ali cestnem načinu - bojevnik, in če kdo želi nastaviti storitev VPN na lastnem strežniku Windows, je vedno pripravljen deliti nasvete o tem, kako nastaviti standardni RAS ali OpenVPN. Ampak, ne glede na to, kako kul smo bili, to ni bil najboljši čas za izobraževalno delo med strankami, saj smo morali težavo odpraviti čim hitreje z minimalnim stresom za uporabnike.
Rešitev, ki smo jo implementirali, je bila naslednja. Analizo prehajajočega prometa smo vzpostavili tako, da spremljamo vse poskuse vzpostavitve TCP povezave na vrata 3389 in iz nje izberemo naslove, ki v 150 sekundah poskušajo vzpostaviti povezavo z več kot 16 različnimi strežniki v našem omrežju. - to so viri napada ( Seveda, če ima eden od klientov ali partnerjev resnično potrebo po vzpostavitvi povezave s toliko strežniki iz istega vira, lahko takšne vire vedno dodate na "bel seznam." Še več, če je v enem omrežju razreda C v teh 150 sekundah identificiranih več kot 32 naslovov, je smiselno blokirati celotno omrežje.Blokada je nastavljena na 3 dni in če v tem času ni bil izveden noben napad iz danega vira, ta vir se samodejno odstrani s »črnega seznama«. Seznam blokiranih virov se posodobi vsakih 300 sekund.
Ta seznam je na voljo na tem naslovu: , lahko na podlagi tega sestavite svoje ACL-je.
Pripravljeni smo deliti izvorno kodo takšnega sistema; v njem ni nič preveč zapletenega (to je več preprostih skriptov, sestavljenih v dobesedno nekaj urah na kolenu), hkrati pa ga je mogoče prilagajati in uporabljati brez samo za zaščito pred takšnim napadom, ampak tudi za odkrivanje in blokiranje vseh poskusov skeniranja omrežja:
Poleg tega smo nekoliko spremenili nastavitve nadzornega sistema, ki sedaj natančneje spremlja reakcijo nadzorne skupine virtualnih strežnikov v našem oblaku na poskus vzpostavitve RDP povezave: če reakcija ne sledi v roku drugič, to je razlog za pozornost.
Rešitev se je izkazala za zelo učinkovito: ni več pritožb s strani strank in partnerjev ter sistema nadzora. Novi naslovi in celotna omrežja se redno dodajajo na črno listo, kar pomeni, da se napad nadaljuje, vendar ne vpliva več na delo naših strank.
Nobenega bojevnika na polju
Danes smo izvedeli, da so se na podobno težavo srečali tudi drugi operaterji. Nekdo še vedno verjame, da je Microsoft naredil nekaj sprememb v kodi storitve oddaljenega dostopa (če se spomnite, smo isto posumili že prvi dan, a smo to različico zelo hitro zavrnili) in obljublja, da bo storil vse, da hitro najde rešitev . Nekateri preprosto ignorirajo težavo in odjemalcem svetujejo, naj se zaščitijo sami (spremenijo priključna vrata, skrijejo strežnik v zasebno omrežje itd.). In že prvi dan nismo le rešili te težave, ampak tudi ustvarili temelje za bolj globalen sistem za odkrivanje groženj, ki ga nameravamo razviti.
Posebna zahvala strankam in partnerjem, ki niso ostali tiho in niso obsedeli na bregu reke in čakali, da bo nekega dne po njej priplavalo truplo sovražnika, ampak so nas takoj opozorili na problem, kar nam je dalo možnost, da ga odpravimo. to na isti dan.
Vir: www.habr.com