Ce qui m'étonne ce sont les drops visibles dans les logs, qui
apparemment concernent les paquets retour des serveur pop3s que
j'interroge, alors que iptables est sensé accepter les connexions
établies (-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT). La
récupération des mails sur ces serveurs pops fonctionne bien.
Voici un extrait:
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC :40:ca:17:85:18:00:07:cb:cf:5a:5a:08:00 SRCt.125.77.109 DST2.168.0.1 LEN@ TOS PREC=0x00 TTLS ID$852 PROTO=TCP SPT™5 DPTH882 SEQ83545547 ACK=0 WINDOW=0 RST URGP=0
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC :40:ca:17:85:18:00:07:cb:cf:5a:5a:08:00 SRCt.125.77.109 DST2.168.0.1 LEN@ TOS PREC=0x00 TTLS ID$853 PROTO=TCP SPT™5 DPTH882 SEQ83545547 ACK=0 WINDOW=0 RST URGP=0
Ce qui m'étonne ce sont les drops visibles dans les logs, qui
apparemment concernent les paquets retour des serveur pop3s que
j'interroge, alors que iptables est sensé accepter les connexions
établies (-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT). La
récupération des mails sur ces serveurs pops fonctionne bien.
Voici un extrait:
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC :40:ca:17:85:18:00:07:cb:cf:5a:5a:08:00 SRCt.125.77.109 DST2.168.0.1 LEN@ TOS PREC=0x00 TTLS ID$852 PROTO=TCP SPT™5 DPTH882 SEQ83545547 ACK=0 WINDOW=0 RST URGP=0
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC :40:ca:17:85:18:00:07:cb:cf:5a:5a:08:00 SRCt.125.77.109 DST2.168.0.1 LEN@ TOS PREC=0x00 TTLS ID$853 PROTO=TCP SPT™5 DPTH882 SEQ83545547 ACK=0 WINDOW=0 RST URGP=0
Ce qui m'étonne ce sont les drops visibles dans les logs, qui
apparemment concernent les paquets retour des serveur pop3s que
j'interroge, alors que iptables est sensé accepter les connexions
établies (-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT). La
récupération des mails sur ces serveurs pops fonctionne bien.
Voici un extrait:
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC :40:ca:17:85:18:00:07:cb:cf:5a:5a:08:00 SRCt.125.77.109 DST2.168.0.1 LEN@ TOS PREC=0x00 TTLS ID$852 PROTO=TCP SPT™5 DPTH882 SEQ83545547 ACK=0 WINDOW=0 RST URGP=0
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC :40:ca:17:85:18:00:07:cb:cf:5a:5a:08:00 SRCt.125.77.109 DST2.168.0.1 LEN@ TOS PREC=0x00 TTLS ID$853 PROTO=TCP SPT™5 DPTH882 SEQ83545547 ACK=0 WINDOW=0 RST URGP=0
Bonjour,
Ce qui m'étonne ce sont les drops visibles dans les logs, qui
apparemment concernent les paquets retour des serveur pop3s que
j'interroge, alors que iptables est sensé accepter les connexions
établies (-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT). La
récupération des mails sur ces serveurs pops fonctionne bien.
Voici un extrait:
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC :40:ca:17:85:18:00 :07:cb:cf:5a:5a:08:00 SRCt.125.77.109 DST2.168.0.1 LEN@ TOS PREC=0x00 TTLS ID$852 PROTO=TCP SPT™5 DPTH882 SEQ 83545547 ACK=0 WINDOW=0 RST URGP=0
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC :40:ca:17:85:18:00 :07:cb:cf:5a:5a:08:00 SRCt.125.77.109 DST2.168.0.1 LEN@ TOS PREC=0x00 TTLS ID$853 PROTO=TCP SPT™5 DPTH882 SEQ 83545547 ACK=0 WINDOW=0 RST URGP=0
Quelqu'un pourrait m'expliquer le pourquoi ?
Bonjour,
Ce qui m'étonne ce sont les drops visibles dans les logs, qui
apparemment concernent les paquets retour des serveur pop3s que
j'interroge, alors que iptables est sensé accepter les connexions
établies (-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT). La
récupération des mails sur ces serveurs pops fonctionne bien.
Voici un extrait:
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC=00:40:ca:17:85:18:00 :07:cb:cf:5a:5a:08:00 SRC=74.125.77.109 DST=192.168.0.1 LEN=40 TOS =00 PREC=0x00 TTL=53 ID=24852 PROTO=TCP SPT=995 DPT=48882 SEQ =1083545547 ACK=0 WINDOW=0 RST URGP=0
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC=00:40:ca:17:85:18:00 :07:cb:cf:5a:5a:08:00 SRC=74.125.77.109 DST=192.168.0.1 LEN=40 TOS =00 PREC=0x00 TTL=53 ID=24853 PROTO=TCP SPT=995 DPT=48882 SEQ =1083545547 ACK=0 WINDOW=0 RST URGP=0
Quelqu'un pourrait m'expliquer le pourquoi ?
Bonjour,
Ce qui m'étonne ce sont les drops visibles dans les logs, qui
apparemment concernent les paquets retour des serveur pop3s que
j'interroge, alors que iptables est sensé accepter les connexions
établies (-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT). La
récupération des mails sur ces serveurs pops fonctionne bien.
Voici un extrait:
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC :40:ca:17:85:18:00 :07:cb:cf:5a:5a:08:00 SRCt.125.77.109 DST2.168.0.1 LEN@ TOS PREC=0x00 TTLS ID$852 PROTO=TCP SPT™5 DPTH882 SEQ 83545547 ACK=0 WINDOW=0 RST URGP=0
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC :40:ca:17:85:18:00 :07:cb:cf:5a:5a:08:00 SRCt.125.77.109 DST2.168.0.1 LEN@ TOS PREC=0x00 TTLS ID$853 PROTO=TCP SPT™5 DPTH882 SEQ 83545547 ACK=0 WINDOW=0 RST URGP=0
Quelqu'un pourrait m'expliquer le pourquoi ?
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC :40:ca:17:85:18:00:07:cb:cf:5a:5a:08:00 SRCt.125.77.109 DST2.168.0.1 LEN@ TOS PREC=0x00 TTLS ID$852 PROTO=TCP SPT™5 DPTH882 SEQ83545547 ACK=0 WINDOW=0 RST URGP=0
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC :40:ca:17:85:18:00:07:cb:cf:5a:5a:08:00 SRCt.125.77.109 DST2.168.0.1 LEN@ TOS PREC=0x00 TTLS ID$853 PROTO=TCP SPT™5 DPTH882 SEQ83545547 ACK=0 WINDOW=0 RST URGP=0
Ce sont des TCP RST (reset) qui sont classés - à tort ou à raison -
comme INVALID par le suivi de connexion de netfilter. Rien de grave a
priori s'il n'y a pas d'effet secondaire.
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC :40:ca:17:85:18:00:07:cb:cf:5a:5a:08:00 SRCt.125.77.109 DST2.168.0.1 LEN@ TOS PREC=0x00 TTLS ID$852 PROTO=TCP SPT™5 DPTH882 SEQ83545547 ACK=0 WINDOW=0 RST URGP=0
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC :40:ca:17:85:18:00:07:cb:cf:5a:5a:08:00 SRCt.125.77.109 DST2.168.0.1 LEN@ TOS PREC=0x00 TTLS ID$853 PROTO=TCP SPT™5 DPTH882 SEQ83545547 ACK=0 WINDOW=0 RST URGP=0
Ce sont des TCP RST (reset) qui sont classés - à tort ou à raison -
comme INVALID par le suivi de connexion de netfilter. Rien de grave a
priori s'il n'y a pas d'effet secondaire.
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC :40:ca:17:85:18:00:07:cb:cf:5a:5a:08:00 SRCt.125.77.109 DST2.168.0.1 LEN@ TOS PREC=0x00 TTLS ID$852 PROTO=TCP SPT™5 DPTH882 SEQ83545547 ACK=0 WINDOW=0 RST URGP=0
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC :40:ca:17:85:18:00:07:cb:cf:5a:5a:08:00 SRCt.125.77.109 DST2.168.0.1 LEN@ TOS PREC=0x00 TTLS ID$853 PROTO=TCP SPT™5 DPTH882 SEQ83545547 ACK=0 WINDOW=0 RST URGP=0
Ce sont des TCP RST (reset) qui sont classés - à tort ou à raison -
comme INVALID par le suivi de connexion de netfilter. Rien de grave a
priori s'il n'y a pas d'effet secondaire.
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC :40:ca:17:85:18:00:07:cb:cf:5a:5a:08:00 SRCt.125.77.109 DST2.168.0.1 LEN@ TOS PREC=0x00 TTLS ID$852 PROTO=TCP SPT™5 DPTH882 SEQ83545547 ACK=0 WINDOW=0 RST URGP=0
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC :40:ca:17:85:18:00:07:cb:cf:5a:5a:08:00 SRCt.125.77.109 DST2.168.0.1 LEN@ TOS PREC=0x00 TTLS ID$853 PROTO=TCP SPT™5 DPTH882 SEQ83545547 ACK=0 WINDOW=0 RST URGP=0
Quelqu'un pourrait m'expliquer le pourquoi ?
Ton programme de récupération (fetchmail?) quitte avant d'attendre la
fin de la liaison (le paquet RST). Du coup le port 48882 est considéré
comme déconnecté, et les paquets de fin sont considérés ni comme RELATED
ni comme ESTABLISHED.
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC :40:ca:17:85:18:00:07:cb:cf:5a:5a:08:00 SRCt.125.77.109 DST2.168.0.1 LEN@ TOS PREC=0x00 TTLS ID$852 PROTO=TCP SPT™5 DPTH882 SEQ83545547 ACK=0 WINDOW=0 RST URGP=0
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC :40:ca:17:85:18:00:07:cb:cf:5a:5a:08:00 SRCt.125.77.109 DST2.168.0.1 LEN@ TOS PREC=0x00 TTLS ID$853 PROTO=TCP SPT™5 DPTH882 SEQ83545547 ACK=0 WINDOW=0 RST URGP=0
Quelqu'un pourrait m'expliquer le pourquoi ?
Ton programme de récupération (fetchmail?) quitte avant d'attendre la
fin de la liaison (le paquet RST). Du coup le port 48882 est considéré
comme déconnecté, et les paquets de fin sont considérés ni comme RELATED
ni comme ESTABLISHED.
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC :40:ca:17:85:18:00:07:cb:cf:5a:5a:08:00 SRCt.125.77.109 DST2.168.0.1 LEN@ TOS PREC=0x00 TTLS ID$852 PROTO=TCP SPT™5 DPTH882 SEQ83545547 ACK=0 WINDOW=0 RST URGP=0
Mar 4 18:07:07 petole DROP: IN=eth0 OUT= MAC :40:ca:17:85:18:00:07:cb:cf:5a:5a:08:00 SRCt.125.77.109 DST2.168.0.1 LEN@ TOS PREC=0x00 TTLS ID$853 PROTO=TCP SPT™5 DPTH882 SEQ83545547 ACK=0 WINDOW=0 RST URGP=0
Quelqu'un pourrait m'expliquer le pourquoi ?
Ton programme de récupération (fetchmail?) quitte avant d'attendre la
fin de la liaison (le paquet RST). Du coup le port 48882 est considéré
comme déconnecté, et les paquets de fin sont considérés ni comme RELATED
ni comme ESTABLISHED.
(François TOURDE) writes:Ton programme de récupération (fetchmail?) quitte avant d'atte ndre la
fin de la liaison (le paquet RST). Du coup le port 48882 est considà ©ré
comme déconnecté, et les paquets de fin sont considérà ©s ni comme RELATED
ni comme ESTABLISHED.
Pourtant ce RST provient du serveur distant apparemment. Ou alors
c'est une réponse à une déconnexion intempestive de "mon" côté ?
Normalement on devrait avoir du FIN depuis mon-serveur puis FIN-ACK
depuis le serveur distant, non ?
fra-duf-no-spam@tourde.org (François TOURDE) writes:
Ton programme de récupération (fetchmail?) quitte avant d'atte ndre la
fin de la liaison (le paquet RST). Du coup le port 48882 est considà ©ré
comme déconnecté, et les paquets de fin sont considérà ©s ni comme RELATED
ni comme ESTABLISHED.
Pourtant ce RST provient du serveur distant apparemment. Ou alors
c'est une réponse à une déconnexion intempestive de "mon" côté ?
Normalement on devrait avoir du FIN depuis mon-serveur puis FIN-ACK
depuis le serveur distant, non ?
(François TOURDE) writes:Ton programme de récupération (fetchmail?) quitte avant d'atte ndre la
fin de la liaison (le paquet RST). Du coup le port 48882 est considà ©ré
comme déconnecté, et les paquets de fin sont considérà ©s ni comme RELATED
ni comme ESTABLISHED.
Pourtant ce RST provient du serveur distant apparemment. Ou alors
c'est une réponse à une déconnexion intempestive de "mon" côté ?
Normalement on devrait avoir du FIN depuis mon-serveur puis FIN-ACK
depuis le serveur distant, non ?
Normalement on devrait avoir du FIN depuis mon-serveur puis FIN-ACK
depuis le serveur distant, non ?
Normalement on devrait avoir du FIN depuis mon-serveur puis FIN-ACK
depuis le serveur distant, non ?
Normalement on devrait avoir du FIN depuis mon-serveur puis FIN-ACK
depuis le serveur distant, non ?
Pascal Hambourg writes:Ce sont des TCP RST (reset) qui sont classés - à tort ou à raison -
comme INVALID par le suivi de connexion de netfilter. Rien de grave a
priori s'il n'y a pas d'effet secondaire.
Merci pour ta réponse. Tant mieux si c'est sans dommage, mais ce n'est
quand même pas "propre".
A priori ce classement a dû être changé dans les dernières versions du
noyau, car ces erreurs n'apparaissaient pas en 2.6.26. C'est depuis
une mise-à-jour en 2.6.32 (backports) que je vois ces drops.
Pascal Hambourg <pascal.mail@plouf.fr.eu.org> writes:
Ce sont des TCP RST (reset) qui sont classés - à tort ou à raison -
comme INVALID par le suivi de connexion de netfilter. Rien de grave a
priori s'il n'y a pas d'effet secondaire.
Merci pour ta réponse. Tant mieux si c'est sans dommage, mais ce n'est
quand même pas "propre".
A priori ce classement a dû être changé dans les dernières versions du
noyau, car ces erreurs n'apparaissaient pas en 2.6.26. C'est depuis
une mise-à-jour en 2.6.32 (backports) que je vois ces drops.
Pascal Hambourg writes:Ce sont des TCP RST (reset) qui sont classés - à tort ou à raison -
comme INVALID par le suivi de connexion de netfilter. Rien de grave a
priori s'il n'y a pas d'effet secondaire.
Merci pour ta réponse. Tant mieux si c'est sans dommage, mais ce n'est
quand même pas "propre".
A priori ce classement a dû être changé dans les dernières versions du
noyau, car ces erreurs n'apparaissaient pas en 2.6.26. C'est depuis
une mise-à-jour en 2.6.32 (backports) que je vois ces drops.
Nicolas KOWALSKI a écrit :A priori ce classement a dû être changé dans les dernières versions du
noyau, car ces erreurs n'apparaissaient pas en 2.6.26. C'est depuis
une mise-à-jour en 2.6.32 (backports) que je vois ces drops.
/me fouille dans les changelogs du noyau...
J'ai trouvé ça dans les changements du noyau 2.6.30 :
netfilter: nf_ct_tcp: fix accepting invalid RST segments
Robert L Mathews discovered that some clients send evil TCP RST
segments, which are accepted by netfilter conntrack but discarded by
the destination. Thus the conntrack entry is destroyed but the
destination retransmits data until timeout.
Nicolas KOWALSKI a écrit :
A priori ce classement a dû être changé dans les dernières versions du
noyau, car ces erreurs n'apparaissaient pas en 2.6.26. C'est depuis
une mise-à-jour en 2.6.32 (backports) que je vois ces drops.
/me fouille dans les changelogs du noyau...
J'ai trouvé ça dans les changements du noyau 2.6.30 :
netfilter: nf_ct_tcp: fix accepting invalid RST segments
Robert L Mathews discovered that some clients send evil TCP RST
segments, which are accepted by netfilter conntrack but discarded by
the destination. Thus the conntrack entry is destroyed but the
destination retransmits data until timeout.
Nicolas KOWALSKI a écrit :A priori ce classement a dû être changé dans les dernières versions du
noyau, car ces erreurs n'apparaissaient pas en 2.6.26. C'est depuis
une mise-à-jour en 2.6.32 (backports) que je vois ces drops.
/me fouille dans les changelogs du noyau...
J'ai trouvé ça dans les changements du noyau 2.6.30 :
netfilter: nf_ct_tcp: fix accepting invalid RST segments
Robert L Mathews discovered that some clients send evil TCP RST
segments, which are accepted by netfilter conntrack but discarded by
the destination. Thus the conntrack entry is destroyed but the
destination retransmits data until timeout.
J'imagine que le meilleur moyen de savoir est de faire un dump du
traffic, pour être sûr. Mais il se peut que la fermeture de la liaison
soit à l'initiative des deux côtés (ton fetchmailer envoie "QUIT" puis
un paquet FIN, ton serveur à réception du "QUIT" envoie aussi un FIN) et
que les RST du serveur soient des résidus ;)
Je te laisse le soin de faire un tcpdump et de nous le commenter
ensuite, hein? ;)
J'imagine que le meilleur moyen de savoir est de faire un dump du
traffic, pour être sûr. Mais il se peut que la fermeture de la liaison
soit à l'initiative des deux côtés (ton fetchmailer envoie "QUIT" puis
un paquet FIN, ton serveur à réception du "QUIT" envoie aussi un FIN) et
que les RST du serveur soient des résidus ;)
Je te laisse le soin de faire un tcpdump et de nous le commenter
ensuite, hein? ;)
J'imagine que le meilleur moyen de savoir est de faire un dump du
traffic, pour être sûr. Mais il se peut que la fermeture de la liaison
soit à l'initiative des deux côtés (ton fetchmailer envoie "QUIT" puis
un paquet FIN, ton serveur à réception du "QUIT" envoie aussi un FIN) et
que les RST du serveur soient des résidus ;)
Je te laisse le soin de faire un tcpdump et de nous le commenter
ensuite, hein? ;)
- fin de la connexion initiée par le serveur distant, FIN:
08:29:12.000665 IP 74.125.79.109.995 > 192.168.0.1.51542: F 2051:2051(0) ack 444 win 106 <nop,nop,timestamp 2547694355 84435379>
- mais mon serveur continue à envoyer des choses, le QUIT peut-être:
08:29:12.001353 IP 192.168.0.1.51542 > 74.125.79.109.995: P 444:467(23) ack 2052 win 362 <nop,nop,timestamp 84435394 2547694354>
- et seulement maintenant il envoit le FIN-ACK:
08:29:12.002039 IP 192.168.0.1.51542 > 74.125.79.109.995: F 467:467(0) ack 2052 win 362 <nop,nop,timestamp 84435394 2547694354>
- en face, le serveur râle (?), et balance deux RST:
08:29:12.042022 IP 74.125.79.109.995 > 192.168.0.1.51542: R 2894719309:2894719309(0) win 0
08:29:12.042276 IP 74.125.79.109.995 > 192.168.0.1.51542: R 2894719309:2894719309(0) win 0
C'est un peu étrange quand même.
- fin de la connexion initiée par le serveur distant, FIN:
08:29:12.000665 IP 74.125.79.109.995 > 192.168.0.1.51542: F 2051:2051(0) ack 444 win 106 <nop,nop,timestamp 2547694355 84435379>
- mais mon serveur continue à envoyer des choses, le QUIT peut-être:
08:29:12.001353 IP 192.168.0.1.51542 > 74.125.79.109.995: P 444:467(23) ack 2052 win 362 <nop,nop,timestamp 84435394 2547694354>
- et seulement maintenant il envoit le FIN-ACK:
08:29:12.002039 IP 192.168.0.1.51542 > 74.125.79.109.995: F 467:467(0) ack 2052 win 362 <nop,nop,timestamp 84435394 2547694354>
- en face, le serveur râle (?), et balance deux RST:
08:29:12.042022 IP 74.125.79.109.995 > 192.168.0.1.51542: R 2894719309:2894719309(0) win 0
08:29:12.042276 IP 74.125.79.109.995 > 192.168.0.1.51542: R 2894719309:2894719309(0) win 0
C'est un peu étrange quand même.
- fin de la connexion initiée par le serveur distant, FIN:
08:29:12.000665 IP 74.125.79.109.995 > 192.168.0.1.51542: F 2051:2051(0) ack 444 win 106 <nop,nop,timestamp 2547694355 84435379>
- mais mon serveur continue à envoyer des choses, le QUIT peut-être:
08:29:12.001353 IP 192.168.0.1.51542 > 74.125.79.109.995: P 444:467(23) ack 2052 win 362 <nop,nop,timestamp 84435394 2547694354>
- et seulement maintenant il envoit le FIN-ACK:
08:29:12.002039 IP 192.168.0.1.51542 > 74.125.79.109.995: F 467:467(0) ack 2052 win 362 <nop,nop,timestamp 84435394 2547694354>
- en face, le serveur râle (?), et balance deux RST:
08:29:12.042022 IP 74.125.79.109.995 > 192.168.0.1.51542: R 2894719309:2894719309(0) win 0
08:29:12.042276 IP 74.125.79.109.995 > 192.168.0.1.51542: R 2894719309:2894719309(0) win 0
C'est un peu étrange quand même.