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

comprendre un log iptables

4 réponses
Avatar
Philippe
Bonjour,

j'ai le port 80 d'ouvert sur un serveur, mais mal grès tout j'ai
iptables qui me bloque certains paquets avec le log suivant :

Jun 25 19:04:13 myhost kernel: Droped Input packet: IN=eth3 OUT=
MAC=00:a0:c9:ea:ae:9a:00:07:cb:1e:35:76:08:00 SRC=86.126.96.41
DST=XXX.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=118 ID=49067 DF
PROTO=TCP SPT=1433 DPT=80 SEQ=3399709268 ACK=289895466 WINDOW=0 RES=0x00
ACK RST URGP=0

Je ne comprend pas pourquoi ce paquet a été droppé par iptables, il est
possible de le savoir en décryptant ce log ?


Philippe

4 réponses

Avatar
Pascal Hambourg
Salut,

Philippe a écrit :

j'ai le port 80 d'ouvert sur un serveur, mais mal grès tout j'ai
iptables qui me bloque certains paquets avec le log suivant :

Jun 25 19:04:13 myhost kernel: Droped Input packet: IN=eth3 OUT=
MAC :a0:c9:ea:ae:9a:00:07:cb:1e:35:76:08:00 SRC†.126.96.41
DST=XXX.XXX.XXX.XXX LEN@ TOS=0x00 PREC=0x00 TTL8 IDI067 DF
PROTO=TCP SPT33 DPT€ SEQ399709268 ACK(9895466 WINDOW=0 RES=0x00
ACK RST URGP=0

Je ne comprend pas pourquoi ce paquet a été droppé par iptables, il est
possible de le savoir en décryptant ce log ?



Jun 25 19:04:13 myhost kernel: Droped Input packet: IN=eth3 OUT
C'est un paquet entrant, reçu par l'interface eth3

MAC :a0:c9:ea:ae:9a:00:07:cb:1e:35:76:08:00

Dans une trame ethernet donc l'adresse MAC destination est
00:a0:c9:ea:ae:9a (normalement celle d'eth3, Intel), l'adresse source
00:07:cb:1e:35:76 (normalement celle du dernier routeur qui a transmis
le paquet, ici une Freebox)

SRC†.126.96.41

Dont l'adresse IP source est 86.128.96.41

DST=XXX.XXX.XXX.XXX LEN@ TOS=0x00 PREC=0x00 TTL8 IDI067 DF

(Pas grand chose d'intéressant ici)

PROTO=TCP SPT33 DPT€ SEQ399709268 ACK(9895466 WINDOW0 RES=0x00
ACK RST URGP=0

Contenant un segment TCP avec le port source 1433 et le port destination
80 (HTTP), avec les flags ACK (acquittement) et RST (reset) activés.

C'est ce qu'on appelle un paquet "reset", qui a pour fonction
d'interrompre une connexion TCP. Sans connaître le jeu de règles et en
particulier la règle qui a bloqué ce paquet, il est délicat d'avancer
une raison, mais une raison courante pour ce type de paquet est qu'il a
été classé dans l'état INVALID par le suivi de connexion TCP de
Netfilter, peut-être parce que la connexion TCP était déjà terminée ou
est restée inactive trop longtemps et a été oubliée.
Avatar
philippe
Pascal Hambourg a écrit :
C'est ce qu'on appelle un paquet "reset", qui a pour fonction
d'interrompre une connexion TCP. Sans connaître le jeu de règles et en
particulier la règle qui a bloqué ce paquet, il est délicat d'avancer
une raison, mais une raison courante pour ce type de paquet est qu'il a
été classé dans l'état INVALID par le suivi de connexion TCP de
Netfilter, peut-être parce que la connexion TCP était déjà terminée ou
est restée inactive trop longtemps et a été oubliée.



Je n'ai pas précisé à iptables de rejeter les paquets marqués INVALID,
est ce effectué par défaut ?
car je ne fait que déclarer cet élément de configuration :

iptables -A newcnx -p tcp --dport 80 -j ACCEPT

sachant que :

iptables -A droplog -m pkttype --pkt-type broadcast -j DROP

droplog est la chaine qui permet de logger tout ce qui se passe.

Merci beaucoup pour ce petit cours ;)

Philippe
Avatar
Pascal Hambourg
philippe a écrit :

Je n'ai pas précisé à iptables de rejeter les paquets marqués INVALID,
est ce effectué par défaut ?



Ça dépend des règles et de la politique par défaut de la chaîne. Avec
une politique par défaut à DROP et pas de règle acceptant les paquets
INVALID, ces derniers sont bloqués.

car je ne fait que déclarer cet élément de configuration :

iptables -A newcnx -p tcp --dport 80 -j ACCEPT

sachant que :

iptables -A droplog -m pkttype --pkt-type broadcast -j DROP

droplog est la chaine qui permet de logger tout ce qui se passe.



Ces quelques extraits du jeu de règle sont insuffisants pour qu'on
puisse en conclure quoi que ce soit, d'autant plus qu'il semble élaboré
puisqu'il fait appel à des chaînes utilisateur.
Avatar
philippe
Pascal Hambourg a écrit :
car je ne fait que déclarer cet élément de configuration :

iptables -A newcnx -p tcp --dport 80 -j ACCEPT

sachant que :

iptables -A droplog -m pkttype --pkt-type broadcast -j DROP

droplog est la chaine qui permet de logger tout ce qui se passe.



Ces quelques extraits du jeu de règle sont insuffisants pour qu'on
puisse en conclure quoi que ce soit, d'autant plus qu'il semble élaboré
puisqu'il fait appel à des chaînes utilisateur.



oui la règle par défaut est de tout bloquer en INPUT OUTPUT et FORWARD
et en effet j'ai oublié de préciser ça :

iptables -N droplog
iptables -N newcnx
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -m state --state NEW -j newcnx
iptables -A INPUT -j droplog
iptables -A newcnx -p tcp --dport 80 -j ACCEPT
iptables -A droplog -m pkttype --pkt-type broadcast -j DROP

donc ok les paquets INVALID sont droppés...

Merci !

Philippe