Cosa fa#
Descrive come una sessione HTTP appare in un dfir — perché i dati viaggiano come segmenti TCP e non come pacchetti HTTP, e come Wireshark riassembla lo stream.
TL;DR#
HTTP è application layer — comanda. TCP è transport layer — trasporta. In Wireshark vedi HTTP solo nei pacchetti di controllo (GET, 200 OK). I dati viaggiano come segmenti TCP puri.
GET / HTTP/1.1 → pacchetto HTTP (visibile)
[dati HTML] → segmenti TCP (etichettati TCP, non HTTP)
HTTP/1.1 200 OK → pacchetto HTTP (visibile, dopo reassembly)Flusso completo di una GET request in dfir#
Pkt 1-3: TCP handshake (SYN / SYN-ACK / ACK)
Pkt 4: HTTP GET / ← unico pacchetto HTTP in uscita
Pkt 5: TCP ACK ← server riceve la GET
Pkt 6-10: TCP segments ← dati HTML in arrivo (protocol = TCP, non HTTP)
Pkt 11: TCP ACK ← client ha ricevuto tutto
Pkt 12: HTTP 200 OK ← Wireshark reassembla, mostra layer HTTP
Perché i pacchetti dati appaiono come TCP e non HTTP:
I segmenti dati intermedi non contengono header HTTP — solo payload. Wireshark li etichetta come TCP segment of a reassembled PDU finché non arriva l'ultimo segmento, poi ricostruisce lo stream completo.
TCP Segmentation — MSS#
I dati vengono spezzati in segmenti da 1460 bytes (MSS — Maximum Segment Size per Ethernet). Esempio: 4633 bytes di HTML → 4 segmenti:
Segmento 1: 1460 bytes
Segmento 2: 1460 bytes
Segmento 3: 1460 bytes
Segmento 4: 253 bytes ← ultimo, più piccoloNagle's Algorithm — bulk transfer vs reverse shell#
| Contesto | Nagle | Comportamento |
|---|---|---|
| HTTP bulk transfer | attivo | aggrega dati fino a MSS, massimizza throughput |
| Reverse shell interattiva | disattivo (TCP_NODELAY) | spedisce ogni carattere immediatamente |
Una reverse shell con Nagle attivo risulterebbe lagosa — ogni tasto aspetterebbe di "riempire" un segmento prima di essere inviato. Per questo le shell interattive usano TCP_NODELAY.
gzip compression in dfir#
La maggior parte dei server invia HTML compresso (Content-Encoding: gzip). In Wireshark:
- Nei segmenti TCP intermedi vedi payload binario compresso — illeggibile
- Solo nell'ultimo pacchetto (dopo reassembly) Wireshark mostra
Content-encoded entity body (gzip): 4633 bytes → 11308 bytes - Per leggere l'HTML:
Follow TCP Stream— Wireshark decomprime automaticamente
Se stai analizzando traffico HTTP sospetto e vedi solo dati binari nei segmenti, non è necessariamente cifratura — potrebbe essere semplice gzip. Usa "Follow TCP Stream" per vedere il contenuto reale.
I due semafori — TCP vs HTTP#
Ogni sessione HTTP ha due livelli di conferma indipendenti:
| Livello | Conferma | Significato |
|---|---|---|
| TCP ACK | "i tuoi byte sono arrivati" | Trasporto ok — nulla sull'applicazione |
| HTTP Status | "la tua richiesta è stata processata" | Applicazione ok (o no) |
Possono contraddirsi:
TCP ACK → verde (i byte sono arrivati)
HTTP 500 → rosso (il server non ha saputo gestire la richiesta)Il TCP ACK è il postino che firma la ricevuta. L'HTTP status code è il destinatario che risponde al contenuto della lettera.
In realtà ci sono tre livelli sovrapposti:
Ethernet/IP → frame arrivato al router corretto (layer 2-3)
TCP ACK → segmenti arrivati intatti all'host (layer 4)
HTTP Status → applicazione ha processato la richiesta (layer 7)Esempio concreto — commento WordPress: POST dati commento → TCP ACK immediato (byte ricevuti) → WordPress scrive su DB → HTTP 302 (commento salvato, redirect). Se il DB fosse down: TCP ACK arriva comunque, poi HTTP 500. Il semaforo TCP è verde, quello applicativo è rosso.
Scenario Reale — Blue Team#
In un dfir di un alert Wazuh, vedi una sequenza anomala:
TCP SYN → SYN-ACK → ACK handshake normale
HTTP POST /upload richiesta upload
TCP segments × 200 trasferimento dati massiccio
HTTP 200 OK upload completato200 segmenti TCP per un POST /upload a un host esterno sconosciuto → probabile exfiltration dati. Il fatto che appaiano come TCP e non HTTP non significa che non sia traffico HTTP.
Collegato a#
- network — hub
- http-in-detail — prospettiva applicativa (metodi, header, cookie)
- tcp-handshake — il 3-way handshake che precede ogni sessione HTTP
- wireshark — tool di analisi dfir
- tshark — versione CLI per automazione
