Denne artikel er den tredje i en serie af artikler "Sådan tager du kontrol over din netværksinfrastruktur." Indholdet af alle artikler i serien og links kan findes her.

Det nytter ikke at tale om helt at eliminere sikkerhedsrisici. I princippet kan vi ikke reducere dem til nul. Vi skal også forstå, at efterhånden som vi stræber efter at gøre netværket mere og mere sikkert, bliver vores løsninger dyrere og dyrere. Du skal finde en afvejning mellem omkostninger, kompleksitet og sikkerhed, der giver mening for dit netværk.

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

Men lad mig minde dig om, at nu taler vi ikke om at skabe et netværk. Ifølge vores begyndelsesbetingelser vi har allerede valgt designet, valgt udstyret og skabt infrastrukturen, og på dette stadie bør vi om muligt "leve" og finde løsninger i sammenhæng med den tidligere valgte tilgang.

Vores opgave er nu at identificere de risici, der er forbundet med sikkerhed på netværksniveau og reducere dem til et rimeligt niveau.

Revision af netværkssikkerhed

Hvis din organisation har implementeret ISO 27k-processer, bør sikkerhedsaudits og netværksændringer passe problemfrit ind i de overordnede processer inden for denne tilgang. Men disse standarder handler stadig ikke om specifikke løsninger, ikke om konfiguration, ikke om design... Der er ingen klare råd, ingen standarder, der dikterer i detaljer, hvordan dit netværk skal være, det er kompleksiteten og skønheden ved denne opgave.

Jeg vil fremhæve flere mulige netværkssikkerhedsrevisioner:

• udstyrskonfigurationsaudit (hærdning)
• revision af sikkerhedsdesign
• adgangsrevision
• procesrevision

Udstyrskonfigurationskontrol (hærdning)

Det ser ud til, at dette i de fleste tilfælde er det bedste udgangspunkt for revision og forbedring af dit netværks sikkerhed. IMHO, dette er en god demonstration af Paretos lov (20% af indsatsen producerer 80% af resultatet, og de resterende 80% af indsatsen producerer kun 20% af resultatet).

Den nederste linje er, at vi normalt har anbefalinger fra leverandører vedrørende "best practices" for sikkerhed ved konfiguration af udstyr. Dette kaldes "hærdning".

Du kan også ofte finde et spørgeskema (eller oprette et selv) baseret på disse anbefalinger, som vil hjælpe dig med at bestemme, hvor godt konfigurationen af ​​dit udstyr overholder disse "best practices" og, i overensstemmelse med resultatet, foretage ændringer i dit netværk . Dette vil give dig mulighed for at reducere sikkerhedsrisici betydeligt ganske nemt, stort set uden omkostninger.

Flere eksempler på nogle Cisco-operativsystemer.

Cisco IOS Configuration Hardening
Cisco IOS-XR Konfigurationshærdning
Cisco NX-OS Konfigurationshærdning
Cisco Baseline-sikkerhedstjekliste

Baseret på disse dokumenter kan der oprettes en liste over konfigurationskrav for hver type udstyr. For eksempel kan disse krav se ud for en Cisco N7K VDC så.

På denne måde kan der oprettes konfigurationsfiler til forskellige typer aktivt udstyr i din netværksinfrastruktur. Dernæst, manuelt eller ved hjælp af automatisering, kan du "uploade" disse konfigurationsfiler. Hvordan man automatiserer denne proces, vil blive diskuteret i detaljer i en anden serie af artikler om orkestrering og automatisering.

Sikkerhedsdesign revision

Et virksomhedsnetværk indeholder typisk følgende segmenter i en eller anden form:

• DC (Offentlige tjenester DMZ og intranet datacenter)
• Internetadgang
• Fjernadgang VPN
• WAN-kant
• Branch
• Campus (kontor)
• Core

Titler taget fra Cisco SAFE model, men det er naturligvis ikke nødvendigt at være knyttet præcist til disse navne og til denne model. Alligevel vil jeg tale om essensen og ikke hænge fast i formaliteter.

For hvert af disse segmenter vil sikkerhedskrav, risici og dermed løsninger være forskellige.

