Pekelná výheň SQL a zdánlivý pokus o DoS

Rychlá odpověď na příchod červa SQL Slammer odráží potenciální pohromu. Vzápětí však přichází hlášení o p...


Rychlá odpověď na příchod červa SQL Slammer odráží potenciální pohromu. Vzápětí
však přichází hlášení o podivném přetížení sítě.
Na konci letošního ledna se internetem doslova prohnal červ Slammer. Naše
společnost na něj byla dobře připravena, takže tu nezpůsobil žádné škody.
Přesto jsme ale následně znovu udělali pečlivou analýzu potenciálních hrozeb,
abychom se ubezpečili, že jsme i do budoucna dobře chráněni. Jak se dalo čekat,
zjistili jsme, že nic není stoprocentní.
Červ Slammer zneužívá slabiny Microsoft SQL Serveru, která za jistých okolností
umožní přetečení bufferu a následně vytváří záplavu paketů podobnou útoku typu
DoS (Denial of Service). Přitom neprovádí žádné skenování serverového softwaru,
na který útočí. Vybírá si náhodně a snaží se infikovat cokoli ve svém dosahu.
Podle nedávno zveřejněné studie byl tento červ přesto dosud nejrychleji se
šířícím internetovým červem. Během prvních třech minut šíření se prý každých
8,5 sekundy zdvojnásobovalo množství infikovaných počítačů, k čemuž mj.
přispěla délka červa 376 bajtů, do kterých se jeho kód vešel, se vměstná do
jediného 404bajtového paketu protokolu UDP.

Naše příprava
Jak jsem už zmínil v úvodu, pečlivá příprava pomohla mé společnosti útok tohoto
červa odrazit. Krátce poté, co se objevil, jsme se rozhodli spustit skenovací
nástroje pro naši infrastrukturu, abychom nalezli potenciálně ohrožené systémy
a aplikovali na ně příslušné záplaty. V mezidobí jsme implementovali do našich
hraničních routerů společnosti Cisco Systems funkci NBAR (Network Based
Application Recognition), kterou jsme nastavili tak, aby vyřadila jakékoli
pakety, jejichž znaky odpovídají paketům útoku červa Slammera.
Problém s NBAR je ale ten,že jde o velmi dočasné řešení. Routery jsou totiž
navrženy k tomu, aby směrovaly provoz, nikoli proto, aby prováděly kontrolu
procházejících paketů. Funkce NBAR tak spotřebovává významnou část výkonu
routeru a může vést k problémům s výkonností. Proto jsme ji nechtěli nechat
zapnutou déle, než to bude nezbytně nutné.
Jakmile byla nastavena pravidla funkce NBAR, odeslali jsme po naší firmě e-mail
s odkazem na webovou stránku, kterou jsme stvořili. Stránka obsahovala
informace o červu SQL Slammer, instrukce pro zjištění, zda je určitý systém
zranitelný tímto červem, a odkaz na záplatu, která řeší problém této
bezpečnostní slabiny. Teprve poté, co jsme provedli další skenování a zjistili
jsme, že záplaty byly aplikovány, a tudíž není žádný z našich systémů červem
zranitelný, jsme zase vypnuli funkci NBAR.
Zdálo se, že se dílo podařilo, ale stoprocentně úspěšní jsme nebyli. Pár
zatoulaných serverů bylo bůhvíjak infikováno. Ještě o týden později jsme
nacházeli systémy, do kterých červ pronikl.

Útok typu DoS?
Několik dní po počátečním incidentu s SQL Slammerem mi volalo naše NOC (Network
Operations Center) a hlásilo mi, že jsou naše servery vystaveny útoku DoS.
Protože máme jen omezenou možnost monitorovat využití přenosového pásma na
některých hraničních zařízeních naší sítě, nebylo hned zcela jisté, co se
vlastně děje. Nicméně využití těchto zařízení bylo zjevně extrémně vysoké, a
výkonnost sítě tak trpěla. Vytáhli jsme si tedy data z našeho systému IDS
(Intrusion Detection System), prozkoumali pakety a objevili nadměrný provoz po
FTP (File Transfer Protocol).
Vzápětí se ukázalo, že naše společnost právě uvolnila nový software pro
download, jehož velikost přesahuje 40 MB. Provoz, který vznikl jeho stahováním,
tak zahltil naši síť. Protože nejsme schopni během několika hodin nebo dní
udělat v našich systémech tak významné změny, aby si síť s podobným nárazovým
zatížením poradila, rozhodli jsme se download outsourcovat prostřednictvím
služby EdgeSuite firmy Akamai Technologies.
Implementace proběhla bez problémů. S několika změnami v konfiguracích našich
serverů a s několika přesměrováními jsme byli připraveni poskytnout našim
zákazníkům bezproblémové stažení softwaru a uživatelům dostatečný výkon sítě.
V blízké budoucnosti se musíme rozhodnout, zda nakonec naši síť upgradujeme,
aby si s takovým objemem provozu poradila, či zda službu downloadů natrvalo
outsourcujeme k nějakému poskytovateli spravovatelných služeb. Možná, že prostě
zůstaneme u Akamai Technologies.

