Re: [ml] Abbattere il TCP via ICMP

> In particolare si fa rimerimento al fatto che l'implementazione bacata
> del tcp non controllerebbe il seq num. Ma nel payload pacchetto icmp
> in questione quel campo non e' proprio presente. 

non ho assolutamente idea di cosa tratti il bollettino, ma ICMP funziona
trasportando anche messaggi d'errore. ad esempio icmp network
unreachable, analogamente a destination unreachabe, sono icmp d'errore
che tornano indietro una volta che si cerca di contattare un host o una
rete per le quali mancano tabelle di routing adeguate.

In questo caso viene generato il pacchetto ip+icmp+64 byte di pacchetto
originario che ha causato l'errore. questo payload serve proprio perche`
la macchina mittente che riceve il pacchetto capisca quale delle sue
sessioni ha ricevuto l'errore... infatti icmp d'errore simili (o altri
piu` adeguati, come "protocol unreachable" o "port unreachable") vengono
utilizzati anche da sistemi di filtro applicati a servizi singoli,
quindi e` giusto che l'host sorgente possa continuare le sue sessioni
segnalando un errore specifico solo a quella problematica.

se ad esempio la nostra rete esce da un firewall, ed abbiamo una vpn in
udp, e noi siamo nattati quindi noi siamo il client che ha stabilito la
sessione verso il server, se qualunque dovesse mandare un icmp d'errore
al nostro firewall -con qualunque sorgente- (non serve neanche spoofare,
perche` il sorgente dovrebbe essere un hop intermedio, quindi
potenzialmente chiunque), ma come payload un pacchetto ip+udp, con
quadrupla ipfirewall.portasorgente ipendpointvpn.portaservervpn, farebbe
chiudere al firewall la connessione.

con udp e' abbastanza facile perche' con 64000 tentativi circa (le porte
sorgenti che il firewall userebbe) riusciresti a buttare giu' la
sessione UDP.

l'esempio della vpn e' solo uno, una vpn risalirebbe e le sessioni al
suo interno non porterebbero problemi, altre comunicazioni basate su udp
invece potrebbero risentirne in modo piu' grave.

per essere piu "sicuro" il firewall di chiudere la sessione, dovrebbe
confrontare anche il restante payload icmp (composto dai dati della
sessione udp), ma e' impossibie, perche' significherebbe che i firewall
dovrebbero tenere traccia dell'ultimo (e magari anche di piu) pacchetto
inviato per ogni sessione.

per quanto riguarda TCP il discorso e' pressoche' simile, se non che il
sequence number svolge gia' contro altri attacchi la parte del numero
impredicibile da una terza parte, per cui se l'implementazione dei
firewall/dei sistemi operativi e' bacata e' perche' non verifica che nel
payload dell'icmp d'errore il seq sia esatto. non facendolo la porta
sorgente sarebbe l'unica parte da predirre, e si e' gia' visto in altri
attacchi che e' abbastanza piccolo il range da lasciare buone
possibilita' all'attaccante.

anche il baco scoperto da antirez riguardo icmp in grado di far
diminuire l'MTU di un path e' senza dubbio d'esempio. quello che ci
tengo a dire in questa mail e`:


LA SOLUZIONE - NON E` - ASSOLUTAMENE
FILTRARE INDISCRIMINATAMENE GLI ICMP.

GLI ICMP -SERVONO-

E SONO PERSONALMENTE STANCO DI LAVORARE SU RETI SULLE QUALI TRACEROUTE
NON FUNZIONA - PERCHE` UN SISTEMISTA CHE VOLEVA SENTIRSI PROTETTO -
ha pensato di droppare tutto il protocollo icmp.


quindi non fate lo stesso errore per piacere, quella non e` una
soluzione, e` come per togliersi un foruncolo operarsi con un bisturi a
3 centimetri di profondita`.

cordialmente, 
Claudio il protettore dell'icmp.

-- 
0xC2752D4B pgp.mit.edu - http://www.gnupg.org - http://www.s0ftpj.org

Attachment: pgpfzMUNvkvxr.pgp
Description: PGP signature