Ez a cikk a harmadik a „Hogyan veheti át az irányítást a hálózati infrastruktúrája felett” című cikksorozatban. A sorozat összes cikkének tartalma és linkjei megtalálhatók itt.

Nincs értelme a biztonsági kockázatok teljes kiküszöböléséről beszélni. Elvileg nem csökkenthetjük őket nullára. Azt is meg kell értenünk, hogy ahogy arra törekszünk, hogy a hálózatot egyre biztonságosabbá tegyük, megoldásaink egyre drágábbak. Olyan kompromisszumot kell találnia a költségek, a bonyolultság és a biztonság között, amely ésszerű a hálózata számára.

Természetesen a biztonsági tervezés szervesen beépül a teljes architektúrába, és az alkalmazott biztonsági megoldások hatással vannak a hálózati infrastruktúra skálázhatóságára, megbízhatóságára, kezelhetőségére, ..., amit szintén figyelembe kell venni.

De hadd emlékeztesselek arra, hogy most nem hálózat létrehozásáról beszélünk. A mi szerint kezdeti feltételek már kiválasztottuk a tervezést, kiválasztottuk a berendezést, kialakítottuk az infrastruktúrát, és ebben a szakaszban lehetőség szerint a korábban választott szemlélet kontextusában kell „élni” és megoldásokat találni.

Feladatunk most a biztonsággal kapcsolatos kockázatok hálózati szintű azonosítása és ésszerű szintre csökkentése.

Hálózatbiztonsági audit

Ha szervezete bevezette az ISO 27k folyamatokat, akkor a biztonsági auditoknak és a hálózati változtatásoknak zökkenőmentesen illeszkedniük kell az általános folyamatokhoz ebben a megközelítésben. De ezek a szabványok továbbra sem konkrét megoldásokról szólnak, nem konfigurációról, nem tervezésről... Nincsenek egyértelmű tanácsok, nincsenek olyan szabványok, amelyek részletesen megszabják, milyen legyen a hálózata, ez a feladat összetettsége és szépsége.

Kiemelnék néhány lehetséges hálózatbiztonsági auditot:

• berendezés konfiguráció audit (edzett)
• biztonsági tervezési audit
• hozzáférési audit
• folyamat audit

Berendezés konfiguráció audit (edzett)

Úgy tűnik, hogy a legtöbb esetben ez a legjobb kiindulópont a hálózat ellenőrzéséhez és biztonságának javításához. IMHO, ez jól mutatja a Pareto-törvényt (az erőfeszítés 20%-a az eredmény 80%-át adja, a maradék 80%-a pedig csak az eredmény 20%-át).

A lényeg az, hogy általában a gyártóktól kapunk ajánlásokat a berendezések konfigurálásakor a biztonság "legjobb gyakorlataira". Ezt nevezik „keményedésnek”.

Ezen ajánlások alapján gyakran találhat kérdőívet (vagy készíthet saját maga), amely segít meghatározni, hogy berendezése konfigurációja mennyire felel meg ezeknek a „legjobb gyakorlatoknak”, és az eredménynek megfelelően módosíthatja a hálózatot. . Ez lehetővé teszi a biztonsági kockázatok jelentős csökkentését meglehetősen egyszerűen, gyakorlatilag költség nélkül.

Néhány példa néhány Cisco operációs rendszerre.

Cisco IOS Configuration Hardening
Cisco IOS-XR Configuration Hardening
Cisco NX-OS Configuration Hardening
Cisco Baseline biztonsági ellenőrzőlista

Ezen dokumentumok alapján minden berendezéstípushoz összeállítható a konfigurációs követelmények listája. Például egy Cisco N7K VDC esetében ezek a követelmények így nézhetnek ki így.

Ily módon konfigurációs fájlok hozhatók létre a hálózati infrastruktúra különböző típusú aktív berendezéseihez. Ezután manuálisan vagy automatizálással „feltöltheti” ezeket a konfigurációs fájlokat. Ennek a folyamatnak az automatizálásáról egy másik, a hangszerelésről és automatizálásról szóló cikksorozatban lesz szó.

