Introduction
Dans les laboratoires précédents, vous avez ouvert et fermé des « portes » (des ports) pour tout le monde. Mais que faire si vous voulez ouvrir la porte uniquement à votre ami, ou la fermer spécifiquement à une personne malveillante connue ?
C’est là que les rich rules entrent en jeu. Au lieu de simplement ouvrir ou fermer un service de manière générale, les rich rules vous permettent d’exprimer une politique plus précise, par exemple en filtrant les adresses source, en journalisant les événements ou en rejetant certains trafics.
Elles sont importantes, car les politiques de pare-feu réelles sont souvent conditionnelles. Les décisions de sécurité ne se résument presque jamais à « port ouvert » ou « port fermé ».
Remarque concernant l’environnement du laboratoire : pour éviter que vous ne perdiez accidentellement l’accès au terminal web, nous utiliserons la zone trusted par défaut. Tout le trafic est donc autorisé, sauf si nous le bloquons explicitement. Dans un environnement de production réel, vous utiliseriez une zone plus restrictive, comme public ou drop.
Dans ce laboratoire, vous apprendrez à :
- Bloquer certaines personnes : rejeter les connexions provenant d’une adresse IP donnée.
- Conserver des traces : journaliser les tentatives afin de voir qui a essayé d’accéder au système.
- Restreindre l’accès : configurer une règle qui autorise l’administration à distance (SSH) uniquement depuis un réseau donné.
- Auditer : enregistrer vos règles dans un fichier pour les examiner.
Bloquer une adresse IP donnée
Dans cette étape, commençons par apprendre à bloquer un acteur malveillant précis. Supposons que vous remarquiez que l’ordinateur à l’adresse 192.168.1.100 essaie de vous attaquer. Vous voulez le bloquer complètement.
Nous allons utiliser une « Rich Rule » pour cela. Même si notre zone par défaut est trusted (qui autorise tout), une règle Reject spécifique prendra le dessus pour cette adresse IP.
Les rich rules sont importantes, car les politiques de pare-feu réelles sont souvent conditionnelles. Vous pouvez vouloir appliquer un comportement différent selon l’adresse source, le service, les besoins de journalisation ou d’autres critères que de simples commandes d’ouverture ou de fermeture ne permettent pas d’exprimer correctement.
La syntaxe ressemble à la construction d’une phrase : rule family="ipv4" source address="192.168.1.100" reject
Exécutez la commande suivante pour ajouter cette règle de manière permanente.
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.100" reject'
Décomposons cette « phrase » :
rule family="ipv4": nous parlons d’adresses IP standard.source address="...": il s’agit de l’adresse de l’acteur malveillant.reject: il s’agit de l’action à effectuer.
Différence entre Reject et Drop :
- Reject est courtois : il indique à l’expéditeur « Partez, vous n’êtes pas autorisé ».
- Drop est brutal : il ignore complètement l’expéditeur, comme si votre ordinateur n’existait pas.
Le choix entre les deux ne relève pas seulement du style. reject fournit un retour plus rapide aux clients légitimes et facilite le dépannage, tandis que drop peut révéler moins d’informations à un attaquant, mais entraîner des délais d’attente plus longs.
Comme nous avons utilisé --permanent, la règle est enregistrée, mais elle n’est pas encore active. Rechargez le pare-feu pour l’appliquer.
sudo firewall-cmd --reload
Vérifiez maintenant que la règle existe.
sudo firewall-cmd --list-rich-rules
La nouvelle règle doit apparaître dans la liste.
Journaliser les paquets rejetés
Dans cette étape, nous allons au-delà du simple blocage : bloquer quelqu’un est utile, mais vous avez parfois besoin de preuves. Vous pouvez ajouter une fonction de « journalisation » à une règle. C’est comme installer une caméra de sécurité qui enregistre chaque déclenchement de la règle.
Cette combinaison du filtrage et de la journalisation est courante dans les opérations de sécurité. Le blocage protège le système, tandis que la journalisation crée des éléments que vous pourrez examiner ultérieurement.
Bloquons une autre adresse IP, 10.0.0.5, mais cette fois nous allons journaliser la tentative avant de la rejeter.
Exécutez cette commande :
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.0.5" log prefix="BLOCKED_IP: " level="info" reject'
Qu’y a-t-il de nouveau ici ?
log: active la caméra.prefix="BLOCKED_IP: ": lors de l’écriture dans les journaux du système, la ligne commence par ce texte. Il devient ainsi très facile de retrouver ultérieurement ces événements précis à l’aide d’outils de recherche.
Appliquez les modifications.
sudo firewall-cmd --reload
Vérifiez votre travail.
sudo firewall-cmd --list-rich-rules
Vous devez maintenant voir deux règles : la première (rejet simple) et la seconde (journalisation et rejet).
Restreindre l’accès à un service
Dans cette étape, considérons un environnement renforcé : vous bloqueriez SSH depuis partout et vous l’autoriseriez uniquement depuis un réseau de confiance, comme votre VPN.
Remarque pédagogique : comme nous utilisons la zone trusted pour maintenir votre connexion active, cette étape est en partie symbolique. Ajouter une règle « Allow » alors que tout est déjà autorisé ne modifie pas le comportement. Cependant, il est essentiel d’apprendre cette syntaxe pour pouvoir l’utiliser avec des zones restrictives telles que public ou drop.
L’objectif est de créer une règle qui signifie : « Autoriser SSH si la source est 192.168.0.0/24 ».
Il s’agit d’un bon exemple du principe du moindre privilège appliqué aux politiques réseau. Au lieu d’exposer l’accès administratif au monde entier, vous le limitez au réseau qui doit légitimement administrer le serveur.
Commencez par supprimer le service SSH général.
sudo firewall-cmd --permanent --remove-service=ssh
Remarque : vous pouvez voir un avertissement tel que Warning: NOT_ENABLED: ssh. C’est normal et attendu. Comme notre zone par défaut est trusted (qui autorise tout par défaut, mais ne comporte aucun service explicitement activé), la tentative de suppression d’un service qui n’est pas explicitement répertorié déclenche cet avertissement sans conséquence.
Ajoutez ensuite la Rich Rule spécifique au sous-réseau.
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.0.0/24" service name="ssh" accept'
Rechargez le pare-feu pour activer ces modifications.
sudo firewall-cmd --reload
Vérifiez maintenant le résultat. Commencez par consulter la liste des services.
sudo firewall-cmd --list-services
ssh ne doit PAS apparaître ici : il a été supprimé de la liste générale des services.
Consultez ensuite les Rich Rules.
sudo firewall-cmd --list-rich-rules
Vous devez voir une règle qui accepte service name="ssh" depuis la source spécifiée.
Auditer vos règles
Dans cette étape, retenez qu’en environnement de production, il est recommandé d’effectuer un audit final de vos règles de pare-feu et d’en créer une copie de sauvegarde avant de fermer votre session. Vous vérifiez ainsi que les règles sont appliquées dans le bon ordre et vous disposez d’un fichier permettant de les restaurer.
Dans cette étape, vous allez exporter vos Rich Rules vers un fichier texte afin de les auditer.
Commencez par afficher toutes les Rich Rules et redirigez la sortie vers un fichier nommé rules_list.txt dans votre dossier de projet.
sudo firewall-cmd --list-rich-rules > ~/project/rules_list.txt
Lisez ensuite le fichier pour vérifier que son contenu est correct.
cat ~/project/rules_list.txt
Vous devez voir la liste des règles créées dans ce laboratoire. Ce fichier constitue désormais une sauvegarde simple de votre configuration de rich rules.
Résumé
Dans ce laboratoire, vous avez développé vos compétences en matière de pare-feu à l’aide des Rich Rules. Vous avez appris à :
- Bloquer certaines adresses IP (la règle « Reject »).
- Journaliser les événements de sécurité (la règle « Camera »).
- Restreindre les services sensibles, comme SSH, aux seuls réseaux de confiance.
- Auditer votre configuration en exportant les règles dans un fichier.
Ces techniques avancées vous offrent la précision nécessaire pour sécuriser des environnements complexes.
