I přesto, že jsou firewally na trhu již poměrně dlouho, a že jsou velmi používané, velké množství společností naráží na problémy s vytvářením a především udržováním firewallových politik. Často pozorujeme problémy už při nasazování této technologie. Organizace mají problém s identifikací povolené komunikace a celkově s nastavením procesů správy firewallových pravidel. To se potom promítá do celkového životního cyklu technologie. I po správné počáteční konfiguraci politiky můžeme za nedlouho vidět značné zhoršení přehlednosti i bezpečnosti pravidel. To se týká zejména (ale nejen) složitějších prostředí s více firewallovými clustery a s více záznamy v bázi pravidel.

Obvyklé chyby ve firewallové politice

V tomto článku projedeme nejčastější chyby, se kterými se v praxi setkáváme. Z toho vyplynou tipy, jak správně nastavit procesy, aby byla správa firewallu co nejefektivnější a zároveň nebyla snížena bezpečnost celého prostředí.

Obrázek 1: Příklad nesprávné politiky

Struktura pravidel

Velmi častým problémem v různých prostředích je nedostatečná specifikace struktury pravidel. Pokud není správně popsaný způsob, jak do firewallové politiky přidávat nová pravidla, každý z administrátorů si vytvoří svojí vlastní metodiku. Ta se ale nemusí mezi jednotlivými administrátory úplně shodovat, takže vznikne první rozpor. Již v tuto chvíli není na první pohled zřejmé, kde které pravidlo hledat. Když navíc není přidávání nových pravidel nijak kontrolováno, pravděpodobně brzy dojde k situaci, kdy někdo přidá pravidlo navrch politiky, aby něco otestoval nebo zajistil akutně potřebný prostup. Tato ad-hoc pravidla pak často v politice zůstanou, čímž se snižuje jak přehlednost, tak často i bezpečnost.

Z toho důvodu je vhodné již v průběhu nasazování firewallu specifikovat jednoznačné procesy, jak přidávat nová pravidla. Tato disciplína je poměrně složitá. Je potřeba najít rovnováhu mezi bezpečností, která vyžaduje rozdrobení politiky na co nejvíce přesně specifikovaných prostupů, a praktickou použitelností, jež se neobejde bez agregace mnoha podobných pravidel do menšího množství obecnějších záznamů. Dále je při plánování firewallové politiky potřeba zohlednit možnosti dané technologie. Zaprvé pravděpodobně bude třeba myslet na optimalizaci výkonu tím, že se používanější prostupy položí v politice výše než méně používané. Zadruhé je třeba zvážit použití funkcionalit specifických pro dané firewallové řešení (zóny, vrstvy, popisky, skoky, atd.). Efektivním použitím těchto vlastností jednotlivých produktů může dojít ke značnému zpřehlednění politiky, ale i k optimalizaci výkonu. Na druhou stranu je ale poté ztížena migrace firewallové politiky k jinému výrobci.

Obrázek 2: Příklad více strukturované politiky. Legenda: 1. Přidání titulků, 2. Přidání zón, 3. Přidání vrstev politiky

Neefektivní politika

Obvyklou chybou je neefektivita konfigurace firewallových pravidel. Často můžeme v politice vidět dlouho nepoužívaná nebo dokonce vyřazená (disabled) pravidla. K této situaci dochází, protože nikdo není odpovědný za pravidelnou kontrolu platnosti zavedených pravidel a chybí proces na jejich pravidelné odebírání. Dále narážíme na to, že se jednotlivé záznamy částečně či úplně překrývají, jsou redundantní nebo by bylo možné je efektivně agregovat. Tyto neduhy vznikají především ve chvíli, kdy administrátoři přidávají podobná pravidla na různá místa. Podobně jako v předchozím případě k tomu dochází zejména ve chvíli, kdy nejsou správně definované postupy pro práci s politikou.

Tyto problémy může z velké části vyřešit samotná technologie firewallu. V některých případech je schopná u nově přidaných pravidel kontrolovat, jestli se nepřekrývají, nebo zda nejsou redundantní. Některé produkty navíc umí ukázat, do jaké míry jsou pravidla využívaná, čímž značně zjednoduší jejich promazávání. Riziko některých problémů se sníží také tím, že se specifikuje, jak přidávat nová pravidla. Pokud se podobná pravidla přidávají na stejné místo, administrátor spíše zahlédne redundantní či překrývající se pravidla. Dále pomůže proces na pravidelné kontroly validity pravidel, při kterých dojde k promazání nepoužívaných a nevalidních prostupů.

