La DMZ arriva senza una definizione allegata. Una voce in una checklist di revisione della sicurezza, una frase nel documento di hardening di un fornitore, un requisito in un annuncio di lavoro messo accanto a TLS e al minimo privilegio.
Lo cerchi e trovi lo schema di un firewall con tre cavi di rete. Uno va verso internet, uno verso una fila di server, uno verso una LAN d'ufficio. Quello che amministri tu, invece, è un solo server in affitto con un solo IP pubblico e nessuna interfaccia di rete di scorta.
La prima immagine è una vera architettura DMZ. Su un solo server puoi riprodurre una parte del suo obiettivo di sicurezza: limitare ciò che internet riesce a raggiungere. Quello che su quello stesso host non puoi riprodurre è il confine di rete separato che rende una DMZ una DMZ.
La versione breve
- Una DMZ separa i servizi che gli estranei devono poter raggiungere dal resto di ciò che gestisci.
- Il punto non è mai stato il cablaggio: il punto era che una compromissione sul lato pubblico si fermasse lì.
- Puoi configurare un firewall e comunque non avere una DMZ.
- Un singolo server con un solo IP pubblico può ridurre l'esposizione con un reverse proxy, regole di firewall sull'host e binding privati o su loopback, ma non crea un segmento DMZ separato.
- Quella versione condivide un kernel con ciò che protegge, quindi contala come esposizione ridotta e non come isolamento.
Cosa questo articolo non tratta
Il perimetro qui è il modello mentale, e tre argomenti adiacenti vengono deliberatamente lasciati da parte.
- Nessun passo di configurazione. Non ci sono impostazioni di reverse proxy, né sintassi di regole firewall, né raccomandazioni su quale strumento installare.
- Nessuna configurazione di router domestici. L'opzione "DMZ host" di un router di casa indica tutt'altra cosa.
- Nessun verdetto sullo zero trust. Se il perimetro di rete sia ancora il controllo primario giusto è un dibattito reale, e qui non viene chiuso.
Che cos'è una DMZ e a cosa serve?
Una DMZ, o zona demilitarizzata, è un segmento di rete che sta tra l'internet non fidato e una rete interna. Ospita i servizi che devono essere raggiungibili pubblicamente, come i server web e i server di posta. Tutto il resto resta dietro un secondo confine, così raggiungere il servizio pubblico non equivale a raggiungere il resto.
La voce del glossario di Mozilla dedicata alla DMZ ne condensa la metà operativa in una sola proposizione: espone solo determinati endpoint definiti, negando al contempo l'accesso alla rete interna dall'esterno. È tutto qui l'obiettivo progettuale, enunciato senza alcun riferimento all'hardware.
I tipi di servizio che classicamente stanno lì derivano dall'obiettivo. Server web, server di posta, server FTP, server VoIP: cose a cui gli estranei devono poter connettersi. Server di directory, database, condivisioni di file, applicazioni interne e interfacce amministrative non sono in quell'elenco, perché nessuno dall'esterno dovrebbe raggiungerle.
Tieniti la proprietà, non l'immagine. Tre interfacce di rete sono un modo per creare un confine di fiducia separato. I design cloud e a server singolo possono applicare lo stesso principio di controllo dell'esposizione in altri modi, ma solo quelli con una zona perimetrale distinta riproducono la DMZ vera e propria.
Come funziona la DMZ classica a tre interfacce?
La DMZ classica si costruisce in due modi. Un design a firewall singolo dà a un solo firewall tre interfacce, una verso internet, una verso la DMZ e una verso la rete interna. Un design a doppio firewall colloca la DMZ tra due firewall separati. Entrambi applicano la stessa regola. Internet raggiunge la DMZ. Internet non raggiunge mai la rete interna.
Il modello a firewall singolo (a tre gambe)
Un firewall, tre interfacce di rete. La prima guarda verso internet. La seconda guarda verso la DMZ, dove vivono i servizi pubblici. La terza guarda verso la rete interna. Il firewall consente il traffico in ingresso da internet verso porte specifiche della DMZ, consente un traffico ristretto dalla DMZ verso l'interno dove un'applicazione lo richiede, e nega tutto il resto.
Il nome di questa forma è firewall a tre gambe. Ogni pacchetto che attraversa le zone passa da un solo apparato, il che rende quel firewall un singolo punto di guasto per il traffico tra zone. Se cede, connettività e applicazione delle policy ne risentono a seconda del comportamento in avaria del firewall e della ridondanza che hai predisposto.
Ho passato un decennio a gestire le operazioni di rete di un ISP, e quello che sorprendeva le persone di un'interfaccia DMZ era quanto fosse ordinaria. Una comune porta ethernet con un'etichetta di fiducia diversa assegnata nella configurazione del firewall. L'architettura non stava nel rame. Stava nel set di regole, e nel fatto che qualcuno avesse pensato con attenzione a quale direzione fosse consentita per ogni flusso.
Il modello a doppio firewall (schiena contro schiena)
Due firewall in serie, con la DMZ nel mezzo. Il firewall esterno lascia entrare il traffico da internet nella DMZ e nulla oltre. Quello interno consente solo il traffico specifico dalla DMZ verso l'interno di cui un'applicazione ha bisogno. Un attaccante che raggiunge la DMZ deve comunque attraversare il confine di policy del firewall interno prima di arrivare alla rete interna.
Due firewall ti danno due confini di policy applicati separatamente, ma aggiungono anche configurazione, patching e complessità operativa. Un guasto o una compromissione del confine esterno non rimuove automaticamente quello interno, anche se la protezione dipende comunque da come i due firewall sono configurati e gestiti.
Una DMZ è la stessa cosa di un firewall?
No. Una DMZ è una rete perimetrale o un segmento di rete separato. Un firewall è uno dei controlli più comuni usati per regolare il traffico tra quella zona, internet e la rete interna. Puoi configurare regole di firewall su una rete piatta senza creare alcuna DMZ, quindi la distinzione è architetturale e non solo una questione di configurazione.
La confusione si capisce. Il firewall è l'oggetto in cui entri, la cosa con un file di configurazione, un fornitore e un contratto di assistenza, e così si prende il nome di ciò che produce. In un segmento non entra mai nessuno.
La conseguenza si manifesta nel momento peggiore possibile. Dai per scontato che il tuo server web pubblico sia compromesso, perché prima o poi lo sarà. Su una rete piatta l'attaccante ha ormai un appoggio su una macchina che può già parlare con il tuo database, il tuo file server e le tue interfacce amministrative, e spostarsi tra loro significa semplicemente usare un accesso già consentito. Quel viaggio di lato si chiama movimento laterale, ed è esattamente ciò che il secondo confine esiste per fermare. La DMZ non impedisce che il server web venga compromesso. Impedisce che un server web compromesso diventi accesso a tutto il resto.
Una precisazione, già che il termine è sotto gli occhi: l'impostazione "DMZ host" di un router domestico o di piccolo ufficio è un'altra funzione. Inoltra il traffico in ingresso non sollecitato verso un unico dispositivo interno, esponendolo direttamente a internet; non crea una rete DMZ separata e protetta.
Come applicare i principi della DMZ su un solo server?
Un singolo server con un solo IP pubblico può riprodurre una parte dell'obiettivo di controllo dell'esposizione di una DMZ, senza riprodurne la separazione di rete. Un reverse proxy può diventare l'unico punto di ingresso pubblico, regole di firewall in ingresso con deny di default possono bloccare il resto, e i servizi interni possono ascoltare su loopback o su un'interfaccia privata anziché sull'indirizzo pubblico.
Parti dal vincolo che questa sezione presuppone: un VPS, un'interfaccia pubblica e nessun apparato firewall separato e nessuna sottorete DMZ sotto il tuo controllo. In quella configurazione non puoi riprodurre la classica topologia a tre gambe sullo stesso host. Le regole di firewall sull'host, la scelta di dove i servizi ascoltano e un reverse proxy possono comunque ridurre l'esposizione, ma non creano lo stesso confine di isolamento.
Un reverse proxy può occupare l'interfaccia pubblica sulle porte 80 e i piani 443 e diventare l'unico punto di ingresso a livello applicativo per il traffico web. Questo restringe la superficie di attacco pubblica, ma non equivale a un'interfaccia DMZ separata, perché il proxy condivide ancora l'host con i servizi che stanno dietro di lui.
Le regole di firewall in ingresso sull'host consentono quelle due porte e scartano il resto. Qualsiasi altro servizio sulla macchina può essere in esecuzione e in ascolto, ma nulla dall'esterno può aprire una connessione verso di esso. Questo avvicina la policy "solo le porte previste sono raggiungibili" su un singolo host; non crea un confine separato verso la rete interna.
I server applicativi, i database e i pannelli di amministrazione non dovrebbero ascoltare sull'indirizzo pubblico. Quando il proxy gira sullo stesso host possono ascoltare su loopback; quando gira altrove sulla rete privata possono ascoltare su un indirizzo privato. In entrambi i casi non c'è nulla in ascolto per quei servizi sull'interfaccia pubblica, quindi aprire una regola in ingresso solo su quell'interfaccia non li espone.
L'accesso amministrativo appartiene al lato interno, non al lato DMZ. Tenere SSH e le interfacce di gestione fuori dal percorso pubblico, dietro una VPN o una rete privata, impedisce connessioni dirette verso di essi da internet.
Come si traducono i concetti di DMZ in sottoreti VPC e security group?
Il modello classico ha una corrispondenza concettuale piuttosto stretta con le primitive di rete del cloud, ma non è uno a uno. Un segmento DMZ diventa una sottorete pubblica. La rete interna diventa una sottorete privata senza rotta verso un gateway internet. Il set di regole del firewall si divide tra i security group, associati alle interfacce di rete delle risorse, e le ACL di rete, collegate alle sottoreti.
| Elemento classico | Equivalente cloud | Che cosa impone |
|---|---|---|
| Segmento DMZ | Subnet pubblica | Fornisce una rotta verso internet; una risorsa ha bisogno anche di un indirizzo pubblico e di regole di sicurezza che consentano il traffico |
| Segmento di rete interna | Subnet privata | Nessuna rotta diretta verso il gateway internet, quindi internet non può avviare connessioni dirette per quella via |
| Interfaccia firewall tra zone | Tabella di routing + collegamento di un gateway internet | Dove il traffico può essere instradato; l'indirizzamento pubblico e i controlli di sicurezza determinano comunque se una risorsa è raggiungibile |
| Set di regole firewall (per zona) | ACL di rete | Regole di consenso e rifiuto senza stato, valutate al bordo della sottorete |
| Set di regole firewall (per host) | Security group | Regole di consenso con stato, applicate alle interfacce di rete delle risorse associate |
| Servizio esposto al pubblico nella DMZ | Bilanciatore di carico o istanza proxy nella sottorete pubblica | L'unico punto di ingresso attraverso cui il traffico deve passare |
I fornitori cloud usano essi stessi questo vocabolario, il che è una buona prova che il termine sia ancora attuale. Il blog di networking di AWS descrive un'architettura DMZ su Amazon VPC che isola i servizi esposti al pubblico dalle reti interne, costruita su VPC Block Public Access, un controllo a livello di Regione lanciato a novembre 2024.
Le sottoreti sono la parte portante di questa corrispondenza. Una sottorete pubblica è pubblica perché la sua tabella di routing punta a un gateway internet. Dato che le tabelle di routing decidono dove viaggiano i pacchetti, la disposizione delle sottoreti plasma la tua esposizione prima di qualsiasi singola regola.
La corrispondenza è imperfetta in un punto preciso. Un'interfaccia firewall imponeva un confine per un intero segmento; un security group, invece, è associato all'interfaccia di rete di una risorsa. Due macchine nella stessa sottorete privata possono portare security group completamente diversi, così l'applicazione atterra a una granularità più fine di quanta un'interfaccia fisica sia mai riuscita a raggiungere. Di solito è un miglioramento. Significa anche che il nome di una sottorete ti dice meno su cosa sia raggiungibile di quanto facesse un tempo un diagramma di rete.
Dove la versione a server singolo non arriva
Su un solo host, il processo esposto al pubblico e i servizi interni condividono un kernel e una macchina. Segmenti separati costringono un attaccante ad attraversare un confine di rete che un firewall ispeziona; un unico host no. Lo schema a server singolo riduce l'esposizione. Non riproduce la separazione.
Se il reverse proxy viene compromesso in un modo che dà all'attaccante l'esecuzione di codice, quel codice gira già sulla macchina su cui gira il tuo database. Il binding su loopback non aiuta a quel punto, perché loopback è raggiungibile dall'host stesso. L'isolamento tramite container o utenti può alzare lo sforzo richiesto, ma container sullo stesso host ne condividono comunque il kernel. Nel modello classico il passo successivo dell'attaccante era un pacchetto su un cavo che qualcosa ispezionava. Qui è un socket locale.
La conseguenza pratica è una soglia, non un verdetto. Quando ciò che sta dietro il proxy vale più della fatica di una seconda macchina, usa una seconda macchina e una rete privata tra le due. Niente di questo articolo va riappreso per farlo, perché niente di tutto ciò ha mai riguardato l'hardware.
Costruisci su un VPS Linux con accesso root, NVMe e la potenza di AMD EPYC.
Vedi piani LinuxIl perimetro non è più l'unico posto in cui si può applicare una policy di sicurezza. L'architettura zero trust elimina la fiducia implicita basata sulla posizione in rete, mentre una connettività privata costruita con WireGuard o Tailscale può ridurre l'esposizione pubblica. Nessuno dei due approcci sostituisce automaticamente la segmentazione o l'autorizzazione. La mia posizione sulla questione più ristretta è netta. Come modello mentale: separa ciò che è raggiungibile da ciò che non lo è, e sappi quale confine contiene una compromissione. Quella domanda sopravvive a ogni architettura nominata sopra, ed è per questo che vale ancora la pena rispondervi.
Domande frequenti
Una DMZ è la stessa cosa di una VPN?
No. Risolvono problemi diversi. Una DMZ controlla cosa possono raggiungere gli estranei non fidati, esponendo un piccolo insieme di servizi e nient'altro. Una VPN dà a persone fidate che stanno fuori un percorso privato verso l'interno, autenticandole su una rete che altrimenti non raggiungerebbero. Molte reti usano entrambe, e nessuna delle due sostituisce l'altra.
Una DMZ è sicura?
Una DMZ non rende sicuro un servizio esposto. Limita fin dove arriva la compromissione di quel servizio. Il servizio rivolto al pubblico resta rivolto al pubblico, resta esposto a chiunque su internet e continua ad aver bisogno di patch, monitoraggio e hardening per conto proprio. La DMZ decide cosa succede dopo che è caduto, non se cadrà.
Ho bisogno di una DMZ se ho un solo server?
Non nel senso classico, e su un singolo host non potresti comunque costruirne una. La topologia a tre interfacce richiede segmenti di rete separati, e un server con un solo IP pubblico non ne ha nessuno. Quello che puoi fare è controllare l'esposizione: rendere un reverse proxy l'unico punto di ingresso pubblico, negare di default le altre porte in entrata e far ascoltare i servizi interni su loopback o su un indirizzo privato. Questo riduce ciò che internet riesce a raggiungere, senza isolare il servizio pubblico dal resto dell'host. Quando ciò che sta dietro il proxy vale più del costo di una seconda macchina, usa due macchine e una rete privata tra le due.
Perché si chiama zona demilitarizzata?
Il termine è preso in prestito dal senso militare di area cuscinetto tra due forze contrapposte, dove nessuna delle due comanda del tutto. L'uso in rete conserva la metafora: la DMZ non appartiene interamente né all'esterno non fidato né all'interno fidato.
Discussione
Commenti
Accedi per partecipare alla discussione.