Newsgroup: it.comp.os.linux.sys
Titolo: Come fa iptables a riconoscere un pacchetto "RELATED"?

Ciao a tutti!
Visto che il Provider dove ho il mio vServer non mi consente ancora di
usare ip6tables e visto che tanto devo usare un programma in userspace per
gestire il tunnel (Virtuozzo non supporta sit), sto scrivendomi un
programma che, oltre a creare il tunnel 6in4, mi faccia anche da
Firewall...
Ora, visto che ricevo TUTTI i bytes che vengono poi inoltrati
all'interfaccia di rete con IPv6, dovrei riuscire a fare cio' che voglio.
Ed e' anche cosi', fino a un certo punto...
Ora sto cercando di capire come fare a riconoscere i pacchetti che abbiano
uno stato "RELATED", in modo da permettere alle risposte di arrivare.
In pratica: come fa iptables (e ip6tables) a implementare la regola:
/sbin/ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
? Guardando i valori ricevuti e spediti, e tenendo d'occhio le RFC non
vedo niente che mi indichi che un pacchetto e' relazionato ad un altro...
L'unica possibilita' che mi viene in mente e' che si guardino le porte e
gli IP in gioco.
E' cosi'? Qualcuno puo' darmi delle dritte?
Grazie
Luca Bertoncello
(
luca...@lucabert.de
)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 gli IP in gioco.
Established: il kernel memorizza le tuple sorgente:porta 
destinazione:porta e le matcha, solo dopo che è stato fatto l'handshake 
TCP.
Per l'UDP che è stateless si basa solo su ip:porta
Se ci metti un nat in mezzo la situazione si complica.
Related: fa packet inspection su alcune particolari porte che tu gli 
indichi in cerca di firme di protocolli particolari come FTP i IRC (per 
le DCC). Il succo però è che ci vuole il modulo del kernel che sappia che 
firme cercare e dove.
In rete è pieno di documentazione.

 firme cercare e dove.
OK, questa e' un po' brutta... Puoi darmi un'idea di COSA devo cercare?
Sono due ore che cerco, ma non ho trovato assolutamente niente (perche'
ovviamente cerco le cose sbagliate).



Fino alla fine della connessione tcp, cioe' fino all'ultimo fin-ack.
ho trovato questo diagramma
http://www.eventhelix.com/realtimemantra/networking/Tcp.pdf

 
http://www.eventhelix.com/realtimemantra/networking/Tcp.pdf
Allora, provo a vedere, con un esempio, se ho capito...
Poniamo che faccia una connessione SMTP al mio Server.
Analizzo questi pacchetti (domande del client e risposte del server):
Client -> Server:
9F ED    00 19   16 39 9F 4F   00 00 00 00   A0 02
srcPort  dstPort     SeqNo       Ack No
A = Offset
000000 = Reserved
000010 = Control (SYN)
-------------------------
Server -> Client:
00 19    9F ED   58 37 BE 54   16 39 9F 50   A0 12
srcPort  dstPort    SeqNo        Ack No
A = Offset
000000 = Reserved
010010 = Control (ACK+SYN)
-------------------------
Client -> Server:
9F ED    00 19   16 39 9F 50   58 37 BE 55   80 10
srcPort  dstPort    SeqNo        Ack No
8 = Offset
000000 = Reserved
010000 = Control (ACK)
-------------------------
Server -> Client:
00 19    9F ED   58 37 BE 55   16 39 9F 50   80 18
srcPort  dstPort    SeqNo        Ack No
8 = Offset
000000 = Reserved
011000 = Control (ACK + PSH)
-------------------------
QUI SI COMINCIA!!! ESTABLISHED!
-------------------------
Client -> Server:
9F ED    00 19   16 39 9F 50   58 37 BE E4   80 10
srcPort  dstPort    SeqNo        Ack No
8 = Offset
000000 = Reserved
010000 = Control (ACK)
-------------------------
Client -> Server:
9F ED    00 19   16 39 9F 50   58 37 BE E4   80 18
srcPort  dstPort    SeqNo        Ack No
8 = Offset
000000 = Reserved
011000 = Control (ACK + PSH)
-------------------------
.. UN PO' DI PACCHETTI IN MEZZO...
-------------------------
Server -> Client:
00 19    9F ED   58 37 BF 0D   16 39 9F 56    80 11
srcPort  dstPort    SeqNo        Ack No
8 = Offset
000000 = Reserved
010001 = Control (ACK + FIN)
-------------------------
Client -> Server:
9F ED    00 19   16 39 9F 56   58 37 BF 0D    80 10
srcPort  dstPort    SeqNo        Ack No
8 = Offset
000000 = Reserved
010000 = Control (ACK)
-------------------------
Client -> Server:
9F ED    00 19   16 39 9F 56   58 37 BF 0E    80 11
srcPort  dstPort    SeqNo        Ack No
8 = Offset
000000 = Reserved
010001 = Control (ACK + FIN)
-------------------------
Server -> Client:
00 19    9F ED   58 37 BF 0E   16 39 9F 57    80 10
srcPort  dstPort    SeqNo        Ack No
8 = Offset
000000 = Reserved
010000 = Control (ACK)
-------------------------
FINITO!
Ho capito giusto?


 Ho capito giusto?
