Quand le module conntrack d'iptable suit-il les états des paquets?

Aug 15 2020

Il doit d'abord stocker les états. Avec un vieux pare-feu BSD que j'ai utilisé, je suppose qu'il s'appelait IPFW, j'avais l'habitude de mettre une règle qui disait "garder une trace de l'état du paquet sortant", et cela était placé sur la direction sortante des interfaces. Ensuite, une autre règle sur la direction entrante qui les a comparés aux états créés par la règle sur la direction sortante. Il y avait donc 2 règles: (1) pour remplir la table des états, c'était sur la direction sortante, et (2) pour rechercher la table des états, c'était sur la direction entrante.

Mais avec connntrack, je le vois appliqué sur la chaîne INPUT, comme cette règle:

iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Cela me fait me demander ce que fait cette déclaration?

Dit-il qu'il commencera à suivre les paquets qui correspondent à cette règle en mettant leurs informations dans le tableau des états?
Ou est-il en train de dire qu'il dispose déjà des informations sur les États et qu'il va agir contre les messages entrants basés sur ces informations? (par exemple accepter s'ils appartenaient à une connexion précédemment acceptée?). Mais, dans ce cas, où la table des états a-t-elle été remplie? Quelle règle fait-il? Ou est-ce implicite et sans règle?

Réponses

5 A.B Aug 15 2020 at 21:43

Présentation introductive de Netfilter et de conntrack

Tout d'abord, le schéma obligatoire sur le flux de paquets dans Netfilter et le réseau général:

Netfilter est le cadre de filtrage de paquets qui s’insère sur le reste de la pile du réseau (représenté par la «décision de routage» et d’autres éléments de boîte blanche à bords arrondis). Netfilter fournit des hooks et des API pour d'autres sous-systèmes et "clients". Parmi ces éléments, on trouve conntrack (le traqueur de connexion) et iptables (ou nftables ). La séparation entre Netfilter et conntrack est assez floue. Vous pouvez simplement considérer conntrack comme une partie intégrée de Netfilter.

Dans le schéma décrivant les différentes étapes qu'un paquet traverse, vous pouvez voir qu'à un moment donné (entre raw / PREROUTING et mangle / PREROUTING, ou entre raw / OUTPUT et mangle / OUTPUT), le paquet traverse conntrack .

À ce stade, conntrack recherchera dans ses propres tables de recherche (une mini base de données de recherche conservée dans la mémoire du noyau):

si les caractéristiques de ce paquet ne sont pas trouvées (et si non déclaré UNTRACKED dans la table brute), une nouvelle entrée de tuple bidirectionnel conntrack (protocole, puis informations spécifiques sur la famille et le protocole: source et port initiaux, destination et port initiaux, source et port de réponse, destination et port de la réponse (ces deux derniers sont généralement inversés, à moins que NAT ou certains protocoles étranges ne soient impliqués, comme la réponse à l'écho correspondant à la demande d'écho pour ICMP)) décrivant le flux est créé avec l'état NEW.
s'il correspond (dans n'importe quelle direction) à une entrée précédente et est compatible avec l'état de ce flux, l'état du flux pourrait être modifié (par exemple: passer de NEW à ESTABLISHED si ce n'était pas le cas auparavant).
si, pour une raison spécifique, le paquet ne peut pas correspondre à un flux existant malgré ses caractéristiques (par exemple: un paquet TCP tardif reçu après une retransmission déjà lancée avec succès, donc étant hors de la fenêtre en ce qui concerne la séquence et les valeurs SACK) le le paquet sera marqué INVALID.
il y a quelques autres cas comme RELATED: il s'agit de paquets ne faisant pas partie du flux lui-même mais liés à un nouveau flux qui peut être associé à un autre flux existant (ie: dans la base de données). Deux exemples sont une erreur ICMP créée à la réception d'un paquet (par exemple: port UDP inaccessible) ou lorsqu'un assistant de protocole spécial comme le module noyau nf_conntrack_ftp, qui est un plugin du sous-système conntrack , détecte qu'un paquet fait partie du flux de données séparé associé avec les commandes FTP PASV / EPSV ou PORT / EPRT effectuées sur le flux de commande (sur le port 21).

Répondre à la question

Tout cela étant dit, voici les réponses à vos deux balles:

dans l'espace de noms principal du réseau, conntrack commence à suivre les connexions dès que ses modules (y compris les éventuels sous-modules spécifiques au protocole pertinents) sont chargés. Pour les espaces de noms de réseau non initiaux (conteneurs ...), cela nécessite également qu'un autre sous-système le référence (comme le module conntrack d' iptables d'OP ou en utilisant une fois la commande conntrackdécrite plus tard). C'est la valeur par défaut et un paquet doit être spécifiquement marqué comme UNTRACKED avant que le sous-système conntrack ne le voit pour que ce paquet ne soit pas suivi. Sous Linux, il n'y a que quelques cas où aucun suivi ne serait nécessaire, mais bien sûr, le pare-feu avec état et le NAT avec état / dynamique ne seront plus disponibles (le NAT stable qui pourrait même nécessiter l'utilisation de UNTRACKED en premier lieu, peut toujours être fait, mais pas avec iptables . tc ou nftables peut). Pour éviter que conntrack ne gère certains paquets, ce type de règle iptables peut être utilisé (par exemple: port 80 / tcp):
```
iptables -t raw -A PREROUTING -p tcp --dport 80 -j CT --notrack
iptables -t raw -A OUTPUT -p tcp --sport 80 -j CT --notrack
```
Lorsque le paquet traverse le filtre / INPUT et atteint cette règle:
```
 iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
```
Le module noyau spécifique de iptablesxt_conntrack interroge le sous-système conntrack (géré par les différents modules noyau concernés nf_conntrack*) et demande l'état de ce paquet dans sa base de données de recherche. Si la réponse est RELATEDou ESTABLISHEDle paquet correspond et passe au verdict ACCEPT. En fait, le résultat est déjà mis en cache dans le paquet la première fois que la recherche a été effectuée (généralement par conntrack ), c'est donc une "recherche" bon marché. Il s'agit donc d'une règle générique pour gérer les flux déjà acceptés auparavant. Ces flux peuvent être initialement acceptés dans des règles mentionnant explicitement -m conntrack --ctstate NEWou simplement des règles ne le mentionnant pas mais placés après cette règle générique (mais gardez à l'esprit l'état INVALID, qui devrait généralement être SUPPRIMÉ avant de le faire).
ajout d'une puce: la gestion des paquets entrants et sortants est assez symétrique entre PREROUTING et OUTPUT (même si ceux-ci ne semblent pas symétriques): les interfaces conntrack en PREROUTING ainsi qu'en OUTPUT (et dans quelques autres endroits, considérant que NAT est travaillant avec conntrack , sauf pour son premier paquet dans l'état NEW traversant la table nat d' iptables ). Cela peut être légèrement différent de la description que vous avez écrite sur IPFW. Si un serveur exécutant des applications restreint également les flux sortants, il a très probablement besoin de cette même règle iptables générique à la fois dans le filtre / OUTPUT et dans le filtre / INPUT, pour permettre aux paquets de réponse sortants du trafic entrant déjà accepté de passer.

Informations supplémentaires

Il existe des outils dédiés pour interagir avec les conntrack tables de consultation du sous - système de conntrack-tools .

conntrack: pour interroger, supprimer ou mettre à jour le contenu des tables de recherche gérées par conntrack .

Quelques exemples.

Vous pouvez lister toutes les entrées suivies (qui peuvent être volumineuses sans filtre supplémentaire) avec:
```
conntrack -L
```
Si votre système fait du NAT (par exemple un routeur devant un LAN privé, ou exécutant des VM et des conteneurs), vous pouvez utiliser --any-nat, --src-natou --dst-natafficher uniquement resp. tous les NAT, tous les NAT source (masquerade) ou tous les NAT de destination (généralement pour les ports transférés):

Surveillance en temps réel des événements conntrack :
```
conntrack -E
```
conntrackd: un démon dont les deux objectifs principaux sont la comptabilité et les statistiques de flux (conntrack), ou la synchronisation d'état de cluster de pare-feu avec état à haute disponibilité .

2 TeroKilkanen Aug 15 2020 at 20:46

Le suivi de connexion est une fonction distincte de Netfilter et n'est pas configuré avec IPTables.

Dans l'image, il y a deux conntrackétapes dans le chemin INPUT et une dans le chemin OUTPUT. Ces étapes associent des paquets individuels aux connexions existantes suivies dans la table de suivi des connexions ou créent de nouvelles entrées de suivi des connexions dans la table.

La fonctionnalité Conntrack est un module du noyau Linux, et elle est souvent incluse dans le noyau dans la configuration par défaut.

Le fonctionnement de Conntrack peut être réglé en ajustant les net.netfilter.nf_conntrackvaleurs sysctl.

Votre deuxième alternative est ce qui se passe. Les informations d'état sont enregistrées par la fonction Conntrack et la règle IPTables consulte simplement la table Conntrack pour obtenir des informations.