See artikkel on kolmas osa artiklite tsüklist "Kuidas võtta võrguinfrastruktuur oma kontrolli alla". Kõigi tsükli artiklite sisu ja lingid leiate siin.

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

Muidugi on turvadesain orgaaniliselt integreeritud üldisesse arhitektuuri ning kasutatavad turvalahendused mõjutavad võrgu infrastruktuuri skaleeritavust, usaldusväärsust, haldust… ja seda tuleb samuti arvesse võtta.

Kuid meenutan, et praegu me ei räägi võrgu loomisest. Vastavalt meie algsetele tingimustele on meil juba valitud disain, valitud varustus ja loodud infrastruktuur, ning sellel hetkel peame võimaluse korral "elama“ ja leidma lahendusi eelmise lähenemise kontekstis.

Meie ülesanne praegu on tuvastada võrgu turvalisusega seotud riskid ja vähendada need mõistlikule tasemele.

Võrgu turbe audit

Kui teie organisatsioonis on rakendatud ISO 27k protsessid, siis peaks turbe ja võrgu muudatuste audit orgaaniliselt sulanduma üldistesse protsessidesse selle lähenemise raames. Kuid need standardid ei käsitle siiski konkreetseid lahendusi, konfiguratsiooni ega disaini… Ei ole üheselt mõistetavaid soovitusi, ei ole standardeid, mis detailselt dikteeriksid, milline peaks olema teie võrk, selles peitub selle ülesande keerukus ja ilu.

Nimetaaksin mitmeid võimalikke võrgu turbe auditeid:

seadmise konfiguratsiooni audit (hardening)
turvesuundi audit
juurdepääsude audit
protsesside audit

Seadmestiku konfiguratsiooni auditeerimine (karmistamine)

Tundub, et enamikul juhtudel on see parim alguspunkt teie võrgu auditi ja turvalisuse parandamiseks. IМХО, see on hea näide Pareto seadusest (20% pingutustest toob 80% tulemusest, samas kui ülejäänud 80% pingutustest toob vaid 20% tulemusest).

Olemus on selles, et tavaliselt on meil varustuse konfigureerimise osas soovitusi tootjatelt "parimate praktikate" kohta turvalisuse osas. Seda nimetatakse "hardening".

Samuti võib sageli kohata küsitlust (või koostada ise), mis põhineb nende soovitustel ja aitab teil määrata, kui hästi vastab teie seadmete konfiguratsioon nendele "parimatele praktikatele" ja vastavalt tulemusele teha muudatusi teie võrgus. See võimaldab teil üsna hõlpsalt, praktiliselt kuludeta, oluliselt vähendada turvariske.

Mõned näited mõnede Cisco operatsioonisüsteemide jaoks.
Cisco IOS konfiguratsiooni kõvaks muutmine
Cisco IOS-XR konfiguratsiooni kõvaks muutmine
Cisco NX-OS konfiguratsiooni kõvaks muutmine
Cisco baasline turvakaontrolli loetelu
Nende dokumentide põhjal võib koostada nõuete nimekirja iga tüübi seadmete konfiguratsiooni jaoks. Näiteks Cisco N7K VDC jaoks võivad need nõuded välja näha nii.

Nii võivad olla loodud konfiguratsioonifailid erinevat tüüpi teie võrguinfrastruktuuri aktiivsetele seadmetele. Edasi saate neid konfiguratsioonifaile "laadida" käsitsi või automatiseerimise abil. Kuidas seda protsessi automatiseerida, käsitletakse põhjalikumalt teistes artiklites, mis käsitlevad orkestreerimist ja automatiseerimist.

Turvadesaini audit

Tavaliselt on ettevõtte võrgus (enterprise network) sellised segmendid vähemalt mõnel viisil olemas:

DC (Avalike teenuste DMZ ja Intranet andmekeskus)
Interneti juurdepääs
Kaugnõrglik VPN
WAN ääreala
Filiaal
Kampuse (kontor)
Tuumik

Nimed on võetud Cisco SAFE mudelitest, kuid ei ole kindlasti vaja otseselt siduda neid nimedega ja selle mudeliga. Oluline on rääkida sisust ja mitte jääda formaalsustesse kinni.

Igaühe jaoks neist segmentidest erinevad turvanõuded, riskid ja vastavad lahendused.

