Denne artikel er den tredje i serien "Hvordan man får netværksinfrastrukturen under kontrol". Indholdet af alle artikler i serien og links kan findes her.

Det giver ikke mening at tale om fuldstændig eliminering af sikkerhedsrisici. I princippet kan vi ikke reducere dem til nul. Det er også vigtigt at forstå, at når vi stræber efter at gøre netværket mere og mere sikkert, bliver vores løsninger også mere og mere omkostningsfulde. Det er nødvendigt at finde en rimelig kompromis mellem pris, kompleksitet og sikkerhed for dit netværk.

Selvfølgelig er sikkerhedsdesign integreret i den samlede arkitektur, og de anvendte sikkerhedsløsninger påvirker skalerbarheden, pålideligheden, administrerbarheden af netværksinfrastrukturen, hvilket også skal tages i betragtning.

Men lad mig minde om, at vi ikke taler om at skabe et netværk på nuværende tidspunkt. I overensstemmelse med vores indledende betingelser har vi allerede valgt design, valgt udstyr og opbygget infrastrukturen, og på dette stadium skal vi så vidt muligt "leve" og finde løsninger inden for den tidligere valgte tilgang.

Vores opgave nu er at identificere de risici, der er forbundet med netværkssikkerhed, og reducere dem til rimelige niveauer.

Netværkssikkerhedsrevision

Hvis din organisation har implementeret ISO 27k-processer, skal sikkerhedsrevisionen og ændringerne i netværket organisk være integreret i de generelle processer i henhold til denne tilgang. Men disse standarder handler stadig ikke om specifikke løsninger, ikke om konfiguration, ikke om design… Der er ingen entydige anbefalinger, ingen standarder, der detaljeret angiver, hvordan dit netværk skal se ud, hvilket gør denne opgave både kompleks og smuk.

Jeg ville fremhæve flere mulige netværkssikkerhedsrevisioner:

udstyrskonfigurationsrevision (hardening)
sikkerhedsdesignrevision
adgangsrevision
procesrevision

Audit af hardwarekonfiguration (hårdnedning)

Det synes at være den bedste startpunkt for revision og forbedring af sikkerheden i dit netværk i de fleste tilfælde. IMHO er det en god demonstration af Pareto-loven (20 % af indsatsen giver 80 % af resultatet, mens de øvrige 80 % af indsatsen kun giver 20 % af resultatet).

Essensen er, at vi normalt har anbefalinger fra leverandører om "best practices" for sikkerhed ved konfiguration af udstyr. Dette kaldes “hardening.”

Det er også ofte muligt at finde en spørgeskema (eller lave en selv) baseret på disse anbefalinger, som kan hjælpe dig med at afgøre, hvorvidt konfigurationen af dit udstyr svarer til disse "best practices", og i henhold til resultatet foretage ændringer i dit netværk. Dette vil gøre det muligt for dig at reducere sikkerhedsrisici betydeligt, faktisk uden omkostninger.

Nogle eksempler for nogle Cisco operativsystemer.
Cisco IOS Konfigurationshærder
Cisco IOS-XR Konfigurationshærder
Cisco NX-OS Konfigurationshærder
Cisco Baseline Sikkerhedstjekliste
Baseret på disse dokumenter kan der oprettes en liste over krav til konfiguration for hver type udstyr. For eksempel kan kravene til Cisco N7K VDC se således ud så.

Dermed kan der oprettes konfigurationsfiler for forskellige typer aktivt udstyr i din netværksinfrastruktur. Herefter kan du manuelt eller ved hjælp af automatisering "laste" disse konfigurationsfiler op. Hvordan man automatiserer denne proces vil blive beskrevet i en anden serie artikler, der er dedikeret til orkestrering og automatisering.

Audit af sikkerhedsdesign

Normalt inden for virksomhedens netværk (enterprise network) findes følgende segmenter i en eller anden form:

DC (Offentlige tjenester DMZ og intranet datacenter)
Internetadgang
Remote access VPN
WAN edge
Filial
Campus (Kontor)
Core

Navnene er taget fra Cisco SAFE modeller, men selvfølgelig er det ikke nødvendigt at knytte sig specifikt til disse navne og denne model. Det er vigtigere at tale om essensen og ikke blive fanget i formaliteter.

