Ta članek je tretji v nizu člankov »Kako prevzeti nadzor nad svojo omrežno infrastrukturo«. Vsebino vseh člankov v seriji in povezave najdete tukaj.

O popolni odpravi varnostnih tveganj nima smisla govoriti. Načeloma jih ne moremo zreducirati na nič. Prav tako moramo razumeti, da naše rešitve postajajo čedalje dražje, medtem ko si prizadevamo narediti omrežje vse bolj varno. Najti morate kompromis med ceno, kompleksnostjo in varnostjo, ki je smiselna za vaše omrežje.

Seveda je varnostna zasnova organsko vpeta v celotno arhitekturo in uporabljene varnostne rešitve vplivajo na razširljivost, zanesljivost, vodljivost, ... omrežne infrastrukture, kar je treba tudi upoštevati.

Naj vas spomnim, da zdaj ne govorimo o ustvarjanju mreže. Po našem začetni pogoji smo že izbrali zasnovo, izbrali opremo in izdelali infrastrukturo, v tej fazi pa bi morali, če je le mogoče, »živeti« in iskati rešitve v kontekstu predhodno izbranega pristopa.

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

Revizija varnosti omrežja

Če je vaša organizacija uvedla procese ISO 27k, bi se morale varnostne revizije in spremembe omrežja brezhibno ujemati s splošnimi procesi v okviru tega pristopa. Toda ti standardi še vedno niso specifične rešitve, ne konfiguracija, ne dizajn ... Ni jasnih nasvetov, nobenih standardov, ki bi natančno določali, kakšno mora biti vaše omrežje, to je kompleksnost in lepota te naloge.

Izpostavil bi več možnih revizij varnosti omrežja:

• revizija konfiguracije opreme (kaljenje)
• revizija zasnove varnosti
• revizija dostopa
• procesna revizija

Revizija konfiguracije opreme (kaljenje)

Zdi se, da je v večini primerov to najboljše izhodišče za revizijo in izboljšanje varnosti vašega omrežja. IMHO, to je dober prikaz Paretovega zakona (20% truda povzroči 80% rezultata, preostalih 80% truda pa le 20% rezultata).

Bistvo je, da imamo običajno priporočila prodajalcev glede "najboljših praks" za varnost pri konfiguriranju opreme. To se imenuje "utrjevanje".

Na podlagi teh priporočil lahko pogosto najdete tudi vprašalnik (ali ga ustvarite sami), ki vam bo pomagal ugotoviti, kako dobro je konfiguracija vaše opreme skladna s temi »najboljšimi praksami«, in v skladu z rezultatom narediti spremembe v vašem omrežju . To vam bo omogočilo, da občutno zmanjšate varnostna tveganja dokaj enostavno, skoraj brez stroškov.

Nekaj ​​primerov za nekatere operacijske sisteme Cisco.

Utrjevanje konfiguracije Cisco IOS
Utrjevanje konfiguracije Cisco IOS-XR
Utrjevanje konfiguracije Cisco NX-OS
Varnostni kontrolni seznam Cisco Baseline

Na podlagi teh dokumentov je mogoče ustvariti seznam konfiguracijskih zahtev za vsako vrsto opreme. Na primer, za Cisco N7K VDC bi te zahteve lahko izgledale tako Tako.

Na ta način lahko ustvarite konfiguracijske datoteke za različne vrste aktivne opreme v vaši omrežni infrastrukturi. Nato lahko ročno ali z uporabo avtomatizacije "naložite" te konfiguracijske datoteke. O tem, kako avtomatizirati ta proces, bomo podrobno razpravljali v drugi seriji člankov o orkestraciji in avtomatizaciji.

Revizija zasnove varnosti

Običajno omrežje podjetja v takšni ali drugačni obliki vsebuje naslednje segmente:

• DC (javne storitve DMZ in intranetni podatkovni center)
• Dostop do interneta
• Oddaljeni dostop VPN
• rob WAN
• Branch
• Kampus (pisarna)
• Core

Naslovi vzeti iz Cisco VARNO modela, ni pa seveda nujno, da se navezujemo prav na ta imena in na ta model. Vseeno želim govoriti o bistvu in se ne zatikati v formalnosti.

Za vsakega od teh segmentov bodo varnostne zahteve, tveganja in s tem tudi rešitve drugačne.

