Connection Tracking, ou ct, ou conntrack avec NFtables

Le connection tracking, ou suivi de connexion, est un principe intéressant et utile lorsque l'on configure le pare-feu NetFilter. Il répond à plusieurs problématiques mais nous allons voir la plus courante.

Si nous avons un serveur Linux (A) protégé par SSH et que je souhaite établir une connexion SSH depuis ce serveur vers un autre serveur Linux (B).

Je vais devoir faire deux choses :

• Autoriser avec nftables les paquets sortants avec comme port de destination le port 22 (SSH), donc avec un commande comme celle-ci :

root@debian# nft add rule monFiltre_IPv4 output tcp dport 22 accept

•  Autoriser avevc nftables les paquets entrants avec comme port source le port 22 (SSH) : ceux qui font le chemin retour ! Donc avec un commande comme celle-ci :

root@debian# nft add rule monFiltre_IPv4 input tcp sport 22 accept

Et c'est ici que ça bloque ! Je n'ai jamais demandé à accepter les connexions SSH entrantes. Avec ce que j'ai fait là, tout le monde va pouvoir tenter une connexion SSH sur mon serveur A alors que je souhaite juste que ce serveur A puisse initier une connexion SSH vers le serveur B, seulement si je ne mets pace en place ma seconde règle, mes paquets de retour ne pourront jamais revenir, problématique intéressante n'est-ce pas ?

En fait pour résoudre le problème, il faudrait que je dise à Netfilter : "tu peux autoriser les paquets entrants, seulement si la connexion est déjà initialisée (par moi dans ce contexte ci).". Et bien voilà, on vient voir ce qu'était le connection tracking.

Autrement dit, nous allons dire à NetFilter d'autoriser mes paquets SSH en sortie (ce qui est normal), puis en entrée, on va lui dire d'accepter tous les paquets qui correspondent à une connexion TCP déjà établie. Cela nous évite donc d'ouvrir le port SSH en entrée. Si un paquet entrant avec un port de destination 22 arrive, il sera refusé dans le cas où il ne correspond pas à une connexion déjà établie. Dans cet exemple précis, voici la règle qu'il faudra ajouter sur la chaine input de ma table (monFiltre_IPv4 ici) :

root@debian# nft add rule monFiltre_IPv4 input ct state established,related accept
root@debian# nft add rule monFiltre_IPv4 input drop

Nous mettons donc en place du connection tracking (ct) qui va porter sur l'état (state) des connexions established et related.

Une petite précision sur les états des connexions TCP. Il en existe 5 :

• NEW : Il s'agit des premiers paquets d'une connexion (Exemple : premier paquet TCP SYN d'une connexion TCP).
• ESTABLISHED : Echange de paquet dans les deux sens, la connexion est dite "établie".
• RELATED : Connexion qui se réfère d'une connexion ESTABLISHED et créé par elle (Exemple, une connexion FTP-DATA après une authentification correcte via le protocole FTP).
• INVALID : Paquet sans état et ne pouvant être rattaché à une connexion déjà connue, à dropper.
• UNTRACKED : Paquet ne faisant pas partie d'une connexion connue.

Les pare-feu gérant les états comme NetFilter sont généralement plus robustes car plus précis dans leur filtrage. Ils sont appelés pare-feu "statefull".

Voilà, c'est la fin du quatrième module, nous avons vu bien des choses dans celui-ci ! N'hésitez pas à revenir sur les sujets qui vous ont parus complexes.

Le secret pour bien comprendre étant de manipuler, si possible dans des contextes réels, nous allons dédier tout le cinquième et dernier module à des exercices concrets, proches de la réalité opérationnelle pour appliquer tout ce que nous avons vu ensemble. Nous verrons au passage comment passer d'un ensemble de règle sous IPtables a leur équivalent nftables.

Rendez-vous dans le cinquième module !