Ta članek je tretji v nizu člankov 'Kako prevzeti nadzor nad mrežno infrastrukturo'. Vsebino vseh člankov iz niza in povezave lahko najdete ovde.

Nima smisla govoriti o popolni odpravi tveganj v zvezi z varnostjo. Načeloma jih ne moremo znižati na nič. Prav tako je treba razumeti, da postajajo naša rešitev za večjo varnost omrežja vse bolj drage. Potrebno je najti razumljiv kompromis med ceno, zapletenostjo in varnostjo za vaše omrežje.

Seveda je varnostna zasnova organsko vgrajena v splošno arhitekturo in uporabljene rešitve varnosti vplivajo na razširljivost, zanesljivost, upravljivost ... mrežne infrastrukture, kar je prav tako treba upoštevati.

Vendar se spomnim, da trenutno ne govorimo o ustvarjanju omrežja. V skladu z našimi začetnimi pogoji smo že izbrali zasnovo, izbrali opremo in ustvarili infrastrukturo, na tem koraku moramo, kolikor je mogoče, 'živeti' in iskati rešitve v kontekstu prej izbrane metode.

Naša naloga zdaj je ugotoviti tveganja, povezana z varnostjo na ravni omrežja, in jih znižati na razumno raven.

Revizija omrežne varnosti

Če so v vaši organizaciji uvedeni postopki ISO 27k, potem mora biti revizija varnosti in sprememb omrežja organsko vključena v splošne procese v okviru tega pristopa. Vendar ti standardi niso o konkretnih rešitvah, ne o konfiguraciji, ne o zasnovi ... Ni natančnih nasvetov, ni standardov, ki podrobno določajo, kako naj bi bilo vaše omrežje, v tem je zapletenost in lepota te naloge.

Izpostavil bi nekaj možnih revizij varnosti omrežja:

revizija konfiguracije opreme (hardening)
revizija varnostne zasnove
revizija dostopov
revizija procesov

Revizija konfiguracije opreme (hardening)

Zdi se, da je v večini primerov to najboljša izhodiščna točka za revizijo in izboljšanje varnosti vašega omrežja. IMHO, to je dobra demonstracija Pareto zakona (20 % truda prinese 80 % rezultata, preostalih 80 % truda pa le 20 % rezultata).

Bistvo je, da običajno imamo priporočila proizvajalcev glede 'najboljših praks' za varnost pri konfiguriranju opreme. To imenujemo 'hardening'.

Pogosto se lahko srečate s vprašalnikom (ali ga sestavite sami) na podlagi teh priporočil, ki vam pomaga določiti, koliko vaša strojna oprema ustreza tem "najboljšim praksam" in v skladu z rezultatom izvedeti spremembe v vašem omrežju. Tako boste lahko precej enostavno, dejansko brez stroškov, bistveno zmanjšali varnostne tveganja.

Nekaj primerov za nekatere operacijske sisteme Cisco.
Utrjevanje Cisco IOS konfiguracije
Utrjevanje Cisco IOS-XR konfiguracije
Utrjevanje Cisco NX-OS konfiguracije
Seznam osnovne varnosti Cisco
Na podlagi teh dokumentov lahko ustvarite seznam zahtev za konfiguracijo za vsak tip strojne opreme. Na primer, za Cisco N7K VDC so te zahteve lahko videti tako.

Tako lahko ustvarite konfiguracijske datoteke za različne tipe aktivne opreme vaše omrežne infrastrukture. Nato lahko ročno ali z uporabo avtomatizacije "naložite" te konfiguracijske datoteke. Kako avtomatizirati ta postopek bo podrobno obravnavano v drugi seriji člankov, posvečenih orkestraciji in avtomatizaciji.

Revizija varnostnega dizajna

Običajno v omrežju podjetja (enterprise network) v neki ali drugi obliki obstajajo naslednji segmenti:

DC (Javna storitev DMZ in intranet podatkovni center)
Dostop do interneta
Oddaljeni dostop VPN
WAN rob
Podružnica
Campus (Pisarna)
Jedro

Ime so vzeta iz Cisco SAFE modelov, vendar seveda ni nujno vezati ravno na ta imena in ta model. Konec koncev želimo govoriti o bistvu in ne zapletati se v formalnosti.

Za vsak od teh segmentov se bodo zahtevani varnostni nivoji, tveganja in s tem rešitve razlikovale.