Lad os se på hver af dem separat for de problemer, du kan støde på fra et sikkerhedsdesignsynspunkt. Selvfølgelig gentager jeg igen, at denne artikel på ingen måde foregiver at være komplet, hvilket ikke er let (hvis ikke umuligt) at opnå i dette virkelig dybe og mangefacetterede emne, men det afspejler min personlige erfaring.

Der er ingen perfekt løsning (i hvert fald ikke endnu). Det er altid et kompromis. Men det er vigtigt, at beslutningen om at bruge den ene eller anden tilgang tages bevidst med forståelse for både fordele og ulemper.

Data Center

Det mest kritiske segment ud fra et sikkerhedssynspunkt.
Og her er der som sædvanlig heller ingen universalløsning. Det hele afhænger meget af netværkskravene.

Er en firewall nødvendig eller ej?

Det ser ud til, at svaret er indlysende, men alt er ikke helt så klart, som det kan se ud. Og dit valg kan ikke kun påvirkes pris.

Eksempel 1. Forsinkelser.

Hvis lav latency er et væsentligt krav mellem nogle netværkssegmenter, hvilket for eksempel er tilfældet i tilfælde af en udveksling, så vil vi ikke kunne bruge firewalls mellem disse segmenter. Det er svært at finde undersøgelser af latency i firewalls, men få switch-modeller kan give latency på mindre end eller i størrelsesordenen 1 mksec, så jeg tror, ​​at hvis mikrosekunder er vigtige for dig, så er firewalls ikke noget for dig.

Eksempel 2. Ydeevne.

Gennemløbet af top L3-switches er normalt en størrelsesorden højere end gennemløbet af de mest kraftfulde firewalls. I tilfælde af højintensiv trafik vil du derfor højst sandsynligt også skulle tillade denne trafik at omgå firewalls.

Eksempel 3. Pålidelighed.

Firewalls, især moderne NGFW (Next-Generation FW), er komplekse enheder. De er meget mere komplekse end L3/L2-switche. De tilbyder et stort antal tjenester og konfigurationsmuligheder, så det er ikke overraskende, at deres pålidelighed er meget lavere. Hvis servicekontinuitet er kritisk for netværket, så skal du måske vælge, hvad der vil føre til bedre tilgængelighed - sikkerhed med en firewall eller enkeltheden af ​​et netværk bygget på switches (eller forskellige slags stoffer) ved hjælp af almindelige ACL'er.

I tilfælde af ovenstående eksempler vil du højst sandsynligt (som sædvanligt) skulle finde et kompromis. Se på følgende løsninger:

• hvis du beslutter dig for ikke at bruge firewalls inde i datacentret, så skal du tænke over, hvordan du begrænser adgangen rundt om perimeteren så meget som muligt. For eksempel kan du kun åbne de nødvendige porte fra internettet (til klienttrafik) og administrativ adgang til datacentret kun fra jump-værter. På jump-værter skal du udføre alle nødvendige kontroller (godkendelse/autorisation, antivirus, logning, ...)
• du kan bruge en logisk opdeling af datacenternetværket i segmenter, svarende til skemaet beskrevet i PSEFABRIC eksempel p002. I dette tilfælde skal routing konfigureres på en sådan måde, at forsinkelsesfølsom eller højintensitetstrafik går "inden for" ét segment (i tilfælde af p002, VRF) og ikke går gennem firewallen. Trafik mellem forskellige segmenter vil fortsætte med at gå gennem firewallen. Du kan også bruge rutelækage mellem VRF'er for at undgå at omdirigere trafik gennem firewallen
• Du kan også bruge en firewall i transparent tilstand og kun for de VLAN'er, hvor disse faktorer (latency/ydeevne) ikke er signifikante. Men du skal nøje studere begrænsningerne forbundet med brugen af ​​denne mod for hver leverandør
• kan du overveje at bruge en servicekædearkitektur. Dette vil tillade kun nødvendig trafik at passere gennem firewallen. Ser godt ud i teorien, men jeg har aldrig set denne løsning i produktion. Vi testede servicekæden for Cisco ACI/Juniper SRX/F5 LTM for omkring 3 år siden, men på det tidspunkt virkede denne løsning "rå" for os.

