View previous topic :: View next topic |
Author |
Message |
truc Advocate
Joined: 25 Jul 2005 Posts: 3199
|
Posted: Mon Apr 26, 2010 9:20 am Post subject: [kernel/iptables] paquets INVALIDs? (résolu) |
|
|
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:
Code: | 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;) _________________ The End of the Internet!
Last edited by truc on Tue Apr 27, 2010 11:47 am; edited 1 time in total |
|
Back to top |
|
|
Poussin l33t
Joined: 08 Jun 2007 Posts: 659 Location: Liège
|
Posted: Mon Apr 26, 2010 10:12 am Post subject: |
|
|
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 |
|
Back to top |
|
|
truc Advocate
Joined: 25 Jul 2005 Posts: 3199
|
Posted: Mon Apr 26, 2010 11:01 am Post subject: |
|
|
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:
Code: | # 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:
Code: | 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à. _________________ The End of the Internet! |
|
Back to top |
|
|
scherz0 Apprentice
Joined: 02 Oct 2008 Posts: 154
|
Posted: Mon Apr 26, 2010 2:44 pm Post subject: |
|
|
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). |
|
Back to top |
|
|
Poussin l33t
Joined: 08 Jun 2007 Posts: 659 Location: Liège
|
Posted: Mon Apr 26, 2010 5:09 pm Post subject: |
|
|
ah ben tiens, chez moi aussi quelques paquets en sortie qui sont invalides (200 en 6h +/-) |
|
Back to top |
|
|
truc Advocate
Joined: 25 Jul 2005 Posts: 3199
|
Posted: Tue Apr 27, 2010 8:56 am Post subject: |
|
|
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 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:) _________________ The End of the Internet! |
|
Back to top |
|
|
scherz0 Apprentice
Joined: 02 Oct 2008 Posts: 154
|
Posted: Tue Apr 27, 2010 10:30 am Post subject: |
|
|
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). |
|
Back to top |
|
|
truc Advocate
Joined: 25 Jul 2005 Posts: 3199
|
Posted: Tue Apr 27, 2010 10:58 am Post subject: |
|
|
Ok merci scherz0, j'investiguerai plus pour vérifier tout ça un peu plus tard, pour l'insant, ça me va. _________________ The End of the Internet! |
|
Back to top |
|
|
|