[ImoLUG] Bridge Nat IpTables: risposte duplicate.

[Paride Balestri]

Ciao Valerio!
Bello strano il tuo problema.
Ho spulciato anche io un po' internet e mi sono imbattuto in questo 
documento.
So che non e' il tuo caso, ma la dinamica dà da pensare...
Ti allego un estratto da   
http://edu.let.unicas.it/lgei/lgei0001/lgei0001_02.html

"... Un altro problema serio  scoperto durante la ricerca  è che chi 
attacca puo superare l'autenticazione  *rlogin*. Un maleitezionato puo 
creare un pacchetto con un indirizzo di IP falso, uno noto al sistema di 
destinazione. Quando il pacchetto viene inviato, la selezione di CC 
permette al pacchetto di essere accettato immediatamente, ed ai dati di 
essere passati. Il sistema di destinazione quindi invia un SYNACK al ip 
originale. Quando questo SYNACK arriva, il sistema di destinazione 
originale invia un riavvio, come se non fosse in uno stato di SYN-SENT. 
Ciò accade troppo tardi, come se il comando fosse già stato eseguito sul 
sistema di destinazione. ...."

Ora non penso proprio che tu sia in una situazione di SYN Attack, ma mi 
fa pensare il discorso della ritrasmissione per SYN-SENT....
Hai verificato che non ti si perdano dei bit nei pacchetti ? o che il 
checksum arrivi corretto?

Se vuoi mandarmi l'output di wireshark ci posso guardare volentieri.
Ciao
Paride (baleF028)

----
 Tu non pensi quadridimensionalmente, Marty...
----
Linux user # 459656 - Linux machine # 367969

Blog: http://toboldlygowherenoonehasgonebefore.blogspot.com
----
Mailing list info: http://lists.linux.it/listinfo/imolug



valerio balbi ha scritto:
> Ciao a tutta la ML!
>
> Come confidato con alcuni di voi sto giocando all'evoluzione del
> firewall LisCO presentato a IF07.
> Per precisione sto cercando di implementare "private virtual firewall".
> Credo di aver sfrugugliato la rete senza trovare indizi che mi possano aiutare
> per cui mi permetto di sottoporvi lo "Strano caso dei Pacchetti Duplicati"
>
>
> Scena del Crimine
>                       -----------------------
> I   )    |           |       |       |       |     |      -------
> N  (     +-----------+ eth2 -+       +- eth4 +-----|     |       |
> T   )    |           |       |       |       |     |-----+       |
> E  (     |           |      br0     br1      |     |     |       |
> R   )    |           |                       |     |     |       |
> N  (     |           |        ipTables       |    [B]     -------
> E   )    |           |      kernel 2.6.18    |
> T  (    [A]           -----------------------
>
> Ho introdotto i bridge per poter aggiungere le tun dei virtual private
> firewall,
> ma prima di evolvere allo stadio definitivo ho fatto un po' di prove
> che mi hanno
> lasciato un po' perplesso. Il pc sulla rete B tenta di fare il
> download di un file grosso
> (per esempio l'ultima stabile da www.kernel.org), ma dopo un po' il
> trasferimento
> si blocca e cade rovinosamente. Sul firewall le regole di filtering
> sono applicate ai
> bridge, come pure le regole di source nat.
>
>
> Il R.I.S.
> Allora ho preso la trace con l'ottimo wireshark sia in A che in B e mi
> sono reso conto
> che sulla rete B c'erano un sacco di ritrasmissioni... (ho già
> cambiato i cavi e l'hub)
>
> In particolare:
> 1 SYN dal pc a br1 misurato su B
> 2 SYN da br0 NAT-tato verso Internet misurato su A
> 3 SYNACK da Internet verso br0 misurato su A
> 4 SYNACK da Internet verso pc proveniente da br1 misurato su B
> 5 SYNACK da Internet verso pc proveniente da br1 misurato su B
>
> Il pacchetto 5 non mi convince x niente, secondo me non dovrebbe mica esserci!
> Comunque l'unica differenza tra i pacchetti 4 e 5 è il TTL maggiorato
> di 1 nel pacchetto 5
> Immagino che questa duplicazione generi un flood che uccide la
> sessione se la sessione è
> corposa come un bel download.
>
> Le Accuse
> Sto pensando che forse c'è qualche problema sul driver sundance usato
> per comandare
> la scheda quadriporta D-Link DFE-580TX, ma non ho trovato evidenze
> significative sui NG.
> Oppure potrebbe essere una configurazione sbagliata dei parametri
> /proc/sys/net/ipv4/conf/br.
> Oppure potrebbe essere un limite del virtual bridge integrato nel
> kernel (stp disabilitato).
>
> Secondo voi in quale punto del ragionamento sto "prendendo il granchio"?
>
> Grazie per l'Attenzione! Ciao!
>   
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: http://lists.linux.it/pipermail/imolug/attachments/20080309/11853b7c/attachment.htm 
-------------- parte successiva --------------
Un allegato non testuale è stato rimosso....
Nome:        smime.p7s
Tipo:        application/x-pkcs7-signature
Dimensione:  2807 bytes
Descrizione: S/MIME Cryptographic Signature
Url:         http://lists.linux.it/pipermail/imolug/attachments/20080309/11853b7c/attachment.bin