Beskyttelsesniveau

Nu skal du besvare spørgsmålet om, hvilke værktøjer du vil bruge til at filtrere trafik. Her er nogle af de funktioner, der normalt er til stede i NGFW (f.eks. her):

• stateful firewalling (standard)
• applikations firewalling
• trusselforebyggelse (antivirus, anti-spyware og sårbarhed)
• URL-filtrering
• datafiltrering (indholdsfiltrering)
• filblokering (blokering af filtyper)
• dos beskyttelse

Og alt er heller ikke klart. Det ser ud til, at jo højere beskyttelsesniveau, jo bedre. Men det skal du også overveje

• Jo flere af ovenstående firewall-funktioner du bruger, jo dyrere bliver det naturligvis (licenser, ekstra moduler)
• brugen af ​​nogle algoritmer kan reducere firewall-gennemstrømningen markant og også øge forsinkelser, se f.eks her
• Ligesom enhver kompleks løsning kan brugen af ​​komplekse beskyttelsesmetoder reducere pålideligheden af ​​din løsning, for eksempel, når jeg brugte applikationsfirewalling, stødte jeg på blokering af nogle ganske standard, fungerende applikationer (dns, smb)

Som altid skal du finde den bedste løsning til dit netværk.

Det er umuligt at besvare spørgsmålet om, hvilke beskyttelsesfunktioner der kan være nødvendige. For det første, fordi det selvfølgelig afhænger af de data, du transmitterer eller gemmer og forsøger at beskytte. For det andet er valget af sikkerhedsværktøjer i virkeligheden 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 fuldt ud.

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

Segmentering