For hver af disse segmenter vil kravene til sikkerhedsniveau, risici og dermed løsningerne variere.

Lad os se på hver af dem enkeltvis med hensyn til de problemer, du kan støde på i forhold til sikkerhedsdesign. Selvfølgelig, som jeg gentager, gør denne artikel ikke krav på at være udtømmende, hvilket er svært at opnå i et så dybt og mangfoldigt emne (hvis det overhovedet er muligt), men den afspejler min personlige erfaring.

Der findes ikke en perfekt løsning (i hvert fald ikke nu). Det er altid et kompromis. Men det er vigtigt, at beslutningen om at anvende en bestemt tilgang er truffet bevidst, med forståelse for både dens fordele og ulemper.

Data Center

Det mest kritiske segment set fra et sikkerhedsperspektiv.
Og, som sædvanligt, er der heller ikke en universel løsning her. Det afhænger meget af netværkets krav.

Er en firewall nødvendig eller ej?

Det kan synes som om, svaret er indlysende, men det er ikke så entydigt, som det ser ud. Og dit valg kan påvirkes af mere end blot pris.

Eksempel 1. Forsinkelser.
Hvis lav forsinkelse mellem visse netværkssegmenter er et væsentligt krav, som for eksempel gælder for børser, kan vi ikke bruge firewalls mellem disse segmenter. Det er svært at finde undersøgelser om forsinkelser i firewalls, men kun få modeller af switche kan levere forsinkelser på mindre end eller omkring 1 mksec, så jeg tænker, at hvis mikrosekunder er vigtigt for dig, så er firewalls ikke det rette valg.

Eksempel 2. Ydeevne.
Båndbredden for de bedste L3-switche er som regel langt højere end båndbredden for de mest kraftfulde firewalls. Derfor, i tilfælde af højintensiv trafik, vil du sandsynligvis også skulle sende den trafik uden om firewalls.

Eksempel 3. Pålidelighed.
Firewalls, især moderne NGFW (Next-Generation FW), er komplekse enheder. De er betydeligt mere komplekse end L3/L2-switche. De tilbyder mange tjenester og konfigurationsmuligheder, så det er ikke overraskende, at deres pålidelighed er betydeligt lavere. Hvis servicekontinuitet er afgørende for netværket, skal du muligvis vælge mellem, hvad der giver den bedste tilgængelighed — sikkerhed via en firewall eller en enkelnetværksopbygning baseret på switche (eller forskellige typer fabrikker) ved hjælp af almindelige ACL.

I de nævnte eksempler må du sandsynligvis (som sædvanligt) finde et kompromis. Overvej følgende løsninger:

