Hvad er en DMZ i netværk?

DMZ dukker op uden en definition vedhæftet. En linje på en sikkerhedstjekliste, en sætning i en leverandørs hærdningsdokument, et krav i et jobopslag placeret ved siden af TLS og least privilege.

Du slår det op og finder et diagram over en firewall med tre netværkskabler. Et går til internettet, et til en række servere, et til et kontor-LAN. Det, du administrerer, er én lejet server med én offentlig IP og ingen ekstra netværksinterfaces overhovedet.

Det første billede er en ægte DMZ-arkitektur. På én server kan du gengive en del af dens sikkerhedsmål: at begrænse, hvad internettet kan nå. Det, du ikke kan gengive på samme host, er den separate netværksgrænse, der gør en DMZ til en DMZ.

Den korte version

• En DMZ adskiller de tjenester, fremmede skal kunne nå, fra resten af det, du kører.
• Det handlede aldrig om kablingen: det handlede om, at et kompromitteret system på den offentlige side skulle stoppe dér.
• Du kan konfigurere en firewall og alligevel ikke have en DMZ.
• Én server med én offentlig IP kan reducere eksponeringen med en reverse proxy, host-firewallregler og private eller loopback-bindinger, men den skaber ikke et separat DMZ-segment.
• Den version deler kerne med det, den beskytter, så regn den som reduceret eksponering og ikke som isolation.

Hvad denne artikel ikke dækker

Omfanget her er den mentale model, og tre tilstødende emner er bevidst ladt i fred.

• Ingen opsætningstrin. Der er ingen reverse proxy-konfiguration, ingen syntaks for firewallregler og ingen anbefaling af, hvilket værktøj du skal installere.
• Ingen konfiguration af forbrugerroutere. Indstillingen "DMZ host" på en hjemmerouter betegner noget helt andet.
• Ingen dom over zero trust. Om netværksperimeteret stadig er den rigtige primære kontrol er en reel diskussion, og den afgøres ikke her.

Hvad er en DMZ, og hvad skal den bruges til?

En DMZ, eller demilitariseret zone, er et netværkssegment, der ligger mellem det utroværdige internet og et internt netværk. Den rummer de tjenester, der skal kunne nås offentligt, såsom webservere og mailservere. Alt andet bliver bag en anden grænse, så det at nå den offentlige tjeneste ikke er det samme som at nå resten.

Mozillas ordlisteopslag om DMZ samler den virksomme halvdel af det i én sætning: den blotlægger kun bestemte definerede endepunkter, mens den nægter adgang til det interne netværk udefra. Det er hele designmålet, formuleret uden henvisning til noget udstyr.

De typer tjenester, der klassisk bor der, følger af målet. Webservere, mailservere, FTP-servere, VoIP-servere: ting, som fremmede skal kunne forbinde til. Directory-servere, databaser, fildelinger, interne applikationer og administrationsgrænseflader står ikke på den liste, for ingen udefra skal kunne nå dem.

Hold fast i egenskaben frem for billedet. Tre netværksinterfaces er én måde at skabe en separat tillidsgrænse på. Cloud- og enkeltserverdesign kan anvende det samme princip om eksponeringskontrol på andre måder, men kun design med en selvstændig perimeterzone gengiver selve DMZ'en.

Hvordan fungerer den klassiske DMZ med tre interfaces?

Den klassiske DMZ bygges på to måder. Et design med én firewall giver den ene firewall tre interfaces, ét til internettet, ét til DMZ'en og ét til det interne netværk. Et design med to firewalls placerer DMZ'en mellem to separate firewalls. Begge håndhæver den samme regel. Internettet når DMZ'en. Internettet når aldrig det interne netværk.

Modellen med én firewall (three-legged)

Én firewall, tre netværksinterfaces. Det første vender mod internettet. Det andet vender mod DMZ'en, hvor de offentlige tjenester bor. Det tredje vender mod det interne netværk. Firewallen tillader indgående trafik fra internettet til bestemte porte i DMZ'en, tillader snæver trafik fra DMZ'en og indad, hvor en applikation kræver det, og afviser alt andet.

Navnet på denne form er three-legged firewall. Hver pakke, der krydser mellem zoner, går gennem én enhed, hvilket gør den firewall til et single point of failure for trafik mellem zoner. Hvis den fejler, påvirkes forbindelse og håndhævelse af politikker afhængigt af firewallens fejltilstand og den redundans, du har på plads.

Jeg brugte et årti på at køre netværksdrift hos en ISP, og det, der overraskede folk ved et DMZ-interface, var, hvor uspektakulært det var. En helt almindelig ethernetport med et andet tillidsmærkat hæftet på i firewallens konfiguration. Arkitekturen lå ikke i kobberet. Den lå i regelsættet, og i at nogen havde tænkt grundigt over, hvilken retning hvert flow måtte gå.

Modellen med to firewalls (ryg mod ryg)

