Newsgroup: it.comp.os.linux.sys
Titolo: [?][IPTABLES] ACK droppato

A volte ricevo dal server mail del mio provider (mi sembra in concidenza di
un time out del servizio POP del provider) una serie di 
Jun 22 20:44:13 exnet kernel: IPNF: Def. dropping: IN=ppp0 OUT= MAC=
SRC=213.21.178.29 DST=151.25.102.52 LEN=40 TOS=0x00 PREC=0x00 TTL=121
ID=24361 PROTO=TCP SPT=110 DPT=55693 WINDOW=0 RES=0x00 ACK URGP=0
E' corretto interpretarli come tentativi del servizio POP di far sapere al
client di posta che la connessione è terminata?
Cosa si aspetta il servizio POP? un RST?

 client di posta che la connessione è terminata?
No: è un semplice ACK, probabilmente duplicato o comunque arrivato fuori
tempo massimo, che il conntrack non considera quindi (più) valido.
-- 
Chaos A.D.		|	Raging crowd
Tanks on the streets	|	Burning cars
Confronting police	|	Bloodshed starts
Bleeding the Plebs	|	Who'll be alive?

 client di posta che la connessione è terminata?
No, ti sta tenendo in stallo. Il perche' ci e' ignoto. In ogni caso,
la spiegazione IMHO e' quella di whiplash: la sessione netfilter non
c'e' piu' (chiusa, probabilmente, dal traffico generato dal client a
causa dello stallo) e l'ACK si schianta su netfilter.
Fabio

 tempo massimo, che il conntrack non considera quindi (più) valido.
