Wat is een DMZ in netwerken?

DMZ komt zonder definitie aanwaaien. Een regel op een security-checklist, een zin in het hardeningsdocument van een leverancier, een eis in een vacature die naast TLS en least privilege staat.

Je zoekt het op en vindt een schema van een firewall met drie netwerkkabels. Eén gaat naar het internet, één naar een rij servers, één naar een kantoor-LAN. Wat jij beheert is één gehuurde server met één publiek IP en geen enkele reserve-netwerkinterface.

Het eerste plaatje is een echte DMZ-architectuur. Op één server kun je een deel van het beveiligingsdoel nabootsen: beperken wat het internet kan bereiken. Wat je op diezelfde host niet kunt nabootsen, is de aparte netwerkgrens die een DMZ tot een DMZ maakt.

De korte versie

• Een DMZ scheidt de diensten die vreemden moeten kunnen bereiken van de rest van wat je draait.
• Het ging nooit om de bekabeling: het ging erom dat een compromittering aan de publieke kant daar zou stoppen.
• Je kunt een firewall configureren en toch geen DMZ hebben.
• Eén server met één publiek IP kan de blootstelling verkleinen met een reverse proxy, host-firewallregels en private of loopback-bindings, maar creëert daarmee geen apart DMZ-segment.
• Die variant deelt een kernel met wat hij beschermt, dus tel hem als verminderde blootstelling en niet als isolatie.

Wat dit artikel niet behandelt

De scope hier is het mentale model, en drie aangrenzende onderwerpen blijven bewust buiten beschouwing.

• Geen bouwstappen. Er staat hier geen reverse-proxyconfiguratie, geen syntaxis van firewallregels en geen aanbeveling over welke tool je moet installeren.
• Geen configuratie van consumentenrouters. De optie "DMZ host" op een thuisrouter duidt iets heel anders aan.
• Geen oordeel over zero trust. Of de netwerkperimeter nog steeds de juiste primaire controle is, is een echt debat, en dat wordt hier niet beslecht.

Wat is een DMZ, en waar dient hij voor?

Een DMZ, oftewel gedemilitariseerde zone, is een netwerksegment tussen het onvertrouwde internet en een intern netwerk. Daar staan de diensten die publiek bereikbaar moeten zijn, zoals webservers en mailservers. Al het andere blijft achter een tweede grens, waardoor het bereiken van de publieke dienst niet betekent dat je de rest bereikt.

Het woordenlijst-item van Mozilla over de DMZ vat de werkzame helft daarvan in één bijzin samen: hij stelt alleen bepaalde gedefinieerde endpoints beschikbaar en weigert tegelijk toegang tot het interne netwerk van buitenaf. Dat is het hele ontwerpdoel, geformuleerd zonder verwijzing naar welke apparatuur dan ook.

De typen diensten die daar klassiek staan, volgen uit het doel. Webservers, mailservers, FTP-servers, VoIP-servers: dingen waarmee vreemden verbinding horen te kunnen maken. Directoryservers, databases, bestandsshares, interne applicaties en beheerinterfaces staan niet op die lijst, want niemand van buiten hoort ze te bereiken.

Onthoud de eigenschap, niet het plaatje. Drie netwerkinterfaces zijn één manier om een aparte vertrouwensgrens te maken. Cloud- en single-serverontwerpen kunnen hetzelfde principe van blootstellingsbeheersing anders toepassen, maar alleen ontwerpen met een afzonderlijke perimeterzone bootsen de DMZ zelf na.

Hoe werkt de klassieke DMZ met drie interfaces?

De klassieke DMZ wordt op twee manieren gebouwd. Een ontwerp met één firewall geeft die firewall drie interfaces, één naar het internet, één naar de DMZ en één naar het interne netwerk. Een ontwerp met twee firewalls plaatst de DMZ tussen twee afzonderlijke firewalls. Beide handhaven dezelfde regel. Het internet bereikt de DMZ. Het internet bereikt nooit het interne netwerk.