Oglejmo si vsakega od njih posebej zaradi težav, na katere lahko naletite z vidika načrtovanja varnosti. Seveda še enkrat ponavljam, da ta članek nikakor ne pretendira na popolnost, kar v tej res globoki in večplastni temi ni lahko (če ne nemogoče) doseči, ampak odraža mojo osebno izkušnjo.

Popolne rešitve ni (vsaj še ne). Vedno je kompromis. Vendar je pomembno, da se za uporabo enega ali drugega pristopa odločimo zavestno, z razumevanjem njegovih prednosti in slabosti.

Podatkovno središče

Najbolj kritičen segment z varnostnega vidika.
In kot običajno, tudi tu ni univerzalne rešitve. Vse je močno odvisno od omrežnih zahtev.

Je požarni zid potreben ali ne?

Zdi se, da je odgovor očiten, vendar ni vse tako jasno, kot se morda zdi. In na vašo izbiro lahko vplivate ne samo Cena.

Primer 1. Zamude.

Če je nizka latenca bistvena zahteva med nekaterimi segmenti omrežja, kar na primer velja v primeru izmenjave, potem med temi segmenti ne bomo mogli uporabljati požarnih zidov. Težko je najti študije o zakasnitvi pri požarnih zidovih, vendar le nekaj modelov stikal lahko zagotovi zakasnitev, manjšo od ali reda velikosti 1 mks, zato menim, da če so vam mikrosekunde pomembne, potem požarni zidovi niso za vas.

Primer 2. Zmogljivost.

Prepustnost vrhunskih stikal L3 je običajno za red velikosti višja od prepustnosti najmočnejših požarnih zidov. Zato boste tudi v primeru visoke intenzivnosti prometa najverjetneje morali omogočiti, da ta promet obide požarne zidove.

Primer 3. Zanesljivost.

Požarni zidovi, zlasti sodobni NGFW (Next-Generation FW), so kompleksne naprave. So veliko bolj zapletena kot stikala L3/L2. Zagotavljajo veliko število storitev in konfiguracijskih možnosti, zato ne preseneča, da je njihova zanesljivost precej manjša. Če je neprekinjenost storitev ključnega pomena za omrežje, potem boste morda morali izbrati, kaj bo privedlo do boljše razpoložljivosti - varnost s požarnim zidom ali preprostost omrežja, zgrajenega na stikalih (ali različnih vrstah tkanin) z uporabo običajnih ACL.

V primeru zgornjih primerov boste najverjetneje (kot običajno) morali najti kompromis. Poglejte naslednje rešitve:

• če se odločite, da ne boste uporabljali požarnih zidov znotraj podatkovnega centra, potem morate razmišljati o tem, kako čim bolj omejiti dostop po obodu. Na primer, lahko odprete samo potrebna vrata iz interneta (za promet odjemalcev) in skrbniški dostop do podatkovnega centra samo s preskočnih gostiteljev. Na jump gostiteljih izvedite vsa potrebna preverjanja (avtentikacija/avtorizacija, antivirus, beleženje, ...)
• lahko uporabite logično razdelitev omrežja podatkovnega centra na segmente, podobno shemi, opisani v PSEFABRIC primer p002. V tem primeru mora biti usmerjanje konfigurirano tako, da gre promet, občutljiv na zakasnitev ali visoko intenzivnost, "znotraj" enega segmenta (v primeru p002, VRF) in ne gre skozi požarni zid. Promet med različnimi segmenti bo še naprej potekal skozi požarni zid. Uporabite lahko tudi uhajanje poti med VRF-ji, da se izognete preusmerjanju prometa skozi požarni zid
• Požarni zid lahko uporabite tudi v transparentnem načinu in samo za tista omrežja VLAN, kjer ti dejavniki (zakasnitev/zmogljivost) niso pomembni. Vendar morate natančno preučiti omejitve, povezane z uporabo tega moda za vsakega prodajalca
• morda boste želeli razmisliti o uporabi arhitekture storitvene verige. To bo omogočilo prehod samo potrebnega prometa skozi požarni zid. V teoriji izgleda lepo, vendar te rešitve še nikoli nisem videl v proizvodnji. Servisno verigo za Cisco ACI/Juniper SRX/F5 LTM smo testirali pred približno 3 leti, vendar se nam je takrat ta rešitev zdela “surova”.

Stopnja zaščite

Zdaj morate odgovoriti na vprašanje, katera orodja želite uporabiti za filtriranje prometa. Tukaj je nekaj funkcij, ki so običajno prisotne v NGFW (npr. tukaj):