Vaatleme igaüht neist eraldi probleemide osas, millega võite silmitsi seista turvadesaini vaatepunktist. Loomulikult kordaksin veel kord, et see artikkel ei pretendeeri täielikkusele, mille saavutamine on selles tõeliselt sügav- ja mitmekesises teemas keeruline (kui üldse võimalik), kuid peegeldab minu isiklikku kogemust.

Ideaalset lahendust ei eksisteeri (igal juhul mitte praegu). See on alati kompromiss. Kuid oluline on, et otsus rakendada üht või teist lähenemist oleks tehtud teadlikult, mõistes nii selle plusse kui ka miinuseid.

Andmekeskus

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

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

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

Näide 1. Viivitused.
Kui madal viivitus on olulise nõudena mõnede võrgusegmentide vahel, nagu näiteks börsi puhul, siis ei saa me nende segmentide vahel kasutada tulemüüre. Uuringud tulemüüride viivituste kohta on raske leida, kuid vaid mõned lülitite mudelid võivad pakkuda viivitusi alla või ligikaudu 1 mksec, seetõttu arvan, et kui mikrosekundid on teile olulised, siis tulemüürid ei ole teie jaoks.

Näide 2. Tõhusus.
Tipptasemel L3 lülitite läbilaskevõime on tavaliselt oluliselt kõrgem kui kõige tõhusamate tulemüüride läbilaskevõime. Seetõttu peate suure intensiivsusega liikluse korral tõenäoliselt suunama selle liikluse tulemüüre vältides.

Näide 3. Usaldusväärsus.
Tulemüürid, eriti tänapäevased NGFW-d (Next-Generation FW), on keerulised seadmed. Need on palju keerulisemad kui L3/L2 lülitid. Need pakuvad palju teenuseid ja konfigureerimisvõimalusi, seega pole üllatav, et nende usaldusväärsus on oluliselt madalam. Kui teenuse järjepidevus on võrgu jaoks kriitiline, peate võib-olla valima, mis toob parema kättesaadavuse — kaitse tulemüüri abil või võrgu lihtsuse, mis põhineb lülititel (või erineva tüübi tehastes) koos tavaliste ACL-idega.

Eelpooltoodud näidete puhul peate tõenäoliselt (nagu tavaliselt) leidma kompromissi. Vaadake järgmisi lahendusi:

kui otsustate mitte kasutada tulemüüre andmekeskuses, peate hoolikalt kaaluma, kuidas piirata juurdepääsu perimeetril. Näiteks võite avada ainult vajalikud pordid Internetis (klientide liikluse jaoks) ja haldusjuurdepääsud andmekeskusesse ainult hüppemaamajade kaudu. Hüppemaamajades peate tegema kogu vajaliku kontrolldi (autentimine/volitamine, viirusetõrje, logimine, ...)
võite kasutada andmekeskuse võrgu loogilist jagamist segmentideks, sarnaselt skeemile, mida kirjeldatakse PSEFABRIC-is näide p002Routimine peab olema seadistatud nii, et viivitustundlik või suure intensiivsusega liiklus liiguks «siseruumides» ühes segmendis (näiteks p002, VRF) ega liiguks läbi tulemüüri. Erinevate segmentide vahel liiklus läheb endiselt läbi tulemüüri. Samuti saab kasutada route leaking-t VRF-ide vahel, et vältida liikluse suunamist läbi tulemüüri.
Samuti on võimalik kasutada tulemüüri läbipaistvas režiimis (transparent mode) ainult nende VLAN-ide puhul, kus need tegurid (viivitus/performance) pole kriitilised. Kuid tuleb hoolikalt uurida, millised piirangud on seotud selle režiimi kasutamisega iga tootja puhul.
Võite kaaluda teenuseketi (service chain) arhitektuuri rakendamist. See võimaldab suunata tulemüüri kaudu vaid vajalikku liiklust. Teoreetiliselt tundub see kena, kuid ma pole kunagi näinud seda lahendust tootmises. Me testisime teenuseketti Cisco ACI/Juniper SRX/F5 LTM keskkonnas umbes 3 aastat tagasi, kuid sel hetkel tundus see lahendus meile «toores».

Kaitseaste

