Come funziona una rete: TCP/IP, protocolli e la disposizione a strati

Se una rete la capisci a quattro strati, il novanta per cento dei problemi che vedrai in un assessment ha già una spiegazione. Il resto no, ma arriviamo anche lì.

La parte che quasi nessuno spiega bene è perché la pila è a strati e non un elenco di protocolli. E la parte che quasi nessuno misura è quanto è grande un pacchetto. Sono le due cose che rendono questo argomento utile.

I comandi e i concetti di questo articolo servono a capire il funzionamento, non a entrare dove non si è autorizzati. Un errore di instradazione su una rete in produzione non è un esercizio: in Italia si configura come intrusione informatica aggravata (art. 615-ter c.p.). Per il lavoro autorizzato, il riferimento è sempre il Vademecum dell'hacker.

Che cos'è una rete, in una frase

Due macchine che parlano di una lingua condivisa. Tutto il resto — i cavi, i router, i protocolli, le DNS — è letteralmente l'infrastruttura che serve perché la lingua sia comune e che il messaggio arrivi.

E c'è un concetto che va detto subito, perché è quello che tiene insieme tutto: Internet non è una rete. È un accordo. Non esiste un "centro" di Internet, non esiste qualcuno che instrada i pacchetti per tutti. Ci sono milioni di reti autonome che hanno accettato di parlare lo stesso protocollo e di passarsi i pacchetti a vicenda.

Questo ha due conseguenze pratiche immediate:

• nessuno può spegnere Internet dall'alto;

• nessuno conosce il percorso completo di un pacchetto, tranne chi lo sta guardando in quel momento.

La pila a strati: perché è fatta così

Il modello di riferimento è l'OSI, sette strati, pensato negli anni Settanta per essere un framework teorico. Quello che funziona davvero è TCP/IP, di cui Internet usa la versione a quattro strati.

+-----------------------------------------------+
| 4. Applicazione    HTTP, DNS, TLS, SSH, SMTP  |
|    qui vive il tuo messaggio: "ciao"          |
+-----------------------------------------------+
| 3. Trasporto       TCP, UDP                   |
|    consegna affidabile, ordine, flusso        |
+-----------------------------------------------+
| 2. Internet        IPv4, IPv6, ICMP           |
|    indirizzamento e instradamento fra reti    |
+-----------------------------------------------+
| 1. Accesso rete    Ethernet, Wi-Fi, PPP, ARP  |
|    bit su cavo, MAC address                   |
+-----------------------------------------------+

La regola dello strato è semplice e va capita bene: ogni strato parla solo col suo vicino. Lo strato 3 non sa nulla dello strato 1, e non deve saperne niente.

Ecco perché questo è utile. Quando un video non si carica:

• se il problema è al livello fisico, non arrivano pacchetti;

• se è al livello 2, la connettività c'è ma le conversazioni si confondono;

• se è al livello 3, il ping verso l'esterno funziona e verso l'interno no;
• se è al livello 4, l'host c'è ma la porta è chiusa;

• se è al livello 4 in alto, connessione stabilita e il problema è nell'applicazione.

Ogni strato esclude a gitto tutti quelli sotto. Questa è la prima cosa da imparare del mestiere, e vale per qualunque guasto: si sale dal basso.

Il viaggio di un pacchetto, davvero

Questo è il punto in cui la teoria diventa utile. Immagina di aprire una pagina web. Il pacchetto che contiene la risposta attraversa, nell'ordine, cinque strati su ciascuno dei due capi e circa dieci salti in mezzo.

                IL TUO BROWSER (host A)
+-----------------------------------------------+
| 4  GET /index.html          (HTTP)            |
+-----------------------------------------------+
| 3  porta 54321 -> 443       (TCP, SYN)        |
+-----------------------------------------------+
| 2  192.168.1.10 -> 93.184.x.x  (IPv4)         |
+-----------------------------------------------+
| 1  aa:bb -> cc:dd           (Ethernet)        |
+-----------------------------------------------+
                      |
                 [ router ]  sfoglia l'IP, cambia l'header L2,
                      |     ma lascia intatto tutto il resto
                 [ router ]  idem, dieci volte
                      |
+-----------------------------------------------+
| 1  cc:dd -> aa:bb           (Ethernet)        |
+-----------------------------------------------+
| 2  93.184.x.x -> 172.217.x.x (IPv4)           |
+-----------------------------------------------+
| 3  porta 443 -> 54321       (TCP, ACK+data)   |
+-----------------------------------------------+
| 4  200 OK, <html>...        (HTTP)            |
+-----------------------------------------------+
                IL SERVER (host B)

Le due cose da notare in questo disegno.

Al primo salto sparisce l'header fisico. Il router riceve un frame Ethernet, legge l'IP destinazione, butta via l'Ethernet e costruisce un nuovo frame per la rete successiva. Al secondo salto l'IP di destinazione è diventato un altro, e la porta di destinazione è diventata la 443, non più la 54321.

