See artikkel on kolmas osa artiklite tsüklist «Kuidas võta võrguinfrastruktuur oma kontrolli alla». Tsükli kõigi artiklite sisu ja lingid leiate siit. siit.

Pole mõtet rääkida täielikust security riskide kõrvaldamisest. Me ei saa neid põhimõtteliselt nulli viia. Samuti tuleb mõista, et püüdes muuta võrku üha turvalisemaks, muutuvad meie lahendused üha kallimaks. Oluline on leida mõistlik kompromiss teie võrgu, hinna, keerukuse ja turvalisuse vahel.

Loomulikult on turvadesain orgaaniliselt integreeritud üldstruktuuri, ja kasutusel olevad security lahendused mõjutavad võrguinfrastruktuuri mõõdetavust, usaldusväärsust, hallatavust jne, seda tuleb samuti arvesse võtta.

Kuid tuletan meelde, et praegu me ei räägi võrgu loomisest. Vastavalt meie algtingimustele on meil juba valitud disain, valitud varustus ja loodud infrastruktuur, ja sel hetkel peame võimalusel selle valitud lähenemise raames «elama» ning leidma lahendusi.

Meie ülesanne on praegu tuvastada võrgu tasandi kaitsega seotud riskid ning vähendada need mõistlikule tasemele.

Võrguturbe audit

Kui teie organisatsioonis on rakendatud ISO 27k protsessid, siis peaks turbe ja võrgu muudatuste audit loomulikult sulanduma selle lähenemise üldprotsessidesse. Kuid need standardid ei käsitle siiski konkreetseid lahendusi, konfiguratsiooni ega disaini... Üheselt mõistetavaid nõuandeid ei ole, ei ole standardeid, mis dikteeriksid teie võrgu täpselt, selles peitubki selle ülesande keerukus ja ilu.

Tõstaksin esile mitu võimaliku võrgu turbe auditi tüüpi:

seadme konfiguratsiooni audit (hardening)
turbe disaini audit
juurdepääsude audit
protsesside audit

Seadme konfiguratsiooni audit (hardeening)

Tundub, et enamikul juhtudel on see parim alguspunkt teie võrgu auditeerimiseks ja turvalisuse parandamiseks. Minu arvates on see hea näide Pareto seadusest (20% pingutustest toovad 80% tulemustest ja ülejäänud 80% pingutustest vaid 20% tulemustest).

Küsimus on selles, et tavaliselt on meil soovitused tootjatelt seoses seadmete konfigureerimise „parimate praktikatega” turvalisuse osas. Seda nimetatakse “hardening”.

Samuti võite sageli leida küsitluse (või koostada selle ise), mis põhineb nende soovitustel ja aitab teil kindlaks teha, kuivõrd teie seadmete konfiguratsioon vastab nendele "parimatele praktikatele" ning vastavalt tulemusele teha muudatusi teie võrgus. See võimaldab teil üsna lihtsalt, tegelikult ilma kuludeta, oluliselt vähendada turvariske.

Mõned näited mõnede Cisco operatsioonisüsteemide kohta.
Cisco IOS konfiguratsiooni tugevdamine
Cisco IOS-XR konfiguratsiooni tugevdamine
Cisco NX-OS konfiguratsiooni tugevdamine
Cisco baasvahekorra kontrollnimekiri
Nende dokumentide põhjal võib luua konfiguratsiooninõuete nimekirja iga tüüpi seadme jaoks. Näiteks Cisco N7K VDC jaoks võivad need nõuded välja näha nii.

Seega võivad erinevate tüüpi aktiivsete seadmete jaoks teie võrgu infrastruktuuris luua konfiguratsioonifailid. Edasi, käsitsi või automatiseerimise abil võite need konfiguratsioonifailid "üles laadida". Kuidas seda protsessi automatiseerida, käsitletakse üksikasjalikult teises artiklite seerias, mis on pühendatud orkestreerimisele ja automatiseerimisele.

Turva kujunduse audit

Ettevõtte võrgus (enterprise network) on tavaliselt järgmised segmendid:

DC (Avalike teenuste DMZ ja Intraneti andmekeskus)
Internet access
Remote access VPN
WAN äär
Filiaal
Campus (kontor)
Põhi

Nimed on võetud Cisco SAFE mudelist, kuid kindlasti ei ole vajalik neid nimesid ja mudelit rangelt järgida. Soovime siiski rääkida olemusest ja mitte takerduda formaalsustesse.

Igaühe jaoks nende segmentide puhul on turvanõuded, riskid ja vastavalt lahendused erinevad.

