Cap 3 - Network Technologies and Security Architecture

Cosa fa

#

Copre l'intera infrastruttura di rete sicura: protocolli di base e sicuri, SSL/TLS, firewall, segmentazione (DMZ/VLAN/air gap), proxy, NAT, Zero Trust, UTM, SASE, Group Policy, DLP, SPF/DKIM/DMARC. Segue l'ordine del libro Gibson Cap 3.

TL;DR

#

Se un protocollo non cripta → sostituiscilo con la versione sicura (FTPS/SFTP, HTTPS, IMAPS, LDAPS, SNMP v3). SSL è deprecato — usare sempre TLS. SSL e TLS sono spesso chiamati insieme ma sono cose diverse. Firewall stateless = filtra su ACL. Stateful = traccia sessioni (L4). NGFW/WAF = Layer 7. Fail-open = permette tutto se il dispositivo va in crash. Fail-closed = blocca tutto — più sicuro. DMZ (screened subnet) = zona tra due firewall per server pubblici. Reverse proxy sta nella DMZ, i web server nella LAN interna. Zero Trust: nessun utente/device fidato per default. Control Plane decide, Data Plane esegue. VLAN = segmentazione logica. Air gap = isolamento fisico totale.

mindmap
  root((Cap 3
Security
Architecture))
    [Reviewing Basic
Networking Concepts]
    [Data in Transit
Protocolli Sicuri]
    [Understanding Network
Infrastructure]
    [Firewall]
    [Implementing Network
Designs]
    [Zero Trust]
    [SASE]
    [Enterprise Security
Capabilities]

Reviewing Basic Networking Concepts

#

mindmap
  root((Reviewing Basic
Networking
Concepts))
    OSI Model
      L7 App WAF NGFW
      L6 Presentation TLS
      L4 Transport TCP UDP
      L3 Network IP stateless FW
      L2 Data Link MAC VLAN
      L1 Physical air gap
    TCP
      SYN SYN-ACK ACK
      Stateful FW traccia sessioni
      SYN flood riempie tabella
    UDP
      Connectionless best-effort
      DNS VoIP gaming
      DoS facile no handshake
    IP e ICMP
      IPv4 32bit IPv6 128bit
      ICMP ping traceroute
      FW blocca ICMP
    ARP
      Risolve IP a MAC
      Poisoning MITM
      BIA hardware LAA modificabile
    DNS
      UDP 53 query
      TCP 53 zone transfer
      DNSSEC firma digitale
      Record A AAAA MX CNAME PTR
    DHCP NTP
      DORA Discover Offer Request Ack
      NTP UDP 123 Kerberos 5min
      NTS sicurezza NTP con TLS

OSI Model

#

Riferimento dettagliato: osi-model.

Mnemonic bottom-up (1→7): Please Do Not Throw Sausage Pizza Away Mnemonic top-down (7→1): All People Seem To Need Data Processing

Firewall e layer: stateless = L3/L4 — stateful = L4 — WAF/NGFW = L7.

TCP — Transmission Control Protocol

#

Connection-oriented: garantisce la consegna tramite three-way handshake.

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: SYN (synchronize)
    S->>C: SYN/ACK (synchronize/acknowledge)
    C->>S: ACK (acknowledge)
    Note over C,S: Connessione stabilita

Usato per: HTTP, HTTPS, SSH, FTP, SMTP.

Perché il three-way handshake è importante per la sicurezza:

TCP non è solo "connesso o non connesso" — ha stati precisi che il firewall stateful traccia:

SYN ──────────────→   stato: SYN_SENT
     ←────────────── SYN-ACK   stato: SYN_RECEIVED
ACK ──────────────→   stato: ESTABLISHED
[traffico normale]
FIN ──────────────→   stato: FIN_WAIT → CLOSED

Il firewall stateful registra ogni connessione con il suo stato. Se arriva un pacchetto anomalo:

• ACK senza SYN precedente → nessuna sessione in tabella → blocca
• RST senza sessione aperta → anomalo → blocca
• Risposta da Google dopo connessione aperta → ESTABLISHED → passa

Il firewall stateless non conosce questi stati — vede solo IP e porta. Un pacchetto con flag anomali lo lascerebbe passare.

Attacchi che sfruttano flag TCP anomali (senza completare il three-way handshake):

Firewall stateful blocca ACK/FIN/XMAS scan — non c'è sessione corrispondente in tabella. Firewall stateless li lascia passare.

UDP — User Datagram Protocol

#

Connectionless: nessun handshake, best-effort delivery. Veloce ma inaffidabile. Usato per: DNS (query), VoIP, streaming, gaming.

IP — Internet Protocol

#

Identifica gli host e instrada il traffico da sorgente a destinazione.

• IPv4: 32 bit, notazione decimale puntata — es. 192.168.1.100
• IPv6: 128 bit, notazione esadecimale — es. FE80:0000:0000:0000:20D4:3FF7:003F:DE62

ICMP — Internet Control Message Protocol

#

Testa la connettività di base tra host.

• ping — verifica raggiungibilità tra due sistemi
• traceroute (Linux) / tracert (Windows) — traccia il percorso hop per hop

ARP — Address Resolution Protocol

#

Risolve indirizzi IPv4 in indirizzi MAC (physical address / hardware address, assegnati dal produttore alla NIC). TCP/IP usa l'IP per raggiungere la rete di destinazione, poi usa il MAC per raggiungere l'host corretto nella subnet. ARP è necessario solo una volta che il pacchetto raggiunge la subnet di destinazione.

L'ARP poisoning (cap. 7) invia risposte ARP false per reindirizzare o interrompere il traffico.

MAC address e hop:

Il MAC della NIC non cambia mai. Quello che cambia ad ogni hop del router sono i MAC src/dst nel frame Ethernet.

Un device, più MAC:

Ogni NIC ha il suo MAC. Un laptop ha NIC separate per wired e wireless — quindi due MAC distinti, uno per ogni scheda:

eth0  (scheda Ethernet)  → MAC: 00-16-EA-DD-A6-60   ← porta RJ45
wlan0 (scheda WiFi)      → MAC: 00-16-EA-DD-A6-61   ← antenna WiFi

Entrambi stampati sull'etichetta del dispositivo o visibili con ip link show.

BIA vs LAA — il MAC è modificabile a livello OS:

L'OS trasmette il LAA se impostato, ignorando il BIA. Questo è il meccanismo del MAC spoofing: l'attaccante cambia il LAA del proprio wlan0 con il MAC di un client autorizzato → bypassa il MAC filtering wireless. Stessa tecnica funziona anche su eth0 contro il port security degli switch (→ cap-04).

PC → [Frame: MAC_PC → MAC_Router] → Router
       distrugge frame, fa ARP, crea nuovo frame
Router → [Frame: MAC_Router → MAC_Server] → Server

• IP src/dst — non cambiano mai (destinazione finale)
• MAC src/dst — ricreati ad ogni hop di router (validi solo per il segmento corrente)

La causa del cambio MAC è il router, non la subnet in sé. Nella stessa subnet, sullo stesso switch, i MAC non cambiano — nessun router coinvolto. I router separano le subnet, quindi hop di router e cambio di subnet coincidono — ma la causa è sempre il router.

ARP poisoning funziona solo nella stessa subnet — non puoi avvelenare ARP su un segmento a cui non sei fisicamente connesso.

Frame — cos'è:

Unità di dati del Layer 2. Contenitore fisico che trasporta un pacchetto IP su un singolo segmento.

| MAC dst | MAC src | Tipo | [ Pacchetto IP ] | FCS |

Il pacchetto IP è la lettera con mittente/destinatario finali. Il frame è la busta per un singolo tratto — al router viene distrutta e ricreata per il tratto successivo.

DNS — Domain Name System

#

Converte hostname in indirizzi IP. Query DNS → UDP 53. Zone transfer → TCP 53.

Come funziona la risoluzione:

Il client chiede al suo DNS server "che IP è getcertifiedgetahead.com?". Se il server conosce la risposta (ce l'ha in cache) risponde direttamente. Altrimenti interroga altri DNS server risalendo la gerarchia (root → TLD → autoritativo) e mette la risposta in cache per le richieste future.

Cache e TTL (Time to Live): ogni risposta DNS ha un TTL in secondi. Client e server tengono la risposta in cache per quel tempo — evitano di ripetere la query. TTL basso = aggiornamenti frequenti. TTL alto = meno traffico ma risposta più vecchia.

Zone Transfer (TCP 53): non è il forwarding di una query. È quando un DNS server secondario copia l'intero database (zone) dal server primario.

Perché si fa la copia:

• Ridondanza — se il server primario va giù, il secondario risponde comunque
• Scalabilità — più server DNS distribuiscono il carico delle query
• Fault tolerance — nessun singolo punto di failure per la risoluzione DNS

Chi fa il zone transfer: l'authoritative nameserver primario verso i secondari. Se hai comprato il dominio su Aruba e non hai cambiato i nameserver, Aruba è il tuo authoritative primario — è lui che gestisce il database e lo replica sui server secondari tramite zone transfer. Se invece punti i record NS verso Cloudflare, Cloudflare diventa il primario. La scelta è sempre tua — dipende da dove punti i record NS. Chiunque abbia un server con software DNS (BIND, PowerDNS) raggiungibile su internet può diventare un authoritative nameserver.

Perché TCP e non UDP: il zone transfer copia l'intero database — potenzialmente migliaia di record. TCP garantisce la consegna ordinata e senza perdita di pacchetti — non per performance, ma per affidabilità. Perdere anche un solo record significherebbe un database incompleto e inconsistente. Query singola = UDP 53 (veloce, un pacchetto). Copia dell'intero database = TCP 53 (affidabile, zero perdita).

CIA Triad applicata al DNS — esempio diretto:

Record DNS:

Perché MX è un server separato: email e web hanno esigenze diverse. Il web server gestisce HTTP, il mail server gestisce SMTP. Possono stare su macchine diverse, con IP diversi, provider diversi. MX permette di avere example.com per il sito e mail.example.com (IP diverso) per la posta — separazione dei carichi e della sicurezza.

CNAME e load balancer: www.example.com CNAME → lb.example.com che risolve a più IP. Cambi un solo record CNAME invece di aggiornare tutti i client. Lo stesso meccanismo che usi quando punti un sottodominio a una piattaforma esterna (es. corsi.example.com → Teachable).

DNSSEC — Domain Name System Security Extensions

Un rischio di DNS è il DNS poisoning (anche detto DNS cache poisoning) — l'attaccante inserisce hostname→IP falsi nella cache del DNS server. Il client chiede "che IP è msn.com?" e il DNS risponde con l'IP del sito malevolo dell'attaccante.

Analogia con ARP poisoning:

• ARP poisoning → inserisce IP→MAC falsi nella cache ARP degli host → reindirizza il traffico locale
• DNS poisoning → inserisce hostname→IP falsi nella cache del DNS server → reindirizza il traffico internet

DNSSEC previene il poisoning con firme digitali — funziona esattamente come DKIM per le email, ma applicato ai record DNS:

sequenceDiagram
    participant R as Resolver (client DNS)
    participant A as DNS Autoritativo
    R->>A: Dammi l'IP di example.com
    A->>R: IP = 1.2.3.4 + RRSIG (firma con chiave privata)
    Note over R: Recupera DNSKEY (chiave pubblica) dal DNS
    Note over R: Verifica la firma RRSIG con la chiave pubblica
    alt Firma valida
        R->>R: Record autentico — usa l'IP
    else Firma non valida
        R->>R: DNS poisoning rilevato — scarta la risposta
    end

• RRSIG (Resource Record Signature) — firma digitale aggiunta a ogni record DNS dal server autoritativo usando la sua chiave privata
• DNSKEY — record che pubblica la chiave pubblica del server autoritativo — chiunque può verificare le firme
• Se la firma non corrisponde → il record è stato manomesso in cache → risposta scartata

Ma come fa il resolver a fidarsi della DNSKEY stessa? Il resolver non ha le chiavi pubbliche di tutti i domini. Ne ha solo una hardcoded nel software: la chiave pubblica della root zone (.) — chiamata trust anchor. Da lì segue una catena di firme verso il basso. Il resolver verifica bottom-up: parte dalla root (di cui si fida per definizione) e scende fino al record richiesto. È lo stesso modello dei certificati TLS — root CA hardcoded nel browser che garantisce per le CA intermedie.

flowchart TD
    TA["TRUST ANCHOR
    Chiave pubblica root (.) hardcoded nel resolver
    — non arriva dalla rete, è nel software stesso"]

    ROOT["ROOT ZONE (.)
    Firma la chiave pubblica di .com
    con la sua chiave privata"]

    COM[".com
    Firma la chiave pubblica di google.com
    con la sua chiave privata"]

    GOOGLE["google.com
    Firma i record DNS — A, MX, ecc.
    con la sua chiave privata"]

    RECORD["Record: google.com = 142.250.x.x
    + firma digitale di google.com"]

    VERIFY["RESOLVER — verifica bottom-up
    1. ha la chiave pubblica root → verifica firma su chiave .com ✓
    2. ora ha chiave .com → verifica firma su chiave google.com ✓
    3. ora ha chiave google.com → verifica firma sul record ✓
    Record accettato"]

    TA --> ROOT
    ROOT -->|"firma chiave pubblica"| COM
    COM -->|"firma chiave pubblica"| GOOGLE
    GOOGLE -->|"firma record"| RECORD
    RECORD --> VERIFY
    TA -.->|"punto di partenza fisso"| VERIFY

    style TA fill:#1a3a1a,stroke:#4aaf7e,color:#ffffff
    style VERIFY fill:#1a2a3a,stroke:#4a9eff,color:#ffffff
    style RECORD fill:#1a1a3a,stroke:#9b59b6,color:#ffffff
    style ROOT fill:#2a2000,stroke:#f0c040,color:#ffffff
    style COM fill:#2a2000,stroke:#f0c040,color:#ffffff
    style GOOGLE fill:#2a2000,stroke:#f0c040,color:#ffffff

DHCP — Dynamic Host Configuration Protocol

#

Assegna automaticamente: IP, subnet mask, gateway, DNS. Flusso DORA: Discover → Offer → Request → Acknowledge

NTP — Network Time Protocol

#

Fornisce sincronizzazione dell'ora tra sistemi di rete. Porta UDP 123. Protocollo più usato per la sincronizzazione del tempo — preciso entro decine di millisecondi.

Perché serve: molti sistemi richiedono che i clock siano allineati. Il caso più critico è Kerberos — se client e server divergono di più di 5 minuti, l'autenticazione fallisce e il login viene rifiutato.

Come funziona in un dominio Microsoft:

graph TD
    I["Server NTP su Internet
    fonte autoritativa"]
    DC1["Domain Controller principale
    Windows Time Service
    si sincronizza con NTP esterno"]
    DC2["Altri Domain Controller
    si sincronizzano con DC principale"]
    PC["Tutti i PC del dominio
    si sincronizzano con un DC"]

    I --> DC1
    DC1 --> DC2
    DC2 --> PC

1. Un Domain Controller usa il Windows Time Service per trovare un server NTP affidabile su internet
2. Gli altri DC si sincronizzano periodicamente con quel DC
3. Tutti i PC del dominio si sincronizzano con uno dei DC

Risultato: tutti i sistemi del dominio hanno lo stesso orario — Kerberos funziona, i log sono coerenti, le audit trail sono affidabili.

NTS — Network Time Security: aggiunge sicurezza a NTP usando TLS. NTP base non ha autenticazione — un attaccante può rispondere a query NTP con timestamp falsificati (time spoofing) per rompere Kerberos o corrompere i log. NTS risolve aggiungendo crittografia e autenticazione sulla stessa logica di NTP. Exam tip: la domanda chiede di proteggere NTP → risposta è NTS.

Data in Transit — Protocolli Sicuri vs Insicuri

#

mindmap
  root((Data in Transit
Protocolli
Sicuri))
    Non usare
      FTP 21 testo in chiaro
      Telnet 23 testo in chiaro
      SSL deprecato POODLE 2014
      HTTP 80 no cifratura
    Usa invece
      SFTP SSH 22 sottosistema SSH
      FTPS 989-990 FTP su TLS
      SSH 22 cifra tutto
      HTTPS 443 HTTP su TLS
      TLS 1.2 o 1.3
    Layer OSI cifratura
      IPsec L3 tutto il pacchetto IP
      TLS L6-L7 solo la sessione app
      SSH L7 sessione remota
    VoIP
      RTP audio video non cifrato
      SRTP RTP con AES
      SIP metadati TCP 5060
      SIPS SIP su TLS 5061
    Accesso Remoto
      SSH chiave pubblica privata
      RDP 3389 TLS VPN prima
      VPN client-to-site site-to-site
    Directory
      LDAP 389 non cifrato
      LDAPS 636 TLS
      Kerberos autentica login

Quando i dati viaggiano in chiaro sulla rete sono vulnerabili all'intercettazione. La cifratura protegge i dati in transito.

Caso comune: un utente su rete pubblica (aeroporto) usa un laptop non cifrato — uno sniffer sulla stessa rete legge tutto il traffico.

Cosa non usare e perché

#

• FTP — trasmette in chiaro. Un packet capture legge dati e credenziali.
• TFTP — UDP 69, no autenticazione, no cifratura. Solo reti interne (boot PXE). Disabilitare in produzione.
• SSL — il protocollo originale per HTTPS. Compromesso (vulnerabilità POODLE, 2014). Non deve essere usato.

Sostituti sicuri

#

• TLS (Transport Layer Security) — sostituto designato di SSL. L'unica versione da usare. TLS 1.2 o 1.3.
• IPsec — cifra il traffico IP a livello di rete (Layer 3). Trasparente alle applicazioni. Usato nelle VPN. Cap 4.
• SSH (Secure Shell) — cifra il traffico remoto. Porta TCP 22. Sostituisce Telnet.
• SFTP — SSH File Transfer Protocol. Porta TCP 22. Non è FTP con TLS — è un sottosistema SSH.
• FTPS — FTP + TLS. Due varianti: explicit (STARTTLS su porta 21) e implicit (porta 989/990).
• SCP (Secure Copy Protocol) — copia file cifrati via SSH. Porta TCP 22.

SSL vs TLS

#

A quale layer OSI cifra ogni protocollo

#

Tabella: Non usare questo → usa questo

#

Voice e VoIP

#

VoIP (Voice over IP) trasmette telefonia sulla rete. Usa RTP (Real-time Transport Protocol). Per cifrare → SRTP (Secure Real-time Transport Protocol).

RTP è incapsulato dentro UDP:

[ Ethernet Frame ]
  [ IP Packet ]
    [ UDP Datagram ]
      [ RTP Header | Audio/Video payload ]

RTP è un protocollo applicativo che si appoggia su UDP — non è un protocollo di trasporto. Aggiunge il suo header (numero di sequenza, timestamp, codec) dentro un datagramma UDP. Motivo: la voce in tempo reale preferisce perdere un pacchetto piuttosto che aspettare la ritrasmissione TCP. Un pacchetto perso = piccolo glitch audio. Un pacchetto ritardato = la conversazione diventa impossibile.

SIP — il "centralinista" della sessione:

SIP stabilisce, mantiene e termina sessioni voce/video. I messaggi SIP sono testo leggibile (come HTTP) e contengono solo metadati — nessun audio. Metadati inclusi: IP mittente e destinatario, software usato, codec negoziato, porte RTP. Dopo che SIP ha stabilito la sessione, parte RTP o SRTP per il trasporto reale.

sequenceDiagram
    participant A as Chiamante
    participant B as Destinatario
    A->>B: INVITE (voglio chiamarti, ecco i miei parametri)
    B->>A: 100 Trying (sto cercando B)
    B->>A: 180 Ringing (sta squillando)
    B->>A: 200 OK (risponde, ecco i suoi parametri)
    A->>B: ACK (confermato)
    Note over A,B: RTP/SRTP — la chiamata vera inizia qui
    A->>B: BYE (riattacco)
    B->>A: 200 OK (chiuso)

I codici 100, 180, 200 sono copiati da HTTP — SIP è l'HTTP della telefonia.

Esempi concreti:

SIP — Teams chiama un collega: prima dell'audio, SIP manda un messaggio di testo con IP sorgente, codec, software. Il collega risponde SIP: "accetto". Solo dopo parte il suono.

SIPS — stesso flusso SIP ma su TLS: nessuno può leggere chi sta chiamando chi.

RTP — una volta che SIP ha stabilito la sessione, RTP trasporta i pacchetti audio su UDP in tempo reale.

SRTP — RTP + cifratura. Usato da WhatsApp, Signal, Zoom — il contenuto della chiamata è cifrato. SIP stabilisce la sessione, SRTP porta l'audio cifrato.

Web

#

Accesso Remoto

#

SSH (Secure Shell) — porta TCP 22. Sostituisce Telnet. Usa crittografia a chiave pubblica.

OpenSSH — suite di tool open source che semplifica l'uso di SSH. Integrata in praticamente tutti i sistemi Linux/macOS e Windows moderni. Supporta anche SCP e SFTP per il trasferimento file sicuro.

Connessione base:

ssh gega                  # connessione con username del client
ssh root@gega             # connessione con account specifico sul server remoto

Il server chiede la password — ma inserirla ogni volta è scomodo e meno sicuro. OpenSSH supporta l'autenticazione senza password tramite coppia di chiavi.

Autenticazione con chiavi — flusso:

ssh-keygen -t rsa         # genera coppia chiave pubblica + privata sul client
ssh-copy-id root@gega     # copia la chiave pubblica sul server remoto
ssh root@gega             # da ora: accesso automatico senza password

Due file generati da ssh-keygen:

La chiave pubblica viene salvata in ~/.ssh/authorized_keys sul server. Quando Maggie si connette, il server sfida il client con un messaggio cifrato con la chiave pubblica — solo chi ha la chiave privata può rispondere correttamente. Nessuna password in rete.

RDP (Remote Desktop Protocol) — porta TCP/UDP 3389. Accesso remoto desktop Windows. Usa TLS per cifrare la sessione. Connessione diretta client → server — non passa per server relay esterni.

Porta 3389 — aperta o chiusa?

Nella LAN non è "tutto aperto" — ci sono due livelli:

• Host-based firewall — ogni macchina Windows ha il suo firewall. RDP è disabilitato di default. Quando lo abiliti, Windows apre automaticamente 3389 localmente.
• Network firewall interno — reti segmentate con VLAN possono avere firewall interni che bloccano 3389 anche tra PC della stessa azienda.

Da internet: 3389 è quasi sempre bloccata sul firewall perimetrale — RDP esposto su internet è uno dei vettori di attacco più sfruttati (brute force, exploit).

Pratica corretta: VPN prima, poi RDP.

La VPN crea un tunnel cifrato attraverso internet. Il tuo PC riceve un IP interno della rete aziendale e il traffico viaggia come se fossi fisicamente in ufficio.

Casa → [Internet] → [Tunnel VPN cifrato] → [LAN aziendale] → Server :3389

Il firewall perimetrale non vede una connessione RDP dall'esterno — vede solo traffico VPN cifrato. Una volta dentro il tunnel, raggiungi 3389 come se fossi alla scrivania.

VPN concentrator — dispositivo dedicato che gestisce le connessioni VPN remote. Invece di far gestire la VPN al firewall, il concentratore si occupa solo di quello — autenticazione, cifratura, assegnazione IP interni. Spesso posizionato nella DMZ.

Site-to-site IPsec tunnel — VPN permanente tra due sedi aziendali. Le due reti appaiono come un'unica LAN estesa — i dipendenti della sede di Milano raggiungono i server di Roma come se fossero nella stessa rete.

Sede Milano (192.168.1.x) ←── IPsec tunnel ──→ Sede Roma (192.168.2.x)

Directory Services

#

I directory service come AD DS forniscono authentication e authorization per tutta la rete — non sono solo un database, sono il sistema centrale che decide chi sei e cosa puoi fare.

AD DS è il sistema (software) che usa due protocolli distinti per farlo:

LDAP specifica i formati per interrogare directory come Microsoft Active Directory (AD DS). Usato per cercare utenti, gruppi, computer in AD.

AD DS usa due protocolli distinti per scopi diversi — non LDAP per tutto:

Flusso login Windows: il dipendente inserisce la password → Windows usa Kerberos per autenticarsi al DC → il DC risponde con un ticket (TGT) → da quel momento usa il ticket per accedere alle risorse senza reinserire la password.

Flusso app web interna (Symfony su server web aziendale):

1. Vai su intranet.acme.com
2. Inserisci le credenziali di dominio
3. Symfony fa una query LDAP verso AD DS — "esiste barno@acme.com? La password corrisponde? A quali gruppi appartiene?"
4. AD DS risponde: "è Barno, appartiene a PrintersAdmin e DevTeam"
5. Symfony mostra solo le sezioni dell'app a cui quei gruppi hanno accesso — es. pannello gestione stampanti

LDAP porta i dati dell'identità dentro l'app — non dà accesso fisico a nulla. L'accesso reale alla stampante a livello di rete resta gestito da AD DS tramite Group Policy, permessi NTFS e Kerberos.

Understanding Network Infrastructure

#

mindmap
  root((Understanding
Network
Infrastructure))
    Switch e Router
      Switch L2 MAC address CAM table
      Router L3 IP address subnet
      Switch unicast solo porte src-dst
      Hub tutto a tutte le porte
    VLAN
      Segmentazione logica stesso switch
      Broadcast domain separati
      East-West lateral movement
      VLAN 1 default non usare
    IPv4 vs IPv6
      IPv4 32bit RFC 1918 privati
      IPv6 128bit no NAT necessario
      NAT traduce privato-pubblico
      PAT stesso IP porte diverse
    Port Security NAC
      Disabilita porte inutilizzate
      MAC filtering dinamico statico
      Flood Guard connessioni eccessive
      STP RSTP loop prevention
      BPDU Guard edge port
      NAC postura device quarantena
    Hardening ACL
      Disabilita servizi inutili
      ACL IP porta protocollo
      Implicit deny blocca il resto
      Stateless filtra ogni pacchetto
    Monitoring
      Inline nel percorso blocca
      SPAN mirror port non blocca
      TAP copia fisica tutto
      SNMP v3 UDP 161 monitoraggio
    Defense in Depth
      Preventative firewall perimetro
      Detective IDS SIEM interno
      Corrective host-based EDR
      HA 49 percent rule coppia FW

Host, Switch, Router

#

Qualsiasi device con un indirizzo IP è un host — chiamato anche client o nodo. Due device fondamentali per connettere gli host:

• Switch — connette host nella stessa rete (LAN). Opera a Layer 2.
• Router — connette reti diverse tra loro. Opera a Layer 3.

Come funziona uno switch — MAC address table:

Lo switch impara i MAC address osservando il traffico. La prima volta che Lisa manda un pacchetto a Homer, lo switch non sa su quale porta si trova Homer → manda il pacchetto in broadcast su tutte le porte.

Lisa (porta 1) → Switch → broadcast su porte 2, 3, 4
                          Homer (porta 4) risponde
                          Switch impara: Homer = porta 4

Da quel momento lo switch registra nella sua MAC address table (anche detta CAM table):

• Lisa → porta 1
• Homer → porta 4

Tutto il traffico successivo tra Lisa e Homer viaggia unicast solo tra porta 1 e porta 4 — nessun'altra porta lo vede.

Implicazione di sicurezza — switch vs hub:

Un attaccante con un protocol analyzer su porta 3 non cattura il traffico unicast tra Lisa (porta 1) e Homer (porta 4) — non arriva fisicamente alla sua porta. Su un hub invece tutto il traffico va a tutte le porte — l'attaccante cattura tutto.

Questo è il motivo principale per cui le organizzazioni hanno sostituito gli hub con gli switch: ridurre il rischio di cattura passiva del traffico.

Due attacchi pratici contro gli switch:

Attacco passivo — cambio porta entro 300 secondi: La MAC address table associa Lisa alla porta 1. Se un attaccante si collega fisicamente sulla porta 1 al posto di Lisa (entro i 300 secondi di aging), i pacchetti indirizzati a Lisa arrivano sulla sua porta. Con la NIC in promiscuous mode li cattura — anche se il MAC di destinazione non è il suo.

Attacco attivo — ARP poisoning: Più potente: l'attaccante manda risposte ARP false a Homer convincendolo che il MAC di Lisa è il suo. Homer aggiorna la cache ARP e da quel momento manda tutto al MAC dell'attaccante — indipendentemente dalla porta, senza aspettare timeout.

Cambio porta:   passivo — aspetti che il traffico arrivi alla tua porta
ARP poisoning:  attivo  — dirigi tu il traffico verso di te

Segmenti, Subnet e Broadcast Domain:

Un segmento è un gruppo di device che condividono lo stesso switch — tutti nella stessa subnet, stesso broadcast domain. I router separano i segmenti e non passano i broadcast.

192.168.1.x                    192.168.2.x
PC1 ──┐                        PC4 ──┐
PC2 ──┤── Switch A ──[ROUTER]── PC5 ──┤── Switch B
PC3 ──┘                        PC6 ──┘

• PC1 → PC2: solo Switch A, router non lo vede mai ✓
• PC1 → PC4: Switch A → Router → Switch B ✓
• PC1 broadcast: Switch A lo manda a PC2 e PC3, router lo droppa → PC4/5/6 non lo vedono ✓

Regola: stessa subnet = traffico sullo switch, senza router. Subnet diverse = obbligatorio passare dal router.

Switch vs Router — perché non usare solo il router:

In un ufficio con 100 PC tutto il traffico interno rimane sullo switch. Il router vede solo il traffico che deve uscire dalla subnet. Se tutto passasse dal router → collo di bottiglia.

Casa vs Ufficio:

A casa il router fa due lavori: verso l'interno si comporta da switch (192.168.1.x), verso l'esterno fa NAT traducendo l'IP privato in IP pubblico per uscire su internet.

Modalità di indirizzamento IPv4

#

Unicast: un host invia a un IP specifico. Gli altri host sulla stessa rete vedono il pacchetto ma non lo processano — non è indirizzato a loro.

Broadcast: un host invia a tutti sulla subnet usando 255.255.255.255. Tutti processano il pacchetto.

IPv4 vs IPv6

#

IPv4: 32 bit, notazione decimale puntata. Spazio esaurito — IANA ha assegnato l'ultimo blocco nel febbraio 2011. NAT come soluzione temporanea. IPv6: 128 bit, notazione esadecimale (8 gruppi da 4 caratteri hex separati da :). Indirizzi praticamente illimitati. Non necessita NAT.

IPv6 e il drop — perché cambia tutto:

In IPv4 il drop degli IP privati è obbligatorio perché non sono univoci — il router non saprebbe dove mandare un pacchetto da 192.168.1.1. In IPv6 gli Unique Local Address sono generati pseudo-random e sono univoci anche tra reti diverse — teoricamente un device interno potrebbe comunicare direttamente con l'esterno senza NAT.

Il firewall in IPv6 filtra comunque per sicurezza — non per ambiguità degli indirizzi. Il drop non è più obbligatorio per ragioni tecniche, ma resta fondamentale per ragioni di sicurezza.

IPv6 torna all'idea originale di internet: ogni host ha un indirizzo globale univoco e comunica direttamente. Il NAT era un workaround per l'esaurimento IPv4, non una feature progettata.

IP pubblici vs privati:

Tutti gli indirizzi su internet sono IP pubblici — univoci a livello mondiale, acquistati o affittati dagli ISP. Le reti interne usano IP privati, definiti dalla RFC 1918.

Questi sono gli unici tre range assegnabili in una rete privata.

Perché i router internet droppano gli IP privati:

Gli IP privati non sono univoci su internet — migliaia di aziende nel mondo usano 192.168.1.1 per il proprio router interno. Se un pacchetto con sorgente 192.168.1.1 arrivasse sul backbone internet, il router non saprebbe dove mandarlo: quell'indirizzo esiste in milioni di posti contemporaneamente.

I router internet hanno quindi una regola esplicita: pacchetto con IP sorgente o destinazione RFC 1918 → drop.

Per questo esiste il NAT — il router traduce l'IP privato in un IP pubblico prima di uscire su internet:

PC (192.168.1.100) → Router NAT → Internet (IP pubblico 85.x.x.x)
                     ↑
                     il pacchetto che esce ha IP pubblico — non viene droppato

Porte Fisiche vs Porte Logiche

#

Porta fisica — connettore hardware: presa RJ-45, porta USB. Porta logica — numero TCP/IP per identificare servizi sullo stesso IP. Es. 192.168.1.10 serve HTTP su 80, HTTPS su 443 e SSH su 22 simultaneamente.

Switch e VLAN

#

VLAN (Virtual Local Area Network) raggruppa host in segmenti logici indipendentemente dalla posizione fisica. Implementata sugli switch. Crea domini broadcast separati.

La grande differenza con il router:

Ogni VLAN ha la sua subnet:

VLAN 10 (HR) → 192.168.10.x VLAN 20 (IT) → 192.168.20.x VLAN 30 (VoIP) → 192.168.30.x

Device su VLAN diverse non si parlano — anche se fisicamente sullo stesso switch. Per far comunicare VLAN diverse serve un router (inter-VLAN routing) o uno switch L3.

Il router fa tutte e tre le cose:

Internet          ← router esce su internet (NAT)
192.168.1.x       ← instrada verso subnet interna A
192.168.2.x       ← instrada verso subnet interna B
VLAN 10 → 192.168.10.x  ← inter-VLAN routing
VLAN 20 → 192.168.20.x  ← inter-VLAN routing

Il router guarda l'IP destinazione e decide dove mandare il pacchetto — verso internet, verso un'altra subnet interna, o verso un'altra VLAN. Per l'inter-VLAN routing il router ha una sub-interfaccia per ogni VLAN, ognuna con il suo IP che fa da gateway:

PC HR (192.168.10.5) → PC IT (192.168.20.8)
  → gateway 192.168.10.1 (router, sub-interfaccia VLAN 10)
  → router instrada verso 192.168.20.8 (sub-interfaccia VLAN 20)

Come si configurano le VLAN — Cisco CLI:

! Crea le VLAN
vlan 10
 name HR
vlan 20
 name IT

! Assegna porte alle VLAN
interface fastethernet 0/1
 switchport mode access
 switchport access vlan 10    ← porta 1 → VLAN HR

interface fastethernet 0/2
 switchport mode access
 switchport access vlan 20    ← porta 2 → VLAN IT

La configurazione è un file testuale nello switch — nessun cavo da spostare. Finito il progetto riconfiguri e il PC torna nella VLAN originale.

Esempi pratici:

• HR e IT sullo stesso switch fisico ma VLAN separate → non si vedono, broadcast isolati
• VoIP su VLAN dedicata → traffico voce non compete con i dati, qualità garantita
• Progetto temporaneo → aggiungi utenti alla VLAN del progetto, finito il progetto riconfiguri in 5 minuti
• Guest Wi-Fi → VLAN separata dalla LAN aziendale (esempio che abbiamo già visto)

East-West vs North-South traffic:

Le VLAN controllano l'east-west traffic — il lateral movement degli attaccanti è sempre east-west. Segmentare con VLAN limita quanto un attaccante può muoversi lateralmente tra server.

Port Security, Flood Guard e NAC

#

Port Security limita i computer che possono connettersi alle porte fisiche dello switch.

Porta fisica vs porta logica — distinzione critica:

Sono due cose completamente diverse con lo stesso nome — trappola classica dell'esame.

Flusso fisico:

Laptop attaccante → wall jack (presa RJ-45 a muro) → porta fisica switch → rete aziendale

Il wall jack è la presa a muro RJ-45 che collega il PC al patch panel nel rack, dove c'è lo switch. Ogni wall jack corrisponde a una porta fisica specifica sullo switch.

Configurazione base di Port Security: disabilitare le porte inutilizzate. Se il wall jack non è in uso, l'amministratore disabilita la porta dello switch corrispondente. Un attaccante che collega un laptop a quel jack ottiene connessione fisica ma zero traffico — la porta è spenta.

Port Security avanzata — tre livelli:

Il MAC filtering dinamico è automatico — il primo device che si connette "prenota" la porta. Il MAC filtering statico richiede configurazione manuale su ogni porta ma garantisce che solo quel preciso device possa trasmettere. Entrambi prevengono il MAC flooding — limitando i MAC per porta, la tabella non può essere riempita con MAC falsi.

Flood Guard protegge dalle connessioni eccessive — rileva e blocca flood limitando le connessioni per porta.

Broadcast Storm e Loop Prevention — STP/RSTP:

Uno switching loop si crea quando esistono percorsi ridondanti tra switch: il pacchetto rimbalza all'infinito, moltiplicandosi ad ogni giro → broadcast storm → la rete va in crash.

Caso 1 — stesso switch (didattico, raro in pratica): Un utente collega due porte dello stesso switch con un cavo RJ-45 (senza nessun host in mezzo):

      | SWITCH |
Porta 3 ←── cavo ──→ Porta 7
  ↑                      ↓
  └──── loop infinito ───┘

Scenario di attacco: un attaccante in una sala conferenze con accesso a due wall jack collega i due jack con un cavo → switching loop → degrada tutta la rete.

Caso 2 — switch multipli (reale, comune): Ufficio con tre switch collegati tra loro per ridondanza — si forma un triangolo:

Switch A ──────── Switch B
    │                  │
    └───── Switch C ───┘

Tre cavi, tre switch → loop garantito. STP blocca una delle porte per spezzare il triangolo:

Switch A ──────── Switch B
    │                  │ ← BLOCCATA da STP
    └───── Switch C ───┘

Se Switch A cade, STP sblocca automaticamente la porta bloccata e il traffico riprende.

Soluzione: STP (Spanning Tree Protocol) e il più recente RSTP (Rapid Spanning Tree Protocol) — installati e abilitati di default sulla maggior parte degli switch moderni. Rilevano i loop e bloccano automaticamente le porte che li causano.

BPDU Guard:

STP rileva i loop scambiando messaggi BPDU (Bridge Protocol Data Unit) tra switch tramite le non-edge port (porte collegate ad altri switch). I BPDU viaggiano sui cavi tra switch diversi — non tra porte dello stesso switch.

Le edge port sono porte collegate a device finali (PC, server, stampante) — non dovrebbero mai ricevere BPDU. Se ne arriva uno, è un segnale di problema: un attaccante sta inviando BPDU falsi per manipolare la topologia STP.

BPDU Guard si abilita sulle edge port: monitora i messaggi BPDU in ingresso. Se ne riceve uno → disabilita immediatamente la porta → blocca l'attacco.

Network Access Control (NAC) verifica la postura del device prima di permettere l'accesso alla rete:

• Antivirus aggiornato? Patch installate? Policy rispettate?

Se il device non rispetta i requisiti → quarantena o accesso negato. Implementazione avanzata di port security.

Hardening Router e ACL

#

Hardening viene dalla metallurgia — "temprare" il metallo per renderlo più duro e resistente agli urti. In security significa la stessa cosa: rendere un sistema più resistente riducendo la superficie di attacco. Non è solo "mettere in sicurezza" — è isolare le compromissioni e limitarne la propagazione. Stesso principio della CKD hardened di BIP32: se un punto viene compromesso, il danno non si propaga.

Hardening router:

• Disabilitare servizi non necessari
• Usare password forti e account separati
• Aggiornare il firmware
• Abilitare il logging

route command — visualizza e modifica la routing table:

# Linux/Mac — mostra routing table
route -n
netstat -rn

# Windows
route print

# Output tipico:
# Destination    Gateway       Genmask         Flags
# 0.0.0.0        192.168.1.1   0.0.0.0         UG    ← default gateway
# 192.168.1.0    0.0.0.0       255.255.255.0   U     ← rete locale

Il router consulta la routing table per ogni pacchetto — decide quale interfaccia usare per raggiungere la destinazione.

ACL (Access Control List) — lista di regole su router e firewall (non switch) che specifica quali IP/porte/protocolli sono permessi o bloccati. Fornisce separazione logica tra segmenti di rete.

Le ACL filtrano su tre caratteristiche:

• IP — blocca singolo host o intera subnet (es. blocca tutto il traffico da 192.168.1.0/24 verso 192.168.5.0/24)
• Porta — blocca protocolli specifici (es. blocca TCP 443 = niente HTTPS)
• Protocollo — TCP, UDP, ICMP

Le regole si applicano in modo direzionale: puoi bloccare solo il traffico in ingresso, solo in uscita, o entrambi.

Equivalente Linux: iptables / ufw

→ Lab pratico: lab-router-acl-iptables

Switch vs Router — chi fa le ACL:

Per passare da 192.168.1.x a 192.168.2.x serve sempre un router (o device L3). Due switch collegati tra loro rimangono nella stessa subnet.

Limite degli IP — subnet e scalabilità:

Una subnet /24 ha 254 host disponibili. Se aggiungi troppi switch e device nella stessa subnet, puoi saturare lo spazio IP — e i broadcast diventano un problema (254 device ricevono ogni broadcast). Soluzione: subnetting — dividere in più subnet separate da router, ognuna con il suo spazio IP e broadcast domain limitato.

Implicit Deny:

L'ultima regola di ogni ACL è "blocca tutto il resto" — anche se non la scrivi. Tutto il traffico non esplicitamente permesso viene bloccato automaticamente.

REGOLA 1: permetti HTTP  (porta 80)   ✓
REGOLA 2: permetti HTTPS (porta 443)  ✓
REGOLA 3: permetti SSH   (porta 22)   ✓
─────────────────────────────────────
IMPLICIT DENY: blocca tutto il resto  ✗ (automatico)

L'implicit deny è attivo solo se esiste almeno una ACL. Dipende dal dispositivo:

Un router Cisco senza ACL configurata passa tutto il traffico — non c'è implicit deny. L'implicit deny si attiva solo quando applichi almeno una regola. Il firewall invece ha implicit deny built-in anche senza regole.

Esempi pratici:

Casa — eMule (P2P):

• Il router blocca tutto il traffico in ingresso da internet (NAT + implicit deny)
• Altri utenti eMule devono connettersi a te dall'esterno → router blocca
• Soluzione: port forwarding — regola esplicita "porta 4662 → manda al mio PC"
• Senza port forwarding il router droppava silenziosamente tutte le connessioni in ingresso

Internet → router (porta 4662) → [regola esplicita] → PC 192.168.1.x  ✓
Internet → router (porta 9999) → [implicit deny]    → bloccato         ✗

Azienda — nuovo server in DMZ:

• Il firewall blocca tutto il traffico verso il nuovo server (implicit deny built-in)
• L'admin deve aprire esplicitamente porta 80 e 443 per il web
• SSH, RDP, database rimangono bloccati anche senza scriverlo — implicit deny li copre

Active vs Passive Controls

#

Un controllo passivo monitora il traffico senza interagire con gli host — nessun agent installato, nessuna configurazione. Un controllo attivo richiede che i dispositivi siano esplicitamente configurati per usarlo.

Inline vs TAP/SPAN

#

Come posizionare i dispositivi di monitoring nella rete:

TAP = Test Access Point. A differenza dello SPAN, non fa decisioni logiche — copia ogni frame fisicamente, corrotto o meno.

Defense in Depth — i tre tipi di controlli

#

I tre layer insieme: il preventative blocca la maggior parte, il detective cattura quello che sfugge, il corrective ferma quello che è già dentro.

Firewall High Availability

#

In produzione i firewall si mettono in coppia per ridondanza. Regola del 49%:

Firewall A (49% load) + Firewall B (49% load) = sistema sano
Se Firewall A cade → Firewall B si trova al 98% — ancora gestibile

Se un singolo firewall è al 70% di load e il partner cade, il secondo va a 140% → crash. Per questo il limite è 49% su ciascuno. I firewall in coppia devono essere dello stesso make, model e versione firmware.

Jump Server

#

Fornisce accesso sicuro tra zone di sicurezza diverse. L'amministratore si connette al jump server (posizionato in zona admin separata o DMZ), poi da lì ai server nella zona target. Anche chiamato bastion host.

Uso tipico: gestire i server nella screened subnet (DMZ) dalla rete interna — l'admin non accede direttamente ai server DMZ ma passa dal jump server come punto di controllo unico.

Admin (LAN interna) → SSH → Jump Server (DMZ) → SSH → Web Server / Mail Server (DMZ)

Connessione: amministratore → SSH/RDP verso jump server → SSH/RDP verso server target.

SSH dall'esterno — casa vs azienda:

Stesso meccanismo di eMule: il router blocca tutto il traffico in ingresso (implicit deny). Per raggiungere SSH dall'esterno serve una regola esplicita (port forwarding porta 22) + IP raggiungibile.

A casa — IP dinamico:

Il provider cambia IP ogni tot ore. Soluzione: DDNS (Dynamic DNS) — un servizio (es. DuckDNS, No-IP) che aggiorna automaticamente un hostname fisso quando l'IP cambia.

casa.duckdns.org → aggiornato automaticamente → 85.x.x.x (IP attuale)
ssh utente@casa.duckdns.org → funziona sempre

Richiede: port forwarding porta 22 sul router + IP fisso o DDNS.

In azienda — SSH non si espone direttamente su internet:

Porta 22 esposta su internet = bersaglio immediato per brute force automatizzati. Le aziende usano:

Entrambi evitano di esporre SSH direttamente. Il jump server è l'unico punto esposto — hardened, monitorato, con accesso limitato a IP specifici.

SNMP — Simple Network Management Protocol

#

Usato per monitorare e gestire dispositivi di rete (router, switch, server). Non dà accesso a shell o interfaccia — legge e scrive solo dati di monitoraggio (metriche operative).

Cosa monitora SNMP:

Tool come Zabbix, Prometheus e Grafana interrogano via SNMP ogni 60 secondi. Se il traffico passa da 100 Mbps a 900 Mbps alle 3 di notte → alert automatico → analista SOC indaga.

Agent SNMP ascolta su UDP 161. Manager riceve trap (notifiche) su UDP 162. Usare sempre v3.

Come funzionano le credenziali SNMP:

Non esiste un prompt di login come SSH. Si configurano una volta in due posti, poi il tool interroga automaticamente ogni X secondi:

Sul dispositivo (router/switch):
  snmp-server community public RO           ← v2: community string
  snmp-server user zabbix v3 auth SHA "pw"  ← v3: username + password

Sul tool di monitoring (Zabbix/Prometheus):
  Host: 192.168.1.1 | SNMP v3 | Username: zabbix | Password: pw

Rischio v1/v2: la community string viaggia in chiaro su UDP — catturabile con Wireshark. Con public (read) l'attaccante vede tutta la configurazione. Con private (write) può modificarla.

Firewall

#

mindmap
  root((Firewall))
    Stateless
      ACL IP porta protocollo
      Ogni pacchetto anonimo L3-L4
      Regole esplicite andata ritorno
      Backbone CDN AWS NACL
    Stateful
      SPI traccia sessioni TCP
      Risposta automatica connessioni aperte
      Layer 4 three-way handshake
      Vulnerabile SYN flood
    WAF
      Layer 7 solo web
      SQLi XSS CSRF
      DMZ davanti al web server
      PCI-DSS obbligatorio
      ModSecurity OWASP CRS
    NGFW
      Deep Packet Inspection L7
      Identifica app indipendente porta
      IPS integrato URL categorization
      Palo Alto Cisco ASA Fortinet
    Host-based vs Network
      Host-based iptables ufw singolo host
      Network-based appliance tutta la rete
      Usarli insieme defense in depth
    Failure Modes
      Fail-open permette tutto Availability
      Fail-closed blocca tutto sicuro
      Security prefer fail-closed
    Regole
      Ordine sequenziale prima vince
      Specifiche prima generali dopo
      Implicit deny automatico finale
      Explicit deny scritto manualmente

Un firewall filtra il traffico in ingresso e in uscita per un singolo host o tra reti. Garantisce che solo specifici tipi di traffico siano permessi in entrata e in uscita.

Tipi di Firewall

#

Stateless (Packet Filtering):

#

• Usa ACL per filtrare su IP src/dst, porta, protocollo.
• Non traccia sessioni — ogni pacchetto valutato singolarmente.
• Opera a Layer 3/4.
• Devi scrivere esplicitamente entrambe le direzioni — richiesta e risposta:

  ALLOW outbound TCP → google.com porta 443   ← la richiesta
  ALLOW inbound  TCP ← google.com porta 443   ← la risposta (serve regola esplicita)

  Senza la seconda regola, la risposta viene bloccata — il router non sa che l'avevi chiesta tu.
• Usato dove la performance è critica e il volume è enorme: backbone internet, CDN, AWS NACL, Cisco ACL su router enterprise.

Stateful:

#

• Usa SPI (Stateful Packet Inspection) — la tecnologia che rende un firewall "stateful".
• Mantiene tabella di stato delle sessioni TCP/UDP attive — traccia il three-way handshake (SYN → SYN-ACK → ACK → ESTABLISHED → FIN).
• Permette automaticamente il traffico di ritorno di connessioni legittime — nessuna regola esplicita per la risposta.
• Opera a Layer 4. Anche chiamato Layer 4 firewall.
  • È proprio per questo che il firewall stateful opera a Layer 4 — perché traccia le sessioni TCP e UDP:
    • TCP ha stati espliciti: SYN → SYN-ACK → ACK → ESTABLISHED → FIN
    • UDP non ha stati nativi, ma il firewall stateful li simula tracciando source/destination IP+porta
• Usato ovunque la sicurezza è priorità: router di casa (SPI integrato), firewall aziendali, perimetro di rete.
• Vulnerabile a SYN flood: l'attaccante manda milioni di SYN senza completare il handshake → la tabella sessioni si riempie → firewall crasha. Non funziona contro stateless — non ha tabella da riempire.

WAF (Web Application Firewall):

#

• Protegge web server da attacchi applicativi: SQLi, XSS, CSRF.
• Opera a Layer 7. Posizionato nella screened subnet (DMZ) davanti al web server.
• Non sostituisce il network firewall — si aggiunge come layer extra (defense-in-depth).
• PCI-DSS lo rende obbligatorio per qualsiasi applicazione che gestisce dati di carte di credito.

Posizionamento:

Internet → [Network Firewall] → [DMZ] → [WAF] → [Web Server]

Esempio: attaccante manda GET /login?user=admin'-- (SQL injection) su HTTPS porta 443 → network firewall lo lascia passare (traffico legittimo) → WAF legge il payload HTTP, riconosce il pattern SQLi → blocca.

Esempio log WAF reale (quello che vedi in produzione):

[2026-05-21 14:32:01] ID:9876 URL:/index.cgi
Service IP: 192.168.1.10:80 (web server demo1, HTTP)
Client IP: 45.33.32.156 (US)
Attack: SQL Injection in Parameter — BLOCKED (security policy)

Il log mostra: timestamp, URL colpita, IP del server, IP del client con paese, tipo di attacco, azione applicata. Utile per forensics e per capire da dove arrivano gli attacchi.

ModSecurity + OWASP CRS è lo stack open source standard:

• ModSecurity = il motore WAF (modulo Apache/Nginx)
• OWASP CRS (Core Rule Set) = le regole che riconoscono SQLi, XSS, CSRF, path traversal

Come developer PHP/Symfony: se hai configurato Apache o Nginx, ModSecurity è il WAF che si installa come modulo. Se il sito usava Cloudflare, avevi un WAF attivo senza saperlo.

NGFW (Next-Generation Firewall):

#

• NGFW = Next-Generation Firewall — 3a generazione di firewall.
  • 1a generazione: stateless — filtra su ACL (IP/porta/protocollo)
  • 2a generazione: stateful — aggiunge stato sessione (three-way handshake)
  • 3a generazione (NGFW): aggiunge DPI, application awareness, user identity, content filtering
• Deep Packet Inspection (DPI) — analizza il contenuto del pacchetto come Wireshark, ma in tempo reale e automatico su milioni di pacchetti/secondo.
• Opera a Layer 7. Anche chiamato Layer 7 firewall.
• Identifica applicazioni indipendentemente dalla porta — BitTorrent su porta 443 sembra HTTPS per il stateful, il NGFW riconosce il pattern del protocollo nel payload e lo blocca.
• Anche chiamato: application layer gateway, stateful multilayer inspection, deep packet inspection.
• Usa ACL ma le estende — non le sostituisce. Le regole sono più avanzate:
  • Stateful: DENY TCP any any port 443 — blocca per porta
  • NGFW: DENY APP BitTorrent — blocca per applicazione, qualunque porta usi
• IPS integrato — il NGFW mantiene una lista di vulnerabilità note e blocca i relativi exploit direttamente nel firewall.
• URL categorization — blocca categorie intere (gambling, adult) o URL specifici (espn.com, yahoo.com).

Esempi pratici di regole NGFW (impossibili su stateful):

• Twitter: permetti lettura, blocca il posting — stessa porta 443, applicazione diversa
• SQL Server: permetti il traffico indipendentemente dalla porta usata
• YouTube: blocca la visione dei video ma permetti la navigazione del sito

Cosa vede ogni firewall — dal pacchetto al contenuto:

Stateless:  [IP src] [IP dst] [porta]                                    → ACL → passa/blocca
Stateful:   [IP src] [IP dst] [porta] [stato TCP]                        → passa/blocca
NGFW:       [IP src] [IP dst] [porta] [stato TCP] [app] [utente] [contenuto] → passa/blocca

Host-Based Firewall:

• Software sull'host individuale (Windows Defender Firewall, iptables/ufw).
• Protegge il singolo host — monitora il traffico che passa per la NIC.
• Usato in azienda su ogni server per bloccare lateral movement anche da traffico interno alla LAN.

Network-Based Firewall:

• Hardware dedicato (appliance) o virtual appliance — ha due o più NIC (Network Interface Card), una lato internet, una lato LAN.
• Tutto il traffico deve fisicamente passarci attraverso.
• Posizionato al perimetro, tra internet e la rete interna.
• Vendor enterprise: Palo Alto (NGFW più quotato negli annunci di lavoro), Cisco ASA, Fortinet.

A casa li hai già entrambi: il router (network firewall, NAT + SPI) e Windows Defender (host-based sul PC). In azienda si usano insieme come parte della strategia defense in depth — il network firewall blocca al perimetro, l'host-based ferma gli attacchi interni.

Defense-in-depth — host-based + network firewall:

Nessun singolo controllo è sufficiente. Se uno fallisce, il successivo ferma l'attacco:

Internet
    │
[Network firewall]     ← Layer 1: blocca al perimetro
    │
[Switch + VLAN]        ← Layer 2: segmenta la rete interna
    │
[Host-based firewall]  ← Layer 3: protegge il singolo server
    │
[Applicazione]         ← Layer 4: autenticazione, autorizzazione

Scenario reale: un attaccante bypassa il network firewall con traffico HTTPS cifrato che sembra legittimo → entra nella LAN → tenta lateral movement verso il DB server → l'host-based firewall del DB server blocca la connessione non autorizzata. Senza host-based firewall, una volta dentro la LAN si muove liberamente.

Topologia casa:

                        [Router/Firewall consumer]
                         NIC 0: IP pubblico ISP
                         NIC 1: 192.168.1.1
                         Switch integrato (4 porte)
Internet ──────────────────────┤
                               ├── PC        192.168.1.10
                               ├── Laptop    192.168.1.11
                               └── Telefono  192.168.1.12 (Wi-Fi)

Il router consumer è router + firewall (NAT/SPI) + switch + access point — tutto in un box.

Topologia aziendale:

Internet
    │
    │ IP pubblico
    │
[Firewall hardware]  ← Palo Alto / Cisco ASA (NGFW)
    │   NIC 0: WAN (internet)
    │   NIC 1: DMZ
    │   NIC 2: LAN
    │
    ├──[DMZ]──────────────────────────────────────
    │         Web server   Mail server   CA
    │
    └──[Switch core]──────────────────────────────
              │
              ├── [Switch piano 1] ── PC, workstation
              ├── [Switch piano 2] ── PC, workstation
              ├── [Server farm]    ── DB, file server
              └── [Jump server]    ── accesso admin
                       │
                    [Host-based firewall su ogni server]

Il firewall hardware fa da router perimetrale — gestisce il traffico tra internet, DMZ e LAN. Gli switch interni distribuiscono il traffico nella LAN senza passare dal firewall.

Hardware vs Virtual/Software — quando si sceglie:

Palo Alto offre entrambi: PA-series (hardware), VM-series (virtual appliance), Prisma Cloud (cloud-native) — stessa interfaccia, stesso set di regole.

Topologia cloud (AWS):

Internet
    │
[AWS Edge / CloudFront]
    │
[AWS Network Firewall]  ← equivalente Palo Alto, tutto virtuale
    │
    ├──[Public Subnet / DMZ]─────────────────────
    │         EC2 web server    Load Balancer
    │         [Security Group]  ← host-based firewall virtuale
    │
    └──[Private Subnet / LAN]────────────────────
              EC2 app server    RDS database
              [Security Group su ogni istanza]

In cloud non esistono switch fisici — tutto il networking è software dentro il VPC (Virtual Private Cloud):

Riepilogo esame — i tre tipi a confronto:

Domande esame tipiche:

• "Quale firewall blocca SQL injection?" → WAF — stateless e stateful non leggono il payload HTTP
• "Differenza tra stateless e stateful?" → entrambi usano ACL, ma stateful considera lo stato della sessione (SPI)
• "WAF sostituisce il network firewall?" → No — si aggiunge come layer extra (defense-in-depth)

Regole Firewall

#

Regole applicate in ordine sequenziale — la prima che corrisponde vince. Regole specifiche prima di quelle generali.

Chain (catena di regole)

Una chain è una lista ordinata di regole. Il pacchetto le attraversa dall'alto verso il basso finché non trova una regola che matcha — lì viene processato (ACCEPT, DROP, o saltato in un'altra chain).

Le tre chain principali di iptables:

L'ordine conta: una regola aggiunta con -A (append) va in fondo. Se una chain UFW/firewall occupa le prime posizioni, le regole manuali aggiunte dopo potrebbero non essere mai raggiunte — il pacchetto è già stato processato prima.

# Corretto su sistema con UFW
sudo ufw allow proto tcp from 192.168.64.200 to any port 9999
sudo ufw status numbered   # verifica
sudo ufw delete [numero]   # rimuovi

# Raw iptables — solo su sistemi senza UFW
sudo iptables -A INPUT -p tcp --dport 9999 -j ACCEPT

Struttura di una regola ACL — 5 elementi:

IP come protocollo = blocca tutto (TCP + UDP + ICMP) — IP è Layer 3 e incapsula tutto quello che sta sopra. TCP blocca solo TCP, UDP solo UDP.

PERMIT TCP    any  192.168.1.10  443   ← permetti HTTPS al web server
PERMIT TCP    any  192.168.1.10  22    ← permetti SSH
DENY   IP     any  any                 ← blocca tutto il resto (TCP+UDP+ICMP)

→ Lab pratico: lab-router-acl-iptables — Fase 5: scrittura regole complete

Explicit deny — regola finale esplicita scritta dall'admin: deny any any / deny any / drop all. Implicit deny — alcuni dispositivi la aggiungono automaticamente come ultima riga.

Cosa hanno in comune — e quale si usa oggi

#

Tutti e 4 filtrano traffico con implicit deny. Tutti usano ACL — la differenza è quanto in profondità guardano il pacchetto:

Quale si usa oggi — si usano insieme in layers:

Internet
    │
[NGFW]        ← perimetro — sostituisce stateless+stateful, aggiunge DPI
    │
[WAF]         ← davanti ai web server nella DMZ
    │
[Host-based]  ← iptables/ufw su ogni server

Il NGFW ha sostituito stateless e stateful puri nel perimetro aziendale. Stateless puro rimane solo su backbone internet e AWS NACL per performance. Il WAF non è alternativo al NGFW — si aggiunge specificamente davanti ai web server.

Failure Modes

#

Si applica a qualsiasi security system che fa enforcement — principalmente firewall, router con ACL, WAF, IPS. Non IDS (che rileva ma non blocca).

Esempi concreti di guasto:

I security professional preferiscono fail-closed — un firewall che crasha e lascia passare tutto è peggio di nessun firewall, perché dà falsa sicurezza. Eccezione: sistemi dove la disponibilità è critica (ospedali, infrastrutture) — lì si valuta caso per caso.

Implementing Network Designs

#

mindmap
  root((Implementing
Network
Designs))
    Screened Subnet DMZ
      FW1 internet verso DMZ
      FW2 DMZ verso LAN
      Web Mail CA server in DMZ
      Due vendor diversi best practice
    Intranet Extranet
      Intranet solo dipendenti LAN
      Extranet partner fornitori zona separata
      Security zones Trusted Untrusted Screened
    NAT
      Traduce IP privato in pubblico
      PAT stesso IP pubblico porte diverse
      Static NAT 1 a 1 server pubblici
      Dynamic NAT pool ISP
      IPsec incompatibile usa NAT-T
    Segmentazione
      Air gap fisico totale SCADA militare
      VLAN logica stesso switch
      Router ACL subnet diverse
      Screened subnet due FW buffer
    Proxy
      Forward proxy LAN client verso internet
      Transparent proxy invisibile al client
      Reverse proxy DMZ protegge server LAN
      Cache content filter log
    Content Filtering
      Blocklist tutto il resto permesso
      Allowlist tutto il resto bloccato
      URL filtering blacklist domini
      DNS filtering blocca prima connessione
    UTM
      Un solo dispositivo tutto incluso
      Firewall URL malware IPS VPN
      SMB budget limitato
      Layer 4 solo porte non app

Screened Subnet (DMZ)

#

La screened subnet è un cuscinetto (buffer zone) tra internet e la LAN interna, protetta da due firewall:

• FW1 — tra internet e la DMZ (firewall perimetrale)
• FW2 — tra la DMZ e l'intranet (firewall interno, protegge la LAN)

I server pubblici (web, mail, CA) stanno nella DMZ — raggiungibili da internet, ma la stessa chiamata che arriva al mail server non passa davanti a FW2. FW2 protegge la LAN interna e non la vede mai direttamente.

graph TD
    I["Internet
    Public IPs"] --> FW1["FW1
    Firewall perimetrale
    (tra internet e DMZ)"]
    FW1 --> DMZ["DMZ — Screened Subnet
    Mail Server | Web Server | CA Server"]
    DMZ --> FW2["FW2
    Firewall interno
    (tra DMZ e intranet — protegge la LAN)"]
    FW2 --> LAN["Intranet — LAN interna
    DB Server | Private IPs"]

Perché esiste la DMZ — il problema che risolve:

Senza DMZ il web server starebbe nella LAN. Quando viene compromesso, l'attaccante è già dentro con accesso a DB, PC e tutto il resto. Con la DMZ, la compromissione rimane confinata al cuscinetto — FW2 blocca prima che raggiunga la LAN. Stesso principio dell'hardening: limitare il blast radius.

Come funzionano le regole sui due firewall:

Cosa può stare nella DMZ:

• Web server (HTTP/HTTPS), Mail server (SMTP), CA server
• FTP server, VPN server, WAF, Jump server

Esempio e-commerce — flusso completo:

Browser utente
    │ HTTPS 443
    ▼
[FW1] — regola: PERMIT TCP any → 192.168.2.10 (web server) port 443
    │
    ▼
Web Server (192.168.2.10) — DMZ
PHP/Symfony riceve la richiesta, deve caricare i prodotti dal DB:
$pdo = new PDO('mysql:host=192.168.1.20;dbname=shop', $user, $pass);
    │ SQL query porta 1433
    ▼
[FW2] — regola: PERMIT TCP 192.168.2.10 → 192.168.1.20 port 1433
         DENY   TCP any               → 192.168.1.20 port 1433
    │
    ▼
DB Server (192.168.1.20) — LAN interna
Risponde solo al web server, mai direttamente al browser

FW1 permette traffico verso il web server (porta 443). Il web server fa la query al DB. FW2 accetta chiamate AL DB solo DAL web server (IP specifico) — dall'esterno nessuno può raggiungere il DB direttamente, nemmeno conoscendo il suo IP. Un attaccante che bypassa FW1 è nella DMZ ma trova FW2 davanti al DB.

Perché FW1 e FW2 dovrebbero essere vendor diversi:

Security best practice: se un attaccante trova una vulnerabilità zero-day in Palo Alto e bypassa FW1, si trova davanti FW2 di Fortinet — architettura diversa, exploit diverso necessario. Due vendor = doppio ostacolo.

Intranet vs Extranet

#

In azienda raramente si esce su internet direttamente — a differenza di casa dove il router è l'unico layer. Il traffico passa attraverso più layer di controllo prima di uscire:

PC dipendente
    │
Switch interno
    │
Firewall interno (NGFW)   ← filtra e monitora
    │
Proxy / DMZ               ← logga tutto il traffico
    │
Firewall perimetrale      ← secondo layer di controllo
    │
Internet

Questo per sicurezza, controllo (l'azienda vede tutto il traffico) e compliance (banche, healthcare devono dimostrare che nessun dato esce senza controllo).

Security zones = dividere la rete per limitare chi parla con chi. Se un attaccante entra in una zona, non può raggiungere le altre — riduce la attack surface.

Le zone hanno nomi che descrivono il livello di fiducia:

Le regole firewall si scrivono in termini di zone: "permetti traffico da Untrusted a Screened su porta 443" — più leggibile e manutenibile di regole su singoli IP.

NAT — Network Address Translation

#

NAT traduce IP privati in pubblici (uscita) e IP pubblici in privati (rientro). Il NAT gateway è tipicamente il router — gestisce la traduzione in entrambe le direzioni automaticamente insieme al firewall stateful (SPI traccia la sessione, NAT traduce gli indirizzi).

PC (192.168.1.10) → richiesta google.com
    │
NAT Gateway
  Traduce:  192.168.1.10:52341 → 85.x.x.x:52341   (privato → pubblico)
  Registra: 85.x.x.x:52341 ↔ 192.168.1.10:52341   (tabella NAT)
    │
Google risponde a 85.x.x.x:52341
    │
NAT Gateway
  Consulta tabella: 85.x.x.x:52341 → 192.168.1.10:52341
  Traduce:  85.x.x.x:52341 → 192.168.1.10:52341   (pubblico → privato)
    │
PC riceve la risposta

PAT — Port Address Translation:

La forma più comune di NAT. Invece di usare IP pubblici diversi per ogni device, usa lo stesso IP pubblico con porte sorgente diverse — è quello che fa il router di casa:

PC1 (192.168.1.10:52341) → 85.x.x.x:52341
PC2 (192.168.1.11:61200) → 85.x.x.x:61200   ← stesso IP pubblico, porta diversa
PC3 (192.168.1.12:44100) → 85.x.x.x:44100

Tutti e tre i device condividono un solo IP pubblico — il NAT li distingue tramite la porta.

Static NAT vs Dynamic NAT:

Esempio Fastweb — due NAT in cascata:

Fastweb ha milioni di clienti consumer. Non ha abbastanza IP pubblici per dargliene uno fisso a testa → usa Dynamic NAT (o CGNAT) lato infrastruttura, PAT lato router di casa:

PC (192.168.1.10)
PC (192.168.1.11)  → PAT router di casa → 85.x.x.x (IP Fastweb)
PC (192.168.1.12)
        ↑                                      ↑
  NAT interno                          Dynamic NAT Fastweb
  (router di casa)                     (IP dal pool, cambia ad ogni connessione)

• Piano consumer (IP dinamico): Fastweb assegna un IP dal pool ogni volta che il router si connette. L'IP può cambiare — per questo serve DDNS se vuoi essere raggiungibile dall'esterno.
• Piano business (IP fisso): Static NAT — Fastweb mappa sempre lo stesso IP pubblico alla tua linea. Serve per ospitare server raggiungibili dall'esterno.

Drawback — incompatibilità con IPsec:

IPsec firma il pacchetto includendo l'header IP con gli indirizzi. Quando NAT cambia l'indirizzo IP sorgente, la firma non corrisponde più → IPsec fallisce. Soluzione: NAT-T (NAT Traversal) — incapsula il traffico IPsec dentro UDP porta 4500, bypassando il problema. Se il tuo design include IPsec attraverso NAT, devi verificare attentamente la compatibilità.

Segmentazione di Rete

#

Segmentare il traffico = dividere la rete in zone isolate in modo che una compromissione in una zona non si propaghi alle altre.

Senza segmentazione tutti i device si vedono — un attaccante che entra da qualsiasi punto raggiunge tutto. Con segmentazione ogni zona parla solo con chi deve, il resto è bloccato.

• Air gap — isolamento fisico totale. Nessun cavo, nessuna connessione di rete. L'unico modo per trasferire dati è fisicamente (USB, microSD, CD).
  • SCADA (Supervisory Control and Data Acquisition) — sistemi industriali che controllano infrastrutture critiche: centrali elettriche, acquedotti, gasdotti, fabbriche. Tenuti in air gap perché un attacco informatico può causare danni fisici reali. Esempio famoso: Stuxnet (2010) ha colpito centrifughe nucleari iraniane nonostante l'air gap — tramite una USB infetta portata fisicamente dentro.
  • Reti militari / classificate — documenti top secret su reti fisicamente separate da internet.
  • Hardware wallet Bitcoin (Coldcard) — le chiavi private non escono mai dal dispositivo. Per firmare: PC online crea transazione non firmata → microSD → Coldcard firma offline → microSD → PC fa broadcast. Un attaccante che compromette il PC non vede mai le chiavi.
• VLAN — segmentazione logica sugli switch
• Router con ACL — separazione logica con controllo traffico
• Screened subnet — zona isolata tra due firewall

Load Balancer

#

Distribuisce il traffico tra più server backend. Migliora disponibilità e prestazioni. NAT usato insieme: un IP pubblico → più IP privati backend.

Proxy Server

#

Proxy = procuratore, intermediario. Va su internet al posto tuo — il sito vede l'IP del proxy, non il tuo. Anche chiamato forward proxy server.

Senza proxy:
PC → google.com direttamente

Con proxy (forward proxy):
PC → Proxy server → google.com
              ↑
         va lui, non tu

Google vede l'IP del proxy, non il tuo. Il proxy recupera la risposta e te la passa.

Come ti difende:

• Il sito vede l'IP del proxy — se il sito è malevolo non sa chi sei
• Controlla la richiesta prima di inoltrarla — se il sito è in blacklist ti blocca prima che tu ci arrivi, mostrando una pagina warning

Forward Proxy:

graph LR
    C["Client LAN"] --> FP["Forward Proxy
    Cache - Filter - Log"]
    FP --> I["Internet"]

Il client configura esplicitamente il proxy. Funzioni principali:

Cache — performance: Il proxy salva le pagine già visitate. Se Lisa apre GetCertifiedGetAhead.com, il proxy la memorizza. Quando Homer apre la stessa pagina, il proxy gliela dà dalla cache senza uscire su internet — risparmio di banda, risposta più veloce. Cache = storage temporaneo (RAM o disco veloce).

Content filtering: Il proxy controlla ogni richiesta contro una blacklist di URL (siti malware, phishing, gambling, contenuti vietati). Le liste vengono comprate in abbonamento da vendor specializzati che categorizzano milioni di siti. Se il sito è in blacklist → blocca + mostra pagina warning con riferimento alla acceptable use policy. I log registrano ogni sito visitato da ogni utente.

Centralized vs Agent-based:

Proxy vs Firewall — content filtering:

Transparent Proxy: stesso lato del forward proxy — sta nella LAN interna, serve i client. Non confonderlo con il reverse proxy che sta nella DMZ. L'unica differenza è che il client non sa di usarlo — nessuna configurazione necessaria.

Dove si trovano i tre proxy nella topologia:

Internet  ← bordo esterno
    │
[FW1]     ← firewall perimetrale (tra internet e DMZ)
    │
[DMZ]     ← zona buffer
  ├── Reverse proxy    ← riceve da internet, passa ai server LAN
  ├── Mail server
  └── CA server
    │
[FW2]     ← firewall interno (tra DMZ e intranet)
    │
[LAN interna / Intranet]
  ├── Forward proxy    ← serve i client interni per uscire su internet
  ├── Transparent proxy← stesso posto del forward, invisibile ai client
  ├── DB server
  └── PC dipendenti    ← bordo interno

Internet
    │
[FW1]
    │
[DMZ]
  ├── Reverse proxy   ← riceve richieste da internet, le passa ai server LAN
  ├── Mail server
  └── CA server
    │
[FW2]
    │
[LAN interna]
  ├── Forward proxy   ← serve i client interni per uscire su internet
  ├── DB server
  └── PC dipendenti

Reverse Proxy:

graph LR
    I["Internet"] --> RP["Reverse Proxy DMZ"]
    RP --> WS1["Web Server 1 LAN"]
    RP --> WS2["Web Server 2 LAN"]

Sta nella DMZ. Appare ai client come un web server, ma in realtà inoltra le richieste ai web server reali nella LAN interna. I client non conoscono mai gli IP reali dei server.

Senza reverse proxy: Il web server starebbe direttamente nella DMZ con IP pubblico noto — chiunque su internet può targetarlo direttamente. Con il reverse proxy il web server si nasconde nella LAN privata — l'attaccante deve bucare prima il reverse proxy e poi ancora FW2 prima di arrivarci.

Flusso esempio — Bart apre GetCertifiedGetAhead.com:

Bart → reverse proxy (DMZ) → web server (LAN) → risposta → reverse proxy → Bart

Bart pensa di parlare con il web server — in realtà parla sempre con il reverse proxy. Il web server non è mai esposto.

Funzioni del reverse proxy:

• Cache — salva le pagine come il forward proxy → migliora le performance del sito
• Load balancing — distribuisce le richieste tra più web server (web farm) → scalabilità
• SSL termination — gestisce HTTPS al posto del web server → meno carico sul server
• Protezione — nasconde IP e architettura interna

Transparent vs Non-transparent proxy:

Caching Proxy: memorizza risposte precedenti. Riduce larghezza di banda.

Centralized vs Agent-Based:

• Centralized — singolo server proxy per tutta la rete
• Agent-based — software su ogni client

Content Filtering e Web Filter

#

Content Filtering: blocca categorie di siti (social media, gambling).

URL Filtering: blacklist di domini specifici.

URL Scanning e Reputation: analisi in tempo reale + punteggio di reputazione per siti non ancora in blacklist.

Block Rules e Open/Closed Lists:

• Blocklist — siti bloccati, tutto il resto permesso
• Allowlist — siti permessi, tutto il resto bloccato (più sicuro)

DNS Filtering: blocca a livello DNS prima che la connessione venga stabilita.

UTM — Unified Threat Management

#

UTM = un solo dispositivo che fa tutto quello che prima richiedeva apparecchi separati.

Prima ogni minaccia aveva la sua soluzione separata — firewall, proxy, antivirus gateway, IPS, spam filter — dispositivi diversi, console diverse, admin diversi. UTM li combina in uno:

UTM appliance
  ├── Firewall
  ├── URL filtering        (come il proxy)
  ├── Malware inspection   (antivirus gateway)
  ├── Content inspection   (spam filter, blocco file zip, streaming)
  ├── Spam filter          (blocca email indesiderate)
  ├── IDS/IPS              (rileva e blocca attacchi)
  ├── VPN concentrator     (endpoint VPN per remote worker)
  ├── Bandwidth shaper / QoS  (priorità al traffico voce su dati)
  ├── CSU/DSU              (connettività WAN — linee dedicate)
  └── DDoS mitigator

Un solo dispositivo, una sola console, un solo rinnovo di licenza.

Drawback importante: molti UTM lavorano solo a Layer 4 — vedono solo porte, non applicazioni. Attivare troppe feature contemporaneamente degrada le performance — spesso si abilitano solo le funzioni essenziali per non rallentare tutto.

Chi lo usa:

• Aziende piccole/medie — budget limitato, pochi admin, non possono gestire 5 dispositivi separati
• Enterprise — preferiscono soluzioni separate (best-of-breed per ogni funzione) con più controllo

Dove sta: al bordo della rete tra internet e intranet — stesso posto di FW1. Se usato come proxy può stare nella DMZ.

Prodotti comuni: Fortinet

Zero Trust

#

mindmap
  root((Zero Trust))
    Principio
      Never trust always verify
      Identita non posizione
      Anche utenti interni verificati
    Adaptive Identity
      PC aziendale ufficio solo password
      Da casa MFA password OTP
      Device personale MFA postura
      IP anomalo blocco alert
    Control Plane DECIDE
      PE Policy Engine giudice grant deny
      PA Policy Administrator messaggero
      PE + PA = PDP
    Data Plane ESEGUE
      PEP Policy Enforcement Point gatekeeper
      Attraversa il confine tra i piani
      Blocca finche PA non decide
    Flusso
      Utente chiede accesso
      PEP raccoglie info passa a PA
      PE valuta contesto grant deny
      PA comunica al PEP
      PEP permette o blocca
    Componenti Data Plane
      Subject utente
      System device
      Enterprise resource obiettivo
      PEP unico a attraversare il confine

Principio fondamentale: nessun utente, dispositivo o sistema è fidato per default, indipendentemente dalla posizione.

Perché è nato Zero Trust — il perimetro non esiste più:

La vecchia filosofia era l'implicit trust — chi era dentro il perimetro della rete era fidato, chi era fuori no. Funzionava quando tutti i dipendenti erano in ufficio e tutto stava nella LAN.

Il problema della LAN aperta: nelle reti tradizionali, una volta dentro la LAN sei libero di muoverti da sistema a sistema senza controlli. Questo vale per gli utenti autorizzati, ma anche per gli attaccanti che hanno bucato il perimetro e per il malware. Zero Trust risolve questo: anche dentro la LAN devi autenticarti per ogni risorsa.

Oggi non funziona più:

• Remote worker da casa → fuori dal perimetro
• Cloud (AWS, Azure) → fuori dal perimetro
• BYOD (dispositivi personali) → dentro il perimetro ma non controllati

Il perimetro è diventato irrilevante — Zero Trust ignora la posizione e si concentra sull'identità.

Analogia:

• Vecchio modo: ufficio con badge — entri, sei fidato, puoi girare liberamente
• Zero Trust: aeroporto — passi il controllo passaporti, poi security, poi ancora il gate. Ogni step verifica. Essere "dentro" non ti dà automaticamente accesso a tutto.

Zero Trust: "Never trust, always verify."

Adaptive Identity — il livello di autenticazione cambia in base al contesto:

Il sistema valuta continuamente: chi sei, da dove accedi, che device usi, che ora è, che risorsa vuoi — e decide il livello di verifica necessario.

graph TD
    subgraph CP["Control Plane - DECIDE"]
        PE["Policy Engine PE
        Valuta la richiesta
        Grant o Deny"]
        PA["Policy Administrator PA
        Comunica la decisione
        Genera token di sessione"]
    end
    subgraph DP["Data Plane - ESEGUE"]
        PEP["Policy Enforcement Point PEP
        Permette o blocca l'accesso"]
    end
    U["Utente o Device"] --> PEP
    PEP --> PA
    PA --> PE
    PE --> PA
    PA --> PEP
    PEP --> R["Risorsa"]

Control Plane vs Data Plane:

Vale per qualsiasi dispositivo — fisico (switch, router, firewall), virtuale (vSwitch, vFirewall), o cloud. Separati perché: se un attaccante accede al Control Plane può riconfigurare tutta la rete. Tenerli separati limita il blast radius.

I tre componenti:

• Policy Engine (PE) — il giudice. Valuta la richiesta e decide grant/deny basandosi su policy e contesto.
• Policy Administrator (PA) — il messaggero. Comunica la decisione del PE al PEP. PE + PA insieme = PDP (Policy Decision Point).
• Policy Enforcement Point (PEP) — il gatekeeper (buttafuori). Tutto il traffico passa attraverso di lui. Non decide — raccoglie le informazioni e le passa al PDP, poi applica la decisione ricevuta.

Flusso:

Utente vuole accedere a una risorsa
    │
[PEP]  ← blocca finché non arriva la decisione
    │
[PA]   ← gira la richiesta al PE
    │
[PE]   ← valuta: chi è? da dove? che device? che ora? → grant o deny
    │
[PA]   ← comunica la decisione al PEP
    │
[PEP]  ← permette o blocca l'accesso

• Adaptive Identity — il livello di autenticazione cambia in base al contesto (vedi tabella sopra).
• Threat scope reduction — accesso minimo necessario per ridurre la superficie di attacco.
• Policy-driven access control — ogni accesso governato da policy esplicite, non fiducia implicita.

Componenti del Data Plane:

Il PEP attraversa il confine tra i due piani — è l'unico sistema che può farlo. Deve ricevere istruzioni dal PA (Control Plane) e poi eseguirle nel Data Plane. È il ponte tra chi decide e chi agisce:

CONTROL PLANE          │  DATA PLANE
                       │
PE → PA ─────────────→ PEP ──────────→ Risorsa
        istruzioni     │    esegue
                       │
              unico che attraversa il confine

SASE — Secure Access Service Edge

#

mindmap
  root((SASE
Secure Access
Service Edge))
    Definizione
      Zero Trust erogato dal cloud
      Nessun hardware in azienda
      Ovunque sia utente ufficio casa bar
    Servizi inclusi
      ZTNA Zero Trust Network Access
      FWaaS Firewall as a Service
      SWG Secure Web Gateway proxy
      CASB Cloud Access Security Broker
      DLP Data Loss Prevention
      IPS Intrusion Prevention
    UTM vs SASE
      UTM appliance fisica on-premise SMB
      SASE cloud distribuito remote work
      SASE scala elastica automatica

SASE = Zero Trust + tutti i servizi di sicurezza, erogati dal cloud.

È l'evoluzione di Zero Trust — invece di installare firewall, proxy, IPS in azienda, tutti questi servizi arrivano dal cloud e si applicano ovunque sia l'utente (ufficio, casa, bar). SASE è l'evoluzione di Zero Trust erogata interamente tramite servizi Cloud.

Servizi inclusi in SASE:

Differenza UTM vs SASE:

Enterprise Security Capabilities

#

mindmap
  root((Enterprise
Security
Capabilities))
    Group Policy
      AD Windows dominio
      Password firewall aggiornamenti
      Propaga automaticamente a tutti i PC
    DLP
      Blocca trasmissione dati sensibili
      PAN PII dati classificati
      Agent endpoint o rete traffico uscita
    FIM
      Hash file critici vs baseline
      Modifica non autorizzata alert
    Email Protocolli
      SMTP 25 SMTPS 465 STARTTLS 587
      POP3 110 POP3S 995 scarica locale
      IMAP 143 IMAPS 993 resta server
    SPF DKIM DMARC
      SPF record TXT IP autorizzati
      DKIM firma digitale chiave privata
      DMARC policy OR SPF o DKIM
      none quarantine reject
    S/MIME
      Cifra contenuto email end-to-end
      Firma digitale body
      Certificato X.509 del destinatario
      Diverso da SPF DKIM protegge canale

OS Security — Group Policy

#

Group Policy permette agli amministratori di definire e applicare configurazioni di sicurezza a tutti i sistemi Windows nell'organizzazione tramite Active Directory.

Esempi: requisiti password, blocco applicazioni, firewall host, gestione aggiornamenti. Una modifica si propaga automaticamente a tutti i computer del dominio.

DLP — Data Loss Prevention

#

Monitora, rileva e blocca la trasmissione non autorizzata di dati sensibili:

• Upload di file con PAN (numeri carte di credito) via email
• Copia di dati classificati su USB
• Invio di PII tramite cloud non autorizzato

Opera su endpoint (agent) o sulla rete (analisi traffico in uscita).

FIM — File Integrity Monitoring

#

Verifica che i file critici di sistema non siano stati modificati non autorizzatamente. Confronta l'hash corrente con un baseline. Se l'hash cambia → alert.

Email

#

SMTP usa STARTTLS per aggiornare una connessione non cifrata (porta 25) a TLS. Porta 587 = submission client→server con STARTTLS.

POP3 vs IMAP — differenza critica:

Email Security — SPF, DKIM, DMARC

#

SPF (Sender Policy Framework)

#

usa record DNS TXT per definire quali server sono autorizzati a inviare email per conto di un dominio. Puoi specificare IP diretti (ip4:1.2.3.4) o usare include:_spf.aruba.it che delega la lista degli IP autorizzati al record SPF di Aruba — alla fine della catena ci sono sempre IP, ma non devi scriverli tu. Il server ricevente controlla il record SPF e verifica che l'IP mittente sia autorizzato.

DKIM (DomainKeys Identified Mail)

#

usa crittografia a chiave pubblica per firmare digitalmente le email. La firma viene aggiunta all'header. Il server ricevente verifica la firma usando la chiave pubblica pubblicata nel DNS. Garantisce integrità e autenticità.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

#

costruito sopra SPF e DKIM. Permette al proprietario del dominio di definire la policy su cosa fare se falliscono (none/quarantine/reject) e fornisce reporting.

Diagramma 1 — Cosa configuri tu nel DNS:

graph TD
    DNS["TUO DNS
    antonelladigilio.it"]

    DNS --> SPF_R["SPF - record TXT su root
    Aruba autorizzato
    Systeme.io autorizzato
    softfail per tutti gli altri"]

    DNS --> DKIM_A["DKIM - selettore a1
    chiave pubblica Aruba"]

    DNS --> DKIM_S["DKIM - selettore systemeio1
    chiave pubblica Systeme.io"]

    DNS --> DMARC_R["DMARC - record su _dmarc
    p=none
    report al tuo indirizzo rua"]

Diagramma 2 — Cosa fa il server ricevente:

graph TD
    MAIL["Email arriva da antonelladigilio.it"] --> SPF_C
    MAIL --> DKIM_C

    SPF_C["Controllo SPF
    IP mittente e' nella lista?"]

    DKIM_C["Controllo DKIM
    Legge selettore dall'header
    Recupera chiave pubblica dal DNS
    Verifica firma - integrita e autenticita"]

    SPF_C --> OR
    DKIM_C --> OR

    OR{"OR
    SPF pass
    oppure DKIM pass?"}

    OR -->|"Almeno uno passa"| OK["Consegna in inbox"]
    OR -->|"Entrambi falliscono"| POL["Applica policy DMARC
    p=none - consegna e manda report
    p=quarantine - metti in spam
    p=reject - rifiuta l'email"]

    OK --> REP["Report aggregato ogni 24h
    inviato al tuo indirizzo rua"]
    POL --> REP

Perché OR — il caso dell'inoltro email:

Quando Bob riceve una tua email e la inoltra a Carol, il server di Bob non è nella tua lista SPF → SPF fallisce inevitabilmente. Ma DKIM può sopravvivere: la firma originale è ancora nell'header, la chiave pubblica è ancora nel tuo DNS, il server di Carol la verifica e trova corrispondenza → DKIM pass.

DKIM fallisce solo se il body viene modificato (footer "Forwarded by X", alterazione MIME) — l'hash del body cambierebbe e la firma non corrisponderebbe più.

Se SPF e DKIM fossero AND, ogni inoltro legittimo verrebbe bloccato da DMARC. L'OR è una scelta architetturale consapevole.

Esempio SPF reale:

v=spf1 include:_spf.aruba.it include:_spf.systeme.io ~all

DMARC policy:

I report DMARC sono inviati dai server riceventi (Gmail, Outlook, GMX) ogni 24h all'indirizzo rua=. Contengono: IP mittente, count email, risultato SPF, risultato DKIM, azione applicata. Sono il sistema di allarme precoce per spoofing del dominio.

Perché SPF e DKIM stanno in record TXT: SPF aveva un record DNS dedicato (tipo 99) ma è stato deprecato nel 2014 con RFC 7208. TXT è il record "testo libero" di DNS — usato per tutto ciò che non ha un tipo dedicato. Il record va su @ (root del dominio) perché il mittente usa il dominio root.

RFC 1034 — CNAME e email: Un nodo con record CNAME non può avere altri record sullo stesso nome. Se corsi.antonelladigilio.it è un CNAME verso una piattaforma esterna, non può avere MX (email) né TXT (SPF). Si sceglie: CNAME per il sito web oppure MX per le email — non entrambi.

Email Gateway — dispositivo o applicazione che fa da barriera tra il sistema email interno e internet. Filtra email in entrata e in uscita per spam, malware e altre minacce. Posizionato tipicamente nella screened subnet.

Scenario reale — Business Email Compromise (BEC):

Il protocollo SMTP non verifica l'identità del mittente — chiunque può impostare From: a qualsiasi indirizzo. Prima di SPF/DKIM/DMARC era banale; ancora oggi funziona contro domini mal configurati.

Attori:

• Server legittimo di acme.com: IP 245.30.30.30
• VPS dell'attaccante: IP 210.1.1.1

Attacco:

1. L'attaccante su 210.1.1.1 installa un server SMTP
2. Imposta From: ceo@acme.com — SMTP non chiede credenziali per questo
3. Invia a contabilita@acme.com: "Urgente — bonifico 50.000€ al fornitore XYZ entro oggi"
4. Senza SPF/DKIM/DMARC: il server ricevente non ha strumenti per verificare — l'email arriva in inbox

Come SPF blocca: il server ricevente fa una query DNS per il record TXT di acme.com. Trova 245.30.30.30 autorizzato. L'email arriva da 210.1.1.1 → disuguaglianza → SPF fail.

Come DKIM blocca: il server legittimo 245.30.30.30 ha la chiave privata di acme.com e firma ogni email con essa. La chiave pubblica corrispondente è pubblicata nel DNS di acme.com (record TXT su selector1._domainkey.acme.com). L'attaccante su 210.1.1.1 non ha la chiave privata → non può generare una firma valida. Il server ricevente recupera la chiave pubblica dal DNS e prova a verificare la firma dell'attaccante → fail. La chiave pubblica è pubblica e disponibile — manca la privata all'attaccante.

Come DMARC chiude: entrambi falliscono → p=reject → email rifiutata prima che arrivi in inbox.

S/MIME — Secure/Multipurpose Internet Mail Extensions

#

S/MIME cifra e firma digitalmente il contenuto delle email — garantisce confidenzialita' e autenticita' del messaggio durante la trasmissione e lo storage.

Come funziona:

• Il mittente cifra l'email con la chiave pubblica del destinatario (solo lui puo' decifrarla)
• Il mittente firma l'email con la propria chiave privata (il destinatario verifica con la chiave pubblica del mittente)
• Entrambe le operazioni usano certificati X.509 — stessa infrastruttura PKI dei certificati web

Differenza chiave per l'esame:

SPF/DKIM/DMARC proteggono il canale di trasporto — verificano che il server mittente sia legittimo. S/MIME protegge il contenuto — cifra e firma il testo dell'email stessa. Possono coesistere.

Scenario Reale — Blue Team

#

Un analista Blue Team applica questi concetti ogni giorno:

• Verifica che i server nella DMZ non comunichino direttamente con i DB interni.
• Controlla che solo HTTPS/SFTP/SSH siano abilitati — firewall blocca FTP/Telnet/HTTP.
• Monitora il NAC per device non conformi in quarantena.
• Usa il jump server per accedere ai sistemi in produzione.
• Il WAF logga tentativi di SQLi sui web server nella DMZ.
• Il DLP blocca upload di file con PAN verso cloud non autorizzato.
• SNMP v3 monitora router e switch — v1/v2 disabilitati.
• I report DMARC segnalano IP sconosciuti che inviano email con il dominio aziendale.

Come developer PHP/Symfony: reverse proxy = screened subnet. NAT = X-Forwarded-For nei log. Group Policy = env vars applicate centralmente. SPF/DKIM = li configuri ogni volta che imposti un dominio per email transazionali (SendGrid, SES).

Trappole Esame Cap 3

#

Risorse

#

• Gibson SY0-701 Cap 3 — Get Certified Get Ahead (Kindle)
• Appendix C: Porte ufficiali — cap-03-well-known-ports
• Professor Messer: Secure Infrastructures · Firewall Types · Secure Communication

Collegato a

#

• network — protocolli, firewall, segmentazione, proxy
• system — OSI model, infrastruttura, Group Policy
• osi-model — dettaglio completo layer
• cap-03-well-known-ports — porte da sapere a memoria
• tcp-handshake — dettaglio three-way handshake
• tcp-udp — dettaglio TCP vs UDP
• icmp-mac-ip — ICMP, MAC, IP
• arp — ARP e ARP poisoning
• ssl-tls — SSL vs TLS in profondità
• cap-02-identity-access-management — IAM si integra con Zero Trust e NAC
• cap-01-security-fundamentals — basi
• indice-gibson-messer-burning-Ice — indice completo Gibson SY0-701