La boîte à outils : OPNsense, nmap et l'IDS/IPS Suricata

Où regarder, une fois la maquette montée, avant d'écrire la première règle de pare-feu ? L'interface d'administration d'OPNsense se range en quelques menus stables sur tout le cours, et le labo ajoute deux ou trois outils dont les noms reviendront souvent.

Interfaces sert à l'adressage de chaque zone, Firewall > Rules aux règles par interface, Firewall > NAT à la traduction d'adresses, Firewall > Aliases à nommer des groupes d'adresses ou de ports, et Status > System Logs > Firewall à lire, ligne par ligne, ce qui vient d'être autorisé ou bloqué.

Le labo utilise aussi des outils installés sur la machine attaquante pour tester la politique du pare-feu depuis l'extérieur, comme le ferait un visiteur ou un intrus. Nmap sonde des ports pour dire s'ils sont ouverts, fermés ou filtrés (le module précédent en détaille la logique). Hping3 forge des paquets à la main, utile pour tester une règle précise sans dépendre d'un service réel. Suricata, lui, tourne côté défense : c'est un IDS/IPS, un système de détection et de prévention d'intrusion qui inspecte le contenu du trafic autorisé par le pare-feu et peut alerter, voire bloquer, un motif connu d'attaque.

UTM : plusieurs fonctions, un seul boîtier

OPNsense ne se limite pas au filtrage réseau : activé pleinement, il rassemble sous un même boîtier un pare-feu, un proxy web capable d'inspecter et de bloquer des pages, un antivirus de flux et l'IDS/IPS Suricata déjà cité. Cette combinaison porte un nom générique : UTM, pour gestion unifiée des menaces. Le module suivant y revient en détail ; retenez pour l'instant que ces fonctions coexistent sur la même machine, sans s'exclure.

Un piège technique revient souvent au premier contact avec ces outils : sur OPNsense, un changement de règle affiché comme sauvegardé n'est pas forcément actif. Une bannière orange Apply changes (appliquer les changements) apparaît après chaque modification de règle ; tant qu'elle n'a pas été cliquée, l'ancienne règle continue de s'appliquer. C'est la cause la plus fréquente d'un test qui semble prouver qu'une règle ne marche pas, alors qu'elle n'a simplement jamais été activée.

À retenir

• Cinq menus OPNsense reviennent dans tout le cours : Interfaces, Firewall > Rules, Firewall > NAT, Firewall > Aliases, et le journal Status > Logs > Firewall.
• Nmap sonde les ports, hping3 forge des paquets à la main : deux outils d'attaque utilisés côté labo pour tester le pare-feu.
• Suricata (IDS/IPS) inspecte le contenu du trafic déjà autorisé ; il complète le filtrage par règles, il ne le remplace pas.
• OPNsense en UTM réunit pare-feu, proxy web, antivirus et IDS/IPS sur un seul boîtier.

Piège d'examen : une règle modifiée puis sauvegardée reste inactive tant que la bannière Apply changes n'a pas été cliquée. Devant un test qui échoue sans raison apparente, vérifiez ce clic manqué en première hypothèse, avant de soupçonner la règle elle-même.

*Vérifié le 27 septembre 2026 sur la documentation OPNsense (menus Firewall > Rules, NAT, Aliases ; IDS/IPS Suricata).*