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