Poglejmo vsak segment posebej glede na težave, s katerimi se lahko srečate z vidika varnostnega dizajna. Seveda, ponovno ponavljam, da ta članek nikakor ne trdi, da je celovit, doseči to v tej res globoki in večplastni temi ni enostavno (če sploh mogoče), vendar odraža moje osebne izkušnje.

Ne obstaja popolna rešitev (vsaj ne trenutno). Vedno gre za kompromis. Pomembno je, da se odločitev za uporabo določenega pristopa sprejme zavestno, z razumevanjem njenih prednosti in slabosti.

Podatkovni center

Najbolj kritičen segment z vidika varnosti.
In, kot ponavadi, tudi tukaj ni univerzalne rešitve. Vse močno odvisno od zahtev glede omrežja.

Ali potrebujemo požarni zid?

Zdi se, da je odgovor očiten, vendar ni vse tako enoznačno, kot se zdi. Na vaš izbor lahko vplivajo tudi drugi dejavniki. cena.

Primer 1. Zamude.
Če je nizka zamuda med določenimi omrežnimi segmenti bistvena zahteva, kar na primer velja za borze, potem med temi segmenti ne bomo mogli uporabljati požarnih zidov. Težko je najti raziskave o zamudah pri požarnih zidovih, toda le redki modeli stikal lahko zagotavljajo zamude manjše ali okoli 1 mksec, zato menim, da če so mikrosekunde za vas pomembne, potem požarni zidovi niso pravi za vas.

Primer 2. Performanse.
Pretočnost vrhunskih L3 stikal je običajno za red velikih razredov višja kot pretočnost najzmogljivejših požarnih zidov. Zato boste v primeru visokointenzivnega prometa najverjetneje morali te prometne tokove usmeriti mimo požarnih zidov.

Primer 3. Zanesljivost.
Požarni zidovi, zlasti sodobni NGFW (Next-Generation Firewall), so zapletena naprava. So bistveno kompleksnejši od L3/L2 stikal. Ponujajo veliko storitev in možnosti konfiguracije, zato ni presenetljivo, da je njihova zanesljivost bistveno nižja. Če je neprekinjenost storitve kritična za omrežje, boste morda morali izbrati, kaj bo prineslo boljšo dostopnost - zaščita s požarnim zidom ali preprostost omrežja, zgrajenega na stikalih (ali različnih tovarnah) z uporabo običajnih ACL.

V primeru zgoraj naštetih primerov boste najverjetneje (kot običajno) morali najti kompromis. Oglejte si naslednje rešitve:

če se odločite, da v podatkovnem centru ne boste uporabljali požarnih zidov, potem morate dobro premisliti, kako maksimalno omejiti dostop na obrobju. Na primer, lahko odprete samo potrebne porte iz interneta (za odjemalski promet) in administrativne dostope v podatkovni center le z jump hosts. Na jump hostih opravite vso potrebno preverjanje (avtentikacijo/avtorizacijo, protivirusno zaščito, beleženje, ...)
lahko uporabite logično delitev omrežja podatkovnega centra na segmente, podobno shemi, opisani v PSEFABRIC primer p002. Hkrati mora biti usmerjanje nastavljeno tako, da občutljiv promet glede latence ali visoko intenziven promet teče „znotraj“ enega segmenta (v primeru p002, VRF-a) in ne teče skozi požarni zid. Promet med različnimi segmenti pa bo še vedno potekal skozi požarni zid. Uporabite lahko tudi route leaking med VRF-ji, da se izognete preusmeritvi prometa skozi požarni zid.
Požarni zid lahko prav tako uporabljate v transparentnem načinu in samo za tiste VLAN-e, kjer ti dejavniki (latenčnost/preformans) niso pomembni. Vendar je treba natančno proučiti omejitve, povezane z uporabo tega načina, za vsakega dobavitelja.
Lahko razmislite o uporabi arhitekture service chain. To bo omogočilo usmerjanje samo potrebnega prometa skozi požarni zid. Teoretično izgleda lepo, a nikoli nisem videl te rešitve v produkciji. Testirali smo service chain za Cisco ACI/Juniper SRX/F5 LTM pred približno 3 leti, vendar se je ta rešitev tedaj zdela „nepregreta“.

Raven zaščite

Zdaj se morate vprašati, katere instrumente želite uporabiti za filtriranje prometa. Tu je nekaj možnosti, ki jih običajno ponuja NGFW (na primer, tukaj):

