See artikkel on kolmas artiklite sarjast „Kuidas oma võrguinfrastruktuuri kontrolli alla võtta”. Sarja kõigi artiklite sisu ja lingid leiate siin.

Turvariskide täielikust kõrvaldamisest pole mõtet rääkida. Põhimõtteliselt ei saa me neid nulli viia. Samuti peame mõistma, et püüdes muuta võrk järjest turvalisemaks, muutuvad meie lahendused aina kallimaks. Peate leidma teie võrgu jaoks mõistliku kompromissi kulude, keerukuse ja turvalisuse vahel.

Loomulikult on turvadisain orgaaniliselt integreeritud üldisesse arhitektuuri ning kasutatavad turbelahendused mõjutavad võrgutaristu skaleeritavust, töökindlust, hallatavust, ..., millega tuleb samuti arvestada.

Kuid lubage mul teile meelde tuletada, et praegu me ei räägi võrgu loomisest. Vastavalt meie esialgsed tingimused oleme juba valinud disaini, valinud seadmed ja loonud infrastruktuuri ning praeguses etapis peaksime võimalusel “elama” ja leidma lahendusi eelnevalt valitud lähenemise kontekstis.

Meie ülesanne on nüüd tuvastada võrgu tasandil turvalisusega seotud riskid ja viia need mõistliku tasemeni.

Võrgu turvaaudit

Kui teie organisatsioon on rakendanud ISO 27k protsesse, peaksid turbeauditid ja võrgumuudatused selle lähenemisviisi raames sujuvalt sobituma üldiste protsessidega. Kuid need standardid ei puuduta ikkagi konkreetseid lahendusi, ei konfiguratsiooni ega disaini... Puuduvad selged nõuanded, standardid, mis määraksid üksikasjalikult, milline teie võrk peaks olema, see on selle ülesande keerukus ja ilu.

Tooksin esile mitu võimalikku võrgu turvaauditit:

• seadmete konfiguratsiooni audit (kõvenemine)
• turvadisaini audit
• juurdepääsu audit
• protsessi audit

Riistvara konfiguratsiooni audit (kõvenemine)

Tundub, et enamikul juhtudel on see parim lähtepunkt teie võrgu auditeerimiseks ja turvalisuse parandamiseks. IMHO, see on hea näide Pareto seadusest (20% pingutusest annab 80% tulemusest ja ülejäänud 80% pingutusest ainult 20% tulemusest).

Põhimõte on see, et tavaliselt on meil seadmete konfigureerimisel müüjatelt soovitusi turvalisuse parimate tavade kohta. Seda nimetatakse "kõvenemiseks".

Samuti võite sageli leida nende soovituste põhjal küsimustiku (või koostada selle ise), mis aitab teil kindlaks teha, kui hästi teie seadmete konfiguratsioon nendele "parimatele tavadele" vastab, ja vastavalt tulemusele oma võrgus muudatusi teha. . See võimaldab teil turvariske üsna lihtsalt ja praktiliselt tasuta vähendada.

Mõned näited mõne Cisco operatsioonisüsteemi kohta.

Cisco IOS-i konfiguratsiooni kõvenemine
Cisco IOS-XR konfiguratsiooni kõvenemine
Cisco NX-OS konfiguratsiooni kõvenemine
Cisco Baseline turvalisuse kontrollnimekiri

Nende dokumentide põhjal saab koostada iga seadmetüübi konfiguratsiooninõuete loendi. Näiteks Cisco N7K VDC jaoks võivad need nõuded välja näha nii.

Sel viisil saab luua konfiguratsioonifaile teie võrgu infrastruktuuri erinevat tüüpi aktiivsete seadmete jaoks. Järgmisena saate need konfiguratsioonifailid käsitsi või automaatika abil üles laadida. Kuidas seda protsessi automatiseerida, arutatakse üksikasjalikult teises orkestreerimist ja automatiseerimist käsitlevates artiklites.

Turvadisaini audit

Tavaliselt sisaldab ettevõttevõrk ühel või teisel kujul järgmisi segmente:

• DC (avalike teenuste DMZ ja sisevõrgu andmekeskus)
• internetiühendus
• Kaugjuurdepääsu VPN
• WAN serv
• Filiaal
• Ülikoolilinnak (kontor)
• tuum

Pealkirjad võetud alates Cisco SAFE mudel, kuid loomulikult ei pea seda täpselt nende nimede ja selle mudeli külge kinnitama. Siiski tahan ma rääkida olemusest ja mitte takerduda formaalsustesse.

Iga nimetatud segmendi puhul on turvanõuded, riskid ja vastavalt ka lahendused erinevad.