Biztonsági tervezés audit

Általában egy vállalati hálózat ilyen vagy olyan formában a következő szegmenseket tartalmazza:

• DC (közszolgáltatási DMZ és intranet adatközpont)
• Internet elérhetőség
• Távoli hozzáférésű VPN
• WAN él
• Ág
• Campus (iroda)
• Mag

A címek innen származnak Cisco SAFE modellt, de természetesen nem szükséges pontosan ezekhez a nevekhez és ehhez a modellhez kötődni. Mégis a lényegről szeretnék beszélni, és nem ragaszkodni a formalitásokhoz.

Ezen szegmensek mindegyikénél eltérőek lesznek a biztonsági követelmények, kockázatok és ennek megfelelően a megoldások.

Nézzük meg mindegyiket külön-külön, hogy milyen problémákkal találkozhat biztonsági tervezési szempontból. Természetesen még egyszer megismétlem, hogy ez a cikk semmiképpen sem állítja be a teljességet, amit ebben az igazán mély és sokrétű témában nem könnyű (ha nem lehetetlen) elérni, de az én személyes tapasztalataimat tükrözi.

Nincs tökéletes megoldás (legalábbis még nem). Ez mindig kompromisszum. De fontos, hogy az egyik vagy másik megközelítés alkalmazása melletti döntést tudatosan hozzuk meg, annak előnyeit és hátrányait egyaránt megértve.

Adatközpont

Biztonsági szempontból a legkritikusabb szegmens.
És szokás szerint itt sincs univerzális megoldás. Minden nagyban függ a hálózati követelményektől.

Kell-e tűzfal vagy nem?

Úgy tűnik, hogy a válasz nyilvánvaló, de nem minden olyan egyértelmű, mint amilyennek látszik. És a választásod nem csak ár.

Példa 1. Késések.

Ha egyes hálózati szegmensek között alapvető követelmény az alacsony késleltetés, ami például csere esetén igaz, akkor ezen szegmensek között nem tudunk tűzfalat használni. Nehéz tanulmányt találni a tűzfalak késleltetéséről, de kevés kapcsolómodell tud 1 mksec-nél kisebb késleltetést biztosítani, ezért úgy gondolom, hogy ha a mikroszekundum fontos Önnek, akkor a tűzfal nem az Ön számára.

Példa 2. Teljesítmény.

A legjobb L3 kapcsolók átviteli sebessége általában egy nagyságrenddel nagyobb, mint a legerősebb tűzfalaké. Ezért nagy intenzitású forgalom esetén nagy valószínűséggel azt is meg kell engedni, hogy ez a forgalom megkerülje a tűzfalakat.

Példa 3. Megbízhatóságát.

A tűzfalak, különösen a modern NGFW (Next-Generation FW) összetett eszközök. Sokkal összetettebbek, mint az L3/L2 kapcsolók. Számos szolgáltatást és konfigurációs lehetőséget biztosítanak, így nem meglepő, hogy megbízhatóságuk jóval alacsonyabb. Ha a szolgáltatás folytonossága kritikus fontosságú a hálózat számára, akkor előfordulhat, hogy választania kell, mi vezet a jobb rendelkezésre álláshoz - a tűzfallal biztosított biztonság vagy a kapcsolókra (vagy különféle szövetekre) épített hálózat egyszerűsége, hagyományos ACL-eket használva.

A fenti példák esetében nagy valószínűséggel (szokás szerint) kompromisszumot kell találnia. Tekintse meg a következő megoldásokat:

• Ha úgy dönt, hogy nem használ tűzfalakat az adatközponton belül, akkor át kell gondolnia, hogyan korlátozza a hozzáférést a kerület körül, amennyire csak lehetséges. Például csak a szükséges portokat nyithatja meg az internetről (kliensforgalomhoz), és adminisztrátori hozzáférést az adatközponthoz csak a jump hostokról. A jump gazdagépeken hajtson végre minden szükséges ellenőrzést (hitelesítés/engedélyezés, vírusirtó, naplózás, ...)
• használhatja az adatközponti hálózat logikai partícióját szegmensekre, hasonlóan a PSEFABRIC-ben leírt sémához példa p002. Ebben az esetben az útválasztást úgy kell beállítani, hogy a késleltetésre érzékeny vagy nagy intenzitású forgalom egy szegmensen belül menjen (p002 esetén VRF), és ne menjen át a tűzfalon. A különböző szegmensek közötti forgalom továbbra is a tűzfalon halad át. A VRF-ek közötti útvonal-szivárgást is használhatja, hogy elkerülje a forgalom tűzfalon történő átirányítását
• Tűzfalat transzparens módban is használhat, és csak azokhoz a VLAN-okhoz, ahol ezek a tényezők (latencia/teljesítmény) nem jelentősek. De gondosan tanulmányoznia kell a mod használatához kapcsolódó korlátozásokat az egyes gyártók esetében
• érdemes megfontolni egy szolgáltatási lánc architektúra használatát. Ez csak a szükséges forgalom áthaladását teszi lehetővé a tűzfalon. Elméletileg jól néz ki, de ezt a megoldást még soha nem láttam gyártásban. Körülbelül 5 éve teszteltük a Cisco ACI/Juniper SRX/F3 LTM szervizláncát, de akkor ez a megoldás „durvának” tűnt számunkra.

Védelmi szint

Most meg kell válaszolnia azt a kérdést, hogy milyen eszközöket szeretne használni a forgalom szűrésére. Íme néhány olyan szolgáltatás, amely általában megtalálható az NGFW-ben (pl. itt):

• állapotalapú tűzfal (alapértelmezett)
• alkalmazás tűzfal
• fenyegetésmegelőzés (vírusirtó, kémprogram-elhárító és sebezhetőség)
• URL-szűrés
• adatszűrés (tartalomszűrés)
• fájlblokkolás (fájltípusok blokkolása)
• dos védelmet

És nem is minden világos. Úgy tűnik, hogy minél magasabb a védelem szintje, annál jobb. De ezt is figyelembe kell venni

• Minél többet használ a fenti tűzfalfunkciók közül, természetesen annál drágább lesz (licencek, kiegészítő modulok)
• egyes algoritmusok használata jelentősen csökkentheti a tűzfal átviteli sebességét és növelheti a késéseket is, lásd például itt
• mint minden összetett megoldás, a komplex védelmi módszerek alkalmazása csökkentheti a megoldás megbízhatóságát, például alkalmazástűzfal használatakor néhány egészen szabványos működő alkalmazás (dns, smb) blokkolásával találkoztam.

Mint mindig, most is meg kell találnia a legjobb megoldást a hálózatához.

Lehetetlen határozott választ adni arra a kérdésre, hogy milyen védelmi funkciókra lehet szükség. Először is azért, mert ez természetesen attól függ, hogy milyen adatokat továbbít vagy tárol és próbál védeni. Másodszor, a valóságban a biztonsági eszközök kiválasztása gyakran az eladóba vetett hit és bizalom kérdése. Nem ismeri az algoritmusokat, nem tudja, mennyire hatékonyak, és nem tudja teljesen tesztelni őket.

Ezért a kritikus szegmensekben jó megoldás lehet a különböző cégek ajánlatainak felhasználása. Például engedélyezheti a víruskeresőt a tűzfalon, de helyileg is használhat (más gyártótól) vírusvédelmet a gazdagépeken.

Szegmentáció