Nüüd tuleb vastata küsimusele, milliseid tööriistu soovite liikluse filtreerimiseks kasutada. Siin on mõned võimalused, mis tavaliselt leiduvad NGFW-s (näiteks, siit):

stateful firewalling (vaikimisi)
rakenduse tulemüüri (application firewalling)
ohtude ennetamine (antivirus, antiviirus ja haavatavuse tõrje)
URL filtreerimine
andmete filtreerimine (sisu filtreerimine)
failide blokeerimine (failitüüpide blokeerimine)
dos kaitse

Ja ka see ei ole nii lihtne. Tundub, et mida kõrgem on kaitse tase, seda parem. Kuid teil tuleb arvesse võtta, et

mida rohkem ülalnimetatud tulemüüri funktsioone kasutate, seda kallim see loomulikult on ( litsentsid, lisamoodulid).
Mõnede algoritmide kasutamine võib oluliselt vähendada tulemüüri läbilaskevõimet ning suurendada viivitusi, vt näiteks siit
Nagu iga keerukas lahendus, võib keerukamate kaitsemeetodite kasutamine vähendada teie lahenduse usaldusväärsust, näiteks rakenduse tulemüüri kasutamisel olen kokku puutunud olukordadega, kus blokeeriti mõningaid täiesti tavalisi rakendusi (dns, smb).

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

Ei saa üheselt vastata küsimusele, milliseid kaitsefunktsioone võib vaja minna. Esiteks, see sõltub loomulikult andmetest, mida edastate või salvestate ja üritate kaitsta. Teiseks, reaalses elus on tihtipeale kaitsevahendite valik usaldamise ja uskumise küsimus teenusepakkuja suhtes. Te ei tunne algoritme, ei tea, kui tõhusad need on, ja ei saa neid täielikult testida.

Seetõttu võivad kriitilistes segmentides heaks lahenduseks olla erinevate ettevõtete pakkumised. Näiteks võite lisada viirusetõrje tulemüürile, kuid kasutada ka kohalikult (teise tootja) viirusetõrjet hostides.

Segmentimine

Jutuks on andmekeskuse võrgu loogiline segmenteerimine. Näiteks VLAN-ide ja alamvõrkude jagamine on samuti loogiline segmenteerimine, kuid me ei käsitle seda, kuna see on iseenesest mõistetav. Huvi pakub segmentimine, arvestades selliseid üksusi nagu FW turvazoonad, VRF (ja nende analoogid erinevate teenusepakkujate kontekstis), loogilised seadmed (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, …), …

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

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

Kui teie võrgus puudub selge loogiline jaotus ning ei ole formuleeritud turvapoliitikate rakendamise reegleid erinevate andmevoogude jaoks, tähendab see, et kui avate mingisuguse juurdepääsu, peate selle ülesande lahendama, ja tõenäoliselt lahendate iga kord selle erinevalt.

Tihti põhineb segmentimine ainult FW turvazoonadel. Seetõttu peate vastama järgmistele küsimustele:

millised turvazonad on vajalikud
millist kaitse taset soovite rakendada igaühe jaoks neist zonadest
kas intra-zone liiklus on vaikimisi lubatud
kui ei, siis millised liiklusfiltreerimise poliitikad rakendatakse iga zona sees
millised liiklusfiltreerimise poliitikad rakendatakse igas zone paaris (allikas / sihtkoht)

TCAM

Sageli esineb probleem ebapiisava TCAM-i (Ternary Content Addressable Memory) osas nii marsruutimise kui ka ligipääsude jaoks. Minu arvates on see üks olulisemaid küsimusi seadmete valimisel, seega tuleks sellele küsimusele läheneda vajaliku täpsusega.

