Tento článok je tretím zo série článkov „Ako prevziať kontrolu nad sieťovou infraštruktúrou“. Obsah všetkých článkov v sérii a odkazy nájdete tu.

O úplnej eliminácii bezpečnostných rizík nemá zmysel hovoriť. V zásade ich nemôžeme znížiť na nulu. Musíme tiež pochopiť, že keď sa snažíme, aby bola sieť stále bezpečnejšia, naše riešenia sú čoraz drahšie. Musíte nájsť kompromis medzi nákladmi, zložitosťou a bezpečnosťou, ktorý má zmysel pre vašu sieť.

Samozrejme, bezpečnostný dizajn je organicky integrovaný do celkovej architektúry a použité bezpečnostné riešenia ovplyvňujú škálovateľnosť, spoľahlivosť, spravovateľnosť, ... sieťovej infraštruktúry, čo by sa malo tiež brať do úvahy.

Dovoľte mi však pripomenúť, že teraz nehovoríme o vytvorení siete. Podľa nášho počiatočné podmienky už sme si vybrali dizajn, vybrali zariadenia, vytvorili infraštruktúru a v tejto fáze by sme, ak je to možné, mali „žiť“ a hľadať riešenia v kontexte predtým zvoleného prístupu.

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

Audit bezpečnosti siete

Ak vaša organizácia implementovala procesy ISO 27k, potom bezpečnostné audity a zmeny siete by mali hladko zapadať do celkových procesov v rámci tohto prístupu. Ale tieto normy stále nie sú o konkrétnych riešeniach, nie o konfigurácii, nie o dizajne... Neexistujú žiadne jednoznačné rady, žiadne normy, ktoré by podrobne diktovali, aká by mala byť vaša sieť, v tom je zložitosť a krása tejto úlohy.

Zdôraznil by som niekoľko možných auditov zabezpečenia siete:

• audit konfigurácie zariadenia (kalenie)
• audit bezpečnostného dizajnu
• audit prístupu
• procesný audit

Audit konfigurácie zariadenia (kalenie)

Zdá sa, že vo väčšine prípadov je to najlepší východiskový bod pre audit a zlepšenie bezpečnosti vašej siete. IMHO je to dobrá demonštrácia Paretovho zákona (20% úsilia produkuje 80% výsledku a zvyšných 80% úsilia produkuje iba 20% výsledku).

Pointa je, že zvyčajne máme odporúčania od predajcov týkajúce sa „osvedčených postupov“ pre bezpečnosť pri konfigurácii zariadenia. Toto sa nazýva „tvrdnutie“.

Na základe týchto odporúčaní môžete tiež často nájsť dotazník (alebo si ho vytvoriť sami), ktorý vám pomôže určiť, do akej miery je konfigurácia vášho zariadenia v súlade s týmito „osvedčenými postupmi“ a v súlade s výsledkom vykonať zmeny vo vašej sieti. . To vám umožní výrazne znížiť bezpečnostné riziká pomerne jednoducho, prakticky bez nákladov.

Niekoľko príkladov niektorých operačných systémov Cisco.

Cisco IOS Configuration Hardening
Spevnenie konfigurácie Cisco IOS-XR
Spevnenie konfigurácie Cisco NX-OS
Kontrolný zoznam zabezpečenia Cisco Baseline

Na základe týchto dokumentov je možné vytvoriť zoznam požiadaviek na konfiguráciu pre každý typ zariadenia. Napríklad pre Cisco N7K VDC môžu tieto požiadavky vyzerať tak.

Týmto spôsobom je možné vytvoriť konfiguračné súbory pre rôzne typy aktívnych zariadení vo vašej sieťovej infraštruktúre. Ďalej, manuálne alebo pomocou automatizácie, môžete tieto konfiguračné súbory „nahrať“. Ako automatizovať tento proces bude podrobne diskutované v ďalšej sérii článkov o orchestrácii a automatizácii.

Audit bezpečnostného dizajnu

Podniková sieť zvyčajne obsahuje nasledujúce segmenty v tej či onej forme:

• DC (verejné služby DMZ a intranetové dátové centrum)
• Prístup na internet
• Vzdialený prístup VPN
• Okraj WAN
• Vetva
• Campus (kancelária)
• Jadro

Tituly prevzaté z Cisco BEZPEČNÉ model, ale nie je potrebné, samozrejme, viazať sa presne na tieto názvy a na tento model. Napriek tomu sa chcem rozprávať o podstate a neutápať sa vo formalitách.

