Création de script Bash pour gérer un pare-feu Iptables

Nous allons commencer par créer notre environnement. Pour cela, nous avons installé deux machines virtuelles Parrot sur VMware.

Nous avons ensuite configuré notre futur serveur/routeur avec deux cartes réseau :

• une carte en mode LAN ,
• et une autre en WAN.

La deuxième machine, appelée admin, a été configurée avec une seule carte réseau en LAN.

La première chose à faire à présent c’est la configuration de la carte réseau local sur les deux machines.

Nous allons nous rendre dans le fichier etc/network/interfaces et nous allons y inscrire notre configuration IP.

Serveur routeur :

Machine Admin :

À présent, nous allons activer le routage sur notre serveur/routeur et revoir quelques bases avant de passer au script :

Pour que l’on puisse avoir accès du LAN au WAN et du WAN au LAN (changement de réseau, il nous faut naturellement un routeur. Toute machine Linux peut faire office de routeur. Pour cela, il faut passer le forwarding de 0 à 1 pour l’activer.

Pour rendre le routage IP permanent sur Parrot, il faut entrer la commande suivante :

echo « net.ipv4.ip_forward=1″ | sudo tee -a /etc/sysctl.conf

La commande echo combinée à un pipe redirige la sortie vers la commande tee -a (qui ajoute du texte sans écraser ce qui est déjà présent). Cela permet d’écrire dans le fichier de configuration système pour activer le routage IP

Vous pouvez également vous rendre directement dans le fichier et passer net.ipv4.ip_forward=0 à net.ipv4.ip_forward=1 et décommenter la ligne.

Si nous mettons en place un routage du LAN vers le WAN, nous avons besoin de masquer nos adresses IP privées en adresse IP publique. Pour cela, comme vous le savez, on utilise le PAT, qui est la forme de NAT la plus utilisée.

sudo iptables -t nat -A POSTROUTING -o ens33 -j MASQUERADE

Explication :

• iptables : outil de gestion du pare-feu.
• -t nat : on agit sur la table NAT.
• -A POSTROUTING : on ajoute une règle à la chaîne POSTROUTING (qui s’applique aux paquets sortants).
• -o ens33 : interface réseau de sortie (ici ens33).
• -j MASQUERADE : permet de masquer l’adresse IP source du réseau privé, en utilisant l’adresse IP publique de l’interface de sortie.

Cette commande utilise la technique PAT (Port Address Translation), qui permet à plusieurs hôtes internes de partager une seule IP publique.

Deux choses importantes à savoir sur Iptables :

1 : Iptables contient plusieurs tables, chacune servant à un type de traitement réseau :

Table filter (par defaut)

Chaînes principales :

• INPUT : trafic entrant
• OUTPUT : trafic sortant
• FORWARD : trafic relayé (routage entre interfaces)

Table nat :

Chaînes principales :

• PREROUTING : avant le routage
• POSTROUTING : après le routage (ex. : masquerade)
• OUTPUT : pour les paquets générés localement

Table mangle :

Sert à modifier les paquets (TTL, TOS, marquage…)
Plus avancé, rarement utilisé dans les cas simples.

Table raw :

Utilisée pour bypasser le suivi de connexion (conntrack), par exemple pour des performances ou des cas spéciaux.

2: Il existe plusieurs types de pare-feu. Iptables est un pare-feu qu’on appel « stateful », c’est à dire qu’il prend on considération l’état des connections et c’est ce qui le rend particulièrement intéressant en terme de sécurité.

Explication :

Lorsque vous souhaitez ouvrir une session, par exemple pour une requête HTTP vers un serveur public, vous envoyez une requête à destination du port 80 du serveur, mais votre port source sera très probablement un port aléatoire compris entre 1024 et 65535.

Ainsi, soit vous laissez TOUS vos ports ouverts (ce qui est très mauvais pour la sécurité), soit TOUS vos ports sont fermés par défaut et refusent de recevoir des connexions entrantes, SAUF celles correspondant à des connexions déjà établies, initiées par votre machine (c’est-à-dire les paquets de réponse liés au handshake TCP, comme les paquets SYN-ACK).

Passons au script :

Etape 1 :

#!/bin/bash
On commence par annoncer le shebang. C’est une séquence de caractères placée en première ligne d’un script qui indique quel interpréteur utiliser pour exécuter ce script.

Ensuite, on déclare nos variables pour les intégrer plus tard dans le script. Cela nous permettra de déployer ce script sur plusieurs configurations différentes.

Par exemple : WAN et LAN.

Enfin, pour ces variables d’interfaces, on met en place un contrôle. Si les variables ne sont pas déclarées au lancement du script, celui-ci ne s’exécutera pas et affichera la raison.

Etape 2 :  

On enchaîne ensuite avec la fermeture des trois chaînes Iptables afin de ne rien laisser passer par défaut. Nous créerons uniquement des règles d’exception selon les besoins.

Nous avons également ajouté un contrôle d’erreur simple : grâce à &&, si la commande s’exécute correctement (code de retour = 0), un echo nous confirme que la chaîne a bien été fermée.

Etape 3 :

Configuration de l’adresse de loopback et autorisation du protocole ICMP.

Pourquoi ?

Loopback
L’adresse 127.0.0.1 (loopback) est utilisée localement par le système pour permettre à des services de communiquer entre eux sur la même machine. De nombreux services critiques, notamment sur les serveurs, en dépendent pour fonctionner correctement.
Bloquer cette adresse pourrait empêcher certains services de démarrer ou de communiquer, ce qui affecterait le fonctionnement global du système.
Autoriser explicitement le trafic loopback est également une bonne pratique en matière de sécurité, car cette adresse n’est accessible que localement : seul le système peut l’utiliser.

ICMP
Le protocole ICMP est essentiel pour tester la connectivité réseau, notamment à l’aide de la commande ping. Il est également utilisé par certains mécanismes réseau comme Path MTU Discovery, qui ajuste la taille optimale des paquets pour éviter la fragmentation.
Bloquer complètement ICMP peut entraîner des problèmes de connectivité, notamment dans des environnements complexes ou distants.

Même si ICMP n’est pas un protocole de type « connexion » comme TCP (pas de handshake), il est partiellement géré par le suivi d’état (conntrack) dans iptables. Par exemple, une requête ping sortante (Echo Request) génère une réponse (Echo Reply) que conntrack considère comme établie. Ainsi, il est courant d’autoriser uniquement les paquets ICMP ayant l’état ESTABLISHED ou RELATED, pour des raisons de sécurité. Cela permet à la machine de recevoir les réponses aux pings qu’elle envoie, tout en bloquant les pings entrants non sollicités. C’est une méthode que l’on peut utiliser également avec une ACL avec le echo reply.

Enfin, nous avons mis en place des contrôles d’erreurs simples, notamment en lançant des pings et en vérifiant les résultats pour s’assurer que la configuration est fonctionnelle.

Etape 4 :

Configuration du routage et activation du PAT

Comme vu précédemment, nous avons intégré l’activation du routage IP directement dans le script. Celui-ci vérifie si le routage est déjà activé (via la directive net.ipv4.ip_forward).

• Si le routage est actif, aucune action n’est effectuée.
• Sinon, le script modifie le fichier /etc/sysctl.conf pour activer le routage de manière persistante, puis applique la modification en temps réel.

Enfin, comme expliqué précédemment, nous activons également le PAT (Port Address Translation) sur l’interface WAN, afin de permettre aux machines du réseau local d’accéder à Internet à travers l’adresse IP publique du serveur.

Etape 5 :

La boucle commence par l’affichage du menu principal.
Nous y présentons l’ensemble des options proposées par le script, permettant à l’utilisateur de sélectionner les actions à effectuer.

Etape 6 :

Rédaction des règles :

Les bonnes pratiques en matière de rédaction de règles, ainsi que les nuances d’écriture possibles.

Les cases :
C’est ici que les lignes de commande vont être affectées en fonction des choix de l’utilisateur.

Il est inutile de vous décrire toutes les commandes en détail : vous ne comprendriez pas tout immédiatement.
En revanche, je vais vous expliquer la logique des règles et les points importants à retenir.

Pour une sécurité optimale :

Comme vue précédemment nous somme sur un pare-feu « stateful » donc voici les différents états de connexions qui vont êtres pris en compte :

• NEW : autorise les paquets de nouvelles connexions.
• ESTABLISHED : autorise les paquets faisant partie d’une connexion déjà établie.
• RELATED : autorise les nouvelles connexions liées à une connexion déjà autorisée.
  Exemple : si une connexion FTP est déjà établie, et qu’un téléchargement est lancé, une nouvelle connexion est initiée sur un port différent ; si les connexions en RELATED ne sont pas autorisées, le téléchargement échouera.

L’avantage d’utiliser conntrack est que vous n’avez pas besoin d’ouvrir tous les ports qui pourraient être utilisés dans une communication comme décrit plus haut.

Généralement :

• Les règles sur la chaîne OUTPUT utilisent le port de destination (--dport).
• Les règles sur la chaîne INPUT utilisent le port source (--sport).
• FORWARD : gère le transit des paquets entre interfaces réseau, par exemple entre WAN et LAN.

Ce n’est pas toujours le cas, comme pour SSH, où l’on cible souvent le port 22 en INPUT pour les connexions entrantes.

Voici à présent quelques exemples :

Petite nouveauté : vous pouvez voir qu’avec des règles qui concernent directement le serveur, il est possible d’effectuer des contrôles d’erreur.

La commande curl permet d’envoyer des paquets via différents protocoles.
L’option -I permet de n’envoyer et de recevoir que l’en-tête (header), sans récupérer le contenu complet d’une page web, ce qui est plus rapide et plus léger pour un test.

Ensuite, on indique l’URL du site à tester, puis on masque les sorties :

• > /dev/null redirige la sortie standard (stdout) vers le « trou noir » de Linux : tout ce qui y est envoyé est immédiatement supprimé.
• 2>&1 ou 2> /dev/null (selon la syntaxe utilisée) masque la sortie d’erreur (stderr).

Cela permet de tester une règle de manière silencieuse, et de récupérer uniquement le code retour pour vérifier si le test a réussi ou échoué.

Comme vous pouvez le constater, il existe plusieurs façons de rédiger des règles, toutes correctes.
Vous pouvez choisir de compacter ou au contraire de détailler votre écriture, selon vos besoins et votre volonté de donner plus ou moins de visibilité sur la configuration. Nous aurions pu ciblé des réseau ou des adresse IP pour filtrer encore plus par exemple.

Etape 6 :

Une fois la boucle fermée il ne nous reste plus qu’a sauvegarder. PS : Pour que le script fonctionne il ne faut pas oublier de l’enregistrer en .sh.

Voici le lien si vous souhaitez télécharger mon script : https://uploadnow.io/f/zsCypw8