Z hlediska bezpečnosti je správné, aby povolující pravidla měla omezenou dobu životnosti. Po jejím uplynutí dojde k vyřazení pravidla z provozu. Předtím jsou ovšem informováni vlastníci aplikací, jež pravidlo využívají, aby potvrdili potřebnost daného prostupu. Některé firewallové technologie mají možnost zajistit časové omezení pravidel, čímž zjednoduší aplikaci zmíněného procesu. Tento postup se ale v praxi příliš nevyužívá, protože je náročný na správu a je potřeba přesného řízení společnosti dle procesů (ke každému prostupu musí být k dispozici požadavky na jeho vytvoření, každý požadavek musí mít odpovědného vlastníka, který potvrdí platnost své žádosti).

Obrázek 3: Zvýšení efektivity pravidel. Legenda: 1. Odstranění déle disablovaných pravidel, 2. Agregace podobných pravidel, 3. Odstranění překrývajících se pravidel, 4. Odstranění redundantních pravidel

Jmenná konvence a komentáře

Na první pohled banální chybou jsou chybějící nebo nesprávné komentáře a názvy záznamů a objektů v konfiguraci firewallové politky. Ačkoliv se může zdát, že jde o pouhou formalitu, je správné pojmenování pravidel i objektů zásadní. Název a komentář jsou u mnoha specifických produktů jediným vodítkem k tomu, proč pravidlo vzniklo. Při nesprávně pojmenovaných objektech bude orientace v politice významně složitější a nebude na první pohled zřejmé, co který záznam znamená. Není dobré používat generická jména typu IP_192.168.1.2 nebo TCP_22, i když v sobě obsahují potřebné informace, nevyužívají naplno potenciál názvu objektu. Ten může napovědět mimo jiné například OS zařízení, vlastníka či fyzické umístění stroje, který se pod danou IP adresou skrývá.

Komentáře jsou pak nejčastěji využívány k vytvoření odkazu na požadavky, na základě kterých pravidlo vzniklo nebo bylo upraveno. Také zde může být uveden seznam žadatelů o tento prostup a jeho schvalovatel.

Aby bylo využívání názvů a komentářů efektivní, je nutné specifikovat jmennou konvenci. Ta by měla být logicky navázaná na konvenci používanou v ostatních systémech organizace (například s CMDB databází či s AD). V každém případě by měla být definice jmen zřejmá již na počátku projektu nasazení firewallu. Kromě samotné konvence je třeba vytvořit proces kontroly správného používání jmen a komentářů. Každý administrátor by měl mít odpovědnost za dokumentaci jím zavedených pravidel.

Obrázek 4: Příklad využití názvů v politice. Legenda: 1. Využití názvů pravidel dle konvence, 2. Využití názvů zařízení dle konvence, 3. Využití názvů služeb či aplikací dle konvence, 4. Používání komentářů k propojení s tiketovacím systémem

Logování

V praxi často narážíme na nedostatečné logování jednotlivých pravidel. Tento problém je nepříjemný, protože se na něj obvykle narazí až ve chvíli, kdy jsou logy skutečně potřeba. Tyto situace jsou často velmi závažné a na dostupnosti logů mohou záviset zásadní rozhodnutí managementu. V některých případech je dostupnost záznamů dokonce zákonnou povinností. Může být obtížné rozhodnout, kterou komunikaci logovat a do jaké hloubky. Některé technologie umožňují logování až na úroveň sedmé vrstvy ISO/OSI modelu, pokud si o ni administrátor požádá. Takto podrobné logy ale obvykle zabírají příliš mnoho prostoru a při jejich vytváření také dochází k vytěžování zařízení.

Opět je vhodné v procesech popsat, jaká pravidla se budou logovat a do jaké míry. Obecně lze říci, že je vhodné logovat zejména uživatelský provoz, tak podrobně, jak je to při technických omezeních možné. Provoz mezi zařízeními je také dobré logovat, ale není třeba takový detail logů. Většinou lze vypnout logování komunikace standardních protokolů, jako je například bootp protokol a podobně. Míru logování je potřeba zvážit z hlediska dostupných technologií a předpokládaného využití logů.

Obrázek 5: Zapnutí logování většiny pravidel. Legenda: 1. Základní logování téměř všech pravidel, 2. Vypnutí logování protokolové komunikace

Konec první části

V prvním díle článku jsme prošli nejčastější chyby, které potkáváme v námi spravovaných prostředích. Druhý díl bude ve výčtu chyb a jejich řešení pokračovat. Kromě toho se v něm dočtete další rady o tom, jak spravovat firewallové politiky (samozřejmě ověřené naší vlastní zkušeností a praxí). Najdete zde doporučení na vhodný způsob dokumentace komunikace mezi aplikacemi a její využití při správě firewallů. Dále také zjistíte, jak vám práci pomohou zefektivnit automatizované nástroje.

Lukáš Solil Autor článku působí jako Security Specialist ve společnosti AEC a.s.