Vaatame igaüht neist eraldi probleemide osas, millega võite silmitsi seista turvaprojektimise vaatenurgast. Loomulikult mainin taas, et käesolev artikkel ei pretendeeri kindlasti täielikkusele, mis on selles tõeliselt sügavas ja mitmekesises teemas keeruline (kui üldse võimalik), kuid peegeldab minu isiklikku kogemust.

Perfekte lahendust ei eksisteeri (muidugi mitte praegu). See on alati kompromiss. Kuid oluline on, et lahenduse rakendamise otsus oleks tehtud teadlikult, mõistes selle plusse ja miinuseid.

Andmekeskus

Turvalisuse seisukohalt kõige kriitilisem segment.
Ja nagu tavaliselt, ei ole ka siin universaalset lahendust. Kõik sõltub tugevalt võrgu nõuetest.

Kas tulemüür on vajalik või mitte?

Tundub, et vastus on ilmne, kuid kõik ei ole nii üheselt mõistetav, nagu võiks arvata. Teie valikut võivad mõjutada mitte ainult hind.

Näide 1. Viivitused.
Kui madala viivitusega ühendus on mõnes võrgu segmentide vahel oluline nõue, nagu näiteks kauplemisel, siis ei saa me nende segmentide vahel kasutada tulemüüre. Uuringud tulemüüride viivituste kohta on keerulised leida, kuid vaid mõningad lülitite mudelid suudavad pakkuda viivitusi, mis on väiksemad või umbes 1 mksekundi. Seega, kui mikrosekundid on teie jaoks tähtsad, ei ole tulemüüri lahendused teie jaoks sobivad.

Näide 2. Töötlusvõimekus.
Tipptasemel L3 lülitite läbilaskevõime on tavaliselt kordades kõrgem kui kõige võimsamate tulemüüride läbilaskevõime. Seetõttu peate kõrge intensiivsusega liikluse korral tõenäoliselt suunama selle liikluse tulemüüride alt ära.

Näide 3. Usaldusväärsus.
Tulemüürid, eriti kaasaegsed NGFW (uue põlvkonna tulemüürid), on keerulised seadmed. Need on oluliselt keerulisemad kui L3/L2 lülitid. Need pakuvad palju teenuseid ja konfigureerimisvõimalusi, seega ei ole üllatav, et nende usaldusväärsus on oluliselt madalam. Kui teenuse järjepidevus on võrgus kriitilise tähtsusega, peate võib-olla valima, mis toob kaasa parema kättesaadavuse — turvalisuse tulemüüriga või võrgu lihtsuse, mis on ehitatud lülitite (või erinevate töötlemiste) ümber koos tavapäraste ACLidega.

Ülaltoodud näidete korral peate tõenäoliselt (nagu tavaliselt) leidma kompromissi. Vaadake järgmiste lahenduste suunas:

Kui olete otsustanud mitte kasutada tulemüüre andmekeskuses, peate hoolikalt läbi mõtlema, kuidas võimalikult palju juurdepääsu piiritleda perimeetril. Näiteks võite avada ainult vajalikud pordid Internetist (klientide liikluseks) ja haldusteenused andmekeskusesse ainult hüppemajutustelt. Hüppemajutustel tuleb teostada kogu vajalik kontroll (autentimine/volitamine, viirusetõrje, logimine …)
võite kasutada andmekeskuse võrgu loogilist jaotust segmenteerimise järgi, nagu on kirjeldatud PSEFABRICis näide p002. Sel juhul peaks marsruutimine olema seadistatud nii, et viivitustundlik või intensiivne liiklus liiguks ühe segmenti (p002, VRF) "siseselt" ega läheks läbi tulemüüri. Liiklus erinevate segmentide vahel suunatakse siiski läbi tulemüüri. Samuti on võimalik kasutada marsruudi lekkeid VRF-ide vahel, et vältida liikluse suunamist läbi tulemüüri.
samuti on võimalik kasutada tulemüüri läbipaistvas režiimis ja ainult nende VLAN-ide jaoks, kus need tegurid (viivitus/jõudlus) ei ole olulised. Kuid tuleb hoolikalt uurida selle vea kasutamisega seotud piiranguid iga tootja jaoks.
võite kaaluda teenuse ahela arhitektuuri rakendamist. See võimaldab suunata läbi tulemüüri ainult vajaliku liikluse. Teoorias tundub see kena, kuid ma pole kunagi näinud seda lahendust tootmises. Testisime teenuse ahelat Cisco ACI/Juniper SRX/F5 LTM umbes 3 aastat tagasi, kuid sel hetkel tundus see lahendus meile "toore".

Kaitsetase

Nüüd tuleb vastata küsimusele, milliseid tööriistu soovite liikluse filtreerimiseks kasutada. Siin on mõned võimalused, mis tavaliselt kaasnevad NGFW-ga (nt siin):