Pre každý z týchto segmentov budú bezpečnostné požiadavky, riziká a podľa toho aj riešenia odlišné.

Pozrime sa na každý z nich osobitne na problémy, s ktorými sa môžete stretnúť z hľadiska bezpečnostného dizajnu. Samozrejme znovu opakujem, že tento článok sa v žiadnom prípade netvári ako úplný, čo nie je ľahké (ak nie nemožné) dosiahnuť v tejto skutočne hlbokej a mnohostrannej téme, ale odráža moju osobnú skúsenosť.

Dokonalé riešenie neexistuje (aspoň zatiaľ). Vždy ide o kompromis. Je však dôležité, aby rozhodnutie o použití jedného alebo druhého prístupu bolo urobené vedome, s pochopením jeho pre a proti.

Dátové centrum

Najkritickejší segment z hľadiska bezpečnosti.
A ako to už býva, ani tu neexistuje univerzálne riešenie. Všetko závisí od požiadaviek siete.

Je firewall potrebný alebo nie?

Zdá sa, že odpoveď je zrejmá, ale všetko nie je také jasné, ako by sa mohlo zdať. A váš výber možno ovplyvniť nielen cena.

Príklad 1. Meškania.

Ak je nízka latencia nevyhnutnou požiadavkou medzi niektorými segmentmi siete, čo je napríklad pravda v prípade výmeny, potom medzi týmito segmentmi nebudeme môcť používať firewally. Je ťažké nájsť štúdie o latencii vo firewalloch, ale len málo modelov prepínačov dokáže poskytnúť latenciu menšiu alebo rádovo 1 mksec, takže si myslím, že ak sú pre vás dôležité mikrosekundy, firewally nie sú pre vás.

Príklad 2. Performance.

Priepustnosť špičkových L3 prepínačov je zvyčajne rádovo vyššia ako priepustnosť najvýkonnejších firewallov. Preto v prípade vysokej intenzity premávky budete tiež s najväčšou pravdepodobnosťou musieť povoliť, aby táto prevádzka obchádzala brány firewall.

Príklad 3. Spoľahlivosť.

Firewally, najmä moderné NGFW (Next-Generation FW) sú zložité zariadenia. Sú oveľa zložitejšie ako prepínače L3/L2. Poskytujú veľké množstvo služieb a možností konfigurácie, preto nie je prekvapujúce, že ich spoľahlivosť je oveľa nižšia. Ak je pre sieť kritická kontinuita služieb, možno si budete musieť vybrať, čo povedie k lepšej dostupnosti – bezpečnosť pomocou brány firewall alebo jednoduchosť siete postavenej na prepínačoch (alebo rôznych typoch štruktúr) pomocou bežných ACL.

V prípade vyššie uvedených príkladov budete musieť s najväčšou pravdepodobnosťou (ako obvykle) nájsť kompromis. Pozrite sa na nasledujúce riešenia:

• ak sa rozhodnete nepoužívať firewally vo vnútri dátového centra, potom sa musíte zamyslieť nad tým, ako čo najviac obmedziť prístup po obvode. Môžete napríklad otvoriť iba potrebné porty z internetu (pre klientsky prenos) a administratívny prístup do dátového centra iba z hostiteľov skokov. Na skokových hostiteľoch vykonajte všetky potrebné kontroly (autentifikácia/autorizácia, antivírus, protokolovanie, ...)
• môžete použiť logické rozdelenie siete dátového centra na segmenty, podobne ako v schéme opísanej v PSEFABRIC príklad p002. V tomto prípade musí byť smerovanie nakonfigurované tak, aby prevádzka citlivá na oneskorenie alebo vysoká intenzita prechádzala „v rámci“ jedného segmentu (v prípade p002, VRF) a neprechádzala cez firewall. Prevádzka medzi rôznymi segmentmi bude naďalej prechádzať cez firewall. Môžete tiež použiť únik trasy medzi VRF, aby ste sa vyhli presmerovaniu prevádzky cez bránu firewall
• Firewall môžete použiť aj v transparentnom režime a len pre tie VLAN, kde tieto faktory (latencia/výkon) nie sú významné. Musíte si však pozorne preštudovať obmedzenia spojené s používaním tohto modu pre každého predajcu
• možno budete chcieť zvážiť použitie architektúry reťazca služieb. To umožní, aby cez firewall prešla iba nevyhnutná prevádzka. Teoreticky to vyzerá pekne, ale toto riešenie som ešte vo výrobe nevidel. Reťazec služieb pre Cisco ACI/Juniper SRX/F5 LTM sme testovali asi pred 3 rokmi, no vtedy sa nám toto riešenie zdalo „hrubé“.