Ma il segmento TCP attraversa i router intatto. Il mittente e il destinatario non cambiano mai, perché stanno agli estremi. È per questo che si dice che la connessione TCP è "logica": esiste fra due estremi, attraversa il mondo, e nessun router in mezzo partecipa.

Questa è anche la definizione operativa di NAT: un router che cambia le porte è un NAT. È il motivo per cui la porta 54321 qui è effimera e non ce la ricordi domani.

I numeri: MTU, MSS e perché i video si fermano

Qui c'è un calcolo di trenta secondi che vale più di un capitolo di teoria.

Un pacchetto Ethernet standard ha una dimensione massima di 1500 byte di payload, e si chiama MTU. Ma dentro quei 1500 byte ci devono stare l'header IP e l'header TCP, e i dati veri sono la parte avanzata.

+---------------------------+--------+--------+------------------+
| dati utili (MSS)          | TCP 20 | IP 20  | payload max 1460 |
+---------------------------+--------+--------+------------------+
|<-------- MSS: 1460 byte ---------->|<------ 40 overhead ------>|

MSS = MTU - 20 (IP) - 20 (TCP) = 1500 - 40 = 1460 byte

Su un pacchetto da 1500 byte, 40 sono intestazioni e 1460 sono dati. Non è un dettaglio accademico: sono quasi il 3% di spreco che, su un video, è un fermo immagine.

Ed è qui che nasce un problema che vedi in continuazione in produzione. Aggiungi un tunnel VPN e quei 40 byte diventano 100, ma il pacchetto continua a essere costruito come se fossero 40. Risultato: i pacchetti grandi non passano, e la pagina si carica ma le immagini no.

NESSUN TUNNEL                 CON VPN (WireGuard/IPSEC)
MTU 1500                      MTU 1500 (ma il tunnel ne usa ~60)
  dati 1460                     dati 1400
  +40 overhead                  +100 overhead  -> 1500+  = ROTTO
                               ...
  funziona                     funziona solo se il MSS viene
                               "clampato" a 1400

sintomo tipico: SSH si blocca appena apri un file grande

Il rimedio si chiama MSS clamping: durante l'handshake, il mittente annuncia nel pacchetto SYN quanto dati vuole inviare, e se il client accetta, entrambi i lati si adattano al valore più piccolo. È una riga di configurazione e risolve una classe intera di problemi che a prima vista non c'entrano niente con la VPN.

I valori da sapere a memoria:

E il comando per misurarlo davvero, se un pacchetto non passa:

# Linux: scopre l'MTU lungo il percorso
tracepath 93.184.216.34

# prova un pacchetto di 1472 byte con il bit "non frammentare"
# 1472 + 20 (IP) + 8 (ICMP) = 1500: la taglia esatta dell'MTU
ping -M do -s 1472 93.184.216.34

Se quel ping va a buon fine, l'MTU è 1500. Se muore e uno più piccolo passa, hai trovato il tuo problema — e spesso è una VPN.

TCP contro UDP: la scelta che definisce tutto il resto

TCP e UDP sono entrambi al livello trasporto, e differiscono su una domanda sola: la consegna deve essere garantita?

TCP garantisce che i dati arrivino nell'ordine e completi, e lo fa invisibilmente, con tre meccanismi:

• la three-way handshake — SYN, SYN-ACK, ACK — che stabilisce la sessione e concorda i parametri;

• i numeri di sequenza, che permettono di sapere che cosa manca e di richiederlo;

• il riinvio di ciò che non arriva entro un timeout.

Il prezzo è che l'overhead non è negoziabile. Ogni pacchetto porta 40 byte di controllo, e prima di poter mandare anche un solo byte devi aspettare il giro del terzo segmento. Per un trasferimento di file è il giusto.

UDP non garantisce niente. Manda e non si cura. Non c'è handshake, non c'è riinvio, l'header è di 8 byte.

TCP: tre viaggi e poi i dati, ma ogni pacchetto torna garantito

  Client                                Server
    |                                     |
    |----------- SYN (seq=0) ------------>|  stabilisce
    |<------ SYN-ACK (ack=1) -------------|  e concorda
    |----------- ACK (seq=1) ------------>|  la sessione
    |                                     |
    |----------- dati (seq=1) ----------->|  ora si parla
    |<---------- dati (seq=1) ------------|  con garanzia

UDP: un viaggio e basta

  Client                                Server
    |----------- dati -------------------->|  vada o non vada,
    |                                      |  nessuno se ne cura
    |----------- dati -------------------->|

La conseguenza pratica, che è quasi il punto dell'articolo: gli strumenti di sicurezza amano UDP e detestano TCP. Un protocollo che si annuncia e poi tace per tre secondi è il segnale più utile che un attaccante possa darti. Gli IDS basati su firme cercano l'attività sulla porta, e per definizione l'attività non c'è: hanno solo SYN senza completare la sessione. Per questo i canali di controllo dei C2 moderni passano da UDP.