Het model met één firewall (three-legged)

Eén firewall, drie netwerkinterfaces. De eerste kijkt naar het internet. De tweede kijkt naar de DMZ, waar de publieke diensten wonen. De derde kijkt naar het interne netwerk. De firewall staat inkomend verkeer vanaf internet toe naar specifieke poorten in de DMZ, staat smal verkeer van de DMZ naar binnen toe waar een applicatie dat vereist, en weigert al het andere.

De naam voor deze vorm is de three-legged firewall. Elk pakket dat tussen zones oversteekt gaat door één apparaat, waardoor die firewall een single point of failure wordt voor verkeer tussen zones. Valt hij uit, dan worden connectiviteit en beleidshandhaving geraakt, afhankelijk van het faalgedrag van de firewall en de redundantie die je hebt ingericht.

Ik heb tien jaar lang netwerkoperaties gedraaid bij een ISP, en wat mensen verbaasde aan een DMZ-interface was hoe onopvallend die was. Een gewone ethernetpoort met een ander vertrouwenslabel eraan gehangen in de firewallconfiguratie. De architectuur zat niet in het koper. Die zat in de regelset, en in het feit dat iemand goed had nagedacht over welke richting elke stroom mocht gaan.

Het model met twee firewalls (rug aan rug)

Twee firewalls in serie, met de DMZ ertussen. De externe firewall laat internetverkeer de DMZ in en niet verder. De interne laat alleen het specifieke verkeer van de DMZ naar binnen toe dat een applicatie nodig heeft. Een aanvaller die de DMZ bereikt, moet nog altijd de beleidsgrens van de interne firewall over voordat hij het interne netwerk bereikt.

Twee firewalls geven je twee apart gehandhaafde beleidsgrenzen, maar ze brengen ook configuratie, patchwerk en operationele complexiteit met zich mee. Een storing of compromittering van de buitenste grens haalt de binnenste niet automatisch weg, al blijft de bescherming afhangen van hoe beide firewalls zijn ingericht en beheerd.

Is een DMZ hetzelfde als een firewall?

Nee. Een DMZ is een apart perimeternetwerk of netwerksegment. Een firewall is een veelgebruikte maatregel om het verkeer tussen die zone, het internet en het interne netwerk te regelen. Je kunt firewallregels instellen op een plat netwerk zonder een DMZ te maken, dus het onderscheid is architectonisch en niet louter een kwestie van configuratie.

De verwarring is begrijpelijk. De firewall is het object waarop je inlogt, het ding met een configuratiebestand, een leverancier en een supportcontract, dus verzamelt het de naam van wat het voortbrengt. Op een segment logt nooit iemand in.

Het gevolg laat zich op het slechtst denkbare moment zien. Ga ervan uit dat je publieke webserver gecompromitteerd is, want dat gebeurt uiteindelijk. Op een plat netwerk heeft de aanvaller nu een steunpunt op een machine die al mag praten met je database, je fileserver en je beheerinterfaces, en daartussen bewegen is simpelweg toegang gebruiken die al was toegestaan. Dat zijwaarts reizen heet laterale beweging, en daarvoor bestaat die tweede grens. De DMZ voorkomt niet dat de webserver gecompromitteerd raakt. Ze voorkomt dat een gecompromitteerde webserver toegang tot al het andere wordt.

Eén verduidelijking nu de term toch voor je ligt: de instelling "DMZ host" op een thuis- of kleinzakelijke router is een andere functie. Die stuurt ongevraagd inkomend verkeer door naar één intern apparaat en stelt dat apparaat rechtstreeks bloot aan het internet; er ontstaat geen apart, beschermd DMZ-netwerk.

Hoe pas je DMZ-principes toe op één server?

