Tento článek je třetí v sérii článků „Jak vzít síťovou infrastrukturu pod kontrolu“. Obsah všech článků série a odkazy najdete zde.

Není smysluplné hovořit o úplném odstranění bezpečnostních rizik. V zásadě je nemůžeme snížit na nulu. Je také třeba chápat, že s tím, jak se snažíme učinit síť stále bezpečnější, naše řešení se stávají stále dražšími. Je nutné najít rozumný kompromis mezi cenou, složitostí a bezpečností pro vaši síť.

Samozřejmě, návrh zabezpečení je organicky začleněn do celkové architektury a používaná bezpečnostní řešení ovlivňují škálovatelnost, spolehlivost, spravovatelnost,… síťové infrastruktury, což také musí být zohledněno.

Ale, připomínám, že nyní nemluvíme o vytváření sítě. V souladu s našimi počátečními podmínkami už máme vybraný návrh, zvolené zařízení a vytvořenou infrastrukturu, a v této fázi bychom měli, pokud možno, „žít“ a hledat řešení v kontextu dříve zvoleného přístupu.

Naším úkolem nyní je identifikovat rizika spojená s bezpečností na úrovni sítě a snížit je na rozumnou úroveň.

Audity síťové bezpečnosti

Pokud ve vaší organizaci byly implementovány procesy ISO 27k, měla by být auditování bezpečnosti a změny v síti organicky zahrnuty do celkových procesů v rámci tohoto přístupu. Tyto standardy však stále nejsou o konkrétních řešeních, nejsou o konfiguraci, nejsou o návrhu… Neexistují jednoznačné rady, neexistují standardy, které detailně diktují, jak by měla vaše síť vypadat, to je komplikovanost a krása této úlohy.

Vyzvedl bych několik možných auditů bezpečnosti sítě:

audit konfigurace zařízení (hardening)
audit bezpečnostního návrhu
audit přístupů
audit procesů

Audit konfigurace zařízení (hardening)

Zdá se, že v mnoha případech je to nejlepší výchozí bod pro audit a zlepšení bezpečnosti vaší sítě. IMHO je to dobrá ukázka Pareto zákona (20 % úsilí přináší 80 % výsledku, a zbývajících 80 % úsilí přináší pouze 20 % výsledku).

Podstatou je, že obvykle máme doporučení od dodavatelů ohledně „nejlepších praktik“ pro bezpečnost při konfiguraci zařízení. To se nazývá „hardening“.

Často lze také nalézt dotazník (nebo si ho vytvořit sami) na základě těchto doporučení, který vám pomůže určit, jak konfigurace vašeho zařízení odpovídá těmto „best practices“, a v závislosti na výsledku provést změny ve vaší síti. Díky tomu budete moci snadno, v podstatě bez nákladů, výrazně snížit bezpečnostní rizika.

Několik příkladů pro některé operační systémy Cisco.
Zpevnění konfigurace Cisco IOS
Zpevnění konfigurace Cisco IOS-XR
Zpevnění konfigurace Cisco NX-OS
Kontrolní seznam základní bezpečnosti Cisco
Na základě těchto dokumentů může být vytvořen seznam požadavků na konfiguraci pro každý typ zařízení. Například pro Cisco N7K VDC mohou tyto požadavky vypadat takto.

Takto mohou být vytvořeny konfigurační soubory pro různé typy aktivního zařízení vaší síťové infrastruktury. Poté, ručně nebo s použitím automatizace, můžete tyto konfigurační soubory „nahrát“. Jak automatizovat tento proces bude podrobně rozebráno v další sérii článků zaměřených na orchestrace a automatizaci.

Audit návrhu bezpečnosti

Obvykle v podnikové síti (enterprise network) existují v různých formách následující segmenty:

DC (DMZ veřejných služeb a intranetové datové centrum)
přístup k internetu
VPN pro vzdálený přístup
WAN okraj
Pobočka
Kampus (kancelář)
Core

