Denne artikkelen er den tredje i en serie artikler "Hvordan ta kontroll over nettverksinfrastrukturen din." Innholdet i alle artiklene i serien og lenker finner du her.

Det er ingen vits i å snakke om å fullstendig eliminere sikkerhetsrisikoer. I prinsippet kan vi ikke redusere dem til null. Vi må også forstå at når vi streber etter å gjøre nettverket mer og sikrere, blir løsningene våre dyrere og dyrere. Du må finne en avveining mellom kostnad, kompleksitet og sikkerhet som gir mening for nettverket ditt.

Selvfølgelig er sikkerhetsdesign organisk integrert i den overordnede arkitekturen og sikkerhetsløsningene som brukes påvirker skalerbarheten, påliteligheten, håndterbarheten, ... av nettverksinfrastrukturen, noe som også bør tas i betraktning.

Men la meg minne om at nå snakker vi ikke om å skape et nettverk. I følge vår Innledende forhold vi har allerede valgt design, valgt utstyr og laget infrastrukturen, og på dette stadiet, hvis mulig, bør vi "leve" og finne løsninger i sammenheng med den tidligere valgte tilnærmingen.

Vår oppgave nå er å identifisere risikoene knyttet til sikkerhet på nettverksnivå og redusere dem til et rimelig nivå.

Nettverkssikkerhetsrevisjon

Hvis organisasjonen din har implementert ISO 27k-prosesser, bør sikkerhetsrevisjoner og nettverksendringer passe sømløst inn i de overordnede prosessene innenfor denne tilnærmingen. Men disse standardene handler fortsatt ikke om spesifikke løsninger, ikke om konfigurasjon, ikke om design... Det er ingen klare råd, ingen standarder som dikterer i detalj hvordan nettverket ditt skal være, dette er kompleksiteten og skjønnheten i denne oppgaven.

Jeg vil fremheve flere mulige nettverkssikkerhetsrevisjoner:

• utstyrskonfigurasjonsrevisjon (herding)
• revisjon av sikkerhetsdesign
• tilgangsrevisjon
• prosessrevisjon

Utstyrskonfigurasjonsrevisjon (herding)

Det ser ut til at dette i de fleste tilfeller er det beste utgangspunktet for å revidere og forbedre sikkerheten til nettverket ditt. IMHO, dette er en god demonstrasjon av Paretos lov (20% av innsatsen produserer 80% av resultatet, og de resterende 80% av innsatsen produserer bare 20% av resultatet).

Poenget er at vi vanligvis har anbefalinger fra leverandører angående "beste praksis" for sikkerhet ved konfigurering av utstyr. Dette kalles "herding".

Du kan også ofte finne et spørreskjema (eller lage et selv) basert på disse anbefalingene, som vil hjelpe deg å finne ut hvor godt konfigurasjonen av utstyret ditt samsvarer med disse "beste praksisene" og, i samsvar med resultatet, gjøre endringer i nettverket ditt . Dette vil tillate deg å redusere sikkerhetsrisikoen betydelig ganske enkelt, nesten uten kostnad.

Flere eksempler for noen Cisco-operativsystemer.

Cisco IOS-konfigurasjonsherding
Cisco IOS-XR-konfigurasjonsherding
Cisco NX-OS-konfigurasjonsherding
Cisco Baseline Security Sjekkliste

Basert på disse dokumentene kan det lages en liste over konfigurasjonskrav for hver type utstyr. For eksempel kan disse kravene se ut for en Cisco N7K VDC så.

På denne måten kan det lages konfigurasjonsfiler for ulike typer aktivt utstyr i din nettverksinfrastruktur. Deretter, manuelt eller ved hjelp av automatisering, kan du "laste opp" disse konfigurasjonsfilene. Hvordan man automatiserer denne prosessen vil bli diskutert i detalj i en annen serie artikler om orkestrering og automatisering.

Revisjon av sikkerhetsdesign

Vanligvis inneholder et bedriftsnettverk følgende segmenter i en eller annen form:

• DC (offentlige tjenester DMZ og intranettdatasenter)
• Internettilgang
• Fjerntilgang VPN
• WAN-kant
• Branch
• Campus (kontor)
• Kjerne

Titler hentet fra Cisco SAFE modell, men det er selvfølgelig ikke nødvendig å være knyttet til disse navnene og til denne modellen. Likevel vil jeg snakke om essensen og ikke gå fast i formaliteter.

For hvert av disse segmentene vil sikkerhetskrav, risiko og følgelig løsninger være forskjellige.

