Hierdie artikel is die derde in 'n reeks artikels "Hoe om beheer oor jou netwerkinfrastruktuur te neem." Die inhoud van alle artikels in die reeks en skakels kan gevind word hier.

Daar is geen sin om daaroor te praat om sekuriteitsrisiko's heeltemal uit te skakel nie. In beginsel kan ons hulle nie tot nul verminder nie. Ons moet ook verstaan ​​dat namate ons daarna streef om die netwerk meer en meer veilig te maak, ons oplossings al hoe duurder word. Jy moet 'n afweging vind tussen koste, kompleksiteit en sekuriteit wat sin maak vir jou netwerk.

Sekuriteitsontwerp is natuurlik organies geïntegreer in die algehele argitektuur en die sekuriteitsoplossings wat gebruik word, beïnvloed die skaalbaarheid, betroubaarheid, bestuurbaarheid, ... van die netwerkinfrastruktuur, wat ook in ag geneem moet word.

Maar laat ek jou herinner dat ons nou nie praat van die skep van 'n netwerk nie. Volgens ons aanvanklike voorwaardes ons het reeds die ontwerp gekies, die toerusting gekies en die infrastruktuur geskep, en op hierdie stadium, indien moontlik, moet ons “leef” en oplossings vind in die konteks van die voorheen gekose benadering.

Ons taak is nou om die risiko's verbonde aan sekuriteit op netwerkvlak te identifiseer en dit tot 'n redelike vlak te verminder.

Netwerk sekuriteit oudit

As jou organisasie ISO 27k-prosesse geïmplementeer het, moet sekuriteitsoudits en netwerkveranderings naatloos by die algehele prosesse binne hierdie benadering inpas. Maar hierdie standaarde gaan steeds nie oor spesifieke oplossings nie, nie oor konfigurasie nie, nie oor ontwerp nie... Daar is geen ondubbelsinnige advies nie, daar is geen standaarde wat in detail dikteer hoe jou netwerk moet wees nie, dit is die kompleksiteit en skoonheid van hierdie taak.

Ek sal verskeie moontlike netwerksekuriteitsoudits uitlig:

• toerusting konfigurasie oudit (verharding)
• sekuriteitsontwerp oudit
• toegang oudit
• proses oudit

Toerustingkonfigurasie oudit (verharding)

Dit blyk dat dit in die meeste gevalle die beste beginpunt is om die sekuriteit van u netwerk te oudit en te verbeter. IMHO, dit is 'n goeie demonstrasie van Pareto se wet (20% van die poging lewer 80% van die resultaat, en die oorblywende 80% van die poging lewer slegs 20% van die resultaat).

Die slotsom is dat ons gewoonlik aanbevelings van verskaffers het oor "beste praktyke" vir sekuriteit wanneer toerusting gekonfigureer word. Dit word "verharding" genoem.

Jy kan ook dikwels 'n vraelys vind (of self een skep) gebaseer op hierdie aanbevelings, wat jou sal help om te bepaal hoe goed die opstelling van jou toerusting aan hierdie "beste praktyke" voldoen en, in ooreenstemming met die resultaat, veranderinge in jou netwerk aanbring . Dit sal jou toelaat om sekuriteitsrisiko's redelik maklik te verminder, teen feitlik geen koste nie.

Verskeie voorbeelde vir sommige Cisco-bedryfstelsels.

Cisco IOS-konfigurasieverharding
Cisco IOS-XR-konfigurasieverharding
Cisco NX-OS-konfigurasieverharding
Cisco Baseline Security Kontrolelys

Op grond van hierdie dokumente kan 'n lys van konfigurasievereistes vir elke tipe toerusting geskep word. Byvoorbeeld, vir 'n Cisco N7K VDC kan hierdie vereistes lyk so.