Le porte, e perché non sono un firewall

Una porta è un numero a 16 bit da 0 a 65535. Le prime 1024 sono "well-known", le altre sono registrate o effimere.

Il concetto che va chiarito bene, perché è l'equivoco più diffuso: una porta aperta non è un accesso. Vuol dire che qualcuno sta accettando connessioni su quel numero. Che cosa succeda dopo dipende dal protocollo, dalle credenziali e da quello che c'è dietro.

Questa frase la metterei sulla parete: *porta aperta non significa porta accessibile*. Il primo è una condizione di rete, il secondo una condizione di sicurezza, e sono due cose completamente diverse. Un servizio in ascolto sulla 443 con un admin/hacker2026 è una porta aperta che è anche accessibile, ma non perché sia aperta.

E c'è il caso opposto, che è più interessante: una porta chiusa è spesso meglio di una filtrata, perché una porta chiusa dice "non qui", mentre una filtrata dice "qualcuno c'è, ma non te lo dico". La differenza fra closed e filtered è un'informazione, e in un assessment è un'informazione che paghi per ottenerla.

Come si indaga, in pratica

L'ordine conta, ed è quello del Vademecum dell'hacker: dal basso in alto, perché ogni livello esclude quelli sotto.

# LIVELLO 1-2: esiste il collegamento? il ping risponde?
ping -c 3 93.184.216.34
ip addr show
ip route

# LIVELLO 2: l'MTU passa davvero? (non fidarti di ping da solo)
tracepath 93.184.216.34

# LIVELLO 3: che porte ci sono, e con quale stato?
# -sV scopre le versioni, -sC esegue gli script NSE
nmap -sV -sC -p- 192.168.1.10

# LIVELLO 4: la porta è aperta o filtrata?
# Le due risposte sono diverse e la differenza è un'informazione.
nc -zv 192.168.1.10 22

# LIVELLO 4-5: la risposta HTTP è quella che dice di essere?
curl -sI https://esempio.it
curl -s -o /dev/null -w '%{http_code} %{ssl_verify_result}\n' https://esempio.it

# LIVELLO 2-3: le query DNS viaggiano davvero su UDP?
dig +short esempio.it

Quattro cose che imparano in pratica, e che nessuna teoria dà:

1. -p- scansiona tutte le porte, -p 22,80,443 solo quelle. La scansione completa su un host con molti servizi richiede minuti.

2. Lo stato filtered non è closed. Il primo dice "c'è qualcosa che non risponde", il secondo dice "non c'è niente".

3. ssl_verify_result a zero è l'unico modo per essere sicuri che la catena di certificati sia valida. Un browser che ti avvisa e uno script che va avanti raccontano due storie diverse.

4. tracepath dice anche il PMTU, traceroute no. Per il problema dei video che si fermano, la differenza è il tutto.

Le trappole, dette prima

Il modello a quattro strati è una semplificazione. Nella realtà ci sono sette livelli e l'HTTP, per esempio, non è al primo strato ma fra il quarto e il quinto. Chi vi insegna OSI a scuola vi ha insegnato uno scheletro didattico, non una descrizione. È utile come strumento di ragionamento e va usato come tale.

L'indirizzo IP non identifica una persona e non è un'identità fissa. Dietro una NAT può esserci un utente; una VPN cambia l'IP senza spostare nessuno. Trattare l'IP come un'identità è l'errore che porta a bloccare l'utente sbagliato — o, peggio, a non bloccare nessuno.

"Non raggiungibile" non è "sì" né "no". Un timeout è un terzo stato, e in un assessment ha tre cause possibili: firewall, host spento, o percorso rotto. Il ping non le distingue. tracepath e i log del router sì.

MTU e DNS sono i due problemi che nessuno guarda. Un video che si ferma e una risoluzione che "a volte" funziona sono quasi sempre uno dei due. Sono anche i due più economici da diagnosticare, e ci metti trenta secondi con i comandi qui sopra.

La regola che usiamo noi

Il ragionamento di CYBER ONIONS sui protocolli è breve, e non riguarda la teoria:

Un protocollo è una promessa fatta a qualcuno. TCP promette che i dati arrivano, UDP non promette niente, HTTPS promette che stai parlando con chi dice di essere.

Ogni volta che leggi un header, quello che conta non è il numero ma l'impegno che quel protocollo si assume. È per questo che un servizio TCP scoperto su una porta pubblica è un finding, e un servizio UDP scoperto è spesso un finding più grave.

In una riga

Se di tutto questo resta una cosa sola: sale dal livello più basso che puoi, escludi tutto quello che hai verificato funzionare, e ripeti su quello che resta.