Linux dispose d'un pare-feu en mode noyau nommé netfilter. Ce fonctionnement en mode noyau le rend très performant mais difficilement accessible. Or un pare-feu fonctionne sur la base de règles d'autorisation, d'interdiction ou de transfert. Pour gérer ces règles, les concepteurs initiaux ont créé la commande iptables. Pour regrouper les règles "dynamiques" ou "fluctuantes", la commande iptablespeut utiliser des jeux d'adresses IP gérés par la commande ipset.
Depuis de nombreux utilitaires tentent d'élever le niveau d'abstraction dans le but de simplifier la gestion des règles du pare-feu car cela peut s'avérer extrêmement complexe si les contraintes sont nombreuses voire paradoxales. En effet, la mauvaise compréhension de la "logique" de la commande iptablespeut provoquer des "trous" de sécurité.
La meilleure façon de vérifier le fonctionnement d'un pare-feu est d'en tracer les actions critiques. Le but de ce document n'est pas d'exposer la logique d'iptables ou d'ipset. Elles sont supposées connues à ce stade. Son objectif est de montrer comment via les journaux gérés par le service systemdil est possible de tracer les actions du pare-feu.
Le mécanisme pour obtenir des traces suites aux actions du pare-feu est assez simple : on envoie le paquet qui répond à une règle vers la cible pré-définie LOG(notez qu'il existe aussi la cible ULOG plus spécifique aux traces utilisateur cf. man iptables en français). Cette commande est non déterminante, c'est à dire que le pare-feu passe à la règle suivante : il ne se déroute pas contrairemennt aux autres actions de l'option -j.
L'option de traçage est -j LOG ce qui trace la correspondance rencontrée dans le journal système. Les distributions les plus récentes (Debian 12 et au-dessus par exemple), n'utilisent plus syslog ou syslog-ng pour gérer les journaux systèmes. En conséquence, les traces de la commande la commande iptables accessibles via la commande journalctl sont noyées dans les autres traces. Fort heureusement, la commande journalctl -g permet de faire une recherche sur expression régulière (-g pour grep). De plus, il est possible de faire précéder chaque trace de la commande iptables d'un préfixe --log-prefix={préfixe} que l'on pourra ensuite rechercher via la commande journalctl -g. On associe aussi généralement aux traces système un niveau de sévérité (de 0 la plus importante à 7) selon les niveaux ci-dessous :
Ce niveau de sévérité est fixé via l'option --loglevel={entier entre 0 et 7}.
iptables -A INPUT -m limit 50/second -j LOG --log-prefix "IPTables: " --log-level 4
La commande ci-dessous détecte les paquets "entrants". Si la fréquence des paquest d'une adresse IP est supérieure à 50 paquets par seconde, alors une trace de type avertissement est inscrite dans le journal avec comme préfixe IPTables:. Pour rechercher ces traces dans le journal système tapez la commande :
journalctl -g 'IPTables'
Dans l'exemple ci-dessus, les adresses émettant des paquets à une fréquecne anormale sont détectés mais ces paquets ne sont pas filtrés car la cible LOG n'est pas déterminante. On peut souhaiter, notamment dans le cas des adresses à rejeter, de tracer le filtrage puis de l'appliquer. Là encore, le problème est simple à résoudre. On créé une "cible" vers laquelle on envoi les paquets filtrés (iptables -N), puis c'est cette cible qui est responsable du traitement effectif du filtrage.
iptables -N LOGPROCESSING # on ajoute une règle pour limiter le nombre de traces dans le journal iptables -A LOGPROCESSING -m limit --limit 2/min -j LOG --log-prefix "IPTables: " --log-level 4 # en sortie de cible, les paquets sont détruits iptables -A LOGPROCESSING -j DROP
En reprenant notre exemple de filtrage des paquets de fréquence trop haute, la règle devient :
iptables -A INPUT -m limit 50/second -j LOGPROCESSING
Lorsque cette règle est rencontrée, les paquets sont redirigés vers la cible LOGPROCESSINGoù l'adresse est tracée et ses paquets détruits.
Rédaction par Jean-Marie Piatte (1983-2021)