Tento článok je tretí v cykle článkov «Ako prevziať kontrolu nad sieťovou infraštruktúrou». Obsah všetkých článkov v cykle a odkazy nájdete tu.

Nedáva zmysel hovoriť o úplnom odstránení bezpečnostných rizík. V princípe ich nemôžeme znížiť na nulu. Taktiež je potrebné chápať, že snaha o zvýšenie bezpečnosti našich sietí zdražuje naše riešenia. Je potrebné nájsť rozumný kompromis medzi cenou, zložitosti a bezpečnosťou v súvislosti s vašou sieťou.

Iste, dizajn zabezpečenia je organicky integrovaný do celkovej architektúry a používané bezpečnostné riešenia ovplyvňujú škálovateľnosť, spoľahlivosť, spravovateľnosť... sieťovej infraštruktúry, čo treba taktiež zohľadniť.

Ale pripomínam, že momentálne nehovoríme o vytváraní siete. V súlade s našimi počiatočnými podmienkami už máme vybraný dizajn, zvolené zariadenia a vytvorenú infraštruktúru, a v tomto štádiu sa musíme, ak to je možné, prispôsobiť a nachádzať riešenia v kontexte predtým zvoleného prístupu.

Našou úlohou teraz je identifikovať riziká spojené s bezpečnosťou na úrovni siete a znížiť ich na rozumnú úroveň.

Audity sieťovej bezpečnosti

Ak máte vo svojej organizácii implementované procesy ISO 27k, potom by audit bezpečnosti a zmeny siete mali byť organicky začlenené do celkových procesov tohto prístupu. Ale tieto normy sa predsa netýkajú konkrétnych riešení, nie konfigurácie ani dizajnu... Neexistujú jednoznačné rady, neexistujú normy presne určené na to, aká by mala byť vaša sieť, v tom spočíva zložitosti a krása tejto úlohy.

Vyzdvihol by som niekoľko možných auditov bezpečnosti siete:

audit konfigurácie zariadení (hardenovanie)
audit bezpečnostného dizajnu
audit prístupov
audit procesov

Audit konfigurácie zariadenia (hardening)

Zdá sa, že v väčšine prípadov je to najlepšia východisková pozícia pre audit a zlepšenie bezpečnosti vašej siete. IMHO to je dobrá demonstrácia Pareto zákona (20 % úsilia prináša 80 % výsledku, zatiaľ čo zvyšných 80 % úsilia prináša iba 20 % výsledku).

Podstatou je, že zvyčajne máme odporúčania od dodávateľov týkajúce sa «najlepších praktík» v oblasti bezpečnosti pri konfigurácii zariadení. Tomu sa hovorí “hardening”.

Často sa tiež stretávame s dotazníkom (alebo ho môžeme vyrobiť sami) na základe týchto odporúčaní, ktorý vám pomôže určiť, do akej miery konfigurácia vášho hardvéru zodpovedá týmto „best practices“ a na základe výsledku vykonať zmeny vo vašej sieti. To vám umožní pomerne jednoducho, v podstate bez nákladov, podstatne znížiť bezpečnostné riziká.

Niekoľko príkladov pre niektoré operačné systémy Cisco.
Zabezpečenie konfigurácie Cisco IOS
Zabezpečenie konfigurácie Cisco IOS-XR
Zabezpečenie konfigurácie Cisco NX-OS
Zoznam základného zabezpečenia Cisco
Na základe týchto dokumentov môže byť vytvorený zoznam požiadaviek na konfiguráciu pre každý typ vybavenia. Napríklad pre Cisco N7K VDC by tieto požiadavky mohli vyzerať tak.

Týmto spôsobom môžu byť vytvorené konfiguračné súbory pre rôzne typy aktívneho vybavenia vašej sieťovej infraštruktúry. Následne, ručne alebo s použitím automatizácie, môžete tieto konfiguračné súbory „nahrávať“. Ako automatizovať tento proces bude podrobne popísané v ďalšej sérii článkov venovaných orchestrácii a automatizácii.

Audit návrhu zabezpečenia

Zvyčajne sa v podnikovom (enterprise) sieti v takej alebo onakej podobe nachádzajú nasledujúce segmenty:

DC (Verejné služby DMZ a intranetový dátový center)
Prístup na internet
VPN s diaľkovým prístupom
WAN okraj
Pobočka
Campus (Kancelária)
Jadro

Názvy sú prevzaté z Cisco SAFE modelu, ale nie je nutné sa striktne viazať na tieto názvy a tento model. Predsa len je dôležité hovoriť o podstate a neuviazať sa vo formálnostiach.