Názvy jsou převzaty z Cisco SAFE modelu, ale není nutné se samozřejmě vázat pouze na těchto názvů a tento model. Hlavně se chceme zaměřit na podstatu a nezaplést se do formálností.

Pro každý z těchto segmentů budou požadavky na úroveň bezpečnosti, rizika a tím pádem také řešení odlišné.

Podívejme se na každý z nich jednotlivě z hlediska problémů, s nimiž se můžete setkat z pohledu návrhu bezpečnosti. Opět zdůrazňuji, že tento článek rozhodně nepretenduje na úplnost, což je v této skutečně hluboké a vícevrstvé tématice obtížné (pokud vůbec možné), ale odráží mé osobní zkušenosti.

Neexistuje ideální řešení (alespoň ne nyní). Vždy je to kompromis. Důležité je, aby rozhodnutí o použití určitého přístupu bylo učiněno vědomě, s porozuměním jak jeho výhod, tak nevýhod.

Datové centrum

Nejkritičtější z pohledu bezpečnosti segment.
A jako obvykle, zde také neexistuje univerzální řešení. Vše závisí na požadavcích na síť.

Je potřeba firewall?

Na první pohled se odpověď zdá zřejmá, ale situace není tak jednoznačná, jak by se mohlo zdát. A na váš výběr může mít vliv nejen cena.

Příklad 1. Zpoždění.
Pokud je nízké zpoždění mezi některými segmenty sítě klíčovým požadavkem, což platí například v případě burzy, pak mezi těmito segmenty nebudeme moci používat firewally. Je obtížné najít studie o zpoždění ve firewallech, ale jen několik modelů přepínačů dokáže poskytnout zpoždění menší nebo kolem 1 mksec, proto si myslím, že pokud jsou pro vás mikrosekundy důležité, firewally nejsou pro vás.

Příklad 2. Výkon.
Propustnost špičkových L3 přepínačů je obvykle o řád vyšší než propustnost nejvýkonnějších firewallů. Proto v případě intenzivního provozu pravděpodobně budete muset tento provoz nasměrovat mimo firewally.

Příklad 3. Spolehlivost.
Firewally, zejména moderní NGFW (Next-Generation FW) – jsou složitá zařízení. Jsou výrazně složitější než L3/L2 přepínače. Nabízejí širokou škálu služeb a možností konfigurace, a proto není překvapením, že jejich spolehlivost je výrazně nižší. Pokud je kontinuita služby kritická pro síť, možná budete muset zvolit, co povede k lepší dostupnosti — ochranu pomocí firewallu nebo jednoduchost sítě založené na přepínačích (nebo různých typech fabric) s využitím standardních ACL.

V případě výše uvedených příkladů pravděpodobně (jak už to bývá) budete muset hledat kompromis. Podívejte se na následující řešení:

Pokud jste se rozhodli nepoužívat firewally uvnitř datového centra, měli byste promyslet, jak co nejvíce omezit přístupy na perimetru. Například můžete otevřít pouze nezbytné porty z Internetu (pro klientský provoz) a administrativní přístupy do datového centra pouze z jump hostů. Na jump hostech provádět veškerou potřebnou kontrolu (autentizaci/ autorizaci, antiviry, logování, …)
Můžete použít logické rozdělení sítě datového centra na segmenty, podobně jako je popsáno ve schématu PSEFABRIC. příklad p002Routing must be configured in such a way that latency-sensitive or high-intensity traffic remains 'within' a segment (in the case of p002, the VRF) and does not pass through the firewall. Traffic between different segments, however, will still go through the firewall. Route leaking between VRFs can also be used to avoid redirecting traffic through the firewall.
You can also use the firewall in transparent mode and only for those VLANs where these factors (latency/performance) are not critical. However, it is important to carefully study the limitations associated with using this mode for each vendor.
You might consider implementing a service chain architecture. This will allow you to route only the necessary traffic through the firewall. Theoretically, it looks nice, but I have never seen this solution in production. We tested service chains for Cisco ACI/Juniper SRX/F5 LTM about three years ago, but at that time, the solution seemed 'raw' to us.

