Connection Tracking, ou ct, ou conntrack avec NFtables

Chapitre Progression:

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).

Schéma-ssh-01Je vais devoir faire deux choses :

  • Ouvrir avec NFtables les connexions sortantes avec comme port de destination le port 22 (SSH) pour les paquets sortants, donc avec un commande comme celle-ci :
nft add rule filter output tcp dport 22 accept
  •  Ouvrir avec NFtables les connexions entrantes avec comme port source le port 22 (SSH) pour les paquets entrants (ceux qui font le chemin retour !), donc avec un commande comme celle-ci :
nft add rule filter 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).". Eh bien voilà, on vient voir ce qu'était la connexion tracking.

Autrement dit, on va 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 ("filter" ici) :

nft add rule filter input ct state established,related accept
nft add rule filter input drop

On met 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 types :

  • NEW : Il s'agit des premiers paquets d'une connexion (Exemple : premièr 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. Tout cela dans la bonne humeur ! 🙂

Rendez-vous dans le cinquième module !

Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Partager sur Google+ Envoyer par mail

    Mickael Dorigny

    Co-fondateur d'IT-Connect.fr. Auditeur en sécurité des systèmes d'information chez Amossys

      mickael has 502 posts and counting.See all posts by mickael