Posouzení nové infrastruktury pro aplikace

Než bude možné zavést nové webové aplikace, musí manažer bezpečnosti najít slabá místa našeho systému. Tuto čin...


Než bude možné zavést nové webové aplikace, musí manažer bezpečnosti najít
slabá místa našeho systému. Tuto činnost je třeba neuspěchat proběhnout by měla
v několika krocích, z nichž každý se zaměřuje na něco jiného.

Naše společnost přecházela po dobu několika měsíců na platformu Oracle 11i.
Nebylo to nic jednoduchého, protože máme spousty klíčových aplikací, které
ovlivňují chod celé společnosti a na jejichž dobře provedeném přechodu na novou
verzi a na migraci velmi záleží. Před několika týdny byly nové aplikace
připraveny ke spuštění, a tehdy přišla má chvíle: měl jsem provést posouzení
bezpečnosti a ukonejšit jakékoliv pochybnosti.
Oracle 11i zajišťuje infrastrukturu pro internetová řešení. Dříve jsme
používali většinou klientsky orientované aplikace, ty však vždy přinášely
určité problémy například to znamenalo, že se pro každého uživatele musel
potřebný software separátně stahovat a instalovat. Uživatelé pak na svých
počítačích provozovali mnohdy i desítky aplikací, měli kvůli nim potíže s
výkonem svých desktopů a také s jejich modernizací nebo úpravami.
Teď tedy budeme podporovat jediné webové rozhraní s různými aplikačními moduly
podle toho, co budou uživatelé vyžadovat. Například zaměstnanec ve finančním
oddělení může klepnout na odkaz, který ho přenese do prostředí firemních účtů
či jiných peněžních operací, a to samozřejmě jen za předpokladu, že k tomu má
příslušná práva. Jiní pracovníci se zase budou moci pomocí jediného okna
prohlížeče dostat k hlášení o výdajích či nákupech.
Novinky samozřejmě potřebují posouzení. V tomto případě je to ještě mnohem
důležitější, neboť aplikace založené na webových technologiích jsou obecně
zranitelnější.
Posuzování obvykle rozdělujeme podle tří klíčových oblastí: architektura,
systém a aplikace. Součástí auditu architektury jsou většinou schémata
počítačových sítí, pravidla pro fungování firewallů, seznamy administrátorů a
uživatelských účtů apod. Pak svou pozornost zaměříme na režim s nejnižším
stupněm privilegií. Když například porozumíme tomu, jak každá aplikace
spolupracuje s ostatními částmi infrastruktury, můžeme zajistit, aby pravidla
nastavená na firewallech dovolila jen to, co je stanovené. Pak prozkoumáme
způsob, jakým se identifikují, řídí a kontrolují privilegované účty, a ujistíme
se, že příslušní uživatelé mají patřičná práva přidělena skutečně podle své
funkce.
Potom přistoupíme k auditu systému. To znamená v každém prostředí spustit řadu
různých komerčních a open source nástrojů a ujistit se, že je systém
nainstalován bez odchylek od bezpečnostních norem a že administrátoři
neprovedli žádné úpravy, kterými by zeslabili zabezpečení systému. Správci
například někdy vytvoří ve svém domovském adresáři soubor ".rhost" a umístí do
něho "+". Soubor .rhost jim pak umožňuje připojit se k serveru s utilitami jako
rlogin, aniž by museli použít heslo. Ono "+" ale dovolí komukoliv, aby se
připojil bez hesla. Pro správce je to pohodlné, ale z hlediska bezpečnosti je
to zakázaná operace. Ještě předtím, než přejdeme do plného provozu, spustíme
komplexní skript, který prověří každý systém, zda na něm takto upravené soubory
nejsou, a také zkontroluje přístupová práva k souborům, účty, systém hesel,
automatizované úlohy, aplikace, záplaty atd. Víme, jak by měl standardní systém
vypadat, a každou odchylku zaznamenáme. Jakmile tento skript provedeme,
zanalyzuje systém pomocí nástroje Tripwire.
Používáme i open source nástroj Nessus, který dokáže skenovat porty a s jehož
pomocí můžeme nalézt podezřelé služby třeba ty, co běží, ač nejsou potřebné
nebo jsou už zastaralé.
Nejtěžší část Audit aplikací je zřejmě nejdůležitější částí našeho posuzování.
S konfiguracemi hardwaru a operačního systému serveru se nám pracuje dobře,
neboť jde o relativně statické prostředí. Jakákoliv odchylka je odhalitelná
pomocí nástroje Tripwire a lze s ní okamžitě naložit dle potřeby. Naproti tomu
aplikace představují doslova džungli. Máme po celém světě stovky vývojářů,
kteří aplikace vytvářejí různými metodami a pomocí různých programovacích
technik. I když bychom rádi zavedli nějakou standardizaci, ve velké
společnosti, jako je ta naše a kde vývoj probíhá i v zahraničí, je to velmi
obtížné.
Pro tento účel opět využíváme komerční i open source nástroje. V současné době
pracuje s produktem WebInspect od společnosti SPI Dynamics, pomocí kterého
hledáme webové servery a aplikace, jež jsou zneužitelné různými útoky, jako je
například modifikace SQL dotazů pomocí přidání dalšího řetězce (SQL injection),
cross-site scripting (neoprávněný přístup k určitým skriptům) či obcházení
autentizace uživatele.
Výsledky posuzování byly smíšené. Ve většině případů byly servery konfigurovány
v rámci dříve stanovených pravidel a jen s několika odchylkami. V jednom
případě uživatel, který byl příliš líný, takže k přesunu souborů nepoužíval
funkci Secure Copy, nedovoleně zprovoznil server FTP. Na několika dalších
serverech správce nakonfiguroval systém tak, aby se mohl přímo přihlásit jako
root.
Zdá se ale, že nejvíce práce je s auditem aplikací. V tomto případě měl skoro
každý aplikační server zranitelnost pro SQL injection. Útok SQL injection
umožňuje hackerovi, aby databázové příkazy zadal v takové podobě (nebo
prostřednictvím URL), která bude následně v databázi provedena. Náprava spočívá
v tom, že aplikace dokáže rozeznat, zda byly takové záludné požadavky zadány, a
následně je zamítne. Říká se tomu také potvrzení vstupních příkazů (input
validation).
Vedle zranitelnosti pomocí SQL injection jsme zjistili i to, že vývojáři
zahrnuli do komentářů několika skriptů citlivé informace a že několik
administračních serverů Dynamo Application bylo nakonfigurováno s výchozím
heslem správce.
Přišli jsme také na nějaké menší problémy u webových serverů, například možnost
jmenovitě uvádět adresáře a prohlížet obsah určitých souborů díky tomu by se
hackeři mohli dostat k cenným informacím. Dalším krokem bude předložení těchto
zjištění projektovým manažerům a sestavení plánu konsolidace. Jakmile bude plán
splněn a skuliny odstraněny, provedeme další krok posuzování, abychom se před
spuštěním ujistili, že v systému nezůstala opravdu žádná otevřená vrátka.









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