To firewalls i serie med DMZ'en imellem. Den ydre firewall lukker internettrafik ind i DMZ'en og ikke længere. Den indre lukker kun den specifikke trafik fra DMZ'en og indad, som en applikation har brug for. En angriber, der når DMZ'en, skal stadig krydse den indre firewalls politikgrænse, før han når det interne netværk.

To firewalls giver dig to separat håndhævede politikgrænser, men de tilføjer også konfiguration, patching og driftsmæssig kompleksitet. En fejl eller et kompromittering af den ydre grænse fjerner ikke automatisk den indre, selvom beskyttelsen stadig afhænger af, hvordan de to firewalls er konfigureret og drevet.

Er en DMZ det samme som en firewall?

Nej. En DMZ er et separat perimeternetværk eller netværkssegment. En firewall er en almindelig kontrol, der bruges til at styre trafikken mellem den zone, internettet og det interne netværk. Du kan konfigurere firewallregler på et fladt netværk uden at skabe en DMZ, så forskellen er arkitektonisk og ikke blot et spørgsmål om konfiguration.

Forvekslingen er forståelig. Firewallen er den genstand, man logger ind på, tingen med en konfigurationsfil, en leverandør og en supportaftale, så den opsamler navnet på det, den frembringer. Ingen logger nogensinde ind på et segment.

Konsekvensen viser sig på det værst tænkelige tidspunkt. Gå ud fra, at din offentlige webserver er kompromitteret, for det bliver den før eller siden. På et fladt netværk har angriberen nu fodfæste på en maskine, der allerede må tale med din database, din filserver og dine administrationsgrænseflader, og at bevæge sig mellem dem er bare at bruge adgang, der allerede var tilladt. Den sidelæns rejse hedder lateral bevægelse, og det er præcis det, den anden grænse findes for at stoppe. DMZ'en forhindrer ikke, at webserveren bliver kompromitteret. Den forhindrer, at en kompromitteret webserver bliver til adgang til alt andet.

En præcisering, mens begrebet er fremme: indstillingen "DMZ host" på en hjemme- eller småkontorrouter er en anden funktion. Den videresender uopfordret indgående trafik til én intern enhed og udsætter den enhed direkte for internettet; den skaber ikke et separat, beskyttet DMZ-netværk.

Hvordan anvender du DMZ-principper på én server?

Én server med én offentlig IP kan gengive en del af DMZ'ens mål om eksponeringskontrol uden at gengive dens netværksadskillelse. En reverse proxy kan blive det eneste offentlige indgangspunkt, indgående firewallregler med default deny kan blokere resten, og interne tjenester kan lytte på loopback eller et privat interface i stedet for på den offentlige adresse.

Start med den begrænsning, dette afsnit forudsætter: én VPS, ét offentligt interface og ingen separat firewall-appliance og intet DMZ-subnet, du selv styrer. I den opsætning kan du ikke gengive den klassiske three-legged-topologi på samme host. Host-firewallregler, valget af hvor tjenesterne lytter, og en reverse proxy kan stadig reducere eksponeringen, men de skaber ikke den samme isolationsgrænse.

En reverse proxy kan optage det offentlige interface på port 80 og 443 og blive det eneste indgangspunkt på applikationsniveau for webtrafik. Det indsnævrer den offentlige angrebsflade, men svarer ikke til et separat DMZ-interface, for proxyen deler stadig host med tjenesterne bag den.

De indgående firewallregler på hosten tillader de to porte og smider resten væk. Enhver anden tjeneste på maskinen må gerne køre og lytte, men intet udefra kan starte en forbindelse til den. Det nærmer sig politikken "kun de tilsigtede porte er tilgængelige" på én host; det skaber ikke en separat grænse mod det interne netværk.

Applikationsservere, databaser og adminpaneler bør ikke lytte på den offentlige adresse. Når proxyen kører på samme host, kan de lytte på loopback; når den kører et andet sted på det private netværk, kan de lytte på en privat adresse. I begge tilfælde er der ingen lytter for de tjenester på det offentlige interface, så det at åbne en indgående regel på netop det interface eksponerer dem ikke.

Administrativ adgang hører til på den interne side, ikke på DMZ-siden. At holde SSH og administrationsgrænseflader ude af den offentlige sti, bag en VPN eller et privat netværk, forhindrer direkte forbindelser til dem fra det offentlige internet.

LÆS

Sådan sikrer du Linux VPS | 20 måder at sikre din VPS-server på

Hvordan oversættes DMZ-begreber til VPC-subnet og security groups?

Den klassiske model har en ret tæt begrebsmæssig oversættelse til cloudens netværksprimitiver, men ikke én til én. Et DMZ-segment bliver til et offentligt subnet. Det interne netværk bliver til et privat subnet uden rute til en internetgateway. Firewallens regelsæt fordeler sig over security groups, der er knyttet til ressourcernes netværksinterfaces, og netværks-ACL'er, der er knyttet til subnet.

