Čerstvě spojené firmy mohou být oslabené

Po spojení firem dochází mimo jiné také ke sladění jejich IT infrastruktury. Mathias se potýká s problémy zajištěn...


Po spojení firem dochází mimo jiné také ke sladění jejich IT infrastruktury.
Mathias se potýká s problémy zajištění bezpečnosti propojených počítačových
sítí.
V jednom z minulých čísel jsem zde psal o problémech s nelegálními bezdrátovými
přístupovými body, které si naši zaměstnanci ve firmě instalují. Řešení této
otázky jsme zatím nedotáhli do konce částečně i kvůli tomu, že se na nás valí
další problémy. V současnosti je tím největším fakt, že naše společnost koupila
jinou firmu a teď je třeba propojit jejich zatím oddělené IT infrastruktury.
Než však úplně opustím téma WLAN (Wireless LAN), rád bych upozornil na jeden
problém, se kterým byste se v této souvislosti také mohli setkat. Pokud
používáte program Net-Stumbler nebo podobný software pro detekci nelegálních
přístupových bodů ve firmě, je třeba si uvědomit, že MAC (Media Access Control)
adresa, kterou detekujete, je rádiová adresa a nikoli síťová (LAN) MAC. Bez
síťové MAC adresy je ovšem problematické trasovat přístupové body až ke zdroji.

Nebezpečí ze spojení
Moje společnost vyrostla během velmi krátké doby z několika set zaměstnanců na
několik tisíc lidí. A to především prostřednictvím řady spojení a akvizicí.
Jednou z činností, které jsou s každou takovou akcí spojeny, je pokud možno co
nejrychlejší propojení IT infrastruktur původních firem. Takové propojení je
ale často zdrojem velkých problémů. Nejde jenom o to, že se ve firmách používá
odlišný software a různé konfigurace počítačů, ale například i o požadavek na
okamžité nastavení vztahu důvěry s dosud neznámou entitou.
Vždy když řešíme problém spojení s jinou společností, vynořuje se první zásadní
otázka: Je lepší změnit jejich systémy a způsoby jejich správy tak, aby
odpovídaly těm našim, nebo je lepší spravovat jejich infrastrukturu tak, jak
byli dosud zvyklí?
Přijaté rozhodnutí pak pochopitelně ovlivní mimo jiné způsob, jakým funguje
naše bezpečnostní infrastruktura. Vezměte si například takové systémy detekce
napadení (IDS, Intrusion Detection Systems). Za běžných okolností je máme
samozřejmě vyladěny tak, aby efektivně monitorovaly dění v naší síti. A nebývá
to jednoduché. Zabere spoustu času, než člověk nastaví systém tak, aby
rozpoznal neškodný provoz od toho, který je pro firmu potenciálně nebezpečný. A
pak přijde okamžik spojení s novou firmou a vy můžete opět začít takřka od
začátku. Jakmile jsme nastavili vztah důvěry mezi naší sítí a sítí nově koupené
společnosti, zprovoznili jsme senzory IDS v každé z nových lokalit. A pak jsme
začali s nastavováním systému IDS a to, co jsme dosud udělali, přišlo z velké
části vniveč. Znovu jsme zkoumali, který provoz je legitimní a prováděli
příslušná nastavení, aby nevyvolával zbytečné poplachy, a který legitimní není.
Zjišťovali jsme, kde má kdo v nové firmě jaké pravomoci, kdo je administrátorem
čeho. Teprve když jsme zjistili, co je co, mohli jsme nastavit senzory IDS
odpovídajícím způsobem.
Po všech provedených změnách si ale ani zdaleka nejsem jist, že náš IDS
skutečně zastaví jakýkoli pokus o průnik do firemních systémů. Pořád nás trápí
falešné poplachy, vynořují se nové otázky ohledně toho, co vlastně je skutečně
nebezpečné, potýkáme se s nastavením souvislostí mezi různými událostmi i se
správným umístěním IDS senzorů v nové infrastruktuře. A s tím, jak roste
množství útoků na aplikační úrovni, klesá i moje víra v to, že žádný útok
nepronikne do naší kritické infrastruktury.