Pre každý z týchto segmentov budú požiadavky na úroveň zabezpečenia, riziká a zodpovedajúce riešenia odlišné.

Preskúmame každý z nich samostatne z pohľadu problémov, s ktorými sa môžete stretnúť z hľadiska návrhu zabezpečenia. Samozrejme, opäť sa opakujem, že táto článok nijako neprezentuje úplnosť, ktorú by bolo v tejto naozaj hlbokej a mnohostranné téme ťažké dosiahnuť (ak vôbec možné), ale odráža moje osobné skúsenosti.

Neexistuje dokonalé riešenie (aspoň nie teraz). Vždy je to kompromis. Ale je dôležité, aby rozhodnutie o aplikácii tohto či oného prístupu bolo urobené vedome, s porozumením výhod a nevýhod.

Dátové centrum

Najkritickejší z hľadiska zabezpečenia segment.
A, ako zvyčajne, ani tu neexistuje univerzálne riešenie. Všetko silne závisí od požiadaviek na sieť.

Je potrebný firewall, alebo nie?

Na prvý pohľad sa odpoveď zdá byť jasná, no nie je to celkom jednoznačné, ako by sa mohlo zdať. A na váš výber môže vplývať nielen cena.

Príklad 1. oneskorenia.
Ak je nízke oneskorenie medzi niektorými segmentmi siete zásadnou požiadavkou, čo je napríklad pravdivé pre burzy, potom medzi týmito segmentmi nebudeme môcť použiť firewally. Ťažko sa nachádzajú štúdie o oneskoreniách v firewaloch, ale len niektoré modely prepínačov môžu poskytnúť oneskorenia menej ako alebo na úrovni 1 μs, takže si myslím, že ak sú pre vás mikrosekundy dôležité, tak firewally nie sú pre vás.

Príklad 2. Výkon.
Priepustnosť najlepších L3 prepínačov je zvyčajne porovnateľne vyššia ako priepustnosť najvýkonnejších firewallow. Preto v prípade vysoko intenzívneho prenosu dát, vám pravdepodobne bude tiež treba pustiť tento prenos obchádzajúc firewally.

Príklad 3. Spoľahlivosť.
Firewally, najmä moderné NGFW (Next-Generation FW) – sú zložitými zariadeniami. Sú oveľa zložitejšie ako L3/L2 prepínače. Poskytujú množstvo služieb a možností konfigurácie, preto nie je prekvapením, že ich spoľahlivosť je výrazne nižšia. Ak je kontinuita služby kritická pre sieť, potom možno budete musieť zvoliť, čo prinesie lepšiu dostupnosť – ochranu pomocou firewalla alebo jednoduchosť siete postavenej na prepínačoch (alebo rôznych fabrikách) s použitím bežných ACL.

V prípade vyššie uvedených príkladov vám pravdepodobne (ako obvykle) bude treba nájsť kompromis. Pozrite sa na nasledujúce riešenia:

ak ste sa rozhodli nepoužívať firewally vo vnútri dátového centra, je potrebné premyslieť, ako maximálne obmedziť prístupy na periférii. Napríklad, môžete otvoriť iba potrebné porty z internetu (pre klientskú prevádzku) a administratívne prístupy do dátového centra len z jump hostov. Na jump hostoch vykonávať všetku potrebnú kontrolu (autentifikácia/autorizačný proces, antivírus, logovanie, …)
môžete využiť logické rozdelenie siete dátového centra na segmenty, podobne ako v schéme opísanej v PSEFABRIC príklad p002Pri tom musí byť smerovanie nastavené tak, aby citlivý alebo vysoko intenzívny prenos dát prebiehal "vnútri" jedného segmentu (v prípade p002, VRF) a neprechádzal cez firewall. Prenos dát medzi rôznymi segmentmi bude naďalej prebiehať cez firewall. Je tiež možné použiť route leaking medzi VRF, aby sa predišlo presmerovaniu prenosu dát cez firewall.
Taktiež je možné použiť firewall v transparentnom režime a iba pre tie VLAN, kde tieto faktory (oneskorenie/vykonnosť) nie sú rozhodujúce. Musíte si však dôkladne preskúmať obmedzenia spojené s používaním tohto režimu pre každého dodávateľa.
Môžete zvážiť zavedenie architektúry service chain. To umožní prenášať cez firewall iba nevyhnutný prenos dát. Teoreticky to vyzerá dobre, ale nikdy som nevidel toto riešenie v praxi. Testovali sme service chain pre Cisco ACI/Juniper SRX/F5 LTM asi pred 3 rokmi, ale v tom čase sa nám to riešenie zdalo "nedostatočné".