Op hierdie manier kan konfigurasielêers vir verskillende tipes aktiewe toerusting in jou netwerkinfrastruktuur geskep word. Vervolgens, met die hand of met behulp van outomatisering, kan u hierdie konfigurasielêers “oplaai”. Hoe om hierdie proses te outomatiseer, sal breedvoerig in 'n ander reeks artikels oor orkestrasie en outomatisering bespreek word.

Sekuriteit ontwerp oudit

Tipies bevat 'n ondernemingsnetwerk die volgende segmente in een of ander vorm:

• DC (publieke dienste DMZ en Intranet datasentrum)
• toegang tot die internet
• Afstandtoegang VPN
• WAN rand
• Tak
• Kampus (Kantoor)
• Core

Titels geneem uit Cisco VEILIG model, maar dit is natuurlik nie nodig om presies aan hierdie name en aan hierdie model geheg te wees nie. Tog wil ek oor die essensie praat en nie in formaliteite vasval nie.

Vir elk van hierdie segmente sal sekuriteitsvereistes, risiko's en, dienooreenkomstig, oplossings verskil.

Kom ons kyk afsonderlik na elkeen van hulle vir die probleme wat u uit 'n sekuriteitsontwerp-oogpunt kan teëkom. Natuurlik herhaal ek weer dat hierdie artikel op geen manier voorgee om volledig te wees nie, wat nie maklik (indien nie onmoontlik nie) is om in hierdie werklik diep en veelvlakkige onderwerp te bereik nie, maar dit weerspieël my persoonlike ervaring.

Daar is geen perfekte oplossing nie (ten minste nog nie). Dit is altyd 'n kompromie. Maar dit is belangrik dat die besluit om een ​​of ander benadering te gebruik, bewustelik geneem word, met 'n begrip van beide die voor- en nadele daarvan.

Data sentrum

Die mees kritieke segment uit 'n veiligheidsoogpunt.
En soos gewoonlik is hier ook geen universele oplossing nie. Dit hang alles baie af van die netwerkvereistes.

Is 'n firewall nodig of nie?

Dit wil voorkom asof die antwoord voor die hand liggend is, maar alles is nie heeltemal so duidelik as wat dit mag lyk nie. En jou keuse kan nie net beïnvloed word nie die prys.

Voorbeeld 1. Vertragings.

As lae latensie 'n noodsaaklike vereiste is tussen sommige netwerksegmente, wat byvoorbeeld waar is in die geval van 'n uitruiling, dan sal ons nie firewalls tussen hierdie segmente kan gebruik nie. Dit is moeilik om studies oor latency in firewalls te vind, maar min skakelmodelle kan latency van minder as of in die orde van 1 mksec bied, so ek dink as mikrosekondes vir jou belangrik is, dan is firewalls nie vir jou nie.

Voorbeeld 2. Prestasie.

Die deurset van top L3 skakelaars is gewoonlik 'n orde van grootte hoër as die deurset van die kragtigste firewalls. Daarom, in die geval van hoë-intensiteit verkeer, sal jy heel waarskynlik ook hierdie verkeer moet toelaat om brandmure te omseil.

Voorbeeld 3. Betroubaarheid.

Firewalls, veral moderne NGFW (Next-Generation FW) is komplekse toestelle. Hulle is baie meer kompleks as L3/L2 skakelaars. Hulle bied 'n groot aantal dienste en konfigurasie-opsies, so dit is nie verbasend dat hul betroubaarheid baie laer is nie. As dienskontinuïteit van kritieke belang is vir die netwerk, moet jy dalk kies wat tot beter beskikbaarheid sal lei - sekuriteit met 'n firewall of die eenvoud van 'n netwerk wat gebou is op skakelaars (of verskeie soorte materiaal) wat gewone ACL's gebruik.

In die geval van bogenoemde voorbeelde sal jy heel waarskynlik (soos gewoonlik) 'n kompromie moet vind. Kyk na die volgende oplossings:

• as jy besluit om nie firewalls binne die datasentrum te gebruik nie, moet jy dink oor hoe om toegang rondom die omtrek soveel as moontlik te beperk. U kan byvoorbeeld slegs die nodige poorte vanaf die internet oopmaak (vir kliëntverkeer) en administratiewe toegang tot die datasentrum slegs vanaf springgashere. Op spring-gashere, voer al die nodige kontroles uit (verifikasie/magtiging, antivirus, aanteken, ...)
• jy kan 'n logiese partisie van die datasentrumnetwerk in segmente gebruik, soortgelyk aan die skema beskryf in PSEFABRIC voorbeeld p002. In hierdie geval moet roetering op so 'n manier gekonfigureer word dat vertraging-sensitiewe of hoë-intensiteit verkeer "binne" een segment gaan (in die geval van p002, VRF) en nie deur die firewall gaan nie. Verkeer tussen verskillende segmente sal voortgaan om deur die brandmuur te gaan. Jy kan ook roetelek tussen VRF's gebruik om te verhoed dat verkeer deur die brandmuur herlei word
• U kan ook 'n firewall in deursigtige modus gebruik en slegs vir daardie VLAN's waar hierdie faktore (latency/prestasie) nie beduidend is nie. Maar jy moet die beperkings wat verband hou met die gebruik van hierdie mod vir elke verkoper noukeurig bestudeer
• jy sal dalk wil oorweeg om 'n dienskettingargitektuur te gebruik. Dit sal slegs die nodige verkeer toelaat om deur die firewall te gaan. Lyk mooi in teorie, maar ek het nog nooit hierdie oplossing in produksie gesien nie. Ons het die diensketting vir Cisco ACI/Juniper SRX/F5 LTM sowat 3 jaar gelede getoets, maar op daardie stadium het hierdie oplossing vir ons "kru" gelyk.

Beskermingsvlak

Nou moet jy die vraag beantwoord watter gereedskap jy wil gebruik om verkeer te filter. Hier is 'n paar van die kenmerke wat gewoonlik in NGFW voorkom (byvoorbeeld, hier):

• stateful firewalling (verstek)
• aansoek firewalling
• bedreigingsvoorkoming (antivirus, anti-spioenware en kwesbaarheid)
• URL-filter
• datafiltrering (inhoudfiltrering)
• lêer blokkering (lêer tipes blokkering)
• dos beskerming

En ook nie alles is duidelik nie. Dit wil voorkom asof hoe hoër die vlak van beskerming, hoe beter. Maar jy moet dit ook in ag neem

• Hoe meer van die bogenoemde firewall-funksies jy gebruik, hoe duurder sal dit natuurlik wees (lisensies, bykomende modules)
• die gebruik van sommige algoritmes kan brandmuurdeurset aansienlik verminder en ook vertragings verhoog, sien byvoorbeeld hier
• soos enige komplekse oplossing, kan die gebruik van komplekse beskermingsmetodes die betroubaarheid van jou oplossing verminder, byvoorbeeld, wanneer ek toepassingsbrandmuur gebruik, het ek blokkering van sommige redelik standaard werkende toepassings (dns, smb) teëgekom.

Soos altyd moet jy die beste oplossing vir jou netwerk vind.

Dit is onmoontlik om die vraag oor watter beskermingsfunksies nodig mag wees definitief te beantwoord. Eerstens, want dit hang natuurlik af van die data wat jy oordra of stoor en probeer beskerm. Tweedens, in werklikheid is die keuse van sekuriteitsinstrumente dikwels 'n kwessie van geloof en vertroue in die verkoper. Jy ken nie die algoritmes nie, jy weet nie hoe effektief dit is nie, en jy kan dit nie ten volle toets nie.

Daarom, in kritieke segmente, kan 'n goeie oplossing wees om aanbiedinge van verskillende maatskappye te gebruik. Byvoorbeeld, jy kan antivirus op die firewall aktiveer, maar ook antivirusbeskerming (van 'n ander vervaardiger) plaaslik op die gashere gebruik.

Segmentering