Eén server met één publiek IP kan een deel van het blootstellingsdoel van een DMZ nabootsen, zonder de netwerkscheiding ervan na te bootsen. Een reverse proxy kan het enige publieke toegangspunt worden, inkomende firewallregels met standaard weigeren kunnen de rest blokkeren, en interne diensten kunnen luisteren op loopback of een privé-interface in plaats van op het publieke adres.

Begin met de randvoorwaarde die deze paragraaf aanneemt: één VPS, één publieke interface en geen aparte firewall-appliance en geen DMZ-subnet onder jouw beheer. In die opzet kun je de klassieke three-legged topologie niet op dezelfde host nabouwen. Host-firewallregels, de keuze waarop diensten luisteren en een reverse proxy kunnen de blootstelling nog steeds verkleinen, maar ze creëren niet dezelfde isolatiegrens.

Een reverse proxy kan de publieke interface bezetten op poort 80 en 443 en het enige toegangspunt op applicatieniveau worden voor webverkeer. Dat versmalt het publieke aanvalsoppervlak, maar staat niet gelijk aan een aparte DMZ-interface, want de proxy deelt de host nog steeds met de diensten erachter.

De inkomende firewallregels op de host laten die twee poorten toe en gooien de rest weg. Elke andere dienst op de machine mag draaien en luisteren, maar niets van buiten kan er een verbinding naartoe opzetten. Dat benadert het beleid "alleen de bedoelde poorten zijn bereikbaar" op één host; het creëert geen aparte grens met het interne netwerk.

Applicatieservers, databases en beheerpanelen horen niet op het publieke adres te luisteren. Draait de proxy op dezelfde host, dan kunnen ze op loopback luisteren; draait hij elders op het privénetwerk, dan kunnen ze op een privéadres luisteren. In beide gevallen luistert er voor die diensten niets op de publieke interface, dus het openzetten van een inkomende regel op alleen die interface stelt ze niet bloot.

Beheertoegang hoort aan de interne kant, niet aan de DMZ-kant. SSH en beheerinterfaces buiten het publieke pad houden, achter een VPN of een privénetwerk, voorkomt directe verbindingen ernaartoe vanaf het publieke internet.

LEES

Linux VPS beveiligen | 20 manieren om je VPS-server te beveiligen

Hoe vertalen DMZ-concepten zich naar VPC-subnetten en security groups?

Het klassieke model heeft een vrij nauwe conceptuele vertaling naar cloudnetwerkprimitieven, maar niet één op één. Een DMZ-segment wordt een publiek subnet. Het interne netwerk wordt een privé-subnet zonder route naar een internetgateway. De regelset van de firewall splitst zich over security groups, die bij de netwerkinterfaces van resources horen, en network ACL's, die aan subnetten hangen.

Cloudleveranciers gebruiken dit vocabulaire zelf, wat een goede aanwijzing is dat de term nog actueel is. De networkingblog van AWS beschrijft een DMZ-architectuur op Amazon VPC die publiek bereikbare diensten scheidt van interne netwerken, gebouwd op VPC Block Public Access, een controle op Regio-niveau die in november 2024 is gelanceerd.

De subnetten zijn het dragende deel van deze vertaling. Een publiek subnet is publiek omdat zijn routetabel naar een internetgateway wijst. Aangezien routetabellen bepalen waar pakketten heen reizen, bepaalt de indeling van je subnetten je blootstelling nog vóór welke afzonderlijke regel dan ook.

De vertaling is op één specifiek punt onvolmaakt. Een firewallinterface handhaafde een grens voor een heel segment; een security group hangt daarentegen aan de netwerkinterface van een resource. Twee machines in hetzelfde privé-subnet kunnen totaal verschillende security groups dragen, waardoor de handhaving fijnmaziger landt dan een fysieke interface ooit voor elkaar kreeg. Meestal is dat vooruitgang. Het betekent ook dat de naam van een subnet je minder vertelt over wat bereikbaar is dan een netwerkdiagram vroeger deed.