Úroveň ochrany

Teraz je potrebné odpovedať na otázku, aké nástroje chcete použiť na filtrovanie prenosu dát. Tu je niekoľko možností, ktoré sú zvyčajne prítomné v NGFW (napríklad, tu):

stateful firewalling (podľa predvoleného nastavenia)
aplikačné firewalling
prevencia hrozieb (antivírus, anti-spyware a zraniteľnosti)
URL filtrovanie
filtrovanie dát (filtrovanie obsahu)
blokovanie súborov (blokovanie typov súborov)
ochrana pred dos

A tiež nie je všetko jednoznačné. Zdalo by sa, že čím vyššia úroveň ochrany, tým lepšie. Ale musíte tiež zohľadniť, že

čím viac z uvedených funkcií firewallu použijete, tým prirodzenejšie to bude drahšie (licencie, dodatočné moduly).
Použitie niektorých algoritmov môže výrazne znížiť priepustnosť firewallu a tiež zvýšiť oneskorenia, pozri napríklad tu
ako každé komplexné riešenie, používanie zložitých metód ochrany môže znížiť spoľahlivosť vášho riešenia, napríklad pri použití application firewalling som sa stretol so zablokovaním niektorých štandardne fungujúcich aplikácií (dns, smb).

Akoby ste mali nájsť optimálne riešenie pre vašu sieť.

Nie je možné jednoznačne odpovedať na otázku, aké funkcie ochrany môžu byť potrebné. Po prvé, pretože to samozrejme závisí od dát, ktoré prenášate alebo uchovávate a snažíte sa ochrániť. Po druhé, v skutočnosti, často je výber ochranných prostriedkov otázkou viery a dôvery k dodávateľovi. Nepoznáte algoritmy, neviete, aké sú efektívne a nemôžete ich plne otestovať.

Preto v kritických segmentoch môže byť dobrým riešením využitie ponúk od rôznych spoločností. Napríklad, môžete zapnúť antivírus na firewalle, ale aj využiť antivírusovú ochranu (od iného výrobcu) lokálne na hostiteľských serveroch.

Segmentácia

Ide o logickú segmentáciu siete dátového centra. Napríklad, rozdelenie na VLAN a podsiete je tiež logická segmentácia, ale tú nebudeme zvažovať vzhľadom na jej zjavnosť. Zaujímavá je segmentácia s ohľadom na také entity ako sú zóny zabezpečenia FW, VRF (a ich analogy u rôznych dodávateľov), logické zariadenia (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, …), …

Príklad takej logickej segmentácie a momentálne žiadaného dizajnu dátového centra je uvedený v p002 projektu PSEFABRIC.

Definovaním logických častí vašej siete môžete ďalej opísať, ako sa pohybuje prevádzka medzi rôznymi segmentmi, na ktorých zariadeniach sa bude vykonávať filtrovanie a akými prostriedkami.

Ak vo vašej sieti chýba jasné logické rozdelenie a nie sú formalizované pravidlá pre aplikáciu bezpečnostných politík na rôzne prúdy dát (flow), znamená to, že pri otvorení určitého prístupu ste nútení riešiť túto úlohu, a s veľkou pravdepodobnosťou ju budete riešiť zakaždým inak.

Často je segmentácia založená len na zónach zabezpečenia FW. Potom je potrebné odpovedať na nasledujúce otázky:

akú zónu zabezpečenia potrebujete
akú úroveň ochrany chcete aplikovať na každú z týchto zón
či bude povolený intra-zone prevádzka ako predvolené
ak nie, aké politiky filtrovania prevádzky budú aplikované vo vnútri každej zón
aké politiky filtrovania prevádzky budú aplikované pre každý pár zón (source/destination)

TCAM

Často sa stretávame s problémom nedostatočného TCAM (Ternary Content Addressable Memory), ako pre smerovanie, tak pre prístupy. IMHO, je to jedna z najdôležitejších otázok pri výbere hardvéru, takže je potrebné túto otázku brať s náležitou vážnosťou.