La oss se på hver av dem separat for problemene du kan støte på fra et sikkerhetsdesignsynspunkt. Selvfølgelig gjentar jeg igjen at denne artikkelen på ingen måte later til å være fullstendig, noe som ikke er lett (om ikke umulig) å oppnå i dette virkelig dype og mangefasetterte emnet, men det gjenspeiler min personlige erfaring.

Det er ingen perfekt løsning (i hvert fall ikke ennå). Det er alltid et kompromiss. Men det er viktig at beslutningen om å bruke en eller annen tilnærming tas bevisst, med forståelse for både fordeler og ulemper.

Datasenter

Det mest kritiske segmentet fra et sikkerhetssynspunkt.
Og som vanlig er det heller ingen universalløsning her. Alt avhenger sterkt av nettverkskravene.

Er en brannmur nødvendig eller ikke?

Det ser ut til at svaret er åpenbart, men alt er ikke fullt så klart som det kan virke. Og valget ditt kan ikke bare påvirkes pris.

Eksempel 1. Forsinkelser.

Hvis lav latens er et essensielt krav mellom enkelte nettverkssegmenter, noe som for eksempel er sant i tilfelle en utveksling, så vil vi ikke kunne bruke brannmurer mellom disse segmentene. Det er vanskelig å finne studier på latens i brannmurer, men få switchmodeller kan gi latens på mindre enn eller i størrelsesorden 1 mksec, så jeg tror at hvis mikrosekunder er viktig for deg, så er ikke brannmurer noe for deg.

Eksempel 2. Performance.

Gjennomstrømningen til topp L3-svitsjer er vanligvis en størrelsesorden høyere enn gjennomstrømningen til de kraftigste brannmurene. Derfor, ved høyintensitetstrafikk, vil du også mest sannsynlig måtte la denne trafikken omgå brannmurer.

Eksempel 3. Pålitelighet.

Brannmurer, spesielt moderne NGFW (Next-Generation FW), er komplekse enheter. De er mye mer komplekse enn L3/L2-brytere. De tilbyr et stort antall tjenester og konfigurasjonsalternativer, så det er ikke overraskende at påliteligheten deres er mye lavere. Hvis tjenestekontinuitet er kritisk for nettverket, må du kanskje velge hva som vil føre til bedre tilgjengelighet - sikkerhet med en brannmur eller enkelheten til et nettverk bygget på svitsjer (eller ulike typer stoffer) som bruker vanlige ACL-er.

Når det gjelder eksemplene ovenfor, vil du mest sannsynlig (som vanlig) måtte finne et kompromiss. Se mot følgende løsninger:

• hvis du bestemmer deg for ikke å bruke brannmurer inne i datasenteret, må du tenke på hvordan du begrenser tilgangen rundt omkretsen så mye som mulig. For eksempel kan du bare åpne de nødvendige portene fra Internett (for klienttrafikk) og administrativ tilgang til datasenteret kun fra hoppverter. På hoppverter, utfør alle nødvendige kontroller (autentisering/autorisering, antivirus, logging, ...)
• du kan bruke en logisk partisjon av datasenternettverket i segmenter, lik skjemaet beskrevet i PSEFABRIC eksempel p002. I dette tilfellet må ruting konfigureres på en slik måte at forsinkelsessensitiv eller høyintensitetstrafikk går "innenfor" ett segment (i tilfellet p002, VRF) og ikke går gjennom brannmuren. Trafikk mellom ulike segmenter vil fortsette å gå gjennom brannmuren. Du kan også bruke rutelekkasje mellom VRF-er for å unngå å omdirigere trafikk gjennom brannmuren
• Du kan også bruke en brannmur i transparent modus og kun for de VLANene hvor disse faktorene (latens/ytelse) ikke er signifikante. Men du må nøye studere begrensningene knyttet til bruken av denne moden for hver leverandør
• kan det være lurt å vurdere å bruke en tjenestekjedearkitektur. Dette vil tillate bare nødvendig trafikk å passere gjennom brannmuren. Ser bra ut i teorien, men jeg har aldri sett denne løsningen i produksjon. Vi testet servicekjeden for Cisco ACI/Juniper SRX/F5 LTM for ca. 3 år siden, men på det tidspunktet virket denne løsningen "rå" for oss.

Beskyttelsesnivå

Nå må du svare på spørsmålet om hvilke verktøy du vil bruke for å filtrere trafikk. Her er noen av funksjonene som vanligvis finnes i NGFW (f.eks. her):

