Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Linux Autres OS Linux Debian iptables et paquets réponses pop3s

iptables et paquets réponses pop3s

11 réponses
Avatar
Nicolas KOWALSKI
Bonjour,

J'ai quelques règles iptables sur ma machines pour filtrer les
requètes entrantes :

# iptables-save
# Generated by iptables-save v1.4.2 on Thu Mar 4 18:03:12 2010
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [56903:19141251]
-A INPUT -i lo -j ACCEPT
-A INPUT -s 192.168.0.0/24 -i eth0 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource
-A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH --rsource -j DROP
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 143 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 465 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 587 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -j ULOG --ulog-prefix "DROP: "
-A INPUT -j DROP
-A FORWARD -j DROP
COMMIT
# Completed on Thu Mar 4 18:03:12 2010


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 ?

Merci,
--
Nicolas

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/87tyswovsv.fsf@petole.demisel.net
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Pascal Hambourg
Nicolas KOWALSKI a écrit :

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 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.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
fra-duf-no-spam
Le 14672ième jour après Epoch,
Nicolas KOWALSKI écrivait:

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 ?



Ton programme de récupération (fetchmail?) quitte avant d'attendr e 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.

Pas grave, mais pas très propre. Tu peux probablement masquer ça dans
les règles iptables, ou alors choisir un récupérateur de mai ls qui
attends au moins un peu les paquets de fermeture de liaison TCP.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Nicolas KOWALSKI
Pascal Hambourg writes:

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.



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

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Nicolas KOWALSKI
(François TOURDE) writes:

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.



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 ?

--
Nicolas

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
fra-duf-no-spam
Le 14672ième jour après Epoch,
Nicolas KOWALSKI écrivait:

(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é ?



En général, et comme tu le dis après, la terminaison d'une l iaison se
fait avec FIN et FIN-ACK ... Mais si pour une raison X ou Y l'un des
côtés ne renvoie pas d'ACK dans certains cas, alors l'autre peut envoyer
un RST pour dire "Bon, on recommence, ça déconne".

Normalement on devrait avoir du FIN depuis mon-serveur puis FIN-ACK
depuis le serveur distant, non ?



Effectivement.

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 li aison
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? ;)

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Pascal Hambourg
Nicolas KOWALSKI a écrit :

Normalement on devrait avoir du FIN depuis mon-serveur puis FIN-ACK
depuis le serveur distant, non ?



Oui, c'est la façon normale de terminer une connexion TCP. RST ne sert
normalement que pour répondre à un paquet TCP inattendu, comme une
demande de connexion SYN sur un port fermé.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Pascal Hambourg
Nicolas KOWALSKI a écrit :
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 moins que ces RST soient réellement invalides.

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.

The patch below adds a new flag and new field to struct
ip_ct_tcp_state so that checking RST segments can be made more
strict and thus TCP conntrack can catch the invalid ones: the RST
segment is accepted only if its sequence number higher than or equal
to the highest ack we seen from the other direction. (The last_ack
field cannot be reused because it is used to catch resent packets.)

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Nicolas KOWALSKI
Pascal Hambourg writes:

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.



Ok, donc le 2.6.26 acceptait des saletés, et le 2.6.32 est plus
strict ; ce n'est pas plus mal.

Maintenant je vais essayer de trouver d'où vient la première
craderie, client (fetchmail) ou serveur pop3s.

Merci pour tes explications et tes recherches,
--
Nicolas

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Nicolas KOWALSKI
(François TOURDE) writes:

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? ;)



Voila voila:

- établissement de la connexion, SYN, SYN-ACK:

08:29:11.434204 IP 192.168.0.1.51542 > 74.125.79.109.995: S 3846148028:3846148028(0) win 5840 <mss 1460,sackOK,timestamp 84435252 0,nop,wscale 5>
08:29:11.473489 IP 74.125.79.109.995 > 192.168.0.1.51542: S 2894717257:2894717257(0) ack 3846148029 win 5672 <mss 1430,sackOK,timestamp 2547693827 84435252,nop,wscale 6>

- ensuite les données habituelles

08:29:11.473604 IP 192.168.0.1.51542 > 74.125.79.109.995: . ack 1 win 183 <nop,nop,timestamp 84435262 2547693827>
08:29:11.489318 IP 192.168.0.1.51542 > 74.125.79.109.995: P 1:103(102) ack 1 win 183 <nop,nop,timestamp 84435266 2547693827>
08:29:11.530504 IP 74.125.79.109.995 > 192.168.0.1.51542: . ack 103 win 89 <nop,nop,timestamp 2547693884 84435266>
08:29:11.531858 IP 74.125.79.109.995 > 192.168.0.1.51542: . 1:1419(1418) ack 103 win 89 <nop,nop,timestamp 2547693884 84435266>
08:29:11.531860 IP 74.125.79.109.995 > 192.168.0.1.51542: P 1419:1661(242) ack 103 win 89 <nop,nop,timestamp 2547693884 84435266>

- 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.

--
Nicolas

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Pascal Hambourg
Nicolas KOWALSKI a écrit :

- 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.



Je ne suis pas un fin connaisseur des subtilités de TCP, mais j'ai
trouvé ça dans RFC 793 :

Case 2: TCP receives a FIN from the network

If an unsolicited FIN arrives from the network, the receiving TCP
can ACK it and tell the user that the connection is closing. The
user will respond with a CLOSE, upon which the TCP can send a FIN to
the other TCP after sending any remaining data. The TCP then waits
until its own FIN is acknowledged whereupon it deletes the
connection. If an ACK is not forthcoming, after the user timeout
the connection is aborted and the user is told.

Donc le côté qui envoie le FIN devrait s'attendre à ce que l'autre côté
envoie encore des données avant d'envoyer son propre FIN.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
1 2