• požarni zid s spremljanjem stanja (privzeto)
• požarni zid aplikacije
• preprečevanje groženj (protivirusna, protivohunska programska oprema in ranljivost)
• Filtriranje URL-jev
• filtriranje podatkov (filtriranje vsebine)
• blokiranje datotek (blokiranje vrst datotek)
• dos zaščita

In tudi ni vse jasno. Zdi se, da višja kot je stopnja zaščite, tem bolje. Vendar morate tudi to upoštevati

• Več zgoraj navedenih funkcij požarnega zidu uporabljate, dražji bo seveda (licence, dodatni moduli)
• uporaba nekaterih algoritmov lahko znatno zmanjša prepustnost požarnega zidu in tudi poveča zamude, glejte npr tukaj
• Kot vsaka zapletena rešitev lahko uporaba zapletenih metod zaščite zmanjša zanesljivost vaše rešitve, na primer pri uporabi požarnega zidu aplikacij sem naletel na blokiranje nekaterih povsem standardno delujočih aplikacij (dns, smb)

Kot vedno morate najti najboljšo rešitev za vaše omrežje.

Nemogoče je dokončno odgovoriti na vprašanje, katere zaščitne funkcije so morda potrebne. Prvič, ker je seveda odvisno od podatkov, ki jih prenašate ali shranjujete in poskušate zaščititi. Drugič, v resnici je izbira varnostnih orodij pogosto stvar vere in zaupanja v prodajalca. Ne poznate algoritmov, ne veste, kako učinkoviti so, in jih ne morete v celoti preizkusiti.

Zato je v kritičnih segmentih lahko dobra rešitev uporaba ponudb različnih podjetij. Na primer, lahko omogočite protivirusni program na požarnem zidu, vendar uporabite protivirusno zaščito (drugega proizvajalca) lokalno na gostiteljih.

Segmentacija