• stateful brannmur (standard)
• applikasjons brannmur
• trusselforebygging (antivirus, antispyware og sårbarhet)
• URL -filtrering
• datafiltrering (innholdsfiltrering)
• filblokkering (blokkering av filtyper)
• dos beskyttelse

Og ikke alt er klart heller. Det ser ut til at jo høyere beskyttelsesnivå, jo bedre. Men du må også vurdere det

• Jo flere av de ovennevnte brannmurfunksjonene du bruker, jo dyrere blir det naturligvis (lisenser, tilleggsmoduler)
• bruk av enkelte algoritmer kan redusere brannmurens gjennomstrømning betydelig og også øke forsinkelser, se for eksempel her
• som enhver kompleks løsning, kan bruk av komplekse beskyttelsesmetoder redusere påliteligheten til løsningen din, for eksempel når jeg bruker applikasjonsbrannmur, oppdaget jeg blokkering av noen ganske standard fungerende applikasjoner (dns, smb)

Som alltid må du finne den beste løsningen for nettverket ditt.

Det er umulig å svare definitivt på spørsmålet om hvilke beskyttelsesfunksjoner som kan kreves. For det første fordi det selvfølgelig avhenger av dataene du overfører eller lagrer og prøver å beskytte. For det andre, i virkeligheten er valget av sikkerhetsverktøy ofte et spørsmål om tro og tillit til leverandøren. Du kjenner ikke algoritmene, du vet ikke hvor effektive de er, og du kan ikke teste dem fullt ut.

Derfor kan en god løsning i kritiske segmenter være å benytte tilbud fra ulike selskaper. Du kan for eksempel aktivere antivirus på brannmuren, men også bruke antivirusbeskyttelse (fra en annen produsent) lokalt på vertene.

Segmentering