Level of Protection

Now you need to answer the question of what tools you want to use for traffic filtering. Here are some of the capabilities that are typically present in NGFW (for example, tady):

stateful firewalling (by default)
aplikační firewall
prevence hrozeb (antivirus, antispyware a zranitelnost)
filtrace URL
filtrace dat (filtrace obsahu)
blokování souborů (blokování typů souborů)
dos protection

And it's not all that straightforward either. One might think that the higher the level of protection, the better. But you also need to consider that

the more features mentioned above you use in the firewall, the more expensive it will naturally be (licenses, additional modules).
The use of certain algorithms can significantly reduce the firewall's throughput and increase latency, see for example tady
Like any complex solution, using sophisticated protection methods may lower the reliability of your solution. For instance, I have encountered application firewalling that blocked some standard applications (dns, smb).

As usual, you need to find a solution that is optimal for your network.

Není možné jednoznačně odpovědět na otázku, jaké ochranné funkce mohou být potřeba. Za prvé, protože to samozřejmě závisí na datech, která předáváte nebo ukládáte a snažíte se chránit. Za druhé, ve skutečnosti je výběr ochranných prostředků často otázkou víry a důvěry vůči dodavateli. Neznáte algoritmy, nevíte, jak efektivní jsou, a nemůžete je plně otestovat.

Proto v kritických segmentech může být dobrým řešením využít nabídky od různých společností. Například můžete zapnout antivir na firewallu, ale také použít antivirovou ochranu (jiného výrobce) lokálně na hostech.

Segmentace

Mluvíme o logické segmentaci sítě datacentra. Například rozdělení na VLANy a podsítě - to je také logická segmentace, ale nebudeme ji brát v úvahu vzhledem k její samozřejmosti. Zajímavá je segmentace se zohledněním takových entit jako FW bezpečnostní zóny, VRF (a jejich ekvivalentů u různých dodavatelů), logických zařízení (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, …), …

Příklad takové logické segmentace a v současné době žádaného designu datacentra je uveden v p002 projektu PSEFABRIC.

Po určení logických částí vaší sítě můžete dále popsat, jak se pohybuje provoz mezi různými segmenty, na jakých zařízeních se bude provádět filtrování a jakými prostředky.

Pokud ve vaší síti chybí jasné logické rozdělení a nejsou formalizována pravidla pro uplatňování bezpečnostních politik pro různé datové toky (flow), znamená to, že při otevírání přístupu musíte tuto otázku řešit, a s velkou pravděpodobností ji pokaždé vyřešíte různě.

Často je segmentace založena pouze na FW bezpečnostních zónách. Poté se musíte odpovědět na následující otázky:

jaké bezpečnostní zóny potřebujete
jakou úroveň ochrany chcete uplatnit na každou z těchto zón
bude povolen intra-zónový provoz jako výchozí
pokud ne, jaké politiky filtrování provozu budou uplatňovány uvnitř jednotlivých zón
jaké politiky filtrování provozu budou uplatňovány pro každou dvojici zón (source/destination)

TCAM

Často se setkáváme s problémem nedostatečné TCAM (Ternární obsahově adresovatelné paměti), jak pro směrování, tak pro přístupy. IMHO, je to jedna z nejdůležitějších otázek při výběru zařízení, proto je třeba k tomu přistupovat s patřičnou opatrností.