Az adatközponti hálózat logikai szegmentálásáról beszélünk. Például a VLAN-okba és alhálózatokba történő particionálás is logikai szegmentálás, de nyilvánvalósága miatt nem vesszük figyelembe. Érdekes szegmentálás az olyan entitások figyelembevételével, mint az FW biztonsági zónák, VRF-ek (és analógjaik a különböző gyártókkal kapcsolatban), logikai eszközök (PA VSYS, Cisco N7K VDC, Cisco ACI bérlő, ...), ...

Ilyen logikai szegmentálásra és a jelenleg keresett adatközpont-kialakításra adunk példát a PSEFABRIC projekt p002.

Miután meghatározta a hálózat logikai részeit, leírhatja, hogyan mozog a forgalom a különböző szegmensek között, mely eszközökön és milyen eszközökkel történik a szűrés.

Ha a hálózatának nincs egyértelmű logikai partíciója, és a különböző adatfolyamokra vonatkozó biztonsági szabályzatok alkalmazásának szabályai nincsenek formalizálva, ez azt jelenti, hogy amikor megnyitja ezt vagy azt a hozzáférést, kénytelen lesz megoldani ezt a problémát, és nagy valószínűséggel minden alkalommal másképp oldja meg.

A szegmentálás gyakran csak az FW biztonsági zónákon alapul. Ezután a következő kérdésekre kell válaszolnia:

• milyen biztonsági zónákra van szüksége
• milyen szintű védelmet kíván alkalmazni ezekre a zónákra
• alapból engedélyezve lesz a zónán belüli forgalom?
• ha nem, milyen forgalomszűrési házirendeket alkalmaznak az egyes zónákon belül
• milyen forgalomszűrési házirendeket alkalmaznak az egyes zónapárokra (forrás/cél)

TCAM

Gyakori probléma az elégtelen TCAM (Ternary Content Addressable Memory), mind az útválasztáshoz, mind a hozzáférésekhez. IMHO, ez az egyik legfontosabb kérdés a felszerelés kiválasztásakor, ezért ezt a problémát megfelelő fokú odafigyeléssel kell kezelni.

1. példa: TCAM továbbítási táblázat.

Nézzük meg Palo Alto 7k tűzfal
Azt látjuk, hogy az IPv4 továbbítási tábla mérete* = 32K
Sőt, ez a számú útvonal közös az összes VSYS-re.

Tételezzük fel, hogy a terv szerint úgy dönt, hogy 4 VSYS-t használ.
Ezen VSYS-ek mindegyike BGP-n keresztül csatlakozik a felhő két MPLS PE-jéhez, amelyeket BB-ként használ. Így 4 VSYS kicseréli egymással az összes konkrét útvonalat, és van egy továbbítási táblázata hozzávetőlegesen azonos útvonalkészletekkel (de különböző NH-kkal). Mert minden VSYS-nek 2 BGP szekciója van (ugyanolyan beállításokkal), majd minden MPLS-en keresztül fogadott útvonalon 2 NH és ennek megfelelően 2 FIB bejegyzés található a Forwarding Table-ban. Ha feltételezzük, hogy ez az egyetlen tűzfal az adatközpontban, és tudnia kell az összes útvonalról, akkor ez azt jelenti, hogy az adatközpontunkban lévő útvonalak teljes száma nem lehet több, mint 32K/(4 * 2) = 4K.

Ha most feltételezzük, hogy 2 adatközpontunk van (azonos kialakítással), és adatközpontok között „kifeszített” VLAN-okat szeretnénk használni (például vMotion esetén), akkor az útválasztási probléma megoldásához host útvonalakat kell használnunk. . Ez azonban azt jelenti, hogy 2 adatközpontnál nem lesz több 4096 lehetséges hosztunknál, és ez természetesen nem biztos, hogy elég.

2. példa: ACL TCAM.

Ha a forgalom szűrését tervezi L3 switcheken (vagy más L3 switcheket használó megoldásokon, például Cisco ACI), akkor a berendezés kiválasztásakor ügyeljen a TCAM ACL-re.