Waar de single-serverversie tekortschiet

Op één host delen het publiek blootgestelde proces en de interne diensten een kernel en een machine. Aparte segmenten dwingen een aanvaller over een netwerkgrens die een firewall inspecteert; één host doet dat niet. Het single-serverpatroon verkleint de blootstelling. Het bootst geen scheiding na.

Raakt de reverse proxy zo gecompromitteerd dat de aanvaller code kan uitvoeren, dan draait die code al op de machine waarop je database draait. Luisteren op loopback helpt dan niet, want loopback is vanaf de host bereikbaar. Container- of gebruikersisolatie kan de benodigde inspanning opschroeven, maar containers op dezelfde host delen nog altijd de kernel van die host. In het klassieke model was de volgende stap van de aanvaller een pakket over een kabel waar iets naar keek. Hier is het een lokale socket.

Het praktische gevolg is een drempel, geen oordeel. Zodra wat achter de proxy staat meer waard is dan de moeite van een tweede machine, neem dan een tweede machine en een privénetwerk ertussen. Niets uit dit artikel hoef je daarvoor opnieuw te leren, want niets ervan ging ooit over de hardware.

De perimeter is niet langer de enige plek waar beveiligingsbeleid kan worden afgedwongen. Zero-trustarchitectuur haalt impliciet vertrouwen op basis van netwerklocatie weg, terwijl privéconnectiviteit gebouwd met WireGuard of Tailscale de publieke blootstelling kan verkleinen. Geen van beide benaderingen vervangt automatisch segmentatie of autorisatie. Mijn standpunt over de smallere vraag is helder. Als mentaal model: scheid wat bereikbaar is van wat dat niet is, en weet welke grens een compromittering insluit. Die vraag overleeft elke hierboven genoemde architectuur, en juist daarom is ze het antwoorden nog steeds waard.

Veelgestelde vragen

Is een DMZ hetzelfde als een VPN?

Nee. Ze lossen verschillende problemen op. Een DMZ regelt wat onvertrouwde buitenstaanders kunnen bereiken, door een kleine set diensten beschikbaar te stellen en verder niets. Een VPN geeft vertrouwde buitenstaanders een privéweg naar binnen, door ze te authenticeren op een netwerk dat ze anders niet zouden bereiken. Veel netwerken draaien beide, en geen van beide vervangt de ander.

Is een DMZ veilig?

Een DMZ maakt een blootgestelde dienst niet veilig. Ze beperkt hoe ver de compromittering van die dienst reikt. De publiek bereikbare dienst blijft publiek bereikbaar, blijft blootgesteld aan iedereen op internet en heeft nog altijd op eigen kracht patches, monitoring en hardening nodig. De DMZ bepaalt wat er gebeurt nadat hij valt, niet of hij valt.

Heb ik een DMZ nodig als ik maar één server heb?

Niet in de klassieke zin, en op één host zou je er sowieso geen kunnen bouwen. De topologie met drie interfaces vereist aparte netwerksegmenten, en een server met één publiek IP heeft er geen. Wat je wel kunt doen is blootstelling beheersen: maak een reverse proxy het enige publieke toegangspunt, weiger standaard de overige inkomende poorten, en laat interne diensten luisteren op loopback of een privéadres. Dat verkleint wat het internet kan bereiken, zonder de publieke dienst te isoleren van de rest van de host. Zodra wat achter de proxy staat meer waard is dan de kosten van een tweede machine, gebruik dan twee machines en een privénetwerk ertussen.

Waarom heet het een gedemilitariseerde zone?

De term is ontleend aan de militaire betekenis van een bufferzone tussen twee tegenover elkaar staande partijen, waar geen van beide volledig de baas is. Het netwerkgebruik houdt die metafoor vast: de DMZ hoort noch helemaal bij het onvertrouwde buiten, noch helemaal bij het vertrouwde binnen.