Príklad 1. Forwarding Table TCAM.
Pozrime sa na Palo Alto 7k firewall.
Vidíme, že veľkosť IPv4 forwarding table* = 32K
Pričom toto množstvo routov je spoločné pre všetky VSYS-y.
Predpokladajme, že podľa vášho dizajnu ste sa rozhodli použiť 4 VSYS-y.
Každý z týchto VSYS-ov je pripojený k dvom PE MPLS cloudom cez BGP, ktorý používate ako BB. Takto si 4 VSYS-y navzájom vymieňajú všetky špecifické trasy a majú forwarding table s približne rovnakými sadami trás (ale s rôznymi NH). Keďže každý VSYS má 2 BGP relácie (s rovnakými nastaveniami), každá trasa prijatá cez MPLS má 2 NH a, samozrejme, 2 FIB záznamy v Forwarding Tabuľke. Ak predpokladáme, že to je jediné firewall v dátovom centre a musí poznať všetky trasy, znamená to, že celkový počet trás v našom dátovom centre nemôže byť väčší ako 32K/(4 * 2) = 4K.
Teraz, ak predpokladáme, že máme 2 dátové centrá (s rovnakým dizajnom) a chceme použiť VLAN-y „rozšírené“ medzi dátovými centrami (napríklad pre vMotion), aby sme vyriešili problém s routovaním, musíme použiť hosťovské trasy. Ale to znamená, že pre 2 dátové centrá nebudeme mať viac ako 4096 možných hostiteľov a samozrejme to môže byť nedostatočné.

Príklad 2. ACL TCAM.
Ak plánujete filtrovať prenosy na L3 prepínačoch (alebo iných riešeniach používajúcich L3 prepínače, napríklad Cisco ACI), pri výbere hardvéru by ste mali venovať pozornosť ACL TCAM.
Predpokladajme, že chcete kontrolovať prístupy na SVI rozhraní Cisco Catalyst 4500. Potom, ako je vidieť z tohto článku, pre kontrolu odchádzajúceho (rovnako ako aj prichádzajúceho) prenosu na rozhraniach môžete použiť len 4096 riadkov TCAM. Čo pri použití TCAM3 poskytne približne 4000 ACE (riadkov ACL).

V prípade, že ste sa stretli s problémom nedostatočného TCAM-u, je najprv potrebné zvážiť možnosť optimalizácie. Takže v prípade problému s veľkosťou Forwarding Tabuľky by ste mali zvážiť možnosť agregácie trás. V prípade problému s veľkosťou TCAM pre prístupy — audit prístupov, odstránenie zastaraných a prekrývajúcich sa záznamov a, ak sa možno, prehodnotenie postupu otvárania prístupov (bude podrobne preskúmané v kapitole venovanej auditu prístupov).

Vysoká dostupnosť

Otázka znie, či použiť HA pre firewally alebo nainštalovať „paralelne“ dve nezávislé krabice a v prípade zlyhania jednej z nich routovať prenos cez druhú?

Na prvý pohľad sa odpoveď javí ako jasná – používať HA. Dôvod, prečo sa táto otázka objavuje, spočíva v tom, že, žiaľ, teoretické a reklamné 99 a niekoľko deviatok za desatinnou čiarkou dostupnosti sa v praxi ukazujú ako oveľa menej optimistické. HA je logicky dostatočne zložitá záležitosť a na rôznom hardvéri, ako aj s rôznymi dodávateľmi (bez výnimiek) sme zaznamenali problémy, chyby a výpadky služby.

Pri používaní HA získate možnosť vypínať jednotlivé uzly a prechádzať medzi nimi bez výpadku služby, čo je dôležité napríklad pri upgrade, ale aj tak existuje dosť vysoká pravdepodobnosť, že sa vám poručia oba uzly súčasne, ako aj to, že ďalší upgrade prebehne nie tak hladko, ako sľubuje dodávateľ (tomuto problému sa môžete vyhnúť, ak máte možnosť otestovať upgrade na laboratórnom zariadení).

Ak nepoužívate HA, z hľadiska dvojitej poruchy sú vaše riziká výrazne nižšie (keďže máte 2 nezávislé firewally), ale pretože relácie nie sú synchronizované, zakaždým, keď dôjde k prechodu medzi týmito firewally, prídete o časť prevádzky. Samozrejme, môžete použiť stateless firewalling, ale v takom prípade zmysel používania firewallu do značnej miery zaniká.

Preto, ak ste v výsledku auditu zistili osamotené firewally a uvažujete o zvýšení spoľahlivosti vašej siete, HA je samozrejme jedným z doporučených riešení, ale musíte zvážiť aj nevýhody spojené s týmto prístupom a možno práve pre vašu sieť bude vhodnejšie iné riešenie.

Pohodlie v správe (managability)

V podstate HA zahŕňa aj spravovateľnosť. Namiesto konfigurácie 2 zariadení osobitne a riešenia problému synchronizácie konfigurácií, ich spravujete do značnej miery, akoby ste mali jedno zariadenie.

Ale možno máte veľa dátových centier a veľa firewallov, potom sa táto otázka dostáva na novú úroveň. A nejde len o konfiguráciu, ale aj o