↓ Skip to main content
u-random
u-random
  1. Concetti/

HTTP in Wireshark - TCP Segmentation e Packet Analysis

·4 mins
intermedio
Network-Defense Dfir
Alessio Barnini
Author
Alessio Barnini
Table of Contents
HTTP in Wireshark - TCP Segmentation e Packet Analysis

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

http_get_wireshark.webp

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
#

http_tcp_segments.webp

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ù piccolo

Nagle's Algorithm — bulk transfer vs reverse shell
#

ContestoNagleComportamento
HTTP bulk transferattivoaggrega dati fino a MSS, massimizza throughput
Reverse shell interattivadisattivo (TCP_NODELAY)spedisce ogni carattere immediatamente
Note

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
Tip

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:

LivelloConfermaSignificato
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)
Tip

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 completato

200 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

Related