Úroveň ochrany

Teraz si musíte odpovedať na otázku, aké nástroje chcete použiť na filtrovanie návštevnosti. Tu sú niektoré z funkcií, ktoré sú zvyčajne prítomné v NGFW (napr. tu):

• stavový firewall (predvolené)
• aplikačný firewall
• prevencia hrozieb (antivírus, antispyware a zraniteľnosť)
• Filtrovanie adries URL
• filtrovanie údajov (filtrovanie obsahu)
• blokovanie súborov (blokovanie typov súborov)
• dos ochranu

A tiež nie je všetko jasné. Zdalo by sa, že čím vyššia úroveň ochrany, tým lepšie. Ale aj to treba zvážiť

• Čím viac z vyššie uvedených funkcií firewallu použijete, tým to bude prirodzene drahšie (licencie, prídavné moduly)
• použitie niektorých algoritmov môže výrazne znížiť priepustnosť firewallu a tiež zvýšiť oneskorenia, viď napr tu
• ako každé komplexné riešenie, aj použitie komplexných metód ochrany môže znížiť spoľahlivosť vášho riešenia, napríklad pri použití aplikačného firewallingu som sa stretol s blokovaním niektorých celkom štandardne fungujúcich aplikácií (dns, smb)

Ako vždy, musíte nájsť najlepšie riešenie pre vašu sieť.

Nie je možné definitívne odpovedať na otázku, aké ochranné funkcie môžu byť potrebné. Po prvé, pretože to samozrejme závisí od údajov, ktoré prenášate alebo ukladáte a ktoré sa snažíte chrániť. Po druhé, v skutočnosti je výber bezpečnostných nástrojov často otázkou viery a dôvery v dodávateľa. 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í. Môžete napríklad povoliť antivírus na firewalle, ale tiež použiť antivírusovú ochranu (od iného výrobcu) lokálne na hostiteľoch.

Segmentácia

