Řekněme vám skvělý příběh o tom, jak se "třetí strany" pokusily zasahovat do práce našich klientů a jak byl tento problém vyřešen.
Jak to vše začalo
Vše začalo ráno 31. října, poslední den v měsíci, kdy mnozí zoufale potřebují mít čas na vyřešení naléhavých a důležitých záležitostí.
Jeden z partnerů, který má v našem cloudu několik virtuálních strojů klientů, kterým obsluhuje, oznámil, že od 9:10 do 9:20 několik serverů Windows běžících na našem ukrajinském webu nepřijímalo připojení ke službě vzdáleného přístupu, uživatelé nemohli přihlásit se na jejich plochy, ale po několika minutách se zdálo, že se problém vyřešil sám.
Zvýšili jsme statistiky provozu komunikačních kanálů, ale nenašli jsme žádné nárůsty nebo výpadky provozu. Podívali jsme se na statistiky zatížení výpočetních zdrojů – žádné anomálie. A co to bylo?
Pak další partner, který v našem cloudu hostuje asi sto dalších serverů, nahlásil stejné problémy, které zaznamenali někteří jejich klienti, a ukázalo se, že obecně byly servery přístupné (správně reagovaly na test ping a další požadavky), ale služba vzdálený přístup na tyto servery buď přijímá nová připojení, nebo je odmítá, a to jsme hovořili o serverech na různých stránkách, na které provoz přichází z různých kanálů přenosu dat.
Podívejme se na tento provoz. Na server dorazí paket s požadavkem na připojení:
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 přijme tento paket, ale odmítne připojení:
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 zjevně nezpůsobují žádné problémy v provozu infrastruktury, ale něco jiného. Možná mají všichni uživatelé problémy s licencováním vzdálené plochy? Možná se nějakému malwaru podařilo proniknout do jejich systémů a dnes byl aktivován, jako tomu bylo před pár lety XData и Petya?
Zatímco jsme to řešili, dostali jsme podobné požadavky od několika dalších klientů a partnerů.
Co se vlastně na těchto strojích děje?
Protokoly událostí jsou plné zpráv o pokusech uhodnout heslo:
Obvykle jsou takové pokusy registrovány na všech serverech, kde se pro službu vzdáleného přístupu používá standardní port (3389) a přístup je povolen odkudkoli. Internet je plný robotů, kteří neustále skenují všechna dostupná připojení a snaží se uhodnout heslo (proto důrazně doporučujeme používat složitá hesla místo „123“). Intenzita těchto pokusů však toho dne byla příliš vysoká.
Co dělat?
Doporučujete, aby zákazníci strávili spoustu času změnou nastavení pro velké množství koncových uživatelů, aby přešli na jiný port? Není to dobrý nápad, zákazníci nebudou spokojeni. Doporučujete povolit přístup pouze přes VPN? Ve spěchu a panice navyšování IPSec připojení pro ty, kteří je nemají zvednuté – takové štěstí se snad neusměje ani na klienty. I když musím říct, že je to v každém případě bohulibá věc, vždy doporučujeme server schovat do privátní sítě a jsme připraveni pomoci s nastavením a pro ty, kteří si to rádi přijdou sami, sdílíme návod pro nastavení IPSec/L2TP v našem cloudu v režimu site-to-site nebo road mode -warrior, a pokud chce někdo nastavit službu VPN na svém vlastním serveru Windows, je vždy připraven sdílet tipy, jak nastavit standardní RAS nebo OpenVPN. Ale bez ohledu na to, jak jsme byli v pohodě, nebyl to nejlepší čas na provádění vzdělávací práce mezi klienty, protože jsme potřebovali problém vyřešit co nejrychleji s minimálním stresem pro uživatele.
Řešení, které jsme implementovali, bylo následující. Analýzu procházejícího provozu jsme nastavili tak, abychom sledovali všechny pokusy o navázání TCP spojení na port 3389 a vybrali z něj adresy, které se během 150 sekund pokusí navázat spojení s více než 16 různými servery v naší síti. - toto jsou zdroje útoku ( Samozřejmě, pokud má jeden z klientů nebo partnerů skutečnou potřebu navázat spojení s tolika servery ze stejného zdroje, můžete takové zdroje vždy přidat na „bílou listinu“. pokud je v jedné síti třídy C po těchto 150 sekund identifikováno více než 32 adres, má smysl zablokovat celou síť. Blokace je nastavena na 3 dny a pokud během této doby nebyly provedeny žádné útoky z daného zdroje, tento zdroj je automaticky odstraněn z „černé listiny“. Seznam blokovaných zdrojů se aktualizuje každých 300 sekund.
Tento seznam je dostupný na této adrese: , můžete na něm sestavit své ACL.
Jsme připraveni sdílet zdrojový kód takového systému, není v něm nic přehnaně složitého (jedná se o několik jednoduchých skriptů zkompilovaných doslova za pár hodin na koleně) a zároveň jej lze upravovat a používat ne pouze k ochraně před takovým útokem, ale také k detekci a blokování jakýchkoli pokusů o skenování sítě:
Kromě toho jsme provedli některé změny v nastavení monitorovacího systému, který nyní podrobněji sleduje reakci řídící skupiny virtuálních serverů v našem cloudu na pokus o navázání RDP spojení: pokud reakce nenastane v rámci za druhé, toto je důvod věnovat pozornost.
Řešení se ukázalo jako docela efektivní: již nejsou žádné stížnosti jak ze strany klientů a partnerů, tak ze strany monitorovacího systému. Na blacklist jsou pravidelně přidávány nové adresy a celé sítě, což naznačuje, že útok pokračuje, ale již neovlivňuje práci našich klientů.
Sám v poli není válečník
Dnes jsme se dozvěděli, že s podobným problémem se setkali i další operátoři. Někdo stále věří, že Microsoft provedl nějaké změny v kódu služby vzdáleného přístupu (pokud si vzpomínáte, první den jsme tušili totéž, ale tuto verzi jsme velmi rychle zavrhli) a slibuje, že udělá vše pro rychlé nalezení řešení . Někteří lidé tento problém jednoduše ignorují a radí klientům, aby se chránili sami (změnili port připojení, skryli server v privátní síti a tak dále). A hned první den jsme nejen vyřešili tento problém, ale také vytvořili základy pro globálnější systém detekce hrozeb, který plánujeme vyvinout.
Zvláštní poděkování patří klientům a partnerům, kteří nezůstali zticha a neseděli na břehu řeky a nečekali, až se po ní jednoho dne poplave mrtvola nepřítele, ale okamžitě nás upozornili na problém, který nám dal možnost odstranit to ve stejný den.
Zdroj: www.habr.com