Ez a cikk a „Hogyan vegyük kezünkbe a hálózati infrastruktúrát” című ciklus harmadik része. A ciklus összes cikkének tartalmát és linkjeit itt találhatja. itt.

Nincs értelme a biztonsági kockázatok teljes megszüntetéséről beszélni. Elvileg nem tudjuk ezeket nullára csökkenteni. Azt is fontos megérteni, hogy ahogy a hálózat biztonságosabbá válik, úgy a megoldásaink egyre drágábbá válnak. Meg kell találni a költség, bonyolultság és biztonság között egy ésszerű kompromisszumot a hálózat számára.

Természetesen a biztonsági dizájn szervesen beépül az általános architektúrába, és a használt biztonsági megoldások befolyásolják a hálózati infrastruktúra skálázhatóságát, megbízhatóságát és kezelhetőségét, melyeket szintén figyelembe kell venni.

De emlékeztetnék, hogy most nem a hálózat létrehozásáról beszélünk. Az általunk megadott kezdeti feltételek szerint már rendelkezünk tervezéssel, kiválasztott eszközökkel és kialakított infrastruktúrával, és ezen a ponton a lehetőségekhez képest "élnünk" kell és megoldásokat kell találnunk a korábban választott megközelítés keretein belül. A feladatunk most az, hogy azonosítsuk a hálózati biztonsággal kapcsolatos kockázatokat és csökkentsük azokat egy ésszerű szintre.

Hálózati biztonsági audit

Ha az Ön szervezetében bevezetésre kerültek az ISO 27k folyamatok, akkor a biztonsági auditot és a hálózat változásait organikusan be kell építeni a keretekbe. De ezek a szabványok nem konkrét megoldásokról, nem konfigurációkról, és nem dizájnról szólnak... Nincsenek egyértelmű tanácsok, nincsenek standardok, amelyek részletesen meghatározzák, hogy milyen legyen a hálózata; ez a feladat bonyolultsága és szépsége.

Kiemelnék néhány lehetséges hálózati biztonsági audit típust:

hardening audit

biztonsági dizájn audit
hozzáférés audit
folyamat audit
Úgy tűnik, hogy a legtöbb esetben ez a legjobb kiindulópont a hálózata biztonságának auditálásához és javításához. Véleményem szerint ez jó bemutatója a Pareto törvénynek (20% erőfeszítés 80% eredményt, míg a maradék 80% erőfeszítés csupán 20% eredményt hoz).

Eszközkonfiguráció audit (hardening)

A lényeg az, hogy általában van ajánlásunk a gyártóktól a biztonsági "legjobb gyakorlatok" tekintetében az eszközök konfigurálásakor. Ezt hívják „hardening”-nek.

Ez megjelölést jelent a gyártók által biztosított biztonsági legjobb gyakorlatokra vonatkozóan az eszközök konfigurálása során.

Gyakran előfordul, hogy egy kérdőívet találunk (vagy készíthetünk magunk is) a fenti ajánlások alapján, amely segít meghatározni, hogy a berendezésünk konfigurációja mennyire felel meg ezeknek a „legjobb gyakorlatoknak”, és a kapott eredmény alapján módosításokat végezhetünk a hálózatunkban. Ez lehetővé teszi, hogy meglehetősen könnyen, igazából költségek nélkül jelentősen csökkentsük a biztonsági kockázatokat.

Néhány példa bizonyos Cisco operációs rendszerekhez.
Cisco IOS Konfiguráció Megerősítése
Cisco IOS-XR Konfiguráció Megerősítése
Cisco NX-OS Konfiguráció Megerősítése
Cisco Alapvető Biztonsági Ellenőrző Lista
Ezekből a dokumentumokból elkészíthető egy követelménylista a konfigurációra vonatkozóan minden berendezéstípus számára. Például a Cisco N7K VDC esetében ezek a követelmények így nézhetnek ki így.

Így kialakíthatók konfigurációs fájlok a hálózati infrastruktúra különböző aktív eszközei számára. Ezt követően manuálisan vagy automatizálás révén „feltöltheti” ezeket a konfigurációs fájlokat. A folyamat automatizálásának módját egy másik cikk sorozat részletezi, amely az automatizálásról és az orkestrációról szól.

Biztonsági tervezési audit

A vállalati hálózatban általában a következő szegmensek valamelyik formájában jelen vannak:

DC (Közszolgáltatások DMZ és intranet adatközpont)
Internet hozzáférés
Távhozzáférési VPN
WAN perem
Fiók
Campus (Iroda)
Mag

