Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

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

1 réponse

1 2
Avatar
Nicolas KOWALSKI
Pascal Hambourg writes:
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.



Je viens de faire un essai en local (fetchmail vers un pop3s local),
et j'obtiens un comportement normal FIN/FIN-ACK, fin de la connexion.

Il y a probablement une raison pour que ce serveur distant envoie des
RST sans attendre le FIN-ACK, mais bon, les voies de gmail sont
impénétrables...

Un grand merci pour votre aide, j'ai appris pleins de choses ! :-)

--
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/
1 2