Vaatleme neid igaüht eraldi, et leida probleeme, millega võite turbekujunduse seisukohast kokku puutuda. Muidugi kordan veel kord, et see artikkel ei pretendeeri mingil juhul täielikkusele, mida selle tõeliselt sügava ja mitmetahulise teema puhul pole lihtne (kui mitte võimatu) saavutada, kuid see peegeldab minu isiklikku kogemust.

Ideaalset lahendust pole (vähemalt veel mitte). See on alati kompromiss. Kuid on oluline, et otsus ühe või teise lähenemise kasuks langetaks teadlikult, mõistes nii selle plusse kui ka miinuseid.

Andmekeskus

Ohutuse seisukohalt kõige kriitilisem segment.
Ja nagu tavaliselt, pole ka siin universaalset lahendust. Kõik sõltub suuresti võrgunõuetest.

Kas teil on tulemüüri vaja või mitte?

Tundub, et vastus on ilmne, kuid kõik pole nii selge, kui võib tunduda. Ja teie valikut saab mõjutada mitte ainult hind.

Näide 1. Viivitused.

Kui mõne võrgusegmendi vahel on oluline nõue madal latentsusaeg, mis näiteks vahetuse puhul kehtib, siis me nende segmentide vahel tulemüüre kasutada ei saa. Tulemüüride latentsusaja uuringuid on raske leida, kuid vähesed lülitimudelid suudavad pakkuda latentsusaega, mis on väiksem või suurusjärgus 1 mksek, seega arvan, et kui mikrosekundid on teie jaoks olulised, siis tulemüürid pole teie jaoks.

Näide 2. Etendus.

Tipptasemel L3 lülitite läbilaskevõime on tavaliselt suurusjärgu võrra suurem kui võimsaimate tulemüüride läbilaskevõime. Seetõttu peate suure intensiivsusega liikluse korral suure tõenäosusega lubama ka sellel liiklusel tulemüüridest mööda minna.

Näide 3. Usaldusväärsus

Tulemüürid, eriti kaasaegne NGFW (Next-Generation FW) on keerulised seadmed. Need on palju keerulisemad kui L3/L2 lülitid. Need pakuvad suurt hulka teenuseid ja konfiguratsioonivõimalusi, mistõttu pole üllatav, et nende töökindlus on palju madalam. Kui teenuse järjepidevus on võrgu jaoks kriitilise tähtsusega, peate võib-olla valima, mis tagab parema kättesaadavuse - tulemüüri turvalisus või tavaliste ACL-ide abil lülititele (või mitmesugustele kangastele) ehitatud võrgu lihtsus.

Ülaltoodud näidete puhul peate suure tõenäosusega (nagu tavaliselt) leidma kompromissi. Vaadake järgmisi lahendusi:

• kui otsustate andmekeskuse sees tulemüüre mitte kasutada, siis peate mõtlema, kuidas piirata juurdepääsu perimeetrile nii palju kui võimalik. Näiteks saate Internetist avada ainult vajalikud pordid (kliendiliikluse jaoks) ja administratiivse juurdepääsu andmekeskusele ainult hüppehostidest. Tehke hüppehostidel kõik vajalikud kontrollid (autentimine/volitamine, viirusetõrje, logimine jne)
• saate kasutada andmekeskuse võrgu loogilist sektsiooni segmentideks, sarnaselt PSEFABRICis kirjeldatud skeemile näide p002. Sel juhul tuleb marsruutimine konfigureerida nii, et viivitustundlik või suure intensiivsusega liiklus läheks ühe segmendi sees (p002 puhul VRF) ja ei läbiks tulemüüri. Liiklus eri segmentide vahel jätkub tulemüüri kaudu. Liikluse tulemüüri kaudu ümbersuunamise vältimiseks saate kasutada ka marsruudi leket VRF-ide vahel
• Tulemüüri saab kasutada ka läbipaistvas režiimis ja ainult nende VLAN-ide puhul, kus need tegurid (latentsus/jõudlus) ei ole olulised. Kuid peate hoolikalt uurima selle modi kasutamisega seotud piiranguid iga müüja jaoks
• võiksite kaaluda teenindusahela arhitektuuri kasutamist. See võimaldab tulemüürist läbida ainult vajalikku liiklust. Teoorias näeb kena välja, aga ma pole seda lahendust tootmises näinud. Testisime Cisco ACI/Juniper SRX/F5 LTM teenindusahelat umbes 3 aastat tagasi, kuid tol ajal tundus see lahendus meile “toores”.

Kaitsetase

Nüüd peate vastama küsimusele, milliseid tööriistu soovite liikluse filtreerimiseks kasutada. Siin on mõned funktsioonid, mis NGFW-s tavaliselt olemas on (näiteks siin):