Hovoríme o logickej segmentácii siete dátových centier. Napríklad rozdelenie do VLAN a podsietí je tiež logická segmentácia, ale nebudeme o nej uvažovať kvôli jej samozrejmosti. Zaujímavá segmentácia zohľadňujúca také entity, ako sú bezpečnostné zóny FW, VRF (a ich analógy vo vzťahu k rôznym predajcom), logické zariadenia (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

Príklad takejto logickej segmentácie a v súčasnosti žiadaný návrh dátového centra je uvedený v p002 projektu PSEFABRIC.

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

Ak vaša sieť nemá jasný logický oddiel a pravidlá uplatňovania bezpečnostných politík pre rôzne dátové toky nie sú formalizované, znamená to, že keď otvoríte ten či onen prístup, budete nútení tento problém vyriešiť a s vysokou pravdepodobnosťou vyrieši to zakaždým inak.

Často je segmentácia založená len na FW bezpečnostných zónach. Potom musíte odpovedať na nasledujúce otázky:

• aké bezpečnostné zóny potrebujete
• akú úroveň ochrany chcete použiť pre každú z týchto zón
• bude vnútrozónová premávka štandardne povolená?
• ak nie, aké politiky filtrovania návštevnosti sa použijú v každej zóne
• aké politiky filtrovania návštevnosti sa použijú pre každú dvojicu zón (zdroj/cieľ)

TCAM

Častým problémom je nedostatočná pamäť TCAM (Ternary Content Addressable Memory), ako pre smerovanie, tak aj pre prístupy. IMHO je to jeden z najdôležitejších problémov pri výbere vybavenia, preto je potrebné venovať tomuto problému náležitú starostlivosť.

Príklad 1. Tabuľka preposielania TCAM.

Poďme sa pozrieť na Palo Alto 7k POŽARNE DVERE
Vidíme, že veľkosť tabuľky preposielania IPv4* = 32 kB
Tento počet trás je navyše spoločný pre všetky systémy VSYS.

Predpokladajme, že podľa vášho návrhu sa rozhodnete použiť 4 VSYS.
Každý z týchto VSYS je pripojený cez BGP k dvom MPLS PE v cloude, ktorý používate ako BB. 4 VSYS si teda navzájom vymieňajú všetky špecifické trasy a majú tabuľku preposielania s približne rovnakými sadami ciest (ale rôznymi NH). Pretože každý VSYS má 2 relácie BGP (s rovnakými nastaveniami), potom má každá trasa prijatá cez MPLS 2 NH a podľa toho 2 položky FIB v tabuľke preposielania. Ak predpokladáme, že toto je jediný firewall v dátovom centre a musí vedieť o všetkých trasách, tak to bude znamenať, že celkový počet trás v našom dátovom centre nemôže byť väčší ako 32K/(4 * 2) = 4K.

Ak teraz predpokladáme, že máme 2 dátové centrá (s rovnakým dizajnom) a chceme použiť VLAN „natiahnuté“ medzi dátovými centrami (napríklad pre vMotion), potom na vyriešenie problému so smerovaním musíme použiť hostiteľské trasy. . To však znamená, že pre 2 dátové centrá nebudeme mať viac ako 4096 možných hostiteľov a, samozrejme, to nemusí stačiť.

Príklad 2. ACL TCAM.

Ak plánujete filtrovať prevádzku na prepínačoch L3 (alebo iných riešeniach, ktoré používajú prepínače L3, napríklad Cisco ACI), pri výbere zariadenia by ste mali venovať pozornosť TCAM ACL.

Predpokladajme, že chcete ovládať prístup na rozhraniach SVI zariadenia Cisco Catalyst 4500. Potom, ako je možné vidieť z tento článok, na riadenie odchádzajúcej (aj prichádzajúcej) prevádzky na rozhraniach môžete použiť iba 4096 liniek TCAM. Čo pri použití TCAM3 vám dá asi 4000 tisíc ACE (riadky ACL).

Ak sa stretnete s problémom nedostatočného TCAM, musíte samozrejme najprv zvážiť možnosť optimalizácie. Takže v prípade problému s veľkosťou tabuľky preposielania musíte zvážiť možnosť agregácie trás. V prípade problému s veľkosťou TCAM pre prístupy auditujte prístupy, odstráňte neaktuálne a prekrývajúce sa záznamy, prípadne revidujte postup otvárania prístupov (podrobne popísané v kapitole o auditovaní prístupov).

Vysoká dostupnosť

Otázka znie: mám použiť HA pre firewally alebo nainštalovať dva nezávislé boxy „paralelne“ a ak jeden z nich zlyhá, smerovať prevádzku cez druhý?

Zdá sa, že odpoveď je zrejmá - použite HA. Dôvod, prečo táto otázka stále vyvstáva, je, že žiaľ, teoretických a reklamných 99 a niekoľko desatinných percent prístupnosti v praxi to zďaleka nie je také ružové. HA je logicky dosť zložitá vec a na rôznych zariadeniach a u rôznych predajcov (neexistovali výnimky) sme zachytili problémy a chyby a zastavovali sa.

Ak používate HA, budete mať možnosť vypínať jednotlivé uzly, prepínať medzi nimi bez zastavenia služby, čo je dôležité napríklad pri robení upgradov, no zároveň nemáte ani zďaleka nulovú pravdepodobnosť, že oba uzly sa zároveň pokazí a tiež, že ďalší upgrade nepôjde tak hladko, ako predajca sľubuje (tomuto problému sa dá vyhnúť, ak máte možnosť testovať upgrade na laboratórnom zariadení).

Ak nepoužívate HA, tak z pohľadu dvojitého zlyhania sú vaše riziká oveľa nižšie (keďže máte 2 nezávislé firewally), ale keďže... relácie nie sú synchronizované, potom pri každom prepnutí medzi týmito bránami firewall stratíte prenos. Môžete samozrejme použiť bezstavový firewall, ale potom sa zmysel používania firewallu do značnej miery stráca.

Ak ste teda v dôsledku auditu objavili osamelé firewally a uvažujete o zvýšení spoľahlivosti vašej siete, potom je HA, samozrejme, jedným z odporúčaných riešení, mali by ste však vziať do úvahy aj nevýhody spojené s s týmto prístupom a možno práve pre vašu sieť by bolo vhodnejšie iné riešenie.

Ovládateľnosť

HA je v princípe aj o ovládateľnosti. Namiesto konfigurácie 2 boxov oddelene a riešenia problému synchronizácie konfigurácií ich spravujete podobne, ako keby ste mali jedno zariadenie.

Ale možno máte veľa dátových centier a veľa firewallov, potom vyvstáva táto otázka na novej úrovni. A otázka nie je len o konfigurácii, ale aj o

• zálohovanie konfigurácií
• aktualizácie
• upgrady
• monitorovanie
• ťažba dreva

A toto všetko môžu vyriešiť centralizované systémy riadenia.

Napríklad, ak používate brány firewall Palo Alto, potom Panoráma je takéto riešenie.

Bude pokračovať.

Zdroj: hab.com