Ach ta správa
Poté, co jsem tento incident sprovodil ze světa, začal jsem hledat nějaký
jednoduchý způsob, jak získat možnost centralizované správy přístupu pro naše
servery se systémem Sun Solaris.
V minulosti většina unixových správců používala prostě Unix NIS (Unix Network
Information Service). Kvůli některým slabinám tohoto systému jsme se ale tohoto
řešení zbavili a zaměřili jsme se na nástroje, které by bylo možno integrovat s
našimi službami Novell eDirectory.
Systém eDirectory používáme pro všechny naše podnikové účty. Slouží jako
databáze informací o uživatelích pro řízení přístupu k PeopleSoftu, Siebelu a k
dalším aplikacím. Nový systém musí umožňovat centrální správu informací typu
uživatelského jména, hesla a domovského adresáře prostřednictvím eDirectory a
musí správci umožnit zvolit si logovací shell pro každého uživatele.
V naší firmě používáme tokeny SecurID od společnosti RSA Security. SecurID
software je aktivován při logování prostřednictvím shellu. Po troše pátrání a
několika telefonátech jsme se rozhodli implementovat nějaký specializovaný
autentizační modul. Na trhu je takových modulů dostupných několik, záleží jen
na tom, co chcete integrovat. My chceme, aby byly kompletní údaje o uživatelích
uloženy v databázi kompatibilní s LDAP, a tak jsme použili modul, který to
umožnil. Aby celý systém fungoval, potřebovali jsme, aby byly knihovny modulu a
klient LDAP nainstalovány na našich serverech se Solarisem.
Brzy se bohužel ukázalo, že nejsme schopni přimět nativního klienta LDAP pro
Solaris, aby fungoval se zmíněným autentizačním modulem a správně se
autentizoval do našeho systému Novell eDirectory. Místo toho jsme museli použít
integrační nástroj LDAP od třetí strany vytvořený australskou společností PADL
Software. Knihovny PADL nám umožnily úspěšně směrovat autentizační požadavky do
eDirectory. Provedli jsme několik předběžných testů a téměř vše se zdálo
pracovat tak, jak bylo inzerováno.
Jeden problém, který se však stále snažíme dořešit, je navázání šifrovaného
spojení mezi Solarisem a serverem eDirectory. Původně jsme si mysleli, že
budeme moci použít technologii SSL (Secure Sockets Layer), ale tady se vyskytly
problémy. Nyní tedy
experimentujeme s protokolem IPSec, ale to bude vyžadovat další rekonfiguraci
na každém unixovém systému, který budeme chtít tímto způsobem chránit.

Nové vlastnosti
Další problém, kterému čelíme, je podpora pro některé dodatečné vlastnosti mimo
autentizační část nasazení celého systému. Mohli bychom například chtít povolit
netgroups (které sdružují dohromady počítače a uživatele se shodnými právy ke
zdrojům, takže je možno celý systém lépe spravovat) a RBAC (Role Based Access
Control).
Když používáme autentizační modul a knihovny PADL se Solarisem 2.8 a
eDirectory, nejsme schopni tyto dodatečné vlastnosti nastavit. Díky testování
Solarisu 9 a iPlanet LDAP serveru od Netscape však víme, že je tato
funkcionalita možná. Takže by teoreticky by to mělo fungovat i s Novell
eDirectory založeném na LDAP. Praxe však bývá často jiná než teorie. V čem je
chyba? Možná, že do příštího článku už budu moci napsat odpověď na tuto otázku.
Ř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.