Červ, který rozdrtil firemní obranu

Červ Sasser by nikdy nemohl proniknout síťovou obranou firmy, kdyby byly včas a zodpovědně realizovány všechny zamýš...


Červ Sasser by nikdy nemohl proniknout síťovou obranou firmy, kdyby byly včas a
zodpovědně realizovány všechny zamýšlené projekty.
Původně jsem byl skálopevně rozhodnut, že v tomto týdnu provedu testy a
hodnocení produktů zajišťujících šifrování disků. Pak se ale náhle objevil červ
Sasser a pronikl všemi liniemi naší obrany. Ještě více frustrující než samotný
úspěšný útok pro nás byl důvod jeho úspěchu: Projekty, jejichž realizaci jsme
již dříve navrhovali a které mohly červa zastavit, byly z řady důvodů smeteny
ze stolu.
Ještě před tím, než nás Sasser přinutil změnit cíl našeho úsilí, jsme pracovali
na plánech pro zlepšení bezpečnosti ve firmě. Spolu se svým týmem jsem již
takřka ukončil výběr vhodného produktu pro aplikaci softwarových záplat. Byli
jsme téměř stoprocentně rozhodnutí pro produkt PatchLink Update společnosti
PatchLink. V naší firmě totiž provozujeme řadu serverů a operačních systémů a
tento produkt byl schopen během provedených testů spolupracovat s naprostou
většinou z nich.
Než ale projekt dotáhneme do konce, musíme řešit jiné problémy. Takové, které
bohužel vyplývají z nedostatečné aplikace záplat, kterou má na svědomí náš
současný systém. Útok červa W32/Sasser je pouze dalším příkladem takového
problému.
Sasser s úspěchem využívá již delší dobu známé slabiny ve službě MS LSASS
(Local Security Authority Subsystem Service), která je součástí systému pro
správu bezpečnosti a autentizace v rámci sítí s Windows. Pokud by naše
společnost aplikovala vhodné záplaty ihned, jak byly dostupné, mohla si úspěšný
útok červa Sasser ušetřit.

V útoku
Jak už to tak bývá, poprvé jsme si všimli, že něco není v pořádku, když byl náš
IT helpdesk zavalen telefonáty informujícími o svévolných pádech některých
systémů. Spolu s nimi se zobrazovalo dialogové okno indikující problém s LSA
Shellem. V ten samý čas se výrazně zvýšilo využití přenosového pásma v síti.
Obrátili jsme se na našeho experta na IDS (Intrusion Detection System) Snort,
který velmi rychle spojil vzniklý provoz s činností Sasseru. Tento červ útočí
tím způsobem, že hledá napadnutelné stroje prostřednictvím TCP portu 445, který
je využíván pro Windows networking. Jakmile Sasser najde vhodnou oběť, rozšíří
se prostřednictvím instalace FTP (File Transfer Protocol) serveru na port 5 554
a nechává otevřený port 9 996 pro vykonávání příkazů. Následně modifikuje
několik služeb a zápisů v registrech, což způsobí pád systému. A potom se dál
šíří prostřednictvím skenování zranitelných systémů a jejich nasměrováním na
FTP server, odkud si mohou stáhnout škodlivý kód.
Dopad útoku Sasseru na mou společnost byl opravdu zásadní. Telefonická volání
na náš helpdesk začala brzy chodit nejen z centrály, ale také z poboček a
posléze i od zámořských poboček a od jednotlivých uživatelů připojených přes
DSL. Ačkoli jsme věděli, že bychom měli co nejdříve nalézt všechny nakažené
systémy, neměli jsme dostatečné prostředky, abychom tak učinili. A tak, abychom
získali čas, jsme požádali naši skupinu síťových správců, aby rekonfigurovala
přístupové seznamy (ACL, Access Control List) na našich síťových zařízeních tím
způsobem, že zablokuje porty 5 554 a 9 996.
Používáme software od Solsoftu pro centrální správu našich přístupových
seznamů, ale disponujeme bohužel také řadou zařízení, která jím na dálku
spravovat nemůžeme. A tak jsme strávili několik hodin jejich postupnou
rekonfigurací.
Poté, co byly všechny seznamy updatovány, snížila se degradace sítě, stejně
jako rychlost šíření Sasseru. Nyní bylo třeba najít stroje, které měly otevřen
port 5 554 nebo 9 996.