Hledání alternativ
Dokud si nebudu jistější, rozšíříme náš systém IDS o kontrolu integrity souborů
prostřednictvím softwaru Tripwire od stejnojmenné společnosti. Tripwire je naše
volba poslední záchrany. Pokud senzory IDS nezachytí snahu o zkompromitování
naší sítě, Tripwire to udělá. Stále také přemýšlíme o tom, že bychom
nainstalovali systém pro detekci průniků založený na hostitelích (host-based),
tj. takový, jehož senzory bychom umístili na všechny naše kritické servery. Při
testech jednoho nabízeného produktu jsme ale zjistili, že požaduje modul SBSM
(Solaris Basic Security Module), který na oplátku vytěžuje procesory našich
serverů až na kritickou úroveň. Jsem si jistý, že od doby našich testů došlo v
produktu ke změnám a jakmile budeme mít více času, jistě provedeme další
zkoumání tohoto i alternativních systémů. Nyní se ale musíme věnovat jiným
záležitostem.

Problémy záloh
Aby toho nebylo málo, narazili jsme na problémy i se softwarem Tripwire. Poté,
co jsme ho nainstalovali na některé naše produkční systémy, nakonfigurovali
jsme ho tak, aby prováděl testy integrity vždy mezi druhou a třetí hodinou
ranní. Současně jsme Tripwire nastavili tak, aby prováděl každou půlhodinu
testy integrity deseti kritických souborů, u kterých by jakákoli změna s
vysokou pravděpodobností znamenala narušení bezpečnosti naší IT infrastruktury.
Jsem v podstatě ochoten si vsadit na to, že pokud by někdo ošálil naše systémy,
jeden z těch deseti souborů (jako např. /etc/passwd nebo etc/default login/) by
byl změněn. A teď k tomu výše avizovanému problému: Existují tři proměnné
související s atributy souborů v unixových operačních systémech, které jsou
důležité jak pro běžné aktivity, tak pro systémy kontrolující integritu, jakým
je např. již zmíněný obsah souboru. Tripwire. Konkrétně jde o atributy Atime,
Mtime a Ctime, které říkají, kdy byl soubor naposledy čten, kdy se naposledy
změnil jeho stav a kdy byl naposledy změněn obsah souboru. Tripwire tyto
atributy používá pro detekci zásahů do souborů. Při standardním nastavení tento
program provede sérii kontrol stavu souboru a zkontroluje je proti původnímu
snapshotu (kopii souboru) pořízenému v době inicializace jeho bezpečnostní
databáze. Problém, na který jsme nedávno narazili, měl co do činění s
pořizováním záloh. Za běžných okolností (a při standardním nastavení) náš
zálohovací software mění atribut Atime s tím, jak zálohuje jednotlivé soubory
na server. To má svůj důvod je totiž nezbytné, aby byl čas přístupu k souboru v
době zálohování nastaven přesně. Aby toho dosáhl, náš zálohovací software
nastavuje atribut Atime každého zálohovaného souboru na čas, který zde byl
uveden před provedením zálohy. Tato akce ale mění atribut Ctime, což způsobí,
že Tripwire vyvolá poplach. Abychom se tomuto problému vyhnuli, museli jsme
nastavit všechny naše konfigurační soubory tak, aby se neprováděla kontrola
atributu Ctime pro zálohované soubory. Je to sice tak trochu improvizace, ale
po provedených změnách běží kontrola integrity tiše a účinně. Je daleko
jednodušší vyladit Tripwire než systém IDS. Což je ovšem logické. Porovnávat
nastavení těchto dvou systémů je tak trochu podobné jako porovnání jablek s
hruškami.
Spojení s novými firmami nám vždy přináší nemalé problémy se zajištěním
bezpečnosti. Mohlo by to ale být ještě horší. Jejich sítě by totiž mohly
používat technologie WLAN.
Ř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.