Les règles à action multiple dans NFtables

Chapitre Progression:

NFtables introduit un nouveau concept intéressant au niveau des règles. Nous avons en effet vu qu'une règle était composée :

  • D'un filtre qui permet de cibler certains paquets selon leur composition
  • D'une action qui permet d'effectuer une action (ou non) par le système

Sous IPtables, chaque règle ne pouvait avoir qu'une action. Cela signifie que si l'on souhaitait écrire des journaux et rejeter les paquets qui avaient comme IP source 192.168.50.4, on devait utiliser deux lignes distinctes, ce qui alourdissait bien évidemment la gestion des règles :

iptables –A INPUT –s 192.168.50.4 –J NFLOG –nflog-prefix "DENY 192.168.50.4 – "
iptables –A INPUT –s 192.168.50.4 –J DROP

NFtables va maintenant pouvoir permettre d'effectuer plusieurs actions en une seule ligne, par exemple, produire des logs, et en plus bloquer les paquets.

I. Produire des logs avec NFtables

NFtables intègre le fait de pouvoir journaliser l'application d'une règle et l'action qu'elle mène, ce qui permet de journaliser plus facilement des évènements traités NFtables.

Note : La fonctionnalité de logging du trafic dans NFtables est pleinement utilisable à partir de la version 3.17 du kernel Linux. Si vous êtes dans une version inférieure, vous aurez à charger un module du Noyau Linux avec la ligne de commande suivante : modprobe ipt_LOG

Si on suit l'exemple vu plus haut avec IPtables, cela donnera cette commande :

nft add rule mon_filtreIPv4 input ip saddr 192.168.10.1 log drop

Si j'utilise ensuite une machine avec cette IP et que j'essaie de communiquer avec mon serveur sur lequel se trouve NFtables, nous verrons des logs dans le fichier /var/log/kernel.log actif :

nftables-logs
Journaux d'évènements (logs) produits par NFtables

Un autre exemple, avec NFtables, on peut facilement loguer tout le trafic entrant :

nft add rule filter input log

Il faut cependant ne pas oublier que cela peut être assez lourd à gérer pour le système, tant en terme de vitesse de traitements que d'espace de stockage. Une autre notion intéressante est celle des préfixes. Celle-ci permet, lorsque l'on produit des logs à partir d'une règle, d'y ajouter un préfixe, une sorte de commentaire :

nft add rule mon_filtreIPv4 input ip saddr 192.168.10.1 log prefix "Nftables_log " drop

On pourra ensuite retourner voir, après avoir généré des logs, dans notre fichier /var/log/kernel.log afin voir notre préfixe :

nftables-logs-01
Journaux d'évènements (logs) produits par NFtables

Il est alors facilement envisageable d'avoir plusieurs préfixes, chacun affecté à une règle particulière.

II. Action Counter dans NFtables

Les "counters" sont la possibilité de compter les paquets qui correspondent à une certaine règle. Cela permet d'obtenir, par exemple, des statistiques qui permettent de répondre à la question "combien de paquets sont passés et dont la structure correspondait avec cette règle ?". Un premier exemple pour que vous voyez à quoi cela va ressembler.

Je souhaite par exemple compter tous les paquets sortants qui porteront sur le protocole DNS en UDP. Pour faire plus clair, je souhaite savoir combien de requêtes DNS ma machine va passer. Je saisis donc, dans ma table de la famille IPv4, dans ma chaine attachée au Hook OUTPUT la règle suivante :

nft add rule mon_filtreIPv4 output udp dport 53 counter

Si l'on étudie cette règle d'un peu plus près (et pour faire un léger rappel ;)) :

  • Nft add rule : J'ajoute une règle via NFtables
  • Mon_filtreIPv4 output : Je l'ajoute dans la table "mon_filtreIPv4" dans la chaine "output"
  • Udp dport 53 : Je filtre les paquets utilisant le protocole de transport "udp" avec pour port destination "53"
  • Counter : La seule action que je vais effectuer sur ces paquets est "counter", c’est-à-dire compter combien d'octets passent

Après avoir passé cette règle, en l'ayant adaptée à vos tables et chaines existantes, vous pourrez effectuer des requêtes DNS en pinguant un nom de domaine ou en naviguant sur internet par exemple.

Note : Pensez à bien autoriser le protocole DNS (UDP, port 53) en entrée et en sortie ! 😉

Après avoir généré du trafic DNS, on pourra regarder notre table "mon_filtreIPv4" via la commande habituelle :

nft list table mon_filtreIPv4 –a

Et voici ce que l'on pourra apercevoir :

P4-nftabes-counter-01

On voit en effet que la partie "counter" s'est incrémentée. J'ai donc généré 12 paquets DNS, ce qui représente 769 octets.

À noter que je n'ai effectué ici qu'un counter, j'aurais également pu, grâce à la prise en compte des multi-actions, compter, et accepter les paquets dans la même commande (ce qui n'aurait été utile que si je terminais ma chaine par un "drop", souvenez-vous 😉 ):

nft add rule mon_filtreIPv4 output udp dport 53 counter accept

Il faut tout de même noter une particularité intéressante de la fonction "counter". Celle-ci va être effective en fonction de l'endroit où vous la placez. Je m'explique, pour cette règle, tous les paquets UDP en destination du port 53 passant sur le Hook Ouput vont être comptés :

nft add rule mon_filtreIPv4 output udp dport 53 counter accept

En revanche pour celle-ci, tous les paquets udp, peu importe le port de destination, vont être comptés :

nft add rule mon_filtreIPv4 output counter udp dport 53 accept

Avez-vous vu la différence ? L'instruction "counter" n'est pas positionnée au même endroit ! L'endroit où est positionné la règle counter va donc jouer sur ce qui va être compté.

Encore une fois, c'est une subtilité qui permet de rendre l'écriture de règle et la manipulation de NFtables plus souple :

nft add rule ip filter output ip daddr 1.2.3.4 counter drop

P4-nftabes-counter-02

Après avoir passé mes deux règles, que vous pourrez voir en handle 55 et 54, j'ai de nouveau généré du trafic UDP (DNS et DHCP), on voit bien la différence des paquets comptabilisés, ce qui montre qu'en fonction de l'endroit où vous positionnez votre "counter", il ne comptera pas les mêmes choses. Soyez donc prudent.

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