A nevek a következőkből származnak Cisco SAFE modellből, de természetesen nem szükséges, hogy ezekhez a nevekhez és modellhez ragaszkodjunk. Végül is a lényegre szeretnénk fókuszálni, nem pedig a formalitásokba ragadni.

Ezekhez a szegmensekhez a biztonsági szint, a kockázatok és ennek megfelelően a megoldások eltérőek lesznek.

Vizsgáljuk meg mindegyiket külön-külön a biztonsági tervezés szempontjából felmerülő problémák tekintetében. Természetesen, ismétlem, hogy ez a cikk nem törekszik a teljességre, ennek elérése ebben a rendkívül mély és sokoldalú témában nem egyszerű (ha egyáltalán lehetséges), de a személyes tapasztalatomat tükrözi.

Nincs tökéletes megoldás (legalábbis jelenleg). Ez mindig kompromisszum. De fontos, hogy a megoldás alkalmazása tudatos döntés keretein belül történjen, amelyben figyelembe veszik az előnyöket és hátrányokat egyaránt.

Data Center

A legkritikusabb szegmens a biztonság szempontjából.
És, mint mindig, itt sincs univerzális megoldás. Minden nagymértékben függ a hálózati követelményektől.

Szükség van-e tűzfalra?

Első ránézésre a válasz nyilvánvalónak tűnik, de a helyzet nem olyan egyértelmű, mint amilyennek látszik. A választásodra nemcsak ár.

Példa 1. Késések.
Ha a hálózat egyes szegmensei között az alacsony késleltetés lényeges követelmény, ami például igaz a tőzsdére, akkor ezek között a szegmensek között nem használhatunk tűzfalakat. Nehéz kutatásokat találni a tűzfalak késleltetéséről, de csak néhány switch-modell képes 1 mksec alatti késleltetést biztosítani, ezért azt gondolom, hogy ha az Ön számára fontosak a mikrosecondumok, akkor a tűzfalak nem Önnek valók.

Példa 2. Teljesítmény.
A csúcs L3 switch-ek sávszélessége általában nagyságrenddel magasabb, mint a legjobban teljesítő tűzfalaké. Ezért magas intenzitású forgalom esetén valószínűleg ezt a forgalmat is a tűzfalak megkerülésével kell irányítania.

Példa 3. Megbízhatóság.
A tűzfalak, különösen a modern NGFW-k (Next-Generation FW) – bonyolult készülékek. Sokkal bonyolultabbak, mint az L3/L2 switch-ek. Számos szolgáltatást és konfigurálási lehetőséget kínálnak, így nem meglepő, hogy a megbízhatóságuk jelentősen alacsonyabb. Ha a szolgáltatás folyamatossága kritikus a hálózat számára, akkor lehet, hogy mérlegelnie kell, hogy mi biztosítja a jobb elérhetőséget – a tűzfal segítségével történő védelem vagy az egyszerűség, amely switch-eken (vagy különféle típusú gyártókon) alapul, a szokásos ACL-ek használatával.

A fenti példák esetében valószínűleg (mint általában) kompromisszumot kell kötnie. Nézze meg a következő megoldásokat:

ha úgy döntött, hogy nem használ tűzfalakat az adatközponton belül, akkor ki kell gondolnia, hogyan korlátozhatja a hozzáféréseket a peremén. Például, csak a szükséges portokat nyithatja meg az Internetről (az ügyfélforgalom számára), és az adatközpontba történő adminisztrációs hozzáféréseket csak ugró hosztokból adhatja meg. Az ugró hosztoknál végezze el az összes szükséges ellenőrzést (hitelesítés/autorizáció, víruskeresés, naplózás, …)
használhat logikai hálózati szegmentációt az adatközpontban, hasonlóan a PSEFABRIC-ben leírt sémához példa p002A router should be configured in such a way that latency-sensitive or high-intensity traffic travels "inside" one segment (in the case of p002, the VRF) and does not pass through the firewall. However, traffic between different segments will still go through the firewall. Route leaking between VRFs can also be used to avoid redirecting traffic through the firewall.
A firewall can also be used in transparent mode and only for those VLANs where these factors (latency/performance) are not significant. However, it is important to carefully study the limitations related to using this mode for each vendor.
You might consider applying service chain architecture. This will allow only necessary traffic to be routed through the firewall. Theoretically, it looks great, 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, this solution seemed "raw" to us.

Védelmi szint

Now, you need to answer the question of which tools you want to use for traffic filtering. Here are some possibilities that are usually present in NGFW (for example, itt):