Cloududbyderne bruger selv dette ordforråd, hvilket er et godt bevis på, at begrebet stadig er aktuelt. AWS' netværksblog beskriver en DMZ-arkitektur på Amazon VPC som isolerer offentligt tilgængelige tjenester fra interne netværk og er bygget på VPC Block Public Access, en kontrol på Region-niveau lanceret i november 2024.

Subnettene er den bærende del af denne oversættelse. Et offentligt subnet er offentligt, fordi dets routingtabel peger på en internetgateway. Eftersom routingtabeller bestemmer, hvor pakker rejser hen, former subnetlayoutet din eksponering, før nogen enkeltregel gør det.

Oversættelsen halter på ét bestemt punkt. Et firewallinterface håndhævede en grænse for et helt segment; en security group er derimod knyttet til en ressources netværksinterface. To maskiner i samme private subnet kan bære helt forskellige security groups, så håndhævelsen lander i en finere granularitet, end et fysisk interface nogensinde nåede. Det er som regel en forbedring. Det betyder også, at et subnets navn fortæller dig mindre om, hvad der kan nås, end et netværksdiagram gjorde før i tiden.

Hvor enkeltserverversionen kommer til kort

På én host deler den offentligt eksponerede proces og de interne tjenester kerne og maskine. Separate segmenter tvinger en angriber over en netværksgrænse, som en firewall inspicerer; én host gør ikke. Enkeltservermønsteret reducerer eksponeringen. Det gengiver ikke adskillelse.

Hvis reverse proxyen kompromitteres på en måde, der giver angriberen kodeudførelse, kører den kode allerede på den maskine, hvor din database kører. At lytte på loopback hjælper ikke da, for loopback kan nås fra selve hosten. Container- eller brugerisolation kan hæve den nødvendige indsats, men containere på samme host deler stadig hostens kerne. I den klassiske model var angriberens næste skridt en pakke over et kabel, som noget inspicerede. Her er det en lokal socket.

Den praktiske konsekvens er en tærskel, ikke en dom. Når det, der står bag proxyen, er mere værd end besværet med en maskine nummer to, så tag en maskine nummer to og et privat netværk imellem dem. Intet i denne artikel skal læres om for at gøre det, for intet af det handlede nogensinde om hardwaren.

Perimeteret er ikke længere det eneste sted, hvor sikkerhedspolitik kan håndhæves. Zero trust-arkitektur fjerner implicit tillid baseret på netværksplacering, mens privat konnektivitet bygget med WireGuard eller Tailscale kan reducere den offentlige eksponering. Ingen af de to tilgange erstatter automatisk segmentering eller autorisation. Min holdning til det snævrere spørgsmål er klar. Som mental model: sortér det, der kan nås, fra det, der ikke kan, og vid, hvilken grænse der indeslutter et kompromittering. Det spørgsmål overlever enhver arkitektur nævnt ovenfor, og netop derfor er det stadig værd at besvare.

Ofte stillede spørgsmål

Er en DMZ det samme som en VPN?

Nej. De løser forskellige problemer. En DMZ styrer, hvad utroværdige udefrakommende kan nå, ved kun at blotlægge et lille sæt tjenester og intet andet. En VPN giver betroede udefrakommende en privat vej ind ved at autentificere dem ind på et netværk, de ellers ikke ville nå. Mange netværk kører begge dele, og ingen af dem erstatter den anden.

Er en DMZ sikker?

En DMZ gør ikke en eksponeret tjeneste sikker. Den begrænser, hvor langt kompromitteringen af den tjeneste rækker. Den offentligt tilgængelige tjeneste er stadig offentligt tilgængelig, stadig udsat for alle på internettet, og har stadig brug for patching, overvågning og hærdning på egne præmisser. DMZ'en afgør, hvad der sker efter den falder, ikke om den falder.

Har jeg brug for en DMZ, hvis jeg kun har én server?

Ikke i klassisk forstand, og du ville alligevel ikke kunne bygge en på én host. Topologien med tre interfaces kræver separate netværkssegmenter, og en server med én offentlig IP har ingen. Det, du kan gøre, er at styre eksponeringen: gør en reverse proxy til det eneste offentlige indgangspunkt, afvis som udgangspunkt de øvrige indgående porte, og lad interne tjenester lytte på loopback eller en privat adresse. Det reducerer, hvad internettet kan nå, uden at isolere den offentlige tjeneste fra resten af hosten. Når det, der står bag proxyen, er mere værd end prisen på en maskine nummer to, så brug to maskiner og et privat netværk imellem dem.

Hvorfor hedder det en demilitariseret zone?

Begrebet er lånt fra den militære betydning af et bufferområde mellem to modstående styrker, hvor ingen af dem har fuld kontrol. Netværksbrugen fastholder metaforen: DMZ'en tilhører hverken helt det utroværdige ydre eller det betroede indre.