Vi snakker om den logiske segmenteringen av datasenternettverket. For eksempel er partisjonering i VLAN og subnett også logisk segmentering, men vi vil ikke vurdere det på grunn av dets åpenhet. Interessant segmentering som tar hensyn til slike enheter som FW-sikkerhetssoner, VRF-er (og deres analoger i forhold til forskjellige leverandører), logiske enheter (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

Et eksempel på slik logisk segmentering og den etterspurte datasenterdesignen er gitt i p002 av PSEFABRIC-prosjektet.

Etter å ha definert de logiske delene av nettverket ditt, kan du beskrive hvordan trafikken beveger seg mellom ulike segmenter, på hvilke enheter filtrering skal utføres og med hvilke midler.

Hvis nettverket ditt ikke har en klar logisk partisjon og reglene for bruk av sikkerhetspolicyer for forskjellige datastrømmer ikke er formalisert, betyr dette at når du åpner denne eller den tilgangen, blir du tvunget til å løse dette problemet, og med stor sannsynlighet vil løse det annerledes hver gang.

Ofte er segmentering kun basert på FW-sikkerhetssoner. Da må du svare på følgende spørsmål:

• hvilke sikkerhetssoner trenger du
• hvilket beskyttelsesnivå du ønsker å gjelde for hver av disse sonene
• vil intrasonetrafikk tillates som standard?
• hvis ikke, hvilke retningslinjer for trafikkfiltrering vil bli brukt innenfor hver sone
• hvilke retningslinjer for trafikkfiltrering vil bli brukt for hvert sonepar (kilde/destinasjon)

TCAM

Et vanlig problem er utilstrekkelig TCAM (Ternary Content Addressable Memory), både for ruting og for tilganger. IMHO, dette er en av de viktigste problemene når du velger utstyr, så du må behandle dette problemet med riktig grad av forsiktighet.

Eksempel 1. Videresendingstabell TCAM.

La oss vurdere Palo Alto 7k brannmur
Vi ser at IPv4-videresendingstabellstørrelse* = 32K
Dessuten er dette antallet ruter felles for alle VSYS.

La oss anta at du i henhold til designet ditt bestemmer deg for å bruke 4 VSYS.
Hver av disse VSYS-ene er koblet via BGP til to MPLS PE-er i skyen som du bruker som en BB. Dermed bytter 4 VSYS alle spesifikke ruter med hverandre og har en videresendingstabell med omtrent samme sett med ruter (men forskjellige NH-er). Fordi hver VSYS har 2 BGP-økter (med samme innstillinger), deretter har hver rute mottatt via MPLS 2 NH og følgelig 2 FIB-oppføringer i videresendingstabellen. Hvis vi antar at dette er den eneste brannmuren i datasenteret og den må kjenne til alle rutene, vil dette bety at det totale antallet ruter i vårt datasenter ikke kan være mer enn 32K/(4 * 2) = 4K.

Nå, hvis vi antar at vi har 2 datasentre (med samme design), og vi ønsker å bruke VLAN "strukket" mellom datasentre (for eksempel for vMotion), må vi bruke vertsruter for å løse rutingproblemet . Men dette betyr at for 2 datasentre vil vi ikke ha mer enn 4096 mulige verter, og selvfølgelig kan dette ikke være nok.

Eksempel 2. ACL TCAM.

Hvis du planlegger å filtrere trafikk på L3-svitsjer (eller andre løsninger som bruker L3-svitsjer, for eksempel Cisco ACI), bør du være oppmerksom på TCAM ACL når du velger utstyr.

Anta at du vil kontrollere tilgangen på SVI-grensesnittene til Cisco Catalyst 4500. Deretter, som det fremgår av denne artikkelen, for å kontrollere utgående (så vel som innkommende) trafikk på grensesnitt, kan du bare bruke 4096 TCAM-linjer. Som når du bruker TCAM3 vil gi deg omtrent 4000 tusen ACE-er (ACL-linjer).

Hvis du står overfor problemet med utilstrekkelig TCAM, må du først av alt selvfølgelig vurdere muligheten for optimalisering. Så, i tilfelle et problem med størrelsen på videresendingstabellen, må du vurdere muligheten for å samle ruter. I tilfelle et problem med TCAM-størrelsen for tilganger, revisjonstilganger, fjern utdaterte og overlappende poster, og eventuelt revider prosedyren for å åpne tilganger (vil bli diskutert i detalj i kapittelet om revisjonstilgang).

Høy tilgjengelighet

Spørsmålet er: bør jeg bruke HA for brannmurer eller installere to uavhengige bokser "parallelt" og, hvis en av dem mislykkes, rute trafikk gjennom den andre?

Det ser ut til at svaret er åpenbart - bruk HA. Grunnen til at dette spørsmålet fortsatt dukker opp er at de teoretiske og reklamemessige 99 og flere desimalprosentene av tilgjengelighet i praksis viser seg å være langt fra så rosenrøde. HA er logisk sett en ganske kompleks ting, og på forskjellig utstyr, og med forskjellige leverandører (det var ingen unntak), fanget vi problemer og feil og servicestopp.

Bruker du HA vil du ha mulighet til å skru av individuelle noder, bytte mellom dem uten å stoppe tjenesten, noe som er viktig for eksempel ved oppgraderinger, men samtidig har du en langt fra null sannsynlighet for at begge nodene vil gå i stykker samtidig, og også at neste oppgradering ikke vil gå så knirkefritt som leverandøren lover (dette problemet kan unngås hvis du har mulighet til å teste oppgraderingen på laboratorieutstyr).

Hvis du ikke bruker HA, er risikoen din mye lavere fra synspunktet om dobbel feil (siden du har 2 uavhengige brannmurer), men siden... økter ikke synkroniseres, så hver gang du bytter mellom disse brannmurene vil du miste trafikk. Du kan selvfølgelig bruke statsløs brannmur, men da er poenget med å bruke en brannmur stort sett tapt.

Derfor, hvis du som et resultat av revisjonen har oppdaget ensomme brannmurer, og du tenker på å øke påliteligheten til nettverket ditt, så er HA selvfølgelig en av de anbefalte løsningene, men du bør også ta hensyn til ulempene forbundet med dette. med denne tilnærmingen, og kanskje spesielt for nettverket ditt, ville en annen løsning være mer egnet.

Håndterbarhet

Prinsipielt handler HA også om kontrollerbarhet. I stedet for å konfigurere 2 bokser separat og håndtere problemet med å holde konfigurasjonene synkronisert, administrerer du dem omtrent som om du hadde én enhet.

Men kanskje du har mange datasentre og mange brannmurer, så dukker dette spørsmålet opp på et nytt nivå. Og spørsmålet handler ikke bare om konfigurasjon, men også om

• sikkerhetskopieringskonfigurasjoner
• oppdateringer
• oppgraderinger
• overvåkning
• hogst

Og alt dette kan løses med sentraliserte styringssystemer.

Så hvis du for eksempel bruker Palo Alto brannmurer, da Vis er en slik løsning.

Skal videreføres.

Kilde: www.habr.com