hvis du har besluttet ikke at bruge firewalls inden i datacentret, skal du overveje, hvordan du maksimalt kan begrænse adgangen ved perimetret. For eksempel kan du kun åbne de nødvendige porte fra internettet (til kundetrafik) og administrative adgangsoplysninger til datacentret kun fra jump hosts. Udfør al nødvendig kontrol (autentifikation/autorisation, antivirus, logning, …) på jump hosts.
du kan bruge logisk opdeling af datacenterets netværk i segmenter, ligesom beskrevet i PSEFABRIC-skematikken. eksempel p002Routing skal være konfigureret på en måde, så trafik, der er følsom over for forsinkelser eller intensiv trafik, går "indeni" et segment (i tilfælde af p002, VRF'en) og ikke går gennem firewall'en. Trafik mellem forskellige segmenter vil stadig gå gennem firewall'en. Route leaking mellem VRF'er kan også bruges for at undgå at omdirigere trafik gennem firewall'en.
Det er også muligt at bruge firewall'en i transparent mode og kun for de VLAN'er, hvor disse faktorer (forsinkelse/ydeevne) ikke er væsentlige. Men det er vigtigt at undersøge begrænsningerne ved brug af denne mode for hver leverandør.
Du kan overveje at anvende en service chain arkitektur. Dette vil tillade at dirigere kun den nødvendige trafik gennem firewall'en. Teoretisk set ser det godt ud, men jeg har aldrig set denne løsning i produktion. Vi testede service chain for Cisco ACI/Juniper SRX/F5 LTM for omkring 3 år siden, men på det tidspunkt syntes denne løsning "rå".

Sikkerhedsniveau

Nu er spørgsmålet, hvilke værktøjer du ønsker at anvende til trafikfiltrering. Her er nogle af de muligheder, der typisk er til stede i NGFW (for eksempel, her):

stateful firewalling (som standard)
applikationsfirewalling
trusselssikring (antivirus, antispyware og sårbarhed)
URL-filtrering
datafiltrering (indholdsfiltrering)
filblokering (blokering af filtyper)
dos protection

Og heller ikke alt er entydigt. Det ville umiddelbart se ud til, at jo højere beskyttelsesniveau, desto bedre. Men du skal også tage højde for, at

jo flere af de ovennævnte firewall-funktioner du bruger, desto dyrere vil det naturligvis blive (licenser, ekstra moduler).
Brug af nogle algoritmer kan betydeligt sænke firewall'ens båndbredde og også øge forsinkelserne, se for eksempel. her
Som med enhver kompleks løsning kan brug af komplekse beskyttelsesmetoder mindske pålideligheden af din løsning, for eksempel når jeg har brugt application firewalling, har jeg stødt på blokering af nogle helt almindelige funktionerende applikationer (dns, smb).

Som sædvanlig skal du finde den optimale løsning til dit netværk.

Det er umuligt entydigt at svare på, hvilke beskyttelsesfunktioner der kan være nødvendige. For det første, fordi det selvfølgelig afhænger af de data, du overfører eller opbevarer og forsøger at beskytte. For det andet, i virkeligheden er valget af beskyttelsesmidler ofte et spørgsmål om tro og tillid til leverandøren. Du kender ikke algoritmerne, du ved ikke, hvor effektive de er, og du kan ikke teste dem grundigt.

Derfor kan det i kritiske segmenter være en god løsning at bruge tilbud fra forskellige virksomheder. For eksempel kan du aktivere antivirus på firewallen, men samtidig bruge antivirusbeskyttelse (fra en anden leverandør) lokalt på værterne.

Segmentering

Det handler om den logiske segmentering af datacentret. For eksempel er opdeling i VLAN'er og subnets også en form for logisk segmentering, men vi vil ikke se nærmere på det, da det er indlysende. Interessant er segmenteringen med hensyn til entiteter som FW sikkerhedszoner, VRF (og deres ækvivalenter for forskellige leverandører), logiske enheder (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, …), …

Et eksempel på en sådan logisk segmentering og en eftertragtet datacenterdesign findes i p002 i projektet PSEFABRIC.

Når du har defineret de logiske dele af dit netværk, kan du beskrive, hvordan trafikken bevæger sig mellem de forskellige segmenter, hvilke enheder der vil udføre filtreringen, og med hvilke midler.

Hvis dit netværk ikke har en klar logisk opdeling, og der ikke er formaliserede regler for anvendelse af sikkerhedspolitikker for forskellige datastreams (flow), betyder det, at når du giver adgang til noget, skal du tage stilling til denne opgave, og med stor sandsynlighed vil du løse den forskelligt hver gang.

Segmentering er ofte kun baseret på FW sikkerhedszoner. Derfor skal du besvare følgende spørgsmål:

hvilke sikkerhedszoner du har brug for
hvilket sikkerhedsniveau du ønsker at anvende på hver af disse zoner
om intra-zone trafik skal være tilladt som standard
hvis ikke, hvilke trafikfiltreringspolitikker der vil blive anvendt inden for hver af zonerne
hvilke trafikfiltreringspolitikker der vil blive anvendt for hvert par zoner (source/destination)

TCAM

Et almindeligt problem er utilstrækkelig TCAM (Ternary Content Addressable Memory), både til routing og adgang. IMHO er dette et af de vigtigste spørgsmål ved valg af udstyr, så det er vigtigt at tage dette spørgsmål alvorligt.

Eksempel 1. Forwarding Table TCAM.
Lad os se på Palo Alto 7k firewallen.
Vi ser, at IPv4 forwarding table size* = 32K
Dette antal ruter er dog samlet for alle VSYS'er.
Antag, at du har besluttet at bruge 4 VSYS'er i henhold til dit design.
Hver af disse VSYS'er er tilsluttet via BGP til to PE MPLS-skyer, som du bruger som BB. På denne måde udveksler 4 VSYS'er alle specifikke ruter med hinanden og har en forwarding-tabel med omtrent de samme sæt ruter (men forskellige NH). Da hver VSYS har 2 BGP-sessioner (med identiske indstillinger), har hver rute, der modtages via MPLS, 2 NH og derfor 2 FIB-poster i Forwarding Table. Hvis vi antager, at dette er den eneste firewall i datacenteret og den skal kende til alle ruter, betyder det, at det samlede antal ruter i vores datacenter ikke kan være mere end 32K/(4 * 2) = 4K.
Nu, hvis vi antager, at vi har 2 datacentre (med identisk design), og vi ønsker at bruge VLAN'er, "strakt" mellem datacentrene (for eksempel til vMotion), så for at løse routingproblemet skal vi bruge host-ruter. Men det betyder, at vi i de 2 datacentre ikke vil have mere end 4096 mulige værter, hvilket naturligvis kan være utilstrækkeligt.

Eksempel 2. ACL TCAM.
Hvis du planlægger at filtrere trafik på L3-switches (eller andre løsninger, der bruger L3-switches, som f.eks. Cisco ACI), skal du ved valg af udstyr være opmærksom på ACL TCAM.
Antag, at du ønsker at kontrollere adgang på SVI-interfacet på Cisco Catalyst 4500. Så kan du, som det fremgår af denne artikel, kun bruge 4096 rækker TCAM til at kontrollere udgående (såvel som indgående) trafik på interface. Hvilket ved brug af TCAM3 giver dig omkring 4000 ACE (rækker ACL).

Hvis du står over for problemet med utilstrækkelig TCAM, skal du først og fremmest overveje muligheden for optimering. Så, i tilfælde af problemer med størrelsen af forwarding-tabellen, skal du overveje at aggregere ruter. I tilfælde af problemer med størrelsen af TCAM til adgang — audit af adgang, sletning af forældede og overlappende poster, samt muligvis en gennemgang af proceduren for adgangsåbning (vil blive behandlet detaljeret i kapitlet, der handler om adgangsaudit).

Høj tilgængelighed

Spørgsmålet er, om man skal bruge HA til firewalls eller sætte to uafhængige enheder "parallelt" og i tilfælde af nedbrud af en af dem rute trafikken gennem den anden?

Det ville synes, at svaret er åbenlyst – at bruge HA. Årsagen til, at dette spørgsmål opstår, ligger desværre i, at de teoretiske og reklamerede 99 og et par neuner efter kommaet på praktisk niveau ikke er så rosenrøde. HA er en logisk kompleks størrelse, og på forskelligt udstyr og med forskellige leverandører (uden undtagelser) har vi fanget problemer, fejl og serviceafbrydelser.

Ved brug af HA får du mulighed for at slukke for enkelte noder, skifte imellem dem uden at stoppe tjenesten, hvilket er vigtigt, for eksempel ved opgraderinger, men du har alligevel en ikke-nul sandsynlighed for, at begge noder kan fejle på samme tid, samt at en opgradering ikke forløber så glat, som leverandøren lover (dette problem kan undgås, hvis du har mulighed for at teste opgraderingen på laboratorieudstyr).

Hvis du ikke bruger HA, så i forhold til dobbeltfejl er dine risici betydeligt lavere (da du har 2 uafhængige firewalls), men da sessionerne ikke er synkroniserede, så hver gang der skiftes mellem disse firewalls, vil du miste trafik. Man kan selvfølgelig bruge stateless firewalling, men så mindskes formålet med at bruge firewall i høj grad.

Derfor, hvis du i forbindelse med en revision opdager ensomme firewalls, og du overvejer at øge pålideligheden af dit netværk, så er HA naturligvis en af de anbefalede løsninger, men du skal også tage højde for ulemperne forbundet med denne tilgang, og måske vil en anden løsning være mere passende for dit netværk.

Brugervenlighed i administration (managability)

HA handler også om administrerbarhed. I stedet for at konfigurere 2 enheder separat og løse problemet med synkronisering af konfigurationer, administrerer du dem i høj grad som om du har én enhed.

Men måske har du mange datacentre og mange firewalls; så bliver dette spørgsmål aktuelt på et nyt niveau. Og spørgsmålet handler ikke kun om konfiguration, men også om