Tegyük fel, hogy szabályozni szeretné a hozzáférést a Cisco Catalyst 4500 SVI interfészein. Ezután, amint az a ez a cikk, az interfészeken a kimenő (valamint a bejövő) forgalom szabályozására csak 4096 TCAM vonal használható. Ami a TCAM3 használatakor körülbelül 4000 ezer ACE-t (ACL-vonalakat) ad.

Ha az elégtelen TCAM problémájával szembesül, akkor természetesen mindenekelőtt mérlegelnie kell az optimalizálás lehetőségét. Tehát a Forwarding Table méretével kapcsolatos probléma esetén mérlegelni kell az útvonalak összesítésének lehetőségét. A hozzáférések TCAM méretével kapcsolatos probléma esetén ellenőrizze a hozzáféréseket, távolítsa el az elavult és egymást átfedő rekordokat, esetleg módosítsa a hozzáférések megnyitásának eljárását (részletesen a hozzáférések ellenőrzése című fejezetben lesz szó).

Magas rendelkezésre állás

A kérdés a következő: használjak HA-t a tűzfalakhoz, vagy telepítsek két független dobozt „párhuzamosan”, és ha az egyik meghibásodik, irányítsam át a forgalmat a másodikon?

Úgy tűnik, hogy a válasz nyilvánvaló - használja a HA-t. A kérdés továbbra is az az oka, hogy sajnos az elméleti és reklámozási 99 és a gyakorlatban több tizedes százalékos akadálymentesítés korántsem bizonyul ennyire rózsásnak. A HA logikailag elég összetett dolog, és különböző berendezéseken és különböző gyártóknál (nem volt kivétel) elkaptuk a problémákat, hibákat és szervizleállásokat.

Ha HA-t használsz, akkor lehetőséged lesz az egyes csomópontok kikapcsolására, a szolgáltatás leállítása nélkül váltani közöttük, ami fontos például a frissítéseknél, ugyanakkor messze a nullától való annak a valószínűsége, hogy mindkét csomópont egyúttal eltörik, és azt is, hogy a következőnél a frissítés nem fog olyan simán menni, mint ahogy azt a gyártó ígéri (ez a probléma elkerülhető, ha lehetőséged van laboratóriumi berendezéseken tesztelni a frissítést).

Ha nem használsz HA-t, akkor a kettős meghibásodás szempontjából sokkal kisebbek a kockázataid (mivel 2 független tűzfalad van), de mivel... A munkamenetek nincsenek szinkronizálva, akkor minden alkalommal, amikor vált a tűzfalak között, elveszíti a forgalmat. Természetesen használhat állapot nélküli tűzfalat, de akkor a tűzfal használatának értelme nagyrészt elveszett.

Ezért ha az audit eredményeként magányos tűzfalakat fedezett fel, és hálózata megbízhatóságának növelésén gondolkodik, akkor természetesen a HA az egyik javasolt megoldás, de figyelembe kell vennie az ezzel járó hátrányokat is. ezzel a megközelítéssel és talán kifejezetten az Ön hálózatához egy másik megoldás megfelelőbb lenne.

Kezelhetőség

A HA elvileg az irányíthatóságról is szól. Ahelyett, hogy 2 dobozt külön konfigurálna, és a konfigurációk szinkronban tartásának problémájával foglalkozna, sokkal inkább úgy kezelheti őket, mintha egyetlen eszköze lenne.

De talán sok adatközpontja és sok tűzfala van, akkor ez a kérdés új szinten merül fel. És a kérdés nem csak a konfigurációról szól, hanem arról is

• biztonsági mentési konfigurációk
• frissítéseket
• frissítéseket
• monitoring
• fakitermelés

Mindez pedig központi irányítási rendszerekkel megoldható.

Tehát például, ha Palo Alto tűzfalakat használ, akkor Panoráma ilyen megoldás.

Продолжение следует.

Forrás: will.com