stateful firewalling (vaikimisi)
rakenduse tulemüür
ohtude ennetamine (viirusevastane, nuhkvara ja haavatavus)
URL-i filtreerimine
andmete filtreerimine (sisu filtreerimine)
failide blokeerimine (failitüüpide blokeerimine)
DDoS kaitse

Ja ka see pole alati üheselt selge. Tundub, et mida kõrgem on kaitseaste, seda parem. Kuid peate arvestama ka sellega, et

mida rohkem eelnimetatud tulemüüri funktsioone te kasutate, seda kallim see loomulikult on (litsentsid, lisamoodulid)
teatud algoritmide kasutamine võib oluliselt vähendada tulemüüri läbilaskevõimet ja suurendada viivitusi, vt näiteks siin
nagu iga keeruline lahendus, võib keerukate kaitsemeetodite kasutamine vähendada teie lahenduse usaldusväärsust, näiteks olen rakendusliku tulemüüriprotsessiga kohtunud teatud täiesti normaalselt toimivate rakenduste (DNS, SMB) blokeerimisega

Nagu tavaliselt, peate leidma oma võrgu jaoks optimaalse lahenduse.

Üheselt ei saa öelda, millised kaitsefunktsioonid võivad olla vajalikud. Esiteks sõltub see seejuures kindlasti andmetest, mida edastate või hoiustate ning proovite kaitsta. Teiseks, sageli on kaitsevahendite valik usaldus ja usk tarnijasse. Te ei tea, millised on algoritmid, ei tea nende efektiivsust ning ei suuda neid täielikult testida.

Seetõttu võib kriitilistes segmentides hea lahendus olla pakkumiste kasutamine erinevatelt ettevõtetelt. Näiteks võite lisada viirusetõrje tulemüürile, kuid kasutada ka (teise tootja) viirusetõrjet kohapeal hostidel.

Segmentimine

Räägime andmekeskuse võrgu loogilisest segmenteerimisest. Näiteks VLAN-ide ja alamvõrkude jagamine on samuti loogiline segmenteerimine, kuid me ei käsitle seda selle ilmsuse tõttu. Huvi pakub segmentatsioon arvestades selliseid üksusi nagu tulemüüri turvapiirkonnad, VRF (ja nende analoogid erinevate tarnijate jaoks), loogilised seadmed (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant jne).

Näide loogilisest segmenteerimisest ja praegu nõutavast andmekeskuse disainist on esitatud p002 projekti PSEFABRIC.

Määratledes oma võrgu loogilised osad, saate edasi kirjeldada, kuidas liiklus erinevate segmentide vahel liigub, millistel seadmetel toimub filtreerimine ja milliste vahenditega.

Kui teie võrgus puudub selge loogiline jaotus ja ei ole formaliseeritud reegleid turvapoliitikate rakendamiseks erinevatele andmevoogudele (flow), tähendab see, et juurdepääsu avamisel peate seda probleemi pidevalt lahendama ning tõenäoliselt lahendate seda iga kord erinevalt.

Sageli põhineb segmentatsioon ainult tulemüüride turvasonidel. Sel juhul peate vastama järgmistele küsimustele:

millised turvazonid on vajalikud
millist kaitsetaset soovite rakendada igaühele neist zonidest
kas intra-zone liiklus on vaikimisi lubatud
kui ei, siis millised liiklusfiltreerimise poliitikad rakendatakse iga zoni sees
millised liiklusfiltreerimise poliitikad rakendatakse iga kahe zoni (source/destination) vahel

TCAM

Sageli esineb probleem, kus TCAM-i (Ternary Content Addressable Memory) maht on liiga väike, nii marsruutimise kui ka ligipääsude jaoks. Minu arvates on see üks olulisemaid küsimusi seadmete valikul, mistõttu tuleks sellele teemale läheneda vajaliku ettevaatlikkusega.

