# [kernel/iptables] paquets INVALIDs? (résolu)

## truc

Bonjour tout le monde!

j'ai tout plein de paquets bloqués par iptables sans que je comprenne pourquoi, en fait, ce sont des paquets INVALID, mais, j'en ai même en OUTPUT:

```
Apr 23 07:18:10 sdsi kernel: [466812.596010] [OUTPUT]INVALID IN= OUT=eth1 SRC=192.168.50.1 DST=192.168.50.119 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=57756 DF PROTO=TCP SPT=8080 DPT=1335 WINDOW=6432 RES=0x00 ACK PSH FIN URGP=0
```

Bref, j'pourrais juste faire un DROP tout gentil sans logger, mais, quand même, avant que j'en arrive là, j'aimerais comprendre! Comment diable se fait-il que moi même je créé des paquets INVALIDs?

Help;)

----------

## Poussin

Je viens d'activer le drop sur l'OUTPUT chez moi (j'avoue, je ne filtrais pas cette chaîne). Je vais voir quel est le taux de drop.

Tu utiles quel commande pour généré ce log? Ta sortie est assez différente de chez moi

----------

## truc

Bah, dans ma recherche du "mais pourquoi j'ai ces paquets DROPés en fin de chaine alors que je les autorises explicitement", j'ai ajouté ça en début de script générant les règles:

```
 # LOG and DROP INVALID packets

 for CHAIN in INPUT FORWARD OUTPUT; do

     $IPTABLES -A $CHAIN -m state --state INVALID -m limit --limit 5/second -j LOG --log-prefix "[$CHAIN]INVALID "

     $IPTABLES -A $CHAIN -m state --state INVALID -j DROP

 done

```

Et à la fin du script j'ai:

```
for CHAIN in INPUT FORWARD OUTPUT; do

    $IPTABLES -A $CHAIN -m limit --limit 5/second -j LOG --log-prefix "[$CHAIN]DROP "

    $IPTABLES -A $CHAIN -j DROP

done
```

EDIT: C'est ce qui m'a permis de découvrir tout ces paquets bloqués sans raison apparente. Mais tu ne veux probablement pas faire un DROP sur la chaine OUTPUT si tu ne faisais pas de filtrage jusque là.

----------

## scherz0

 *Quote:*   

> Comment diable se fait-il que moi même je créé des paquets INVALIDs? 

 

Soit l'émetteur de ce paquet ne respecte pas TCP, soit (plus probablement) il s'agit d'un problème au niveau du suivi des connexions (connection tracking) par netfilter.  Lorsque ce paquet est examiné par le module state, la connexion liée au paquet est déjà considérée terminée.

C'est un problème très ancien dans netfilter et ses prédécesseurs.  Je ne sais pas si c'est une question d'interprétation de TCP dans netfilter, ou une erreur de mise en oeuvre (ordre dans lequel les modules examinent le paquet).

----------

## Poussin

ah ben tiens, chez moi aussi quelques paquets en sortie qui sont invalides (200 en 6h +/-)

----------

## truc

 *scherz0 wrote:*   

> Soit l'émetteur de ce paquet ne respecte pas TCP, soit (plus probablement) il s'agit d'un problème au niveau du suivi des connexions (connection tracking) par netfilter.  Lorsque ce paquet est examiné par le module state, la connexion liée au paquet est déjà considérée terminée.
> 
> C'est un problème très ancien dans netfilter et ses prédécesseurs.  Je ne sais pas si c'est une question d'interprétation de TCP dans netfilter, ou une erreur de mise en oeuvre (ordre dans lequel les modules examinent le paquet).

 

Ok, mais une connexion TCP ne reste t-elle pas ouverte plusieurs minutes avant d'être considérée terminée? Cela voudrait dire que le module state peut mettre jusqu'à plusieurs minutes avant de faire son boulot  :Shocked:  Qu'est ce que je loupe là?

Ou alors c'est plutôt une connexion qui a été fermée volontairement dont tu parles c'est bien ça?

Merci en tout cas, j'ai un début d'impression d'être un peu moins con:)

----------

## scherz0

 *Quote:*   

> Ok, mais une connexion TCP ne reste t-elle pas ouverte plusieurs minutes avant d'être considérée terminée? Cela voudrait dire que le module state peut mettre jusqu'à plusieurs minutes avant de faire son boulot  Qu'est ce que je loupe là?

 

Non, dans la procédure normale une connexion TCP se termine lorsque les deux entités ont envoyé et accusé réception du signal de fin (flag FINish).  Lorque le suivi des connexions de netfilter observe cet échange de FIN, il considére que la connexion est terminée et que tout paquet ultérieur est invalide.

Par contre, en cas de problème lors de la communication (timeout, host ou port inaccessible), il peut y avoir un envoi unilatéral d'un paquet ReSeT, qui signifie la fin de la connexion.  J'imagine que ces "plusieurs minutes" que tu mentionnes font référence au timeout.

 *Quote:*   

> Ou alors c'est plutôt une connexion qui a été fermée volontairement dont tu parles c'est bien ça? 

 

Oui, le paquet que tu as indiqué a le flag FIN, il fait partie de la fin normale de la connexion.

Ensuite, pour savoir si il s'agit de la demande de fin ou de la réponse à cette demande, il faudrait avoir la trace complète.  Étant donné le port (8080), j'imagine qu'il s'agit d'une requête http.  Dans ce cas la fin peut être autant à l'intiative du client (si il s'agit d'un client simple) que du serveur (timeout au niveau http, pas tcp).

----------

## truc

Ok merci scherz0, j'investiguerai plus pour vérifier tout ça un peu plus tard, pour l'insant, ça me va.

----------