Příklad 1. Směrovací tabulka TCAM.
Pojďme se podívat na Palo Alto 7k firewall.
Vidíme, že velikost IPv4 směrovací tabulky* = 32K
Přitom je toto množství routů celkové pro všechny VSYS.
Předpokládáme, že podle vašeho designu jste se rozhodli použít 4 VSYS.
Každý z těchto VSYS je přes BGP připojen k dvěma PE MPLS cloudům, které používáte jako BB. Tímto způsobem si 4 VSYS vyměňují všechny specifické routy mezi sebou a mají směrovací tabulku s přibližně stejnou sadou tras (ale různými NH). Protože každý VSYS má 2 BGP relace (se stejnými nastaveními), každý rout, získaný přes MPLS, má 2 NH a tudíž 2 FIB záznamy ve směrovací tabulce. Pokud předpokládáme, že to je jediný firewall v datacentru a měl by znát všechny routy, bude to znamenat, že celkové množství rout v našem datacentru nemůže být více než 32K/(4 * 2) = 4K.
Nyní pokud předpokládáme, že máme 2 datacentra (se stejným designem) a chceme používat VLANy „protažené“ mezi datacentry (například pro vMotion), abychom vyřešili problém směrování, musíme použít hostitelské routy. Ale to znamená, že na 2 datacentra máme maximálně 4096 možných hostitelů a samozřejmě to může být nedostatečné.

Příklad 2. ACL TCAM.
Pokud plánujete filtrovat provoz na L3 přepínačích (nebo jiných řešeních, která používají L3 přepínače, například Cisco ACI), musíte při výběru zařízení věnovat pozornost ACL TCAM.
Předpokládejme, že chcete kontrolovat přístupy na SVI rozhraních Cisco Catalyst 4500. Jak je vidět z tohoto článku, pro kontrolu odchozího (i příchozího) provozu na rozhraních můžete použít pouze 4096 řádků TCAM. Což při použití TCAM3 poskytne přibližně 4000 ACE (řádků ACL).

Pokud se setkáte s problémem nedostatečného TCAM, měli byste nejprve zvážit možnosti optimalizace. Pokud je problém s velikostí Forwarding Table, je dobré zvážit agregaci tras. Pokud je problém s velikostí TCAM pro přístupy, je třeba provést audit přístupů, odstranit zastaralé a překrývající se záznamy a případně přehodnotit postup otvírání přístupů (toto bude podrobněji rozebráno v kapitole věnované auditu přístupů).

Vysoká dostupnost

Měli bychom použít HA pro firewally, nebo raději umístit "paralelně" dvě nezávislé jednotky a v případě selhání jedné z nich směrovat provoz přes druhou?

Na první pohled se zdá, že odpověď je jasná – použít HA. Důvod, proč se však tato otázka objevuje, spočívá v tom, že bohužel teoretických a reklamních 99 a několik devítek za desetinnou čárkou dostupnosti se v praxi ukazuje být daleko od ideálu. HA je logicky poměrně složitá záležitost a na různých zařízeních a s různými výrobci (žádná výjimka nebyla) jsme narazili na problémy a chyby a zastavení služby.

Pokud použijete HA, získáte možnost vypínat jednotlivé uzly a přepínat mezi nimi bez přerušení služby, což je důležité například při upgradech. Máte však také poměrně vysokou pravděpodobnost, že se vám obě uzly rozbijí současně, a i to, že další upgrade neproběhne tak hladce, jak to slibuje výrobce (tomuto problému se lze vyhnout, pokud máte možnost testovat upgrade na laboratorním zařízení).

Pokud nepoužíváte HA, jsou vaše rizika v případě dvojitého selhání výrazně nižší (protože máte 2 nezávislé firewally), ale jelikož se relace nesynchronizují, pokaždé, když dojde k přepnutí mezi těmito firewally, budete ztrácet provoz. Můžete sice použít stateless firewalling, ale pak většina smyslu používání firewallu ztrácí význam.

Pokud jste tedy při auditu zjistili osaměle stojící firewally a přemýšlíte o zvýšení spolehlivosti vaší sítě, HA je samozřejmě jedním z doporučených řešení, ale musíte zvážit i nevýhody spojené s tímto přístupem a možná pro vaši síť bude vhodnější jiné řešení.

Pohodlí v řízení (manageability)

V podstatě je HA také o řízení. Místo konfigurace dvou zařízení odděleně a řešení problému se synchronizací konfigurací je spravujete do značné míry tak, jako byste měli jedno zařízení.

Ale možná máte více datových center a mnoho firewallů, pak se tento problém posune na novou úroveň. A otázka není jen o konfiguraci, ale také o