Špatná komunikace usnadňuje útok červa

Včasné varování zůstává bez povšimnutí. SQL Slammer si tak nachází cestu do firemní sítě a rozpoutává se peklo...


Včasné varování zůstává bez povšimnutí. SQL Slammer si tak nachází cestu do
firemní sítě a rozpoutává se peklo.
Náš systém detekce narušení (IDS, Intrusion Detection System) sestává v zásadě
z několika PC, která fungují jako síťové senzory, na nichž běží open source
software Snort. Tento IDS funguje velmi dobře mimo jiné nás včas varoval před
nadcházejícím útokem SQL Slammer. Bohužel marně.
Nefungovala totiž komunikace mezi mojí skupinou a oddělením, které má na
starosti provoz v síti. A tak malá nepříjemnost přerostla v problém velkého
rozsahu. Nyní management hovoří o tom, že by odpovědnost za nápravu mělo
převzít moje malé oddělení ale na zvládnutí tohoto úkolu nejsme připraveni.
Po našich sítích na celém světě máme rozmístěno více než 25 IDS senzorů, a tak
vidíme přes 90 % celého interního provozu naší firmy. Zbývajících 10 % pochází
z našich technických laboratoří; monitorování tohoto provozu plánujeme na dobu,
kdy budeme mít k dispozici příslušné zdroje.

Podrobný pohled
S pomocí IDS máme k dispozici unikátní pohled na naši síť. Jsme jediným IT
oddělením ve firmě, které vidí veškerý provoz, jakmile vstupuje do naší sítě
nebo ji opouští, a zkoumá jej na úrovni paketů. S tímto úplným pohledem není
překvapivé, že jsme si aktivity související s SQL Slammerem útokem všimli jako
první.
Červ Slammer vstoupil do naší sítě přes nezáplatovaný server v jedné z našich
technických laboratoří. Osoba, která IDS monitorovala, si všimla odchozího
provozu, který odpovídal SQL Slammeru, zhruba v půl osmé ráno, a vystopovala
jeho původ zpět k serveru v laboratoři. Příslušný zaměstnanec následně odeslal
e-mail s detaily podezřelého provozu a následně zavolal příslušnému oddělení a
zanechal hlasovou zprávu.
Skupina zajišťující provoz sítě dostává takové množství e-mailů, že jakmile ji
neupozorníte, že jste odeslali něco důležitého, může se stát, že zpráva zůstane
bez povšimnutí. A přesně to se tentokrát také stalo. E-mailové varování si
nikdo nepřečetl a hlasovou zprávu nevyzvedl včas, aby bylo možno útok
zablokovat. O několik hodin později jsme se museli potýkat s ohromným množstvím
zpráv o problémech se sítí a servery.
Přestože SQL Slammer pochází z ledna 2003, různé jeho verze se po internetu
pohybují dodnes. Mezitím zaměstnanci naší firmy stále instalují nové a nové
servery, zvláště pak v laboratorním prostředí, a tyto servery nejsou vybaveny
příslušnými záplatami a opravnými balíčky. Proto jsme zranitelní vůči útoku SQL
Slammeru i mnoha dalším.
Důsledky zmíněného útoku byly drahé. Při posledním incidentu jsme museli
nastavit seznamy přístupových práv na příslušných klíčových směrovačích,
abychom omezili následky útoku, což vyžadovalo mnohahodinovou práci 15-20 lidí.
Pokud by byly stroje záplatovány, k žádnému incidentu nemuselo dojít. Ale i
když tomu tak nebylo, tak v případě, že by komunikace lépe fungovala a odezva
na počáteční varování byla rychlejší, bylo by možno zamezit eskalaci problému.
Se svým týmem se snažím vyřešit problém zranitelných míst v laboratořích.
Protože máme jen omezenou kontrolu nad tím, jak se zde servery nastavují,
rozhodli jsme se mezi laboratorními počítači a segmenty firemní sítě nasadit
zařízení, která nabízejí filtrování URL, skenování proti virům a určité funkce
firewallu.
Chceme se také zabývat problémem s komunikací a hlášením incidentů, k čemuž
hodláme využít nástroj pro korelaci dat, který bude odesílat varovná hlášení na
konzoli, která je lépe spravovatelná než běžná poštovní schránka. Nechceme se
prostě už spoléhat na nejistý e-mail.

Překvapivé řešení
Nejsme však jediní, kdo přichází s řešeními. Jakmile jsme opět získali nad
situací kontrolu, oddělení pro bezpečnost IT obdrželo e-mail od vysoce
postaveného manažera, v němž navrhoval, abychom se právě my stali centrálním
kontaktním bodem pro všechny události související s viry. Měli bychom také
odpovídat za řešení a vytváření veškerých bezpečnostních hlášení, týkajících se
virů. Podle jeho názoru to dává smysl, neboť právě můj tým vždy nejdříve
reagoval na výskyt jakéhokoli škodlivého kódu v naší síti.
I když nás takové uznání těší, tento e-mail nám současně způsobil starosti a
stal se předmětem rozsáhlé diskuse. Jistě jsme v nejvýhodnější pozici, pokud
jde o detekci škodlivých aktivit v naší síti; a také můžeme poskytnout
nejrelevantnější informace o bezpečnostních záležitostech počínaje hackery a
konče viry. Ale nedomníváme se, že naše malá skupina by měla odpovídat za
vypořádání se s každým virem, který odhalí.
Měli bychom mít na starosti pouze určité incidenty. Například pokud dostaneme
informaci, že někdo úmyslně zanesl škodlivý kód do naší sítě nebo napsal virus,
to by bylo něco jiného. Ale s určitým poučením od bezpečnostní skupiny se
oddělení pro podporu desktopů vždy s viry vypořádávalo velmi dobře.
Vzhledem k počtu zaměstnanců a našim schopnostem slouží oddělení bezpečnosti k
odhalování problémů. Ale nápravu by měl mít na starosti někdo jiný.

Specializace
S ohledem na omezené zdroje by nám řešení problémů s viry mohlo zabrat většinu
času, a tím by byla narušena naše schopnost věnovat se dalším záležitostem,
které souvisejí s bezpečností. Jedná se také o politicky velmi ožehavou otázku.
Je nutné, abychom odpověděli velmi opatrně, abychom si neznepřátelili své
kolegy z jiných IT oddělení.
Doufáme, že se podaří nalézt kombinaci školení a dalších nástrojů, s jejichž
pomocí budeme moci většinu provozních úkolů souvisejících s bezpečností předat
jiným skupinám. Tak se budeme moci soustředit na to, co děláme nejlépe totiž na
bezpečnostní informační technologie, architekturu a konzultace.
Ř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.