• olekupõhine tulemüür (vaikimisi)
• rakenduste tulemüür
• ohtude ennetamine (viirusetõrje, nuhkvaratõrje ja haavatavus)
• URL-i filtreerimine
• andmete filtreerimine (sisu filtreerimine)
• failide blokeerimine (failitüüpide blokeerimine)
• dos kaitset

Ja ega kõik pole selge. Näib, et mida kõrgem on kaitsetase, seda parem. Kuid peate ka sellega arvestama

• Mida rohkem ülaltoodud tulemüüri funktsioone kasutate, seda kallim see loomulikult on (litsentsid, lisamoodulid)
• mõne algoritmi kasutamine võib oluliselt vähendada tulemüüri läbilaskevõimet ja suurendada ka viivitusi, vt näiteks siin
• nagu iga keeruline lahendus, võib ka keeruliste kaitsemeetodite kasutamine vähendada teie lahenduse töökindlust, näiteks rakenduste tulemüüri kasutamisel puutusin kokku mõne üsna standardselt töötava rakenduse (dns, smb) blokeerimisega

Nagu alati, peate leidma oma võrgu jaoks parima lahenduse.

Küsimusele, milliseid kaitsefunktsioone võib vaja minna, on võimatu lõplikult vastata. Esiteks seepärast, et see sõltub loomulikult andmetest, mida te edastate või salvestate ja üritate kaitsta. Teiseks on tegelikkuses sageli turvavahendite valik usu ja müüja vastu usalduse küsimus. Te ei tea algoritme, te ei tea, kui tõhusad need on ja te ei saa neid täielikult testida.

Seetõttu võib kriitilistes segmentides olla heaks lahenduseks erinevate ettevõtete pakkumiste kasutamine. Näiteks saate lubada tulemüüris viirusetõrje, aga kasutada ka hostides lokaalselt viirusetõrjet (teisest tootjast).

Segmenteerimine

Räägime andmekeskuste võrgu loogilisest segmenteerimisest. Näiteks VLAN-ideks ja alamvõrkudeks jaotamine on samuti loogiline segmenteerimine, kuid me ei võta seda selle ilmselguse tõttu arvesse. Huvitav segmenteerimine, võttes arvesse selliseid üksusi nagu FW turvatsoonid, VRF-id (ja nende analoogid seoses erinevate tarnijatega), loogilised seadmed (PA VSYS, Cisco N7K VDC, Cisco ACI Renant, ...), ...

Sellise loogilise segmenteerimise ja praegu nõutava andmekeskuse kujunduse näide on toodud PSEFABRIC projekti p002.

Olles määratlenud oma võrgu loogilised osad, saate kirjeldada, kuidas liiklus eri segmentide vahel liigub, millistel seadmetel ja milliste vahenditega filtreerimine toimub.

Kui teie võrgul pole selget loogilist partitsiooni ja erinevate andmevoogude turvapoliitikate rakendamise reeglid pole vormistatud, tähendab see, et selle või teise juurdepääsu avamisel olete sunnitud selle probleemi lahendama ja suure tõenäosusega lahendab selle iga kord erinevalt.

Sageli põhineb segmenteerimine ainult FW turvatsoonidel. Seejärel peate vastama järgmistele küsimustele:

• milliseid turvatsoone vajate
• millist kaitsetaset soovite igale nimetatud tsoonile rakendada
• kas tsoonisisene liiklus on vaikimisi lubatud?
• kui ei, siis milliseid liikluse filtreerimise eeskirju igas tsoonis rakendatakse
• milliseid liikluse filtreerimise reegleid rakendatakse iga tsoonipaari jaoks (allikas/sihtkoht)

TCAM

Levinud probleem on ebapiisav TCAM (Ternary Content Addressable Memory) nii marsruutimiseks kui ka juurdepääsuks. IMHO, see on seadmete valimisel üks olulisemaid küsimusi, seega peate sellesse probleemi suhtuma asjakohase hoolega.

Näide 1. Edastustabel TCAM.

Vaatame Palo Alto 7k tulemüür
Näeme, et IPv4 edastamistabeli suurus* = 32K
Lisaks on see marsruutide arv ühine kõigi VSYS-ide jaoks.

Oletame, et vastavalt oma disainile otsustate kasutada 4 VSYS-i.
Kõik need VSYS-id on BGP kaudu ühendatud pilve kahe MPLS PE-ga, mida kasutate BB-na. Seega vahetavad 4 VSYS-i omavahel kõiki konkreetseid marsruute ja neil on edastamistabel ligikaudu samade marsruutide komplektidega (kuid erinevad NH-d). Sest igal VSYS-il on 2 BGP seanssi (samade seadistustega), siis on igal MPLS-i kaudu vastuvõetud marsruudil 2 NH ja vastavalt 2 FIB kirjet edastamistabelis. Kui eeldame, et see on andmekeskuse ainus tulemüür ja see peab teadma kõiki marsruute, siis see tähendab, et meie andmekeskuse marsruutide koguarv ei tohi olla suurem kui 32K/(4 * 2) = 4K.