Ons praat oor die logiese segmentering van die datasentrumnetwerk. Byvoorbeeld, partisionering in VLAN's en subnette is ook logiese segmentering, maar ons sal dit nie oorweeg nie as gevolg van die voor die hand liggendheid daarvan. Interessante segmentering met inagneming van sulke entiteite soos FW-sekuriteitsones, VRF's (en hul analoë in verhouding tot verskeie verskaffers), logiese toestelle (PA VSYS, Cisco N7K VDC, Cisco ACI-huurder, ...), ...

'n Voorbeeld van so 'n logiese segmentering en die tans in aanvraag datasentrumontwerp word gegee p002 van die PSEFABRIC-projek.

Nadat u die logiese dele van u netwerk gedefinieer het, kan u dan beskryf hoe verkeer tussen verskillende segmente beweeg, op watter toestelle filtering uitgevoer sal word en op watter manier.

As u netwerk nie 'n duidelike logiese partisie het nie en die reëls vir die toepassing van sekuriteitsbeleide vir verskillende datavloei nie geformaliseer is nie, beteken dit dat wanneer u hierdie of daardie toegang oopmaak, u gedwing word om hierdie probleem op te los, en met 'n hoë waarskynlikheid dat u sal dit elke keer anders oplos.

Dikwels is segmentering slegs gebaseer op FW-sekuriteitsones. Dan moet jy die volgende vrae beantwoord:

• watter sekuriteitsones het jy nodig
• watter vlak van beskerming jy op elk van hierdie sones wil toepas
• sal intra-sone verkeer by verstek toegelaat word?
• so nie, watter verkeerfiltreringsbeleide sal binne elke sone toegepas word
• watter verkeerfiltreringsbeleide vir elke paar sones toegepas sal word (bron/bestemming)

TCAM

'n Algemene probleem is onvoldoende TCAM (Ternary Content Addressable Memory), beide vir roetering en vir toegang. IMHO, dit is een van die belangrikste kwessies by die keuse van toerusting, so jy moet hierdie probleem met die toepaslike mate van sorg behandel.

Voorbeeld 1. Aanstuurtabel TCAM.

kom ons oorweeg dit Palo Alto 7k firewall
Ons sien dat IPv4-aanstuurtabelgrootte* = 32K
Boonop is hierdie aantal roetes algemeen vir alle VSYS'e.