Näide 1. Forwarding table TCAM.
Vaadakem Palo Alto 7k tulekahjusüsteemi.
Nägime, et IPv4 marsruutimislaud* = 32K
Samuti on see marsruutide arv kogusumma kõikide VSYS-ide jaoks.
Oletame, et vastavalt teie kujundusele otsustasite kasutada 4 VSYS-i.
Igaüks neist VSYS-idest on BGP kaudu ühendatud kahe PE MPLS pilvega, mida kasutate BB-na. Seega vahetavad 4 VSYS-i kõik spetsiifilised marsruudid omavahel ning omavad forwarding table'i, kus on umbes samasugused marsruutide kogumid (aga erinevad NH-d). Kuna igal VSYS-il on 2 BGP seanssi (sarnaste seadistustega), siis igal marsruudil, mis saadakse MPLS-i kaudu, on 2 NH-d ja vastavalt 2 FIB kirjesid Forwarding Table'is. Kui eeldada, et see on ainus tulemootor andmekeskuses ja see peab teadma kõikidest marsruutidest, siis tähendab see, et meie andmekeskuses ei tohi kogumarsruutide arv ületada 32K/(4 * 2) = 4K.
Nüüd, oletame, et meil on 2 andmekeskust (sama kujundusega) ja soovime kasutada VLAN-e, mis on "venitatud" andmekeskuste vahel (näiteks vMotioni jaoks). Selle marsruutimisprobleemi lahendamiseks peame kasutama hosti marsruute. Kuid see tähendab, et kahe andmekeskuse jaoks on meil mitte rohkem kui 4096 võimalikku hosti, ja kindlasti sellest ei pruugi piisata.

Näide 2. ACL TCAM.
Kui kavatsete filtreerida liiklust L3 lülitites (või muudes lahendustes, mis kasutavad L3 lüliteid, näiteks Cisco ACI), peate seadmete valimisel pöörama tähelepanu ACL TCAM-ile.
Oletame, et soovite kontrollida juurdepääse Cisco Catalyst 4500 SVI liidestel. Nagu näha on selle artikli, väljuva (nagu ka sissetuleva) liikluse kontrollimiseks liidestel saate kasutada vaid 4096 TCAM-rida. Mis TCAM3 kasutamise korral annab teile umbes 4000 ACE-d (ACL-rida).

Kui te olete silmitsi seisnud TCAM-i piisamatuse probleemiga, siis tuleks kõigepealt kaaluda optimeerimise võimalusi. Näiteks, kui probleemiks on Forwarding Table'i suurus, tuleks mõelda marsruutide aggregaatimisele. Kui probleem on TCAM-i suuruses juurdepääsude jaoks — juurdepääsude audit, vanade ja kattuvate kirjade eemaldamine, samuti võib-olla juurdepääsude avamise protseduuri ülevaatamine (mida käsitletakse põhjalikult juurdepääsude auditi peatükis).

Kõrge saadavus

Küsimus on, kas kasutada HA-d tulemüüride jaoks või paigaldada „paralleelselt” kaks sõltumatut seadme, ning kui üks neist ebaõnnestub, suunata liiklust läbi teise?

Esmapilgul paistab vastus olevat ilmne – kasutada HA-d. Kuid küsimus tekib üsna sageli seetõttu, et kahjuks teoreetilised ja reklaamitud 99 ja mõned kümnendikud kättesaadavusest osutuvad praktikas kaugeltki mitte nii roosiliseks. HA on loogiliselt piisavalt keeruline asi, ja erinevatel seadmetel ning erinevate tootjatega (välja arvatud juhul, kui on muid erandeid) oleme leidnud probleeme, vigu ja teenuse seiskumisi.

HA kasutamisel on teil võimalus välja lülitada üksikute node'ide ja vahetada nende vahel teenuse peatumise vältimiseks, mis on oluline näiteks uuenduste ajal. Siiski on teil endiselt põhjendamatu oht, et mõlemad node'id võivad samal ajal rikkis olla, samuti et järgmine uuendus ei pruugi kulgeda nii sujuvalt, nagu tootja lubab (seda probleemi saab vältida, kui teil on võimalus katsetada uuendust laboratoorsetes tingimustes).

Kui te ei kasuta HA-d, on teie riskid tavalise rikete osas oluliselt madalamad (kuna teil on 2 sõltumatut tulemüüri). Kuid kuna sessioonid ei ole sünkroniseeritud, kaotate iga kord, kui toimub vahetus nende tulemüüri vahel, liiklust. Loomulikult on võimalik kasutada staateless tulemüürimist, kuid siis kaotab tulemüüri kasutamine suuresti oma mõtte.

Seega, kui auditi tulemusena leiate, et teie tulekindlad seadmed seisavad üksinda ja mõtlete, kuidas oma võrgu usaldusväärsust suurendada, siis HA on kindlasti üks soovitatavaid lahendusi. Kuid te peaksite arvestama ka selle lähenemise puudustega, ja võib-olla on teie võrgule sobivam mõni muu lahendus.

Halduse mugavus

Tõepoolest, HA on ka haldatavus. Selle asemel, et seadistada kahte seadet eraldi ja lahendada konfiguratsioonide sünkroniseerimise probleem, haldate neid paljuski nagu ühte seadet.

Kuid võib-olla on teil palju andmekeskusi ja palju tulekindlaid seadmeid, siis tõuseb see küsimus uuele tasemele. Ja küsimus ei ole ainult konfiguratsioonis, vaid ka