Vi taler om den logiske segmentering af datacenternetværket. For eksempel er partitionering i VLAN'er og undernet også logisk segmentering, men vi vil ikke overveje det på grund af dets indlysendehed. Interessant segmentering under hensyntagen til sådanne enheder som FW-sikkerhedszoner, VRF'er (og deres analoger i forhold til forskellige leverandører), logiske enheder (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

Et eksempel på en sådan logisk segmentering og det aktuelt efterspurgte datacenterdesign er givet i p002 af PSEFABRIC-projektet.

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

Hvis dit netværk ikke har en klar logisk partition, og reglerne for anvendelse af sikkerhedspolitikker for forskellige datastrømme ikke er formaliserede, betyder det, at når du åbner denne eller hin adgang, er du tvunget til at løse dette problem, og med stor sandsynlighed vil løse det hver gang anderledes.

Ofte er segmentering kun baseret på FW-sikkerhedszoner. Så skal du besvare følgende spørgsmål:

• hvilke sikkerhedszoner har du brug for
• hvilket beskyttelsesniveau du ønsker at anvende for hver af disse zoner
• vil intra-zone trafik være tilladt som standard?
• hvis ikke, hvilke trafikfiltreringspolitikker vil blive anvendt inden for hver zone
• hvilke trafikfiltreringspolitikker vil blive anvendt for hvert par af zoner (kilde/destination)

TCAM

Et almindeligt problem er utilstrækkelig TCAM (Ternary Content Addressable Memory), både til routing og til adgange. IMHO, dette er et af de vigtigste spørgsmål, når du vælger udstyr, så du skal behandle dette problem med den passende grad af omhu.

Eksempel 1. Videresendelsestabel TCAM.

Lad os se på Palo Alto 7k firewall
Vi ser, at IPv4-videresendelsestabelstørrelse* = 32K
Desuden er dette antal ruter fælles for alle VSYS'er.

Lad os antage, at du i henhold til dit design beslutter dig for at bruge 4 VSYS.
Hver af disse VSYS'er er forbundet via BGP til to MPLS PE'er i skyen, som du bruger som en BB. 4 VSYS udveksler således alle specifikke ruter med hinanden og har en viderestillingstabel med omtrent samme rutesæt (men forskellige NH'er). Fordi hver VSYS har 2 BGP-sessioner (med samme indstillinger), derefter har hver rute modtaget via MPLS 2 NH og følgelig 2 FIB-poster i videresendelsestabellen. Hvis vi antager, at dette er den eneste firewall i datacentret, og den skal kende til alle ruterne, så vil det betyde, at det samlede antal ruter i vores datacenter ikke må være mere end 32K/(4 * 2) = 4K.

Hvis vi nu antager, at vi har 2 datacentre (med samme design), og vi ønsker at bruge VLAN'er "strakt" mellem datacentre (f.eks. til vMotion), så skal vi for at løse routingproblemet bruge værtsruter . Men det betyder, at for 2 datacentre vil vi ikke have mere end 4096 mulige værter, og det kan selvfølgelig ikke være nok.

Eksempel 2. ACL TCAM.

Hvis du planlægger at filtrere trafik på L3-switche (eller andre løsninger, der bruger L3-switche, for eksempel Cisco ACI), skal du, når du vælger udstyr, være opmærksom på TCAM ACL.

Antag, at du vil kontrollere adgangen på SVI-grænsefladerne på Cisco Catalyst 4500. Så, som det kan ses af denne artikel, for at kontrollere udgående (såvel som indgående) trafik på grænseflader, kan du kun bruge 4096 TCAM-linjer. Hvilket, når du bruger TCAM3, vil give dig omkring 4000 tusind ACE'er (ACL-linjer).

Hvis du står over for problemet med utilstrækkelig TCAM, så skal du først og fremmest selvfølgelig overveje muligheden for optimering. Så i tilfælde af et problem med størrelsen af ​​videresendelsestabellen, skal du overveje muligheden for at samle ruter. I tilfælde af et problem med TCAM-størrelsen for adgange, revisionsadgange, fjern forældede og overlappende registreringer og revider muligvis proceduren for åbning af adgange (vil blive diskuteret detaljeret i kapitlet om revisionsadgange).

High Availability

Spørgsmålet er: skal jeg bruge HA til firewalls eller installere to uafhængige bokse "parallelt" og, hvis en af ​​dem fejler, dirigere trafik gennem den anden?

Det ser ud til, at svaret er indlysende - brug HA. Grunden til, at dette spørgsmål stadig opstår, er, at de teoretiske og reklamemæssige 99 og adskillige decimalprocenter af tilgængelighed i praksis desværre viser sig at være langt fra så rosenrøde. HA er logisk set en ret kompleks ting, og på forskelligt udstyr og med forskellige leverandører (der var ingen undtagelser), fangede vi problemer og fejl og servicestop.

Hvis du bruger HA, vil du have mulighed for at slukke for individuelle noder, skifte mellem dem uden at stoppe tjenesten, hvilket er vigtigt for eksempel ved opgraderinger, men samtidig har du en langt fra nul sandsynlighed for, at begge noder vil gå i stykker på samme tid, og også at den næste opgradering ikke vil gå så gnidningsfrit 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å er dine risici fra dobbeltfejlssynspunktet meget lavere (da du har 2 uafhængige firewalls), men da... sessioner ikke synkroniseres, så hver gang du skifter mellem disse firewalls vil du miste trafik. Du kan selvfølgelig bruge statsløs firewalling, men så er pointen med at bruge en firewall stort set tabt.

Derfor, hvis du som følge af revisionen har opdaget ensomme firewalls, og du tænker på at øge pålideligheden af ​​dit netværk, så er HA selvfølgelig en af ​​de anbefalede løsninger, men du bør også tage højde for de ulemper, der er forbundet med dette. med denne tilgang og måske specifikt til dit netværk, ville en anden løsning være mere egnet.

Håndterbarhed

I princippet handler HA også om kontrollerbarhed. I stedet for at konfigurere 2 bokse separat og håndtere problemet med at holde konfigurationerne synkroniserede, administrerer du dem meget, som hvis du havde én enhed.

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

• backup konfigurationer
• opdateringer
• opgraderinger
• overvågning
• logning

Og alt dette kan løses med centraliserede ledelsessystemer.

Så hvis du for eksempel bruger Palo Alto firewalls, så Vis er sådan en løsning.

Fortsættes.

Kilde: www.habr.com