stateful firewalling (privzeto)
aplikacijski požarni zid
preprečevanje groženj (antivirus, proti vohunskim in ranljivostim)
filtriranje URL-jev
filtriranje podatkov (filtriranje vsebine)
blokiranje datotek (blokiranje tipov datotek)
zaščita pred DDoS-om

In tudi ni vse tako enostavno. Zdi se, da višja raven zaščite pomeni boljšo zaščito. A morate tudi upoštevati, da

več funkcij požarnega zidu, kot je navedeno zgoraj, uporabite, temeljito to postane dražje (licence, dodatni moduli).
Uporaba nekaterih algoritmov lahko znatno zmanjša prepustnost požarnega zidu ter poveča latenco, glejte na primer tukaj
Kot katero koli kompleksno rešitev lahko uporaba zapletenih zaščitnih metod zmanjša zanesljivost vaše rešitve. Na primer, pri uporabi application firewalling sem naletel na blokiranje nekaterih povsem običajno delujočih aplikacij (dns, smb).

Kot običajno morate najti optimalno rešitev za vašo mrežo.

Ni mogoče je natančno odgovoriti na vprašanje, katere zaščitne funkcije so potrebne. Prvič, ker to seveda zaleži od podatkov, ki jih prenašate ali shranjujete in jih želite zaščititi. Drugič, v resnici je pogosto izbira zaščitnih sredstev vprašanje vere in zaupanja do ponudnika. Ne poznate algoritmov, ne veste, kako učinkoviti so in ne morete jih popolnoma preizkusiti.

Zato je v kritičnih segmentih dobro rešitev uporaba ponudb različnih podjetij. Na primer, lahko vključite antivirus na požarnem zidu, hkrati pa uporabljate antivirusno zaščito (drugih proizvajalcev) lokalno na gostiteljih.

Segmentacija

Gre za logično segmentacijo omrežja podatkovnega centra. Na primer, razdelitev na VLAN in podmreže – to je tudi logična segmentacija, vendar je ne bomo obravnavali zaradi njene očitnosti. Zanimiva je segmentacija, ki upošteva entitete, kot so FW varnostne cone, VRF (in njihovi analogi za različne ponudnike), logične naprave (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, …), …

Primer te logične segmentacije in trenutno povpraševane zasnove podatkovnega centra je prikazan v p002 projekta PSEFABRIC.

Ko določite logične dele vašega omrežja, lahko opisujete, kako se premika promet med različnimi segmenti, na katerih napravah bo potekala filtracija in s katerimi sredstvi.

Če v vašem omrežju ni jasne logične delitve in pravil za uporabo varnostnih politik za različne tokove podatkov (flow), to pomeni, da se ob odpiranju kakršnega koli dostopa prisiljeni odločiti za to nalogo in z veliko verjetnostjo jo boste vsakič reševali drugače.

Pogosto je segmentacija osnovana le na FW varnostnih conah. Takrat se morate odgovoriti na naslednja vprašanja:

kakšne varnostne cone potrebujete
kako raven zaščite želite uporabiti za vsako od teh con
bo intra-zone promet privoljen po privzetku
če ne, katere politike filtracije prometa se bodo uporabljale znotraj vsake od con
kakšne politike filtracije prometa se bodo uporabljale za vsak par con (source/destination)

TCAM

Pogosto se pojavlja težava z nezadostnim TCAM (Ternary Content Addressable Memory) tako za usmerjanje kot za dostop. IMHO, to je ena najpomembnejših vprašanj pri izbiri opreme, zato je potrebno to zadevo obravnavati s pravilno mero natančnosti.