Si, non ho dubbi sul fatto che iptables/conntrack droppi l'ACK perchè è
relativo a una connessione non valida o non più valida.
Il mio dubbio è perchè il server POP mi invia una serie di ACK relativi a
una connessione non valida o non più valida, e quale risposta si attende.
Vedi risposta a Bio per qualche dettaglio in più

 c'e' piu' (chiusa, probabilmente, dal traffico generato dal client a
]zac[
mmmm, c'è qualcosa che non mi torna:
1 - La connessione la chiude il server POP, per mancanzi di comandi POP e
non per ritardi o timeout sulla trasmissione dei pacchetti.
2 - Se il client fa richieste relative a connessioni chiuse il server POP
dovrebbe rispondere con RST, o con niente, ma con ACK?
3 - Che senso hanno quegli ACK da parte di un destinatario di una
connessione?
Vedi risposta a whiplash, il mio dubbio verte sul senso del comportamento
del server POP e non di iptables.

 aspetta?
Dal log la connessione non pare chiusa. Il server POP sta segnalando una
finestra (WINDOW) di ricezione pari a 0, in pratica la tua macchina e`
invitata a non inviare nulla fino all'advertising di una nuova windows.
Il meccanismo serve per controllare le congestioni.
Il perche` venga droppata da netfilter non e` chiaro, anche se come e`
stato detto puo` essere che il pacchetto (a causa della congestione del
server) arrivi duplicato o dopo il FIN di chiusura.
Luca
-- 
Home: 
http://kronoz.cjb.net
"Accadono cose che sono come domande. Passa un minuto, oppure anni, e
 poi la vita risponde."

 connessione?
Il destinatario di una connessione invia sempre degli ACK, allo scopo
di confermare la ricezione dei dati. E viceversa. Quando la finestra,
invece, e' 0, ti sta dicendo di non inviare piu' niente, fino a nuovo
ordine (ACK con WINDOW>0).
Fabio

 ordine (ACK con WINDOW>0).
]zac[
Con questi dati e dopo avere eliminato di torno la mia ipotesi inziale mi è
tutto più chiaro.
Come mi è chiaro che ho ampie lacune (da colmare) sul protocoloo TCP.
Il tutto mi ha schiarito molti dubbi, grazie.

 server) arrivi duplicato o dopo il FIN di chiusura.
]zac[
Si, in effetti è tutto molto ... chiaro e liscio.
La cosa curiosa è che quegli ACK arrivino dopo che la connessione e il
'traffico POP' sono terminati da tempo e correttamente.
Naturalmente da un server con una 'congestione' non ci può aspettare una
'attività regolare'.


 ordine (ACK con WINDOW>0).
Sbaglio o questo fa gridare al lupo i kernel recenti?
Ciaotutti,
* -- coi log strapieni di "treason uncloaked"

 * -- coi log strapieni di "treason uncloaked"
Boh, comunque i miei log sono pieni di ack, ack/push e ack/fin/push (e meno
male che c'è 'limit') tutti considerati invalid, quasi al limete del flood:
70 ack dal sito web di nvidia:
70 giu 25 17:29:31 giu 25 18:06:37 00:00:37:06 exnet IPNF: Def. dropping:
ppp0 - tcp 216.228.115.17 - 
216.228.115.0/24
 NVIDIA AS11414 NVIDIA 80 http
151.25.91.70 
ppp-70-91.25-151.libero.it
 33628 - -a------
circa 30 ack/push + 50 ack/fin/push da siti web supereva/dadanet:
3 giu 25 16:00:33 giu 25 16:01:40 00:00:01:07 exnet IPNF: Dropping: ppp0 -
tcp 195.110.126.34 
adamo34.supereva.it
 80 http 151.25.109.179
ppp-179-109.25-151.libero.it
 11416 - -a--p---
6 giu 25 15:59:58 giu 25 16:01:47 00:00:01:49 exnet IPNF: Def. dropping:
ppp0 - tcp 195.110.122.164 - 
195.110.122.0/23
 DADANET AS12363 DADA S.p.a.
80 http 151.25.109.179 
ppp-179-109.25-151.libero.it
 5102 - -af-p---

.
Altri casi erano dovuti a connessioni half open, per cui il timeout di
netfilter e' molto basso, e basta anche poco ritardo per farlo scadere
e causare il drop di eventuali trasmissioni successive.
Non ultimo, ci sono alcuni bug nella macchina a stati di netfilter per
il tcp window tracking che possono portare a scartare pacchetti validi
come INVALID. Alcuni di questi sono gia' stati corretti nel cvs AFAIK.
In ogni caso, DROPpare invece che REJECTare peggiora la situaizone.
Fabio

 * -- coi log strapieni di "treason uncloaked"
In teoria la finestra non la si dovrebbe ridurre spostando a sinistra 
il margine di destra, ma se la controparte compie un simile lavoretto
il proprio stack tcp/ip dovrebbe essere sufficientemente robusto e si
dovrebbe adeguare senza far cadere la comunicazione. Probabilmente il
kernel si lamenta e logga questi eventi, spesso causati da stack tcp/
ip poco rispettosi, ma dovrebbe proseguire senza troppi problemi.
Fabio

 In ogni caso, DROPpare invece che REJECTare peggiora la situaizone.
]zac[
Si, concordo, era anche la mia sensazione.
Diciamo che mi sono fatto prendere la mano dal 'mo chiudo tutto e tutti
fuori e poi conquisterò il mondo).
Anche se gli ack arrivati dal sito di nvidia (l'altro caso) erano
paragonabili a un flood, una serie di pacchetti continuativi per alcuni
minuti, a mio parere, solo limitati dal 'limit' di ipfilter.
E' mia intenzione provare a rispondere agli ack invalidi provenienti dalla
porta 80 con reject/rst (magari usando limit/burst).

 ip poco rispettosi, ma dovrebbe proseguire senza troppi problemi.
]zac[
Da quel che ho visto ipfilter filtra pochissimi ack con window a 0 (è una
''sensazione'' perchè non conosco un sistema per loggare i pacchetti con
window a 0 (non esiste un match sulla window)).

 window a 0 (non esiste un match sulla window)).
Non e' che sia sbagliato in assoluto che la window sia 0, eh? Dipende da 
come ci arrivi, AFAIK. Comunque se sei curioso di vedere la frequenza di
questi fenomeni, puoi loggare il traffico con window=0 con il match u32.
Fabio

 Suppongo che intendi dire che i bug sono ancora presenti nel kernel-2.6.12-1
Non ho ancora visto. Direi di no, perchè la patch è della fine di maggio.
Fabio

 Guarda a caso, è riferito a un cluster di server di advertising :-)
Ma va? le incredibile coincidenze della vita.
Vediamo se con il nuovo kernel e un po' di reject sparsi qua e la si riesce
a tenere i log a dimensioni umane.

 questi fenomeni, puoi loggare il traffico con window=0 con il match u32.
Molte grazie, ho proprio la curiosità di vedere che combina il server POP
del mio provider.

 questi fenomeni, puoi loggare il traffico con window=0 con il match u32.
]zac[
Beh me l'aspettavo più facile, ci vuole qualcosa del genere 
iptables -A INPUT -p tcp --tcp-flags SYN,ACK ACK -m u32 --u32 "4&0x1FFF=0 &&
0>>22&0x3C@12&0xFFFF=0x0" -j LOG -m limit --limit 10/minute --log-prefix
"IPNF: Window 0: "
Senza contare che 'u32' si applica ai sorgenti di iptables con
patch-o-matic.
Credo che i promessi sposi in sanscrito siano più 'maneggevoli'.

 
http://groups.google.it/group/it.comp.reti.ip-admin/msg/99212dc1ceda31a
?.
]zac[
Ho iniziato a sperimentare il reject usando
iptables -A INPUT -m state --state INVALID -p tcp --tcp-flags SYN,ACK ACK -j
REJECT --reject-with tcp-reset -m limit --limit 10/minute
Non ho ancora qualche risultato valido, ma ho curiosamente notato che
facendo click sulle icone del desktop di kde l'azione relativa viene
eseguita dopo molti secondi, mentre il lancio dal menu e molte altre cose
funzionano regolarmente.
Verrebbe quasi da concludere che gli ack invalid sono in realtà
'validi' (usati).

 questi fenomeni, puoi loggare il traffico con window=0 con il match u32.
]zac[
ipt_u32 è decisamente non funzionante, almeno con il kernel 2.6.12-1, ci
sono degli usi dell'aritmetica dei puntatori piuttosto ''spericolati'', che
probabilmente hanno smesso di funzionare dopo qualche modifica di qualche
parte del kernel.
Piuttosto fastidioso scoprire che molte, molte ore di prove di impostazioni
delle regole di iptables sono state inutili, dopo aver corretto ipt_u32 è
risultata giusta una delle prime regole 'definitive' provate.
Comunque ipt_u32 è piuttosto interessante, visto che consente di eseguire il
match su ogni Byte (e bit) degli header IP e TCP.