stateful firewalling (by default)
application firewalling
threat prevention (antivirus, anti-spyware, and vulnerability)
URL filtering
data filtering (content filtering)
file blocking (file types blocking)
dos protection

And it's not all so straightforward. It might seem that the higher the level of protection, the better. But you also need to consider that

the more of the aforementioned firewall features you use, the more expensive it will naturally be (licenses, additional modules).
Using some algorithms can significantly reduce the throughput of the firewall, as well as increase latencies; see, for example, itt
like any complex solution, using complex protection methods can decrease the reliability of your solution; for instance, when using application firewalling, I encountered blocks on some completely standard applications (DNS, SMB).

As usual, you need to find the optimal solution for your network.

Nem lehet egyértelműen megválaszolni, hogy milyen védelmi funkciókra lehet szükség. Először is, ez természetesen attól függ, hogy milyen adatokat továbbít vagy tárol, és mit próbál megvédeni. Másodsorban, valójában a védelmi eszközök kiválasztása sokszor a beszállítóban való hitet és bizalmat tükröz. Ön nem ismeri az algoritmusokat, nem tudja, mennyire hatékonyak, és nem tudja őket teljes mértékben tesztelni.

Ezért kritikus szegmensekben jó megoldás lehet különböző cégek ajánlatait használni. Például antivírus programot aktiválhat a tűzfalon, de a helyi hosztokon egy másik gyártó antivírus védelmét is alkalmazhatja.

Szegmentálás

A középpontban a adatközpont hálózatának logikai szegmentálása áll. Például a VLAN-ok és alhálózatok kialakítása is logikai szegmentáció, de ezt most nem vizsgáljuk a nyilvánvalósága miatt. Azt a szegmentációt tartjuk érdekesnek, amely figyelembe veszi az olyan entitásokat, mint a tűzfal biztonsági zónák, VRF (és ezek megfelelői különböző beszállítók esetében), logikai eszközök (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, …), …

Például egy ilyen logikai szegmentáció és a jelenleg népszerű adatközponti tervezési példa található a P002 PSEFABRIC projektben.

Miután meghatározta a hálózata logikai részeit, tovább leírhatja, hogyan halad a forgalom a különböző szegmensek között, milyen eszközökön fogják végezni a szűrést, és milyen eszközöket fognak alkalmazni.

Ha a hálózatában nincs világos logikai felosztás, és a különböző adatfolyamokra (flow) vonatkozó biztonsági politikák alkalmazására vonatkozó szabályok nincsenek formalizálva, akkor ez azt jelenti, hogy amikor egy adott hozzáférést biztosít, mindig ezt a feladatot fogja megoldani, és nagy valószínűséggel minden alkalommal másképp fogja megoldani.

Gyakran a szegmentálás csak a tűzfal biztonsági zónáira alapozódik. Ekkor a következő kérdésekre kell válaszolnia:

milyen biztonsági zónákra van szüksége
milyen védelmi szintet szeretne alkalmazni ezekre a zónákra
engedélyezve lesz-e alapértelmezett intra-zóna forgalom
ha nem, akkor milyen forgalomszűrési politikákat fognak alkalmazni az egyes zónákon belül
milyen forgalomszűrési politikákat fognak alkalmazni a zónák (forrás/cél) párjaira

TCAM

Gyakori probléma a TCAM (Ternary Content Addressable Memory) hiánya, mind a routolás, mind a hozzáférések esetében. Véleményem szerint ez az egyik legfontosabb kérdés a hardver kiválasztásakor, ezért ezt a kérdést megfelelő figyelemmel kell kezelni.

1. Példa. Forwarding Table TCAM.
Nézzük meg Palo Alto 7k tűzfal.
Látjuk, hogy az IPv4 forwarding table size* = 32K
Ez a szám a route-ok összes VSYS-re vonatkozóan összesített.
Tegyük fel, hogy az Ön dizájnja alapján 4 VSYS-t fog használni.
Mindegyik VSYS BGP-n keresztül csatlakozik a használt PE MPLS felhőhöz, amelyet BB-ként használ. Így a 4 VSYS összesen megosztja egymással az összes specifikus route-ot, és körülbelül azonos route-készletekkel rendelkezik (de különböző NH-kel). Mivel minden VSYS-nek 2 BGP session-je van (ugyanazzal a beállítással), ezért minden MPLS-en keresztül kapott route-nak 2 NH-ja és ennek megfelelően 2 FIB bejegyzése van a Forwarding Table-ben. Ha feltételezzük, hogy ez az egyetlen tűzfal a dátacentrum területén, és ismernie kell az összes route-ot, akkor ez azt jelenti, hogy a dátacentrumunkban lévő összes route száma nem lehet több mint 32K/(4 * 2) = 4K.
Most, ha feltételezzük, hogy 2 dátacentrumunk van (ugyanazzal a dizájnnal), és VLAN-okat akarunk használni, „kiterjesztve” a dátacentrumok között (például vMotion-hoz), akkor a routolási probléma megoldásához host route-okat kell használnunk. Ez azonban azt jelenti, hogy a 2 dátacentrumra összesen nem lehet több mint 4096 lehetséges hostunk, és ez valószínűleg nem lesz elegendő.

