Pacchetto TCP RST indesiderato con Scapy

Question

Per capire come funziona TCP, ho provato a creare il mio TCP SYN/SYN-ACK/ACK (basato sul tutorial: http://www.thice.nl/creating-ack-get-packets-with-scapy/).

Il problema è che ogni volta che il mio computer riceve il SYN-ACK dal server, genera un pacchetto RST che interrompe il processo di connessione.

Ho provato su un OS X Lion e su un Ubuntu 10.10 Maverick Meerkat, entrambi hanno ripristinato la connessione. Ho trovato questo: http://lkml.indiana.edu/hypermail/linux/net/0404.2/0021.html, non so se è la ragione.

Qualcuno potrebbe dirmi quale potrebbe essere la ragione? E come evitare questo problema?

Grazie.

Answer 1

L'articolo citato rende questo abbastanza chiaro ...

Dal momento che non stanno completando il TCP piena stretta di mano il sistema operativo potrebbe tentare di prendere il controllo e può iniziare a inviare RST (reset) dei pacchetti, per evitare questo possiamo usare iptables:

iptables -A OUTPUT -p tcp --tcp-flags RST RST -s 192.168.1.20 -j DROP 

in sostanza, il problema è che scapy viene eseguito in spazio utente, e il kernel linux riceveranno lo SYN-ACK prima. Il kernel invierà un RST perché non avrà un socket aperto sul numero di porta in questione, prima di avere la possibilità di fare qualcosa con scapy.

La soluzione (come menzionato nel blog) è quella di impedire al kernel di inviare un pacchetto RST.

Answer 2

Non ho una risposta non iptables, ma è possibile risolvere il problema di ripristino. Invece di provare a filtrare il reset in uscita nella tabella dei filtri, filtra tutti i pacchetti in arrivo dalla destinazione nella tabella non elaborata. Ciò impedisce che i pacchetti di ritorno dalla destinazione vengano elaborati dal kernel, sebbene scapy li veda ancora. Ho usato la seguente sintassi:

iptables -t raw -A PREROUTING -p tcp --dport <source port I use for scapy traffic> -j DROP 

Questa soluzione mi obbliga a utilizzare la stessa porta di origine per il mio traffico; sentiti libero di usare il tuo iptables-fu per identificare i pacchetti di ritorno del tuo obiettivo.

Answer 3

L'articolo del blog citato in altre risposte non è del tutto corretto. Non è solo che non stai completando l'handshake a tre vie, è che lo stack IP del kernel non ha idea che ci sia una connessione in corso. Quando riceve il SYN-ACK, invia un RST-ACK perché è inaspettato. Ricevere il primo o l'ultimo davvero non vi entra. Lo stack riceve il SYN-ACK è il problema.

L'utilizzo di IPTables per il dropout dei pacchetti RST è un approccio comune e valido, ma a volte è necessario inviare uno RST da Scapy. Un approccio più coinvolto ma molto funzionale è quello di andare più in basso, generando e rispondendo all'ARP con un MAC diverso da quello dell'host. Ciò consente di avere la possibilità di inviare e ricevere qualsiasi cosa senza alcuna interferenza da parte dell'host.

Chiaramente questo è uno sforzo maggiore. Personalmente, prendo questo approccio (al contrario dell'impostazione di riduzione RST) quando devo effettivamente inviare uno RST da solo.