Näide 1. Forwarding Table TCAM.
Vaadakem Palo Alto 7k tuletrüüsi.
Näeme, et IPv4 forwarding table size* = 32K
Sellisel juhul on see ridade koguarv kõigi VSYS-ide jaoks.
Eeldame, et teie disaini kohaselt 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õiki spetsiifilisi radasid üksteisega ja omavad approximately samade marsruutide kogumit (kuid erinevate NH-dega). Kuna iga VSYS-il on 2 BGP seanssi (sama konfigureerimisega), siis igal marsruudil, mis saadakse läbi MPLS-i, on 2 NH-d ja vastavalt 2 FIB-kirjet Forwarding Table-is. Kui eeldada, et see on ainus tuletrüüs andmekeskuses ja see peab teadma kõiki marsruute, siis see tähendab, et meie andmekeskuse kogumarsruutide arv ei saa ületada 32K/(4 * 2) = 4K.
Nüüd, kui eeldada, et meil on 2 andmekeskust (sama disainiga), ja soovime kasutada VLAN-e, mis on 'venitatud' andmekeskuste vahel (nt vMotioni jaoks), siis marsruutimise probleemi lahendamiseks peame kasutama hosti marsruute. Kuid see tähendab, et 2 andmekeskusele on meil maksimaalselt 4096 võimalikku hosti ja sellest võib kindlasti puududa.

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), siis seadmete valimisel tuleb tähelepanu pöörata ACL TCAM-ile.
Eeldame, et soovite kontrollida ligipääse Cisco Catalyst 4500 SVI liidese kaudu. Niisiis, nagu näha on selle artikli, saab väljuva (nagu ka sisenemise) liikluse kontrollimiseks liideseid kasutada vaid 4096 TCAM-i rida. Mis TCAM3 kasutamisel annab teile umbes 4000 ACE (ACL-i rida).

Kui teil on probleem vähese TCAM-i tõttu, tuleks esmajärgus kaaluda optimeerimist. Näiteks, kui Forwarding Table'i suuruse probleem esineb, tuleks vaadata marsruutide agregatsiooni võimalusi. TCAM-i suuruse probleemide puhul, mis on seotud juurdepääsudega, on vajalik auditeerida juurdepääse, eemaldada vananenud ja kattuvad sissekanded ning võimalusel vaadata üle juurdepääsude avamise protseduur (millest räägitakse põhjalikult juurdepäsuauditile pühendatud peatükis).

Kõrge kättesaadavus

Küsimus seisneb selles, kas kasutada HA-d tulemüüride jaoks või paigaldada «paralleelselt» kaks sõltumatut seadet ning suunata liiklus teise seadmest, kui üks neist peaks jooksma kokku?

Esmapilgul tundub vastus olevat ilmne – kasutada HA-d. Põhjus, miks see küsimus siiski esile kerkib, on see, et paraku on teoreetilised ja reklaamitud 99 ja mõned üheksa pärast koma protsenti kättesaadavusest praktikas kaugel ideaalist. HA on loogiliselt keeruline ning erineval varustusel ja erinevate tarnijatega (erandeid pole olnud) oleme leidnud probleeme, vigu ja teenuse katkestusi.

HA kasutamisel saate võimaluse välja lülitada üksikud sõlmed, vahetada nende vahel teenuse katkestamata, mis on oluline näiteks uuenduste korral, ent samas on teil ikkagi kaugelt mitte null tõenäosus, et mõlemad sõlmed purunevad korraga, samuti see, et järgmine uuendus ei pruugi kulgeda nii sujuvalt, nagu tarnija lubab (seda probleemi saab vältida, kui teil on võimalus katsetada uuendust laboriseadmetel).

Kui te ei kasuta HA-d, siis topeltviga riskide seisukohalt on riskid oluliselt madalamad (sest teil on 2 sõltumatut tulemüüri), ent kuna sessioonid ei ole sünkroniseeritud, siis iga kord, kui toimub vahetus nende tulemüüride vahel, kaotate te liiklust. Loomulikult saab kasutada stateless tulemüürimist, kuid siis kaotab tulemüüri kasutamise mõte paljuski oma tähenduse.

Seega, kui auditi tulemusena leiate üksikute tulemüüride olemasolu ja kaalute oma võrgu usaldusväärsuse suurendamist, on HA kindlasti üks soovitatud lahendus, kuid peate arvestama ka selle lähenemisega seotud miinustega ning ilmselt sobib just teie võrgule mõni teine lahendus paremini.

Halduse mugavus (haldamine)

Põhimõtteliselt hõlmab HA ka hallatavust. Selle asemel, et konfigureerida kahte seadet eraldi ja lahendada konfiguratsioonide sünkroniseerimise probleem, hallate neid paljuski nagu ühte seadet.

Kuid võib-olla teil on palju andmekeskusi ja palju tulemüüre, siis kerkib see küsimus uuele tasemele. Ja küsimus ei ole mitte ainult konfigureerimises, vaid ka