Quasi.
1) in realtà potresti non aver finito: rimangono tutte le possibile
ritrasmissioni di pacchetti precedenti che potrebbero arrivare tardi
2) in realtà il "gioco" parte già dal SYN/ACK di risposta: quello è già
un ESTABLISHED per la state machine, anche se non lo è per lo stack
TCP... Anzi, non è nemmeno detto che il NEW sia un SYN...
3) lo stesso meccanismo è usato per UDP (domanda/risposta), per ICMP
(es: echo request -> echo reply), per GRE, ecc.
4) rimane tutta la gestione dei RELATED, che è la più complicata e la
più indispensabile per il corretto funzionamento dello stack...
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

 le DCC). 
Ci sarebbero anche gli icmp, nei RELATED (ad esempio, un pacchetto udp a una porta chiusa
genera un icmp port unreachable in riposta che viene riconosciuto come RELATED dal kernel.)
(non voglio fare il pignolo rompicoglioni, ci mancherebbe, è che se ci si deve cimentare
nella scrittura di un software di firewalling possono essere dettagli importanti)

whiplash ha scritto:





Potresti suggerirmi degli URL dove la costa e' spiegata nel dettaglio?
Attualmente ho analizzato nel dettaglio una comunicazione TCP (SMTP) e UDP
(Query DNS).
L'ICMPv6 e' una cosa che devo ancora analizzare, ma che voglio fare nel
brevissimo periodo...
Ciao


 Potresti suggerirmi degli URL dove la costa e' spiegata nel dettaglio?
Cosa ti serve, esattamente, qualcosa sulla parte TCP?
Questo è un ottimo paper che spiega la questione del tcp window tracking; anche se è
incentrata su ipfilter, la parte concettuale è comunque applicabile:
http://www.usenix.org/events/sec01/invitedtalks/rooij.pdf
Sul conntracking in linux, più in generale, magari puoi trovare interessante questo
paper di Medozas che, essendo focalizzato su come scrivere nuovi moduli per
netfilter/xtables/iptables, fa una bella overview su tutto il framework in generale:
http://jengelh.medozas.de/documents/Netfilter_Modules.pdf

 essere dettagli importanti)
Hai pienamente ragione ma chi vuole scrivere quel software si studia i 
libri e la documentazione, non viene a chiedere a noi fessi sul NG!

CtRiX ha scritto:



Non mi permetterei mai di darvi del fesso...
Comunque, il programma che sto scrivendo e' una soluzione MOLTO
temporanea, in attesa che il mio Provider, prima o poi (probabilmente
prima, ma chissa' quando) mi attivi il supporto IPv6 nativo e i rispettivi
moduli di ip6tables...
Non ho intenzione di fare alcunche' di troppo complesso, ma solo quel poco
che mi serve per chiudere un po' di porte e aprirle solo a pochi IP.
Ciao


 IP.
In bocca al lupo.

 In bocca al lupo.
Diciamo che la prima versione del ConnectionTracking (per l'Established)
sembra funzionare sia con pacchetti TCP, che UDP che ICMPv6.
Ho ancora da lavorare un po' con i pacchetti TCP. Ora faccio
(volutamente!!) delle cose sbagliate, ma volevo almeno vedere se riuscivo
a fare un'analisi...
Ora pero' mia moglie vuole andare a fare due passi, quindi per oggi
fine... :D


 a fare un'analisi...
Per curiosità, come ti stai interfacciando allo stack ip?

whiplash ha scritto:


Pensavo di averlo detto all'inizio...
Ho un vServer con Virtuozzo. Il provider, adesso come adesso, non fornisce
IPv6 nativo, ma a me piacerebbe averlo.
Non avendo Virtuozzo il modulo "sit", devo usare un altro sistema per
crearmi il tunnel IPv6.
Un modo e' tramite tb_userspace. Visto che il mio provider non mi fornisce
neanche (ancora!) i moduli per ip6tables, non metto su il tunnel finche'
non ho una possibilita' di mettere anche in piedi un Firewall.
Visto che sotto Linux esiste il binomio Firewal === Netfilter e Netfilter
non ce l'ho, me ne faccio uno io in userspace, allo stesso livello del
programma che mi tira in piedi il tunnel.
Visto che il programma, per definizione, riceve (e trasmette) tutti i dati
delle connessioni IPv6, non ho problemi a filtrare a quel livello.
Quindi lo faccio! :D
E' una soluzione sicuramente temporanea, visto che il provider ha gia'
detto di voler offire IPv6 nativo (prima o poi, non si sa bene quando).
Ma in ogni caso, almeno, imparo cosa succede a livello IP. E questo puo'
essere sempre utile in futuro!


 firme cercare e dove.
Ci sono anche gli icmp, fra i related. Tanto per complicare le cose...
:-)
bye G.L.
-- 
Da i.d.c.tutela:
P.S. Quando ci sarà lo switch-off, avrò problemi anche col
monitor del PC? Ho visto che è collegato in modalità analogica.