Magari il dubbio è di quelli che nono importano molto a nessuno, ma io
ci stò pensando da un pò e ancora non sono riuscito a capire la
differenza ( se esiste), in quanto il mio misero diploma di perito
tecnico :-) non mi permette di andare oltre la lettura degli HOWTO
:-)))))))))


Allora confontando il setup di due firewall linux, mi sono trovato
davanti ad una diversa gestione delle connessioni, in particolare su
uno, probabilmente più vecchio la gestione delle connessioni viene fatta
in prima istanza sul valore del bit di SYN/ACK accettando solo le
connessoni che sono già state richieste dall'interno.

Su uno script basato su kernel più recenti la gestione non viene fatta
più tramite il bit di SYN/ACK ma tramite il modulo CONNTRACK (sempre che
la memoria non mi inganni), controllando lo stato della connessione
(RELATED ESTABILISHED, ecc,ecc )

Ora la domanda che mi nacse spontanea è visto che in pratica fanno lo
stesso mestiere, sia il primo che il secondo, quale delle due è più
efficiente?
Mi sembra di capire da quello che ho potuto capire, che la seconda è
migliore in quanto la "traccia" delle connessioni viene tenuta dal
kernel, e quindi non è possibile che modificando i bit in invio, la
connessione venga accettata lo stesso.

Qualcuno può smentire/confermare questa deduzione?!?!?!?


--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Marco Cavaliere:
> Mi sembra di capire da quello che ho potuto capire, che la seconda è
> migliore in quanto la "traccia" delle connessioni viene tenuta dal
> kernel, e quindi non è possibile che modificando i bit in invio, la
> connessione venga accettata lo stesso.
>
> Qualcuno può smentire/confermare questa deduzione?!?!?!?

Il connection tracking permette di stabilire se un pacchetto puo' essere
accettato o meno senza fermarsi all'analisi del header dei pacchetti ma
esaminado anche il payload (cioe' i dati contenuti) e la storia della
connessione.
Un esempio classico e' quello del protocollo ftp, che prevede che il client
si connetta al sever per stabilire la sessione ma se si e' in modalita'
"active" (lo e' di default) al momento del download e' il sever a
connettersi al client per la trasmissione dei dati su una porta che varia di
volta in volta.
Il modulo ip_conntrack_ftp esamina il dialogo tra client e server ftp ed e'
ingrado di comprendere in base questo che la sessione prevede una
connessione dal server verso il client su una determinata porta quindi
quando arriva la richiesta di connessione viene accettata perche'
"collegata" (related) alla sessione ftp esistente, mentre in caso contrario
potrebbe essere respinta.

Spero di aver chiarito il concetto e non aver fatto confusione nonostante
l'ora tarda :-)

Alessandro.

Marco Cavaliere:
> e quindi non è possibile che modificando i bit in invio, la
> connessione venga accettata lo stesso.
>
Questo lo escludei comunque, eventualmente mi smentisca chi e' piu'
preparato di me.

Alessandro.

Sgranocchiando in cranio di test, vi trovai inciso:

> Marco Cavaliere:
>> e quindi non è possibile che modificando i bit in invio, la
>> connessione venga accettata lo stesso.
>>
> Questo lo escludei comunque, eventualmente mi smentisca chi e' piu'
> preparato di me.

Dipende da come è fatta la regola (una connessione può essere NEW anche se
*non* inizia con un SYN, e pertanto venire accettata), ma non è questo il
punto.
E il fatto che ftp abbia una sessione inversa è ininfluente: non serve la
macchina di state a gestirla: tutte le implementazioni di nat, anche le
più becere, già si occupano di fare il rewrite nel payload (anzi, se leggi
la RFC, essa stessa cita giusto il caso...).
Lo scenario che considerate è un po' ristretto, e sensato solamente se
rapportato a tcp.
E udp, gre, icmp, igmp, ecc, che *non* hanno nessun syn o qualcosa che gli
assomigli?
Serve un layer di astrazione dalle specifiche del protocollo, e la state
machine è esattamente questo: permette di capire chi inizia una
comunicazione e chi risponde, ecc. *senza* entrare nel merito di quale è
il protocollo che parla e dei suoi internals ( --state NEW != --syn,
*anche* su tcp ).

Consiglierei di andare a leggere il breve link sul funzionamento del
connection tracking che trovate nella sezione documentazione di
netfilter.org. E' breve e son 5 minuti spesi bene...

Hola

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~
The Skull says:
Stop VeriSign. Go to http://www.whois.sc/verisign-dns/
* The most stupid thing since Microsoft Network... <g> *

Il Thu, 23 Oct 2003 21:54:45 +0000, Marco Cavaliere ha scritto:

> Su uno script basato su kernel più recenti la gestione non viene fatta
> più tramite il bit di SYN/ACK ma tramite il modulo CONNTRACK (sempre
> che la memoria non mi inganni), controllando lo stato della connessione
> (RELATED ESTABILISHED, ecc,ecc )
> Ora la domanda che mi nacse spontanea è visto che in pratica fanno lo
> stesso mestiere, sia il primo che il secondo, quale delle due è più
> efficiente?

Se in termini di efficienza intendi computazionale credo che il tutto
dipende da come sono le politiche di filtraggio.

Di sicuro è che se si accettano in primis i pacchetti Related,
Established si potrebbe risparmiare qualcosina (oddio veramente non so la
politica di ricerca di una connessione...)

> Mi sembra di capire da quello che ho potuto capire, che la seconda è
> migliore in quanto la "traccia" delle connessioni viene tenuta dal
> kernel, e quindi non è possibile che modificando i bit in invio, la
> connessione venga accettata lo stesso.

Che intendi per bit modificato?

Se intendi modificato mandando un pacchetto ad hoc modificato al più
viene scartato...

--
| /
| \Byte - Andrea Briganti - kbytesys(aaattt)tiscali.it
CSLug member: http://cslug.linux.it - JID: kbyte@jabber.linux.it
***Ogni ideologia o movimento non è immune dagli idioti