NEW de conntrack sur un paquet ACK : ce que cela ne prouve pas

Dans le journal du pare-feu, il y a une ligne que vous n’attendiez pas : un paquet ACK, un état conntrack NEW, une adresse source qui n’est pas la vôtre, un port de destination ouvert. La tentation est de le lire comme une nouvelle connexion entrante que personne n’a autorisée. Ce que la ligne dit réellement est plus étroit : lorsque ce paquet a atteint ce hook, le suiveur n’avait aucun état correspondant, et le paquet portait un ACK. Ce sont deux faits sur deux choses différentes, et aucun des deux n’est la transcription complète d’une poignée de main. Voici l’ordre que je suis avant de tirer une conclusion.

Commencez par le paquet, pas par le verdict

Séparez les observations avant de les interpréter. Les drapeaux TCP décrivent ce paquet, l’état du suiveur décrit ce qu’il savait à ce hook, et votre capture ne décrit que la fenêtre que vous avez enregistrée.

Confondre ces trois choses, c’est ainsi qu’un ACK devient « le fournisseur a laissé entrer quelqu’un ».

Ce que NEW signifie vraiment au hook

La correspondance conntrack d’iptables documente NEW comme un paquet qui démarre une connexion, ou un paquet associé à une connexion qui n’a pas encore vu de trafic dans les deux sens. ESTABLISHED signifie que le suiveur a vu des paquets dans les deux sens. Aucune des deux définitions ne dit que le paquet était un SYN, ni qu’il est arrivé sans historique.

Un suiveur qui commence à observer un flux en cours de route classe le paquet suivant selon ce qu’il sait, et cela peut être rien. C’est une affirmation sur la mémoire du suiveur, non sur l’intention de l’hôte distant.

Le suivi lâche explique la plupart des surprises avec ACK

Le noyau documente nf_conntrack_tcp_loose, ce qui permet au suiveur de récupérer des connexions TCP dont il n’a pas vu le début. Avec le réglage à sa valeur par défaut, un ACK au milieu d’un flux peut être adopté comme flux établi. Désactivez-le, et le même paquet sera plus probablement classé INVALID plutôt que NEW. Les deux issues décrivent les règles du suiveur, non l’historique de l’application.

Vérifiez donc ce réglage avant de bâtir une théorie sur l’étiquette.

Écartez les causes ennuyeuses dans cet ordre

La plupart des événements NEW sur ACK que j’ai poursuivis se sont terminés par l’une de celles-ci, et toutes sont bon marché à vérifier :

• La table conntrack a été vidée, ou le suiveur a redémarré.
• L’hôte a redémarré, ou le flux a migré vers un autre namespace ou périphérique.
• Le routage asymétrique a fait sortir le SYN par un chemin que vous ne capturez pas.
• NAT a réécrit le tuple, donc l’entrée ne correspond plus à ce que vous avez lu.
• La capture a commencé tard et n’a jamais vu le début.

Chacune de ces causes retire les paquets antérieurs de la vue du suiveur tout en laissant les suivants intacts. Un redémarrage ou un vidage de table est le plus facile à confirmer via l’uptime et les journaux. Le routage asymétrique se voit comme une capture unidirectionnelle. NAT est le plus sournois, car le tuple que le suiveur a stocké n’est pas celui imprimé dans le journal.

Notez lesquelles vous avez écartées, et comment, avant de continuer.

Lisez le tuple, l’interface et le hook

Une entrée conntrack est indexée par adresses, ports et protocole, donc toute traduction change l’entrée qui correspond. Notez aussi l’interface et le hook, car un paquet vu sur la mauvaise interface ou après une autre chaîne vous dit que le chemin n’est pas celui du schéma. Quand l’événement implique un VPN, décidez si vous regardez le paquet interne ou le porteur externe. Comparez ensuite avec ce que la passerelle a journalisé pour le même tuple à cinq éléments.

Deux vues d’un même flux qui se contredisent sont plus instructives que l’une ou l’autre seule.

Quand il vaut la peine d’escalader

Escaladez quand vous pouvez montrer un service joignable qui ne devrait pas l’être, avec le flux, la règle qui l’a autorisé et des preuves des deux côtés. Ne signalez pas un défaut du fournisseur sur la base d’une seule étiquette d’état ou d’une capture partielle, car ce signalement sera clos avec l’explication que vous venez de lire. Si le service est réellement exposé, le propriétaire de cette frontière est la bonne personne pour le corriger, et une redirection de port déléguée ou une écoute involontaire est une cause plus probable qu’un bug.

Corrigez ensuite le trou de visibilité qui a laissé un paquet ressembler à une session entière.