Perché la visibilità si degrada

Il lavoro del SOC dipende dalla capacità di osservare chi parla con chi e cosa viene trasmesso. Diverse tecnologie legittime — cifratura, traduzione degli indirizzi, incapsulamento — riducono o rimuovono questa visibilità. Non sono di per sé malevole, ma un analista deve sapere cosa viene nascosto e quale dato di monitoring rimane affidabile.

Encryption e TLS: il contenuto sparisce

Con TLS (e il predecessore SSL) il payload applicativo viaggia cifrato. Da una cattura di pacchetti o da un flusso NetFlow l’analista vede ancora gli header di rete (IP sorgente/destinazione, porte, dimensioni, timing) ma non URL, header HTTP, credenziali o file trasferiti. Restano visibili solo i metadati del handshake:

  • SNI (Server Name Indication) nel ClientHello, che rivela l’hostname richiesto — a meno di ECH/Encrypted Client Hello.
  • Il certificato del server (in TLS 1.2 in chiaro; in TLS 1.3 l’intero scambio di certificati è cifrato).
  • Versione, cipher suite, dimensioni e cadenza dei record.

Componenti di un certificato X.509

Campo Cosa contiene Uso per l’analista
Subject / CN / SAN Identità del server (FQDN) Confronto con SNI e DNS
Issuer CA emittente CA sconosciuta/self-signed = sospetto
Validity Date notBefore/notAfter Certificati appena creati o scaduti
Public Key Chiave pubblica del soggetto Base della cifratura asimmetrica
Serial / Thumbprint Identificativi univoci Pivoting su threat intel
Signature Firma della CA Catena di fiducia (chain of trust)

Questi elementi si inquadrano in una PKI: le CA firmano i certificati, i client validano la catena fino a una root CA fidata. Un certificato self-signed o firmato da una CA non nota è un classico indicatore di C2 o phishing.

TLS inspection

Per recuperare il contenuto si usa la TLS/SSL inspection (SSL decryption), tipicamente su un firewall come Firepower/FTD o un secure web proxy. Il dispositivo si interpone come man-in-the-middle autorizzato: termina la sessione TLS del client presentando un certificato firmato da una CA interna (deployata sugli endpoint aziendali), ispeziona il traffico in chiaro applicando IPS/AMP/URL filtering, poi ri-cifra verso il server reale. Senza la CA interna trusted sui client, l’utente riceverebbe errori di certificato. Traffico con certificate pinning o requisiti di privacy/compliance viene spesso escluso dalla decryption.

NAT e PAT: l’indirizzo sorgente mente

Il NAT riscrive gli indirizzi IP nell’header; il PAT (NAT overload) mappa molti host interni su un unico IP pubblico distinguendoli per porta sorgente. Effetto sul monitoring: un sensore posto all’esterno del confine NAT (o sul firewall dopo la traduzione) vede come sorgente l’IP pubblico tradotto, non l’indirizzo RFC1918 reale dell’host interno.

Conseguenza operativa: l’attribuzione diventa difficile. Per risalire all’host reale servono i log di traduzione NAT correlati per timestamp e porta, oppure una cattura a monte del NAT. Vale anche per CGNAT e per il NAT lato attaccante, che offusca l’origine reale di una scansione.

Tunneling, proxy e load balancing

  • Tunneling (IPsec/GRE, VPN SSL, DNS tunneling, ICMP tunneling): il pacchetto interno è incapsulato in un altro. L’analista vede l’header esterno (es. ESP tra due gateway) ma non il traffico trasportato; nei tunnel malevoli i dati vengono esfiltrati dentro protocolli “leciti”.
  • Proxy: il client dialoga col proxy, che apre una nuova connessione verso la destinazione. Sul segmento server-side la sorgente osservata è l’IP del proxy. I log del proxy (spesso con header X-Forwarded-For) sono la fonte per recuperare il client reale.
  • Load balancer: possono fare SNAT, per cui i server backend vedono come sorgente il balancer e non il client; anche qui X-Forwarded-For o log dedicati recuperano l’IP originale.

Trappole tipiche d’esame

  • Scenario: dopo un firewall con PAT il SIEM mostra un solo IP pubblico come sorgente di molte connessioni → la sorgente osservata è l’IP tradotto, non l’host interno reale; servono i log NAT (IP+porta+timestamp) per l’attribuzione.
  • Scenario: cattura di traffico HTTPS, si chiede quale campo rivela l’hostname senza decifrare → SNI nel ClientHello (in TLS 1.2 anche il certificato in chiaro); in TLS 1.3 il certificato è cifrato.
  • Scenario: l’organizzazione vuole applicare IPS/AMP al traffico cifrato in uscita → TLS/SSL inspection con CA interna distribuita sugli endpoint, non semplice deep packet inspection.
  • Scenario: i server web vedono tutte le richieste provenire da un unico IP interno → è un proxy/load balancer con SNAT; l’IP client reale è nell’header X-Forwarded-For o nei log del proxy.
  • Scenario: traffico DNS anomalo con record TXT enormi e alta frequenza → DNS tunneling per esfiltrazione/C2, esempio di dato nascosto dentro un protocollo consentito.