DMZ e Screened Subnet#
La DMZ (DeMilitarized Zone), o Screened Subnet nel linguaggio Security+, e' una rete intermedia che isola i server pubblici da internet e dalla LAN interna. L'obiettivo e' contenere il danno: se un server pubblico viene compromesso, l'attaccante non ottiene accesso diretto alla rete interna.
Mappa Globale#
DMZ e Screened Subnet — Panoramica#
Il Principio della Screened Subnet#
La Screened Subnet e' un'architettura difensiva basata sul principio della difesa in profondita': anche se un attaccante riesce a compromettere un server pubblico, deve ancora superare almeno un altro firewall per raggiungere la LAN interna dove vivono i dati critici.
Il termine "DMZ" viene dalla terminologia militare (zona smilitarizzata tra due fronti). In Security+, il termine tecnico corretto e' Screened Subnet.
flowchart LR
subgraph INET[Internet - Untrusted]
ATT[Attaccante / Utente legittimo]
end
subgraph DMZ[Screened Subnet - Semi-trusted]
WEB[Web Server :443]
MAIL[Mail Gateway :25]
DNS_PUB[DNS Pubblico :53]
REVPRX[Reverse Proxy]
end
subgraph LAN[LAN Interna - Trusted]
DB[Database Server]
AD[Active Directory]
FILE[File Server]
DEV[Workstation dev]
end
FW_EXT[Firewall Esterno]
FW_INT[Firewall Interno]
ATT --> FW_EXT
FW_EXT --> WEB
FW_EXT --> MAIL
FW_EXT --> DNS_PUB
FW_EXT --> REVPRX
WEB --> FW_INT
REVPRX --> FW_INT
FW_INT --> DB
FW_INT --> AD
Architettura Single Firewall (3 interfacce)#
L'architettura single firewall usa un unico apparato con tre interfacce di rete separate: WAN (internet), DMZ e LAN. E' la soluzione piu' semplice ed economica, ma presenta un punto critico.
flowchart TD
INET[Internet]
subgraph FW[Firewall Unico - 3 NIC]
WAN[NIC WAN]
NIC_DMZ[NIC DMZ]
NIC_LAN[NIC LAN]
end
subgraph DMZ[DMZ]
WEB[Web Server]
MAIL[Mail Server]
end
subgraph LAN[LAN Interna]
DB[Database]
AD[Active Directory]
end
INET --> WAN
NIC_DMZ --> DMZ
NIC_LAN --> LAN
Vantaggi: costo ridotto, singola interfaccia di gestione, meno complessita' operativa.
Svantaggio critico: se il firewall e' compromesso (0-day nel firmware, misconfiguration grave), l'attaccante ottiene visibilita' e accesso sia alla DMZ che alla LAN interna in un colpo solo. Un singolo punto di fallimento protegge tutto.
Architettura Dual Firewall (piu' sicura)#
L'architettura dual firewall inserisce due firewall distinti: uno tra internet e la DMZ, uno tra la DMZ e la LAN interna. E' la configurazione raccomandata per ambienti con dati sensibili.
flowchart LR
INET[Internet]
FW_EXT[Firewall Esterno\nvendor A]
subgraph DMZ[Screened Subnet]
WEB[Web Server]
MAIL[Mail Gateway]
DNS[DNS Pubblico]
JUMP[Jump Server]
end
FW_INT[Firewall Interno\nvendor B]
subgraph LAN[LAN Interna]
DB[Database]
AD[Active Directory]
ERP[ERP / Finance]
end
INET --> FW_EXT
FW_EXT --> DMZ
DMZ --> FW_INT
FW_INT --> LAN
Regole tipiche dei due firewall:
| Firewall | Permette | Blocca |
|---|---|---|
| Esterno | Traffico verso DMZ (80, 443, 25, 53) | Tutto il traffico diretto verso LAN |
| Interno | Solo query specifiche da DMZ verso LAN (es. DB port 5432 da web server) | Connessioni generiche da DMZ a LAN |
Raccomandazione di sicurezza: usare firewall di vendor diversi per i due apparati. Un 0-day su Palo Alto che compromette il firewall esterno non funziona automaticamente su un Fortinet interno — l'attaccante deve trovare un secondo exploit per un secondo vendor.

Mappa — Dual Firewall#
Cosa va in DMZ#
La DMZ ospita servizi che devono essere raggiungibili da internet ma non hanno bisogno di accesso diretto alla LAN interna. Il principio guida e' il minimo privilegio: ogni server in DMZ deve poter raggiungere solo le risorse LAN strettamente necessarie al suo funzionamento.
| Servizio | Porta | Traffico LAN necessario |
|---|---|---|
| Web server | 443, 80 | Query DB (5432/3306), LDAP auth (389/636) |
| Mail gateway (SMTP relay) | 25, 587 | Inoltro a mail server interno (25) |
| DNS autoritativo pubblico | 53 | Nessuno (zone file locale) |
| FTP/SFTP pubblico | 21, 22 | Storage interno (NFS/SMB) |
| Reverse proxy / Load balancer | 443 | Backend app server interni |

Bastion Host#
Il bastion host e' un server esposto direttamente su internet, progettato con hardening massimo per resistere agli attacchi. Ha un unico scopo specifico e una superficie di attacco ridotta al minimo.
- Solo i servizi strettamente necessari sono attivi — tutto il resto e' disabilitato o rimosso
- OS patchato all'ultima versione, configurazione hardened (CIS Benchmark, STIG)
- Logging e monitoring intenso: ogni accesso, ogni comando, ogni connessione fallita
- Nessun software aggiuntivo, nessun account utente non necessario
- Esempio classico: un server SSH jump raggiungibile da internet per accesso amministrativo in emergenza
Il termine "bastion" non e' una categoria di prodotto ma una filosofia di hardening: qualsiasi server esposto su internet dovrebbe essere trattato come un bastion host.
Jump Server / Jump Box#
Il jump server (o jump box) e' un host posizionato in DMZ o in una rete separata, usato come punto di transito obbligato per accedere alla LAN interna in modo amministrativo. Tutta l'attivita' admin passa per lui, centralizzando il logging e il controllo.
sequenceDiagram
participant ADM as Admin (internet)
participant JUMP as Jump Server (DMZ)
participant FW as Firewall Interno
participant SRV as Server LAN Target
ADM->>JUMP: SSH / RDP da IP aziendale whitelistato
JUMP->>JUMP: Auth MFA, log sessione
JUMP->>FW: SSH verso LAN (solo da jump box IP)
FW->>SRV: Connessione permessa (regola specifica)
SRV->>JUMP: Shell aperta
JUMP->>ADM: Sessione tunnel
Note over JUMP: Ogni comando loggato nel jump server
Sessione registrata per audit
Vantaggi:
- Log centralizzati di tutta l'attivita' amministrativa
- La LAN non e' mai esposta direttamente su internet
- Regola semplice sul FW interno: "SSH permesso solo da IP jump server"
- Session recording per compliance e forensics
Evoluzione enterprise: il jump server puo' essere sostituito o integrato con soluzioni PAM (Privileged Access Management) come CyberArk Privileged Access Manager o HashiCorp Vault — offrono credential checkout, session recording, just-in-time access e audit trail completo senza richiede SSH fisico al jump server.
Dev parallel: In AWS, un bastion host EC2 in una public subnet con security group che permette SSH solo dagli IP dell'ufficio e' esattamente questo pattern. Da li' si accede alle istanze in private subnet che non hanno IP pubblico. Elastic Beanstalk, ECS e altri servizi managed eliminano la necessita' del bastion per i workload applicativi, ma le operazioni DB/admin sui server lo richiedono ancora.

Mappa — Bastion e Jump Server#
Cloud DMZ Equivalenti#
In cloud, il concetto di DMZ si implementa con subnet separation e controlli di rete nativi del provider. La logica e' identica: separare le risorse pubbliche da quelle private con controlli di accesso.
flowchart TD
subgraph AWS[AWS VPC]
subgraph PUB[Public Subnet - DMZ equivalente]
ELB[Elastic Load Balancer]
NAT[NAT Gateway]
BAST[Bastion EC2]
end
subgraph PRIV[Private Subnet - LAN equivalente]
APP[App Servers ECS/EKS]
RDS[RDS Database]
CACHE[ElastiCache]
end
SG_PUB[Security Group Public\nAllow 443 from 0.0.0.0/0]
SG_PRIV[Security Group Private\nAllow 5432 from App SG only]
end
IGW[Internet Gateway]
INET[Internet]
INET --> IGW
IGW --> ELB
ELB --> APP
APP --> RDS
SG_PUB -.-> ELB
SG_PRIV -.-> RDS
| Cloud | DMZ Equivalent | LAN Equivalent | Firewall Equivalent |
|---|---|---|---|
| AWS | Public Subnet (ELB, NAT GW) | Private Subnet (EC2, RDS) | Security Group (stateful per risorsa) |
| Azure | Hub VNet con Azure Firewall | Spoke VNet privati | NSG + Azure Firewall |
| GCP | Public-facing subnet | Private subnet con Private Google Access | VPC Firewall Rules |
I Security Group AWS e gli NSG Azure sono firewall stateful per singola risorsa — il concetto e' lo stesso del stateful firewall tradizionale, applicato a livello micro-segmentazione invece che perimetrale.