Kui nüüd eeldame, et meil on 2 andmekeskust (sama kujundusega) ja tahame kasutada andmekeskuste vahel “venitatud” VLAN-e (näiteks vMotioni jaoks), siis marsruutimisprobleemi lahendamiseks peame kasutama hosti marsruute. . Kuid see tähendab, et kahe andmekeskuse jaoks pole meil rohkem kui 2 võimalikku hosti ja loomulikult ei pruugi sellest piisata.

Näide 2. ACL TCAM.

Kui plaanite liiklust filtreerida L3 kommutaatoritel (või muudel L3 lüliteid kasutavatel lahendustel, nt Cisco ACI), siis peaksite seadmeid valides pöörama tähelepanu TCAM ACL-ile.

Oletame, et soovite juhtida juurdepääsu Cisco Catalyst 4500 SVI liidestele. Seejärel, nagu on näha selle artikli, liideste väljuva (ja ka sissetuleva) liikluse juhtimiseks saate kasutada ainult 4096 TCAM-liini. Mis TCAM3 kasutamisel annab teile umbes 4000 tuhat ACE-d (ACL read).

Kui seisate silmitsi ebapiisava TCAM-i probleemiga, peate kõigepealt loomulikult kaaluma optimeerimise võimalust. Seega, kui on probleeme edastamistabeli suurusega, peate arvestama marsruutide liitmise võimalusega. Juurdepääsude TCAM-i suuruse probleemi korral kontrollige juurdepääsu, eemaldage aegunud ja kattuvad kirjed ning võimaluse korral vaadake üle juurdepääsude avamise protseduur (sellest tuleb täpsemalt juttu juurdepääsude auditeerimise peatükis).

Kõrge käideldavus

Küsimus on järgmine: kas ma peaksin kasutama tulemüüride jaoks HA-d või paigaldama kaks sõltumatut kasti "paralleelselt" ja kui üks neist ebaõnnestub, suunata liiklus läbi teise?

Tundub, et vastus on ilmne - kasutage HA-d. Põhjus, miks see küsimus ikka üles kerkib, on see, et paraku ei osutu teoreetiline ja reklaam 99 ning mitmed kümnendkohad ligipääsetavuse praktikas kaugeltki nii roosiliseks. HA on loogiliselt üsna keeruline asi ning erinevatel seadmetel ja erinevate müüjatega (erandeid polnud) tabasime probleeme ja vigu ning teenindusseiskusid.

Kui kasutate HA-d, on teil võimalus üksikud sõlmed välja lülitada, nende vahel teenust peatamata vahetada, mis on oluline näiteks versiooniuuenduste tegemisel, kuid samal ajal on teil nullist kaugel tõenäosus, et mõlemad sõlmed läheb samal ajal katki ja ka seda, et järgmine uuendus ei lähe nii libedalt kui müüja lubab (seda probleemi saab vältida, kui on võimalus uuendust katsetada laboriseadmete peal).

Kui sa HA-d ei kasuta, siis topelttõrke seisukohalt on sinu riskid palju väiksemad (kuna sul on 2 sõltumatut tulemüüri), aga kuna... seansse ei sünkroonita, siis iga kord, kui nende tulemüüride vahel vahetate, kaotate liikluse. Muidugi saab kasutada olekuta tulemüüri, kuid siis läheb tulemüüri kasutamise mõte suures osas kaotsi.

Seega, kui olete auditi tulemusena avastanud üksikud tulemüürid ja mõtlete oma võrgu töökindluse suurendamisele, siis on HA loomulikult üks soovitatud lahendusi, kuid arvestada tuleks ka sellega kaasnevate puudustega. selle lähenemisviisi ja võib-olla just teie võrgu jaoks sobiks mõni muu lahendus sobivam.

Juhitavus

Põhimõtteliselt tähendab HA ka juhitavust. Selle asemel, et konfigureerida 2 kasti eraldi ja lahendada konfiguratsioonide sünkroonis hoidmise probleem, saate neid hallata nii, nagu oleks teil üks seade.

Kuid võib-olla on teil palju andmekeskusi ja palju tulemüüre, siis tekib see küsimus uuel tasemel. Ja küsimus pole ainult konfiguratsioonis, vaid ka selles

• varukonfiguratsioonid
• uuendused
• uuendused
• jälgimine
• metsaraie

Ja seda kõike saab lahendada tsentraliseeritud juhtimissüsteemidega.

Näiteks kui kasutate Palo Alto tulemüüre, siis panoraam on selline lahendus.

Et jätkata.

Allikas: www.habr.com