Primer 1. Forwarding Table TCAM.
Oglejmo si Palo Alto 7k firewall.
Vidimo, da je velikost IPv4 forwarding table* = 32K
To število usmeritev pa je skupno za vse VSYS-e.
Predpostavimo, da ste se v skladu z vašim oblikovanjem odločili uporabiti 4 VSYS-e.
Vsak od teh VSYS-ov je preko BGP povezan z dvema PE MPLS oblakoma, ki ju uporabljate kot BB. Tako si 4 VSYS-i izmenjujejo vse specifične usmeritve med seboj in imajo forwarding table z približno enakimi nabori usmeritev (vendar z različnimi NH). Ker ima vsak VSYS po 2 BGP seji (z enakimi nastavitvami), ima vsaka usmeritev, pridobljena preko MPLS, 2 NH in posledično 2 FIB zapisa v Forwarding Table. Če predpostavimo, da je to edini firewall v podatkovnem centru in mora poznati vse usmeritve, to pomeni, da skupno število usmeritev v našem podatkovnem centru ne more biti več kot 32K/(4 * 2) = 4K.
Zdaj, če predpostavimo, da imamo 2 podatkovna centra (z enakim oblikovanjem), in želimo uporabiti VLAN-e, »raztegnjene« med podatkovnimi centri (na primer za vMotion), moramo za rešitev težave z usmerjanjem uporabiti gostiteljske usmeritve. Toda to pomeni, da imamo na 2 podatkovna centra največ 4096 mogočih gostiteljev in seveda to morda ne bo dovolj.

Primer 2. ACL TCAM.
Če nameravate filtrirati promet na L3 stikalah (ali drugih rešitvah, ki uporabljajo L3 stikala, na primer Cisco ACI), morate pri izbiri opreme paziti na ACL TCAM.
Predpostavimo, da želite nadzorovati dostop na SVI vmesnikih Cisco Catalyst 4500. Takrat, kot je razvidno iz ovog članka, lahko za nadzor izhodnega (prav tako kot in vhodnega) prometa na vmesnikih uporabite le 4096 vrstic TCAM. Kar pri uporabi TCAM3 pomeni približno 4000 tisoč ACE (vrstic ACL).

Če se soočate s težavo pomanjkanja TCAM-a, je najprej seveda potrebno razmisliti o optimizaciji. Tako, v primeru težave z velikostjo Forwarding Table, razmislite o agregaciji poti. V primeru težave z velikostjo TCAM za dostope — opravite pregled dostopov, odstranite zastarele in prekrivne vnose ter morda ponovno preučite postopek odpiranja dostopov (to bo podrobneje obravnavano v poglavju, posvečenem pregledu dostopov).

Visoka razpoložljivost

Vprašanje je, ali uporabiti HA za požarne zidove ali pa postaviti dve neodvisni enoti 'paralelno' in ob primeru okvare ene izmed njih usmerjati promet preko druge?

Na videz je odgovor očiten – uporabiti HA. Razlog, zakaj se to vprašanje kljub temu pojavi, je ta, da se, žal, teoretičnih in oglaševalskih 99 in še nekaj devetic za vejico glede dostopnosti v praksi izkaže za daleč od optimističnega. HA je logično dovolj zapleten sistem, in na različni opremi, ter pri različnih proizvajalcih (brez izjem) smo naleteli na težave, napake in zaustavitve storitev.

V primeru uporabe HA boste imeli možnost izklopiti posamezne vozlišča, preklapljati med njimi brez zaustavitve storitve, kar je pomembno, na primer, pri nadgradnjah, vendar je to povezano s precejšnjo verjetnostjo, da se bo zgodilo, da se bosta obe vozliščni enoti hkrati pokvarili, ter, da nadgradnja ne bo potekala tako gladko, kot obljublja proizvajalec (to težavo lahko preprečite, če imate možnost testirati nadgradnjo na laboratorijski opremi).

Če ne uporabljate HA, so tveganja v primeru dvojne okvare znatno nižja (ker imate 2 neodvisna požarna zidu), toda ker se seje ne sinhronizirajo, boste kadarkoli, ko bo prišlo do preklopa med temi požarnimi zidovi, izgubljali promet. Seveda lahko uporabite stateless firewalling, toda takrat se smisel uporabe požarnega zidu v veliki meri izgubi.

Zato, če ste med pregledom odkrili osamljene požarne zidove in razmišljate o povečanju zanesljivosti vaše omrežne infrastrukture, je HA seveda ena od priporočenih rešitev, vendar morate upoštevati tudi slabosti, povezane s tem pristopom, in morda bo za vaše omrežje primernejša druga rešitev.

Enostavnost upravljanja

Na splošno HA vključuje tudi vprašanje upravljanja. Namesto da bi konfigurirali dve napravi ločeno in rešili težavo s sinhronizacijo konfiguracij, z njimi upravljate skoraj tako, kot da imate eno samo napravo.

Toda, morda imate veliko podatkovnih centrov in veliko požarnih zidov, takrat se to vprašanje pojavi na novi ravni. In vprašanje ni le o konfiguriranju, temveč tudi o