{"id":31058,"date":"2019-10-31T21:39:12","date_gmt":"2019-10-31T18:39:12","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-tretya-setevaya-bezopasnost-chast-pervaya\/"},"modified":"2019-10-31T21:39:12","modified_gmt":"2019-10-31T18:39:12","slug":"kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-tretya-setevaya-bezopasnost-chast-pervaya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-tretya-setevaya-bezopasnost-chast-pervaya","title":{"rendered":"S\u00e5dan f\u00e5r du kontrol over din netv\u00e6rksinfrastruktur. Kapitel tre. Netv\u00e6rkssikkerhed. Del \u00e9n","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i>Denne artikel er den tredje i serien \"Hvordan man f\u00e5r netv\u00e6rksinfrastrukturen under kontrol\". Indholdet af alle artikler i serien og links kan findes <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/447008\/\">her<\/a><\/noindex><\/i>.<\/p>\n<p><img decoding=\"async\" alt=\"S\u00e5dan f\u00e5r du kontrol over din netv\u00e6rksinfrastruktur. Kapitel tre. Netv\u00e6rkssikkerhed. Del \u00e9n\" src=\"\/wp-content\/uploads\/2019\/04\/cdf33cc6797d26df8fef5533f2570c47.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDet giver ikke mening at tale om fuldst\u00e6ndig eliminering af sikkerhedsrisici. I princippet kan vi ikke reducere dem til nul. Det er ogs\u00e5 vigtigt at forst\u00e5, at n\u00e5r vi str\u00e6ber efter at g\u00f8re netv\u00e6rket mere og mere sikkert, bliver vores l\u00f8sninger ogs\u00e5 mere og mere omkostningsfulde. Det er n\u00f8dvendigt at finde en rimelig kompromis mellem pris, kompleksitet og sikkerhed for dit netv\u00e6rk. <\/p>\n<p>Selvf\u00f8lgelig er sikkerhedsdesign integreret i den samlede arkitektur, og de anvendte sikkerhedsl\u00f8sninger p\u00e5virker skalerbarheden, p\u00e5lideligheden, administrerbarheden af netv\u00e6rksinfrastrukturen, hvilket ogs\u00e5 skal tages i betragtning.<\/p>\n<p>Men lad mig minde om, at vi ikke taler om at skabe et netv\u00e6rk p\u00e5 nuv\u00e6rende tidspunkt. I overensstemmelse med vores <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/433614\/\">indledende betingelser<\/a><\/noindex> har vi allerede valgt design, valgt udstyr og opbygget infrastrukturen, og p\u00e5 dette stadium skal vi s\u00e5 vidt muligt \"leve\" og finde l\u00f8sninger inden for den tidligere valgte tilgang.<\/p>\n<p>Vores opgave nu er at identificere de risici, der er forbundet med netv\u00e6rkssikkerhed, og reducere dem til rimelige niveauer. <noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Netv\u00e6rkssikkerhedsrevision<\/h1>\n<p>\nHvis din organisation har implementeret ISO 27k-processer, skal sikkerhedsrevisionen og \u00e6ndringerne i netv\u00e6rket organisk v\u00e6re integreret i de generelle processer i henhold til denne tilgang. Men disse standarder handler stadig ikke om specifikke l\u00f8sninger, ikke om konfiguration, ikke om design\u2026 Der er ingen entydige anbefalinger, ingen standarder, der detaljeret angiver, hvordan dit netv\u00e6rk skal se ud, hvilket g\u00f8r denne opgave b\u00e5de kompleks og smuk.<\/p>\n<p>Jeg ville fremh\u00e6ve flere mulige netv\u00e6rkssikkerhedsrevisioner:<\/p>\n<ul>\n<li>udstyrskonfigurationsrevision (hardening)<\/li>\n<li>sikkerhedsdesignrevision<\/li>\n<li>adgangsrevision<\/li>\n<li>procesrevision<\/li>\n<\/ul>\n<p><\/p>\n<h1>Audit af hardwarekonfiguration (h\u00e5rdnedning)<\/h1>\n<p>\nDet synes at v\u00e6re den bedste startpunkt for revision og forbedring af sikkerheden i dit netv\u00e6rk i de fleste tilf\u00e6lde. IMHO er det en god demonstration af Pareto-loven (20 % af indsatsen giver 80 % af resultatet, mens de \u00f8vrige 80 % af indsatsen kun giver 20 % af resultatet). <\/p>\n<p>Essensen er, at vi normalt har anbefalinger fra leverand\u00f8rer om \"best practices\" for sikkerhed ved konfiguration af udstyr. Dette kaldes \u201chardening.\u201d<\/p>\n<p>Det er ogs\u00e5 ofte muligt at finde en sp\u00f8rgeskema (eller lave en selv) baseret p\u00e5 disse anbefalinger, som kan hj\u00e6lpe dig med at afg\u00f8re, hvorvidt konfigurationen af dit udstyr svarer til disse \"best practices\", og i henhold til resultatet foretage \u00e6ndringer i dit netv\u00e6rk. Dette vil g\u00f8re det muligt for dig at reducere sikkerhedsrisici betydeligt, faktisk uden omkostninger.<\/p>\n<blockquote><p>Nogle eksempler for nogle Cisco operativsystemer.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/en\/us\/support\/docs\/ip\/access-lists\/13608-21.html\">Cisco IOS Konfigurationsh\u00e6rder<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/tools.cisco.com\/security\/center\/resources\/increase_security_ios_xr_devices.html\">Cisco IOS-XR Konfigurationsh\u00e6rder<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/tools.cisco.com\/security\/center\/resources\/securing_nx_os.html\">Cisco NX-OS Konfigurationsh\u00e6rder<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/en\/us\/td\/docs\/solutions\/Enterprise\/Security\/Baseline_Security\/securebasebook\/appendxD.html\">Cisco Baseline Sikkerhedstjekliste<\/a><\/noindex><\/p>\n<p>Baseret p\u00e5 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\u00e5ledes ud <noindex><a rel=\"nofollow\" href=\"https:\/\/www.dropbox.com\/s\/hnat6yriyptigzb\/7k_hard.xlsx?dl=0\">s\u00e5<\/a><\/noindex>.<\/p><\/blockquote>\n<p>\nDermed kan der oprettes konfigurationsfiler for forskellige typer aktivt udstyr i din netv\u00e6rksinfrastruktur. Herefter kan du manuelt eller ved hj\u00e6lp 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.<\/p>\n<h1>Audit af sikkerhedsdesign<\/h1>\n<p>\nNormalt inden for virksomhedens netv\u00e6rk (enterprise network) findes f\u00f8lgende segmenter i en eller anden form: <\/p>\n<ul>\n<li>DC (Offentlige tjenester DMZ og intranet datacenter)<\/li>\n<li>Internetadgang<\/li>\n<li>Remote access VPN<\/li>\n<li>WAN edge<\/li>\n<li>Filial<\/li>\n<li>Campus (Kontor)<\/li>\n<li>Core<\/li>\n<\/ul>\n<p>\nNavnene er taget fra <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/en\/us\/td\/docs\/solutions\/Enterprise\/Security\/SAFE_RG\/SAFE_rg\/chap1.html\">Cisco SAFE<\/a><\/noindex> modeller, men selvf\u00f8lgelig er det ikke n\u00f8dvendigt at knytte sig specifikt til disse navne og denne model. Det er vigtigere at tale om essensen og ikke blive fanget i formaliteter.<\/p>\n<p>For hver af disse segmenter vil kravene til sikkerhedsniveau, risici og dermed l\u00f8sningerne variere.<\/p>\n<p>Lad os se p\u00e5 hver af dem enkeltvis med hensyn til de problemer, du kan st\u00f8de p\u00e5 i forhold til sikkerhedsdesign. Selvf\u00f8lgelig, som jeg gentager, g\u00f8r denne artikel ikke krav p\u00e5 at v\u00e6re udt\u00f8mmende, hvilket er sv\u00e6rt at opn\u00e5 i et s\u00e5 dybt og mangfoldigt emne (hvis det overhovedet er muligt), men den afspejler min personlige erfaring.<\/p>\n<p>Der findes ikke en perfekt l\u00f8sning (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\u00e5else for b\u00e5de dens fordele og ulemper.<\/p>\n<h2>Data Center<\/h2>\n<p>\nDet mest kritiske segment set fra et sikkerhedsperspektiv.<br \/>\nOg, som s\u00e6dvanligt, er der heller ikke en universel l\u00f8sning her. Det afh\u00e6nger meget af netv\u00e6rkets krav. <\/p>\n<h3>Er en firewall n\u00f8dvendig eller ej?<\/h3>\n<p>\nDet kan synes som om, svaret er indlysende, men det er ikke s\u00e5 entydigt, som det ser ud. Og dit valg kan p\u00e5virkes af mere end blot<b> pris<\/b>. <\/p>\n<blockquote><p>Eksempel 1. <b>Forsinkelser.<\/b><\/p>\n<p>Hvis lav forsinkelse mellem visse netv\u00e6rkssegmenter er et v\u00e6sentligt krav, som for eksempel g\u00e6lder for b\u00f8rser, kan vi ikke bruge firewalls mellem disse segmenter. Det er sv\u00e6rt at finde unders\u00f8gelser om forsinkelser i firewalls, men kun f\u00e5 modeller af switche kan levere forsinkelser p\u00e5 mindre end eller omkring 1 mksec, s\u00e5 jeg t\u00e6nker, at hvis mikrosekunder er vigtigt for dig, s\u00e5 er firewalls ikke det rette valg.<\/p><\/blockquote>\n<blockquote><p>Eksempel 2. <b>Ydeevne.<\/b><\/p>\n<p>B\u00e5ndbredden for de bedste L3-switche er som regel langt h\u00f8jere end b\u00e5ndbredden for de mest kraftfulde firewalls. Derfor, i tilf\u00e6lde af h\u00f8jintensiv trafik, vil du sandsynligvis ogs\u00e5 skulle sende den trafik uden om firewalls.<\/p><\/blockquote>\n<p><\/p>\n<blockquote><p>Eksempel 3. <b>P\u00e5lidelighed.<\/b><\/p>\n<p>Firewalls, is\u00e6r moderne NGFW (Next-Generation FW), er komplekse enheder. De er betydeligt mere komplekse end L3\/L2-switche. De tilbyder mange tjenester og konfigurationsmuligheder, s\u00e5 det er ikke overraskende, at deres p\u00e5lidelighed er betydeligt lavere. Hvis servicekontinuitet er afg\u00f8rende for netv\u00e6rket, skal du muligvis v\u00e6lge mellem, hvad der giver den bedste tilg\u00e6ngelighed \u2014 sikkerhed via en firewall eller en enkelnetv\u00e6rksopbygning baseret p\u00e5 switche (eller forskellige typer fabrikker) ved hj\u00e6lp af almindelige ACL.<\/p><\/blockquote>\n<p> I de n\u00e6vnte eksempler m\u00e5 du sandsynligvis (som s\u00e6dvanligt) finde et kompromis. Overvej f\u00f8lgende l\u00f8sninger: <\/p>\n<ul>\n<li>hvis du har besluttet ikke at bruge firewalls inden i datacentret, skal du overveje, hvordan du maksimalt kan begr\u00e6nse adgangen ved perimetret. For eksempel kan du kun \u00e5bne de n\u00f8dvendige porte fra internettet (til kundetrafik) og administrative adgangsoplysninger til datacentret kun fra jump hosts. Udf\u00f8r al n\u00f8dvendig kontrol (autentifikation\/autorisation, antivirus, logning, \u2026) p\u00e5 jump hosts.<\/li>\n<li>du kan bruge logisk opdeling af datacenterets netv\u00e6rk i segmenter, ligesom beskrevet i PSEFABRIC-skematikken. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/nihole\/PSEFABRIC\/wiki\/p002-design\">eksempel p002<\/a><\/noindex>Routing skal v\u00e6re konfigureret p\u00e5 en m\u00e5de, s\u00e5 trafik, der er f\u00f8lsom over for forsinkelser eller intensiv trafik, g\u00e5r \"indeni\" et segment (i tilf\u00e6lde af p002, VRF'en) og ikke g\u00e5r gennem firewall'en. Trafik mellem forskellige segmenter vil stadig g\u00e5 gennem firewall'en. Route leaking mellem VRF'er kan ogs\u00e5 bruges for at undg\u00e5 at omdirigere trafik gennem firewall'en.<\/li>\n<li>Det er ogs\u00e5 muligt at bruge firewall'en i transparent mode og kun for de VLAN'er, hvor disse faktorer (forsinkelse\/ydeevne) ikke er v\u00e6sentlige. Men det er vigtigt at unders\u00f8ge begr\u00e6nsningerne ved brug af denne mode for hver leverand\u00f8r.<\/li>\n<li>Du kan overveje at anvende en service chain arkitektur. Dette vil tillade at dirigere kun den n\u00f8dvendige trafik gennem firewall'en. Teoretisk set ser det godt ud, men jeg har aldrig set denne l\u00f8sning i produktion. Vi testede service chain for Cisco ACI\/Juniper SRX\/F5 LTM for omkring 3 \u00e5r siden, men p\u00e5 det tidspunkt syntes denne l\u00f8sning \"r\u00e5\".<\/li>\n<\/ul>\n<p><\/p>\n<h3>Sikkerhedsniveau<\/h3>\n<p>\nNu er sp\u00f8rgsm\u00e5let, hvilke v\u00e6rkt\u00f8jer du \u00f8nsker at anvende til trafikfiltrering. Her er nogle af de muligheder, der typisk er til stede i NGFW (for eksempel, <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.paloaltonetworks.com\/pan-os\/8-0\/pan-os-admin\/policy\/security-profiles.html\">her<\/a><\/noindex>):<\/p>\n<ul>\n<li>stateful firewalling (som standard)<\/li>\n<li>applikationsfirewalling<\/li>\n<li>trusselssikring (antivirus, antispyware og s\u00e5rbarhed)<\/li>\n<li>URL-filtrering<\/li>\n<li>datafiltrering (indholdsfiltrering)<\/li>\n<li>filblokering (blokering af filtyper)<\/li>\n<li>dos protection<\/li>\n<\/ul>\n<p>\nOg heller ikke alt er entydigt. Det ville umiddelbart se ud til, at jo h\u00f8jere beskyttelsesniveau, desto bedre. Men du skal ogs\u00e5 tage h\u00f8jde for, at<\/p>\n<ul>\n<li>jo flere af de ovenn\u00e6vnte firewall-funktioner du bruger, desto dyrere vil det naturligvis blive (licenser, ekstra moduler).<\/li>\n<li>Brug af nogle algoritmer kan betydeligt s\u00e6nke firewall'ens b\u00e5ndbredde og ogs\u00e5 \u00f8ge forsinkelserne, se for eksempel. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.paloaltonetworks.com\/products\/secure-the-network\/next-generation-firewall\/pa-7000-series\">her<\/a><\/noindex><\/li>\n<li>Som med enhver kompleks l\u00f8sning kan brug af komplekse beskyttelsesmetoder mindske p\u00e5lideligheden af din l\u00f8sning, for eksempel n\u00e5r jeg har brugt application firewalling, har jeg st\u00f8dt p\u00e5 blokering af nogle helt almindelige funktionerende applikationer (dns, smb).<\/li>\n<\/ul>\n<p>\nSom s\u00e6dvanlig skal du finde den optimale l\u00f8sning til dit netv\u00e6rk.<\/p>\n<p>Det er umuligt entydigt at svare p\u00e5, hvilke beskyttelsesfunktioner der kan v\u00e6re n\u00f8dvendige. For det f\u00f8rste, fordi det selvf\u00f8lgelig afh\u00e6nger af de data, du overf\u00f8rer eller opbevarer og fors\u00f8ger at beskytte. For det andet, i virkeligheden er valget af beskyttelsesmidler ofte et sp\u00f8rgsm\u00e5l om tro og tillid til leverand\u00f8ren. Du kender ikke algoritmerne, du ved ikke, hvor effektive de er, og du kan ikke teste dem grundigt. <\/p>\n<p>Derfor kan det i kritiske segmenter v\u00e6re en god l\u00f8sning at bruge tilbud fra forskellige virksomheder. For eksempel kan du aktivere antivirus p\u00e5 firewallen, men samtidig bruge antivirusbeskyttelse (fra en anden leverand\u00f8r) lokalt p\u00e5 v\u00e6rterne.<\/p>\n<h3>Segmentering<\/h3>\n<p>\nDet handler om den logiske segmentering af datacentret. For eksempel er opdeling i VLAN'er og subnets ogs\u00e5 en form for logisk segmentering, men vi vil ikke se n\u00e6rmere p\u00e5 det, da det er indlysende. Interessant er segmenteringen med hensyn til entiteter som FW sikkerhedszoner, VRF (og deres \u00e6kvivalenter for forskellige leverand\u00f8rer), logiske enheder (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, \u2026), \u2026<\/p>\n<blockquote><p>Et eksempel p\u00e5 en s\u00e5dan logisk segmentering og en eftertragtet datacenterdesign findes i <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/nihole\/PSEFABRIC\/wiki\/p002-design\">p002 i projektet PSEFABRIC<\/a><\/noindex>.<\/p><\/blockquote>\n<p> N\u00e5r du har defineret de logiske dele af dit netv\u00e6rk, kan du beskrive, hvordan trafikken bev\u00e6ger sig mellem de forskellige segmenter, hvilke enheder der vil udf\u00f8re filtreringen, og med hvilke midler.<\/p>\n<p>Hvis dit netv\u00e6rk ikke har en klar logisk opdeling, og der ikke er formaliserede regler for anvendelse af sikkerhedspolitikker for forskellige datastreams (flow), betyder det, at n\u00e5r du giver adgang til noget, skal du tage stilling til denne opgave, og med stor sandsynlighed vil du l\u00f8se den forskelligt hver gang. <\/p>\n<p>Segmentering er ofte kun baseret p\u00e5 FW sikkerhedszoner. Derfor skal du besvare f\u00f8lgende sp\u00f8rgsm\u00e5l:<\/p>\n<ul>\n<li>hvilke sikkerhedszoner du har brug for<\/li>\n<li>hvilket sikkerhedsniveau du \u00f8nsker at anvende p\u00e5 hver af disse zoner <\/li>\n<li>om intra-zone trafik skal v\u00e6re tilladt som standard <\/li>\n<li>hvis ikke, hvilke trafikfiltreringspolitikker der vil blive anvendt inden for hver af zonerne<\/li>\n<li>hvilke trafikfiltreringspolitikker der vil blive anvendt for hvert par zoner (source\/destination)<\/li>\n<\/ul>\n<p><\/p>\n<h3>TCAM<\/h3>\n<p>\nEt almindeligt problem er utilstr\u00e6kkelig TCAM (Ternary Content Addressable Memory), b\u00e5de til routing og adgang. IMHO er dette et af de vigtigste sp\u00f8rgsm\u00e5l ved valg af udstyr, s\u00e5 det er vigtigt at tage dette sp\u00f8rgsm\u00e5l alvorligt.<\/p>\n<blockquote><p>Eksempel 1. Forwarding Table TCAM.<\/p>\n<p>Lad os se p\u00e5 <noindex>Palo Alto 7k<\/noindex> firewallen.<br \/>\nVi ser, at IPv4 forwarding table size* = 32K<br \/>\nDette antal ruter er dog samlet for alle VSYS'er.<\/p>\n<p>Antag, at du har besluttet at bruge 4 VSYS'er i henhold til dit design.<br \/>\nHver af disse VSYS'er er tilsluttet via BGP til to PE MPLS-skyer, som du bruger som BB. P\u00e5 denne m\u00e5de udveksler 4 VSYS'er alle specifikke ruter med hinanden og har en forwarding-tabel med omtrent de samme s\u00e6t 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\u00e6re mere end 32K\/(4 * 2) = 4K. <\/p>\n<p>Nu, hvis vi antager, at vi har 2 datacentre (med samme design), og vi \u00f8nsker at bruge VLAN'er, \"strakt\" mellem datacentrene (f.eks. til vMotion), skal vi for at l\u00f8se routingsproblemet bruge v\u00e6rtsruter. Men det betyder, at vi for 2 datacentre kun har maksimalt 4096 mulige v\u00e6rter, og det kan selvf\u00f8lgelig v\u00e6re utilstr\u00e6kkeligt.<\/p><\/blockquote>\n<blockquote><p>Eksempel 2. ACL TCAM.<\/p>\n<p>Hvis du planl\u00e6gger at filtrere trafik p\u00e5 L3-switches (eller andre l\u00f8sninger, der bruger L3-switches, som f.eks. Cisco ACI), skal du ved valg af udstyr v\u00e6re opm\u00e6rksom p\u00e5 ACL TCAM.<\/p>\n<p>Antag, at du \u00f8nsker at kontrollere adgang p\u00e5 SVI-interfacet p\u00e5 Cisco Catalyst 4500. S\u00e5 kan du, som det fremg\u00e5r af <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/en\/us\/support\/docs\/switches\/catalyst-4000-series-switches\/66978-tcam-cat-4500.html\">denne artikel<\/a><\/noindex>, kun bruge 4096 r\u00e6kker TCAM til at kontrollere udg\u00e5ende (s\u00e5vel som indg\u00e5ende) trafik p\u00e5 interface. Hvilket ved brug af TCAM3 giver dig omkring 4000 ACE (r\u00e6kker ACL).<\/p><\/blockquote>\n<p> Hvis du st\u00e5r over for problemet med utilstr\u00e6kkelig TCAM, skal du f\u00f8rst og fremmest overveje muligheden for optimering. S\u00e5, i tilf\u00e6lde af problemer med st\u00f8rrelsen af forwarding-tabellen, skal du overveje at aggregere ruter. I tilf\u00e6lde af problemer med st\u00f8rrelsen af TCAM til adgang \u2014 audit af adgang, sletning af for\u00e6ldede og overlappende poster, samt muligvis en gennemgang af proceduren for adgangs\u00e5bning (vil blive behandlet detaljeret i kapitlet, der handler om adgangsaudit).<\/p>\n<h3>H\u00f8j tilg\u00e6ngelighed<\/h3>\n<p>\nSp\u00f8rgsm\u00e5let er, om man skal bruge HA til firewalls eller s\u00e6tte to uafh\u00e6ngige enheder \"parallelt\" og i tilf\u00e6lde af nedbrud af en af dem rute trafikken gennem den anden?<\/p>\n<p>Det ville synes, at svaret er \u00e5benlyst \u2013 at bruge HA. \u00c5rsagen til, at dette sp\u00f8rgsm\u00e5l opst\u00e5r, ligger desv\u00e6rre i, at de teoretiske og reklamerede 99 og et par neuner efter kommaet p\u00e5 praktisk niveau ikke er s\u00e5 rosenr\u00f8de. HA er en logisk kompleks st\u00f8rrelse, og p\u00e5 forskelligt udstyr og med forskellige leverand\u00f8rer (uden undtagelser) har vi fanget problemer, fejl og serviceafbrydelser.<\/p>\n<p>Ved brug af HA f\u00e5r 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\u00e5 samme tid, samt at en opgradering ikke forl\u00f8ber s\u00e5 glat, som leverand\u00f8ren lover (dette problem kan undg\u00e5s, hvis du har mulighed for at teste opgraderingen p\u00e5 laboratorieudstyr).<\/p>\n<p>Hvis du ikke bruger HA, s\u00e5 i forhold til dobbeltfejl er dine risici betydeligt lavere (da du har 2 uafh\u00e6ngige firewalls), men da sessionerne ikke er synkroniserede, s\u00e5 hver gang der skiftes mellem disse firewalls, vil du miste trafik. Man kan selvf\u00f8lgelig bruge stateless firewalling, men s\u00e5 mindskes form\u00e5let med at bruge firewall i h\u00f8j grad.<\/p>\n<p>Derfor, hvis du i forbindelse med en revision opdager ensomme firewalls, og du overvejer at \u00f8ge p\u00e5lideligheden af dit netv\u00e6rk, s\u00e5 er HA naturligvis en af de anbefalede l\u00f8sninger, men du skal ogs\u00e5 tage h\u00f8jde for ulemperne forbundet med denne tilgang, og m\u00e5ske vil en anden l\u00f8sning v\u00e6re mere passende for dit netv\u00e6rk.<\/p>\n<h3>Brugervenlighed i administration (managability)<\/h3>\n<p>\nHA handler ogs\u00e5 om administrerbarhed. I stedet for at konfigurere 2 enheder separat og l\u00f8se problemet med synkronisering af konfigurationer, administrerer du dem i h\u00f8j grad som om du har \u00e9n enhed. <\/p>\n<p>Men m\u00e5ske har du mange datacentre og mange firewalls; s\u00e5 bliver dette sp\u00f8rgsm\u00e5l aktuelt p\u00e5 et nyt niveau. Og sp\u00f8rgsm\u00e5let handler ikke kun om konfiguration, men ogs\u00e5 om<\/p>\n<ul>\n<li>backup af konfigurationer<\/li>\n<li>opdateringer<\/li>\n<li>opgraderinger<\/li>\n<li>overv\u00e5gning<\/li>\n<li>logning<\/li>\n<\/ul>\n<p>\nOg alt dette kan l\u00f8ses med centraliserede managementsystemer. <\/p>\n<blockquote><p>For eksempel, hvis du bruger Palo Alto firewalls, s\u00e5 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.paloaltonetworks.com\/products\/management\/panorama\">Panorama<\/a><\/noindex> er en s\u00e5dan l\u00f8sning.\n<\/p><\/blockquote>\n<p>\n<i>Forts\u00e6ttes.<\/i><br \/>\n<br \/>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/435138\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0442\u0440\u0435\u0442\u044c\u0435\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb. \u0421\u043e\u0434\u0435\u0440\u0436\u0430\u043d\u0438\u0435 \u0432\u0441\u0435\u0445 \u0441\u0442\u0430\u0442\u0435\u0439 \u0446\u0438\u043a\u043b\u0430 \u0438 \u0441\u0441\u044b\u043b\u043a\u0438 \u043c\u043e\u0436\u043d\u043e \u043d\u0430\u0439\u0442\u0438 \u0437\u0434\u0435\u0441\u044c. \u041d\u0435\u0442 \u0441\u043c\u044b\u0441\u043b\u0430 \u0433\u043e\u0432\u043e\u0440\u0438\u0442\u044c \u043e \u043f\u043e\u043b\u043d\u043e\u043c \u0443\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u0438\u0438 security \u0440\u0438\u0441\u043a\u043e\u0432. \u041c\u044b \u0432 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u0435 \u043d\u0435 \u043c\u043e\u0436\u0435\u043c \u0441\u043d\u0438\u0437\u0438\u0442\u044c \u0438\u0445 \u0434\u043e \u043d\u0443\u043b\u044f. \u0422\u0430\u043a\u0436\u0435 \u043d\u0443\u0436\u043d\u043e \u043f\u043e\u043d\u0438\u043c\u0430\u0442\u044c, \u0447\u0442\u043e \u043f\u0440\u0438 \u0441\u0442\u0440\u0435\u043c\u043b\u0435\u043d\u0438\u0438 \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0441\u0435\u0442\u044c \u0431\u043e\u043b\u0435\u0435 \u0438 \u0431\u043e\u043b\u0435\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0439 \u043d\u0430\u0448\u0438 \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0441\u0442\u0430\u043d\u043e\u0432\u044f\u0442\u0441\u044f [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":23033,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-31058","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0442\u0440\u0435\u0442\u044c\u0435\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-tretya-setevaya-bezopasnost-chast-pervaya\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c. \u0413\u043b\u0430\u0432\u0430 \u0442\u0440\u0435\u0442\u044c\u044f. \u0421\u0435\u0442\u0435\u0432\u0430\u044f \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c. \u0427\u0430\u0441\u0442\u044c \u043f\u0435\u0440\u0432\u0430\u044f | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0442\u0440\u0435\u0442\u044c\u0435\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-tretya-setevaya-bezopasnost-chast-pervaya\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:39:12+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:39:12+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47S\u00e5dan f\u00e5r du kontrol over dit netv\u00e6rksinfrastruktur. Kapitel tre. Netv\u00e6rkssikkerhed. Del \u00e9n | ProHoster","description":"Denne artikel er den tredje i r\u00e6kken af artikler \"S\u00e5dan f\u00e5r du kontrol over dit netv\u00e6rksinfrastruktur\".","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-tretya-setevaya-bezopasnost-chast-pervaya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c. \u0413\u043b\u0430\u0432\u0430 \u0442\u0440\u0435\u0442\u044c\u044f. \u0421\u0435\u0442\u0435\u0432\u0430\u044f \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c. \u0427\u0430\u0441\u0442\u044c \u043f\u0435\u0440\u0432\u0430\u044f | ProHoster","og:description":"\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0442\u0440\u0435\u0442\u044c\u0435\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-tretya-setevaya-bezopasnost-chast-pervaya","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:39:12+00:00","article:modified_time":"2019-10-31T18:39:12+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"31058","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 04:20:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:24:14","updated":"2026-01-21 04:20:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/31058","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=31058"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/31058\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/23033"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=31058"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=31058"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=31058"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}