Kom ons neem aan dat jy volgens jou ontwerp besluit om 4 VSYS te gebruik.
Elkeen van hierdie VSYS'e is via BGP gekoppel aan twee MPLS PE's van die wolk wat jy as 'n BB gebruik. Dus, 4 VSYS ruil alle spesifieke roetes met mekaar en het 'n aanstuurtabel met ongeveer dieselfde stelle roetes (maar verskillende NH'e). Omdat elke VSYS het 2 BGP-sessies (met dieselfde instellings), dan het elke roete wat via MPLS ontvang word 2 NH en, dienooreenkomstig, 2 FIB-inskrywings in die Aanstuurtabel. As ons aanvaar dat dit die enigste firewall in die datasentrum is en dit moet weet van al die roetes, dan sal dit beteken dat die totale aantal roetes in ons datasentrum nie meer as 32K/(4 * 2) = 4K kan wees nie.

As ons nou aanneem dat ons 2 datasentrums het (met dieselfde ontwerp), en ons wil VLAN's wat tussen datasentrums "gestrek" is (byvoorbeeld vir vMotion) gebruik, dan moet ons gasheerroetes gebruik om die roeteringsprobleem op te los . Maar dit beteken dat ons vir 2 datasentrums nie meer as 4096 moontlike gashere sal hê nie en natuurlik is dit dalk nie genoeg nie.

Voorbeeld 2. ACL TCAM.

As jy van plan is om verkeer op L3-skakelaars te filter (of ander oplossings wat L3-skakelaars gebruik, byvoorbeeld Cisco ACI), moet jy let op die TCAM ACL wanneer jy toerusting kies.

Gestel jy wil toegang beheer op die SVI-koppelvlakke van die Cisco Catalyst 4500. Dan, soos gesien kan word uit Hierdie artikel, om uitgaande (sowel as inkomende) verkeer op koppelvlakke te beheer, kan jy slegs 4096 TCAM-lyne gebruik. Wat as u TCAM3 gebruik, u ongeveer 4000 duisend ACE's (ACL-lyne) sal gee.

As u gekonfronteer word met die probleem van onvoldoende TCAM, dan moet u natuurlik eers die moontlikheid van optimalisering oorweeg. Dus, in die geval van 'n probleem met die grootte van die aanstuurtabel, moet u die moontlikheid oorweeg om roetes saam te voeg. In die geval van 'n probleem met die TCAM-grootte vir toegang, oudit toegang, verwyder verouderde en oorvleuelende rekords, en hersien moontlik die prosedure vir die opening van toegang (sal in detail bespreek word in die hoofstuk oor oudit toegang).

Hoë beskikbaarheid

Die vraag is: moet ek HA vir firewalls gebruik of twee onafhanklike bokse "in parallel" installeer en, as een van hulle misluk, verkeer deur die tweede lei?

Dit wil voorkom asof die antwoord voor die hand liggend is - gebruik HA. Die rede waarom hierdie vraag steeds ontstaan, is dat die teoretiese en advertensie-99 en verskeie desimale persentasies van toeganklikheid in die praktyk ongelukkig nog lank nie so rooskleurig blyk te wees nie. HA is logies nogal 'n komplekse ding, en op verskillende toerusting, en met verskillende verskaffers (daar was geen uitsonderings nie), het ons probleme en foute en diensstop opgespoor.

As jy HA gebruik, sal jy die geleentheid hê om individuele nodusse af te skakel, tussen hulle te skakel sonder om die diens te stop, wat belangrik is, byvoorbeeld wanneer opgraderings gedoen word, maar terselfdertyd het jy 'n ver van nul waarskynlikheid dat beide nodusse terselfdertyd sal breek, en ook dat die volgende die opgradering nie so glad sal verloop as wat die verkoper belowe nie (hierdie probleem kan vermy word as jy die geleentheid het om die opgradering op laboratoriumtoerusting te toets).

As jy nie HA gebruik nie, dan is jou risiko's uit die oogpunt van dubbele mislukking baie laer (aangesien jy 2 onafhanklike firewalls het), maar aangesien ... sessies nie gesinchroniseer word nie, dan sal jy elke keer as jy tussen hierdie firewalls wissel, verkeer verloor. Jy kan natuurlik staatlose firewalling gebruik, maar dan is die punt van die gebruik van 'n firewall grootliks verlore.

Daarom, as jy as gevolg van die oudit eensame firewalls ontdek het, en jy dink daaraan om die betroubaarheid van jou netwerk te verhoog, dan is HA natuurlik een van die aanbevole oplossings, maar jy moet ook die nadele daaraan verbonde in ag neem met hierdie benadering en miskien spesifiek vir jou netwerk, sal 'n ander oplossing meer geskik wees.

Hanteerbaarheid

In beginsel gaan HA ook oor beheerbaarheid. In plaas daarvan om 2 bokse afsonderlik op te stel en die probleem te hanteer om die konfigurasies gesinchroniseer te hou, bestuur jy dit baie asof jy een toestel het.

Maar miskien het jy baie datasentrums en baie firewalls, dan ontstaan ​​hierdie vraag op 'n nuwe vlak. En die vraag gaan nie net oor konfigurasie nie, maar ook oor

• rugsteun konfigurasies
• opdaterings
• opgraderings
• monitering
• aanteken

En dit alles kan opgelos word deur gesentraliseerde bestuurstelsels.

So, byvoorbeeld, as jy Palo Alto-firewalls gebruik, dan View is so 'n oplossing.

Om voortgesit te word.

Bron: will.com