Govorimo o logični segmentaciji omrežja podatkovnega centra. Na primer, particioniranje na VLAN in podomrežja je prav tako logična segmentacija, vendar je ne bomo upoštevali zaradi njene očitnosti. Zanimiva segmentacija z upoštevanjem takšnih entitet, kot so varnostne cone FW, VRF-ji (in njihovi analogi glede na različne prodajalce), logične naprave (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

Primer takšne logične segmentacije in trenutno zahtevane zasnove podatkovnega centra je podan v p002 projekta PSEFABRIC.

Ko definirate logične dele vašega omrežja, lahko nato opišete, kako se promet premika med različnimi segmenti, na katerih napravah se bo izvajalo filtriranje in na kakšen način.

Če vaše omrežje nima jasne logične particije in pravila za uporabo varnostnih politik za različne tokove podatkov niso formalizirana, to pomeni, da ste, ko odprete ta ali oni dostop, prisiljeni rešiti to težavo in z veliko verjetnostjo bo rešil vsakič drugače.

Segmentacija pogosto temelji le na varnostnih območjih FW. Nato morate odgovoriti na naslednja vprašanja:

• katera varnostna območja potrebujete
• kakšno raven zaščite želite uporabiti za vsako od teh območij
• ali bo promet znotraj območja privzeto dovoljen?
• če ne, kateri pravilniki za filtriranje prometa bodo uporabljeni znotraj posamezne cone
• kateri pravilniki za filtriranje prometa bodo uporabljeni za vsak par območij (vir/cilj)

TCAM

Pogosta težava je nezadostna količina TCAM (Ternary Content Addressable Memory), tako za usmerjanje kot za dostope. IMHO, to je eno najpomembnejših vprašanj pri izbiri opreme, zato morate to vprašanje obravnavati z ustrezno mero skrbnosti.

Primer 1. Tabela posredovanja TCAM.

Poglejmo Palo Alto 7k požarni zid
Vidimo, da je velikost tabele za posredovanje IPv4* = 32K
Poleg tega je to število poti skupno za vse VSYS.

Predpostavimo, da se glede na vašo zasnovo odločite za uporabo 4 VSYS.
Vsak od teh VSYS je prek BGP povezan z dvema MPLS PE v oblaku, ki ju uporabljate kot BB. Tako 4 VSYS med seboj izmenjujejo vse specifične poti in imajo tabelo za posredovanje s približno enakimi nizi poti (vendar različnimi NH). Ker vsak VSYS ima 2 seji BGP (z enakimi nastavitvami), potem ima vsaka pot, prejeta prek MPLS, 2 NH in temu primerno 2 FIB vnosa v tabeli posredovanja. Če predpostavimo, da je to edini požarni zid v podatkovnem centru in mora poznati vse poti, bo to pomenilo, da skupno število poti v našem podatkovnem centru ne sme biti večje od 32K/(4 * 2) = 4K.

Zdaj, če predpostavimo, da imamo 2 podatkovna centra (z enako zasnovo) in želimo uporabiti VLAN-e, »raztegnjene« med podatkovnimi centri (na primer za vMotion), potem moramo za rešitev težave z usmerjanjem uporabiti gostiteljske poti . A to pomeni, da za 2 podatkovna centra ne bomo imeli več kot 4096 možnih gostiteljev in seveda to morda ne bo dovolj.

Primer 2. ACL TCAM.

Če nameravate filtrirati promet na stikala L3 (ali druge rešitve, ki uporabljajo stikala L3, na primer Cisco ACI), potem pri izbiri opreme bodite pozorni na TCAM ACL.

Recimo, da želite nadzorovati dostop do vmesnikov SVI Cisco Catalyst 4500. Nato, kot je razvidno iz ta članek, za nadzor odhodnega (kot tudi dohodnega) prometa na vmesnikih lahko uporabite samo 4096 linij TCAM. Kar vam bo pri uporabi TCAM3 dalo približno 4000 tisoč ACE (vrstic ACL).

Če se soočate s problemom nezadostnega TCAM, morate seveda najprej razmisliti o možnosti optimizacije. Torej, v primeru težave z velikostjo tabele za posredovanje, morate razmisliti o možnosti združevanja poti. V primeru težave z velikostjo TCAM za dostope revidirajte dostope, odstranite zastarele in prekrivajoče se zapise ter po možnosti revidirajte postopek za odpiranje dostopov (podrobneje o tem v poglavju o revizijskih dostopih).

Visoka dostopnost

Vprašanje je: naj uporabim HA za požarne zidove ali naj namestim dve neodvisni škatli "vzporedno" in če ena od njiju odpove, usmerim promet skozi drugo?

Zdi se, da je odgovor očiten - uporabite HA. Razlog, zakaj se to vprašanje še poraja, je v tem, da se teoretični in oglaševalski 99 ter več decimalnih odstotkov dostopnosti v praksi žal še zdaleč ne izkažejo za tako rožnate. HA je logično precej kompleksna zadeva in na drugačni opremi in pri različnih prodajalcih (ni bilo izjem) smo lovili težave in hrošče ter servisne ustavitve.

Če uporabljate HA, boste imeli možnost izključiti posamezna vozlišča, preklapljati med njimi brez prekinitve storitve, kar je pomembno na primer pri nadgradnjah, hkrati pa imate daleč od nič verjetnosti, da obe vozlišči se bo ob tem pokvaril in tudi, da naslednja nadgradnja ne bo potekala tako gladko, kot obljublja prodajalec (tej težavi se je mogoče izogniti, če imate možnost preizkusiti nadgradnjo na laboratorijski opremi).

Če ne uporabljate HA, potem so z vidika dvojne napake vaša tveganja veliko manjša (ker imate 2 neodvisna požarna zidu), a ker ... seje niso sinhronizirane, boste vsakič, ko preklopite med temi požarnimi zidovi, izgubili promet. Seveda lahko uporabite požarni zid brez stanja, vendar je smisel uporabe požarnega zidu v veliki meri izgubljen.

Torej, če ste kot rezultat revizije odkrili osamljene požarne zidove in razmišljate o povečanju zanesljivosti vašega omrežja, potem je HA seveda ena od priporočenih rešitev, vendar morate upoštevati tudi slabosti, povezane z s tem pristopom in morda posebej za vaše omrežje bi bila primernejša druga rešitev.

Vodljivost

Načeloma gre pri HA tudi za obvladljivost. Namesto da konfigurirate 2 škatli ločeno in se ukvarjate s problemom ohranjanja sinhronizacije konfiguracij, jih upravljate tako, kot če bi imeli eno napravo.

Morda pa imate veliko podatkovnih centrov in veliko požarnih zidov, potem se to vprašanje pojavi na novi ravni. In vprašanje ni le v konfiguraciji, ampak tudi v

• varnostne kopije konfiguracij
• posodobitve
• nadgradnje
• spremljanje
• sečnja

In vse to je mogoče rešiti s centraliziranimi sistemi upravljanja.

Torej, na primer, če uporabljate požarne zidove Palo Alto Poglej je taka rešitev.

Se nadaljuje.

Vir: www.habr.com