Zpět k portu
Naše společnost využívá pro automatický sken několika linuxových serverů.
Chtěli jsme proskenovat každý server ve firmě, ale právě jsem požádal síťové
správce o zablokování veškerého provozu na portech 5 554 a 9 996. Takže skenery
nemohly pracovat. Musel jsem tedy za síťovými správci zajít znovu a opět je
požádat o změnu nastavení všech routerů, firewallů a přepínačů. Abych to řekl
jemně nebyli příliš šťastní.
Když se ohlédnu zpět, musím říci, že jsme to vše měli odhadnout dopředu. Možná,
že to mělo být součástí našich interních popisů správných postupů. Místo toho
jsme ale změnili ACL ve snaze uhasit požár bez toho, abychom si uvědomili, že
bude třeba servery také proskenovat.
Po několika dalších hodinách strávených nad změnami přístupových seznamů jsme
byli konečně schopni začít provádět skenování serverů. Tucty jich byly
infikované a většina z takto postižených strojů se nacházela ve vývojových
laboratořích.
Bezpečnostní situace v této části naší firmy byla po nějakou dobu jablkem
sváru. Servery, které se zde nacházejí, nejsou opečovávány se stejnou
pozorností jako produkční systémy, a tak je celkem běžné, že zde člověk najde
servery bez aplikovaných záplat. O tomto problému víme již několik měsíců a za
tu dobu jsem se již několikrát snažil dosáhnout odpojení těchto systémů od
zbytku firemní sítě. I když jsem v těchto snahách zaznamenal určité úspěchy,
část laboratoří stále vzdorovala. Teď neseme následky.

Posílení hradeb
Již delší dobu také zvažujeme nasazení produktu FortiGate od společnosti
Fortinet. Jde o zařízení typu "vše v jednom" obsahuje antivirus pracující v
reálném čase, firewall, služby VPN (Virtual Private Network) a IDS/P (Intrusion
Detection System/Prevention).
Plánujeme umístění těchto zařízení k našim VPN branám, abychom síť bránili
proti uživatelům, kteří se do sítě připojují přes VPN koncentrátor. Mnozí z
těchto uživatelů mají na svých domácích počítačích nainstalován náš VPN
software a v několika případech zavlekly tyto počítače do naší sítě škodlivé
kódy.
Chtěli bychom používat i další metody obrany, jako například omezený vzdálený
přístup k určitým strojům prostřednictvím jejich MAC (Media Access Control)
adres nebo prostřednictvím PKI (Public Key Infrastructure). Nebo bychom mohli
nakonfigurovat VPN klienta, aby se odmítl připojit, dokud na desktopu není
nainstalován a spuštěn požadovaný firewall a antivirus.
Příští týden se bude konat setkání více oddělení, kde bude řeč i o Sasseru. I
tam se budeme snažit najít cesty, jak zlepšit proces reakce na podobné
bezpečnostní incidenty. Musíme opravdu zapracovat na tom, abychom naši
infrastrukturu posunuli do stavu, kdy bude takovým hrozbám úspěšně odolávat.
Ale každá technologická změna, která má vyřešit uvedené problémy, s sebou nese
nutnost překonat strašlivou kombinaci kulturních, obchodních a dalších potíží
včetně finančních než se změny podaří realizovat. Bohužel i nejrozumněji
znějící požadavky na změny vyžadují množství času, než jsou schváleny. Naše
neschopnost reagovat rychle a rozhodně nás tak zbytečně vystavuje velkým
bezpečnostním rizikům.
Řešíte podobné problémy jako Mathias Thurman? Podělte se o svoje zkušenosti s
námi i se čtenáři Computerworldu. Můžete psát na adresu bezpecnost@idg.cz.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.