Skip to main content
  1. Concetti/

DMZ e Screened Subnet: Dual-Firewall, Bastion Host, Jump Server

·6 mins
Alessio Barnini
Author
Alessio Barnini
Table of Contents

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:

FirewallPermetteBlocca
EsternoTraffico verso DMZ (80, 443, 25, 53)Tutto il traffico diretto verso LAN
InternoSolo 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.

dmz-screened-subnet-architecture.webp

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.

ServizioPortaTraffico LAN necessario
Web server443, 80Query DB (5432/3306), LDAP auth (389/636)
Mail gateway (SMTP relay)25, 587Inoltro a mail server interno (25)
DNS autoritativo pubblico53Nessuno (zone file locale)
FTP/SFTP pubblico21, 22Storage interno (NFS/SMB)
Reverse proxy / Load balancer443Backend app server interni

DMZ.webp


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.

dmz-webserver-database-protection.webp

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
CloudDMZ EquivalentLAN EquivalentFirewall Equivalent
AWSPublic Subnet (ELB, NAT GW)Private Subnet (EC2, RDS)Security Group (stateful per risorsa)
AzureHub VNet con Azure FirewallSpoke VNet privatiNSG + Azure Firewall
GCPPublic-facing subnetPrivate subnet con Private Google AccessVPC 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.

vpn-remote-access-screened-subnet.webp

Related