2. Példa. ACL TCAM.
Ha forgalmat kíván szűrni L3 switch-eken (vagy más L3 switch-et használó megoldásokon, például Cisco ACI), akkor a hardver választásakor figyelmet kell fordítania az ACL TCAM-re.
Tegyük fel, hogy a Cisco Catalyst 4500 SVI interfészein kívánja ellenőrizni a hozzáféréseket. Akkor, ahogy azt a ezen cikket, a kimenő (és belépő) forgalom ellenőrzéséhez az interfészeken csupán 4096 TCAM sort használhat. Ez TCAM3 használatával körülbelül 4000 ACE-t (ACL sort) eredményez.

Ha problémát tapasztal a TCAM hiánya miatt, akkor először természetesen a lehetőségek optimalizálását kell megvizsgálnia. Például, ha a Forwarding Table méretével van problémája, érdemes fontolóra venni az útvonalak aggregálását. Ha a hozzáférések TCAM méretével van probléma - auditálja a hozzáféréseket, távolítsa el az elavult és átfedő bejegyzéseket, illetve esetleg vizsgálja felül a hozzáférések megnyitásának eljárását (erről részletesebben a hozzáférés-ellenőrzésről szóló fejezetben lesz szó).

Magas rendelkezésre állás

A kérdés az, hogy használjunk-e HA-t a tűzfalakhoz, vagy állítsunk be „párhuzamosan” két független eszközt, és ha az egyik meghibásodik, akkor irányítsuk a forgalmat a másikon keresztül?

Úgy tűnhet, hogy a válasz nyilvánvaló – használjunk HA-t. Ennek a kérdésnek a felmerülése az a sajnálatos tény, hogy a reklámozott elméleti 99 és néhány tizedesjegy után a gyakorlatban messze nem mindig ilyen rózsás a helyzet. A HA logikailag meglehetősen bonyolult dolog, és különböző berendezéseken és más szállítókkal is (kivétel nélkül) találkoztunk problémákkal, hibákkal és szolgáltatáskimaradással.

A HA használata esetén lehetősége lesz egyes node-ok leállítására, és közöttük való váltásra a szolgáltatás leállítása nélkül, ami fontos, például frissítések során, de ezzel együtt nem elhanyagolható az a valószínűség sem, hogy mindkét node egyszerre hibásodik meg, és hogy egy újabb frissítés nem fog olyan zökkenőmentesen zajlani, ahogy azt a szállító ígéri (ezt a problémát elkerülheti, ha lehetősége van a frissítést labor berendezéseken tesztelni).

Ha nem használ HA-t, akkor a dupla hiba szempontjából a kockázatai jelentősen alacsonyabbak (mivel 2 független tűzfala van), de mivel a session-ök nincsenek szinkronizálva, ezért minden alkalommal, amikor váltás történik ezen tűzfalak között, forgalmat fog veszteséget szenvedni. Használhat stateless firewall-t is, de ekkor a tűzfal használatának értelme sok szempontból elveszik.

Ezért, ha az audit során egyedül álló tűzfalakat talál, és a hálózata megbízhatóságának növelésén gondolkodik, a HA természetesen az ajánlott megoldások egyike, de azt is figyelembe kell vennie, hogy ezzel a megközelítéssel kapcsolatos hátrányok is vannak, és esetleg az Ön hálózatának más megoldása lenne a megfelelőbb.

Kezelhetőség

A HA lényegében a kezelhetőségről is szól. Ahelyett, hogy külön-külön konfigurálná a két dobozt és megoldaná a konfigurációk szinkronizálásának problémáját, nagyrészt úgy kezeli őket, mintha egyetlen eszköze lenne.

De lehet, hogy sok adatközpontja és sok tűzfala van, akkor ez a kérdés egy új szintre lép. A kérdés nemcsak a konfigurálásra vonatkozik, hanem szintén