Date de dernière modification de l’article :
Dans cet article, nous explorerons comment Suricata fonctionne en tant que solution IPS et comment son intégration dans OpnSense peut renforcer la sécurité de votre réseau. Nous aborderons les configurations, ainsi que les meilleures pratiques pour améliorer l’efficacité de votre système de sécurité.
Le Système de Détection d’Intrusion (IDS) peut être installé sur nos pare-feux ou appareils pour identifier des déclencheurs ou des anomalies dans le trafic réseau. Cette détection repose sur des signatures et des règles que nous configurons dans l’IDS.
Le Système de Prévention des Intrusions (IPS) offre les mêmes capacités que l’IDS, mais va plus loin en permettant également de bloquer ou de refuser le trafic spécifique en fonction des signatures ou des anomalies détectées.
Rendez-vous vers l’article suivant si vous voulez comprendre l’installation & la configuration de base d’OpnSense :
Section 1 : Configuration de notre IDPS Suricata dans l’interface d’administration WEB d’OpnSense :
A. Installation & configuration de notre IDPS Suricata :
Pour que notre IDPS fonctionne correctement, il sera nécessaire d’accéder aux paramètres de l’interface et de vérifier que les paramètres matériels réseau suivants soient bien cochés :
Après avoir appliqué les modifications, rendez-vous dans « Services », « Détection d’intrusion », puis « Administration ». Activez le « Mode avancé » et cochez toutes les cases pour activer les options suivantes : Cochez « Activé », « mode IPS », « mode promiscuité » et « Activer les alertes syslog ».
Ensuite, pour le « Pattern matcher », passez le mode en « Hyperscan », séléctionnez les interfaces sur lesquelles vous souhaitez que Suricata vous prévienne d’actions malveillantes par le biais de règles. Dans « Home networks », ce sera normalement déjà rempli sinon, vous avez juste à remplir les plages d’adresses IP utilisées pour des environnements réseau privés conformément à ce que dit les normes protocolaires : RFC1918. Appliquez les modifications pour finaliser.
B. Paramétrage des règles et des profils :
Nous allons d’abord télécharger des configurations de règles pré-établies qui sont proposées pour Suricata en allant dans « Download », séléctionnez les règles que vous souhaitez, pour ma part, je vais vous faire une rapide description des règles que je vais choisir de télécharger (cliquez sur « Download & Update Rules » une fois votre sélection de règles terminée et activez vos règles en cliquant sur « Enable selected » ) :
– abuse.ch/SSL Fingerprint Blacklist :
Détecte et prévient des listes noires d’empreintes numériques SSL reconnues comme malveillantes / corrompues.
– abuse.ch/SSL IP Blacklist :
Détecte et prévient des listes noires d’adresses IP associées à des certifications SSL reconnues comme malveillantes/corrompues.
– abuse.ch/URLhaus :
Liste de sites réputés pour héberger des malwares.
– abuse.ch/ThreatFox :
liste de menaces connues qui contient des indicateurs de compromission (IoCs), principalement des adresses IP, domaines et hachages de fichiers liés à des logiciels malveillants.
– ET open/3coresec :
Plus ou moins la même chose que la règle précédente sauf qu’elle protège davantage contre les menaces avancées et récentes.
– ET open/botcc :
« BotCC » signifie « Botnet Command & Control », ce qui indique que cette règle cible les infrastructures utilisées pour contrôler des réseaux de machines infectées (botnets).
– ET open/botcc.portgrouped :
« Portgrouped » signifie que cette règle classe les adresses IP suspectes par port réseau. Elle est optimisée pour identifier les communications malveillantes sur des ports spécifiques utilisés fréquemment par les botnets.
– ET open/ciarmy :
Liste noire d’adresses IPs malveillantes reconnues comme malveillantes.
– ET open/compromised :
« Compromised » signifie que ces IPs sont associées à des machines infectées qui ont été piratées, infectées par un malware ou utilisées pour des activités malveillantes.
– ET open/drop :
« Drop » signifie que les paquets provenant de ces IPs sont immédiatement rejetés avant d’être traités par le reste du trafic réseau.
Une fois vos règles téléchargées et activées, vous pouvez regarder votre liste de règles en action avec la possibilité de les éditer et de la désactiver à tout moment :
C. Ajout de Sets de règles personnalisées ou trouvées sur des sites externes dans votre Suricata :
Nous allons nous rendre sur le repo GitHub du projet suivant : https://github.com/aleksibovellan/opnsense-suricata-nmaps , qui nous permettra de récupérer un fichier de règles pour notre Suricata qui nous permettront de générer des alertes à chaque fois qu’un scan SYN ( La machine cliente envoie un segment TCP avec le SYN flag activé pour signaler qu’elle veut établir une connexion avec la machine serveur. ) de ports sera effectué sur nos interfaces définies dans la configuration générale de notre Suricata.
Le but étant de faire un test avec un PC client Linux se trouvant sur mon interface LAN pour effectuer un scan de ports via NMAP et vérifier si Suricata détecte bien cette action comme malveillante en affichant des alertes.
Pour ce faire, téléchargez le fichier nommé « local.rules » du dépôt Github sur un poste client faisant parti de l’infra pour l’envoyer ensuite via WinSCP dans le système de fichier du serveur qui héberge le service OpnSense.
Nous allons d’abord autoriser notre poste client de se connecter en SCP sur notre serveur Opnsense pour effectuer l’envoi de fichiers en allant sur l’interface d’administration WEB de notre Opnsense, se rendre dans les paramètres « Système », puis « Settings », puis « Administration », dans la partie « Secure shell » des paramètres, nous allons cocher « Enable secure shell », ensuite cocher « Permit root user login » & « Permit password login », laissez le port 22 et appliquez les modifications :
Allez sur votre poste client Windows et lancez WinSCP, ensuite configurez les paramètres de connexion entre vos deux machines, choisissez plutôt le protocole SFTP pour l’envoi de fichiers pour davantage de sécurité :
Acceptez les échanges de clefs que va effectuer WinSCP entre vos deux machines :
Dans l’arborescence fichier du côté de votre poste client WIndows, allez dans l’emplacement où se trouve le fichier de règles que vous avez téléchargé précédemment sur Github et dans l’arborescence de fichiers de votre serveur OpnSense allez dans « /usr/local/etc/suricata/opnsense.rules/ ». Ensuite, faites clic droit sur le fichier de règles et cliquez sur « Envoyer… » et cliquez a nouveau sur « Envoyer… », faites exactement la même manipulation pour copier votre fichier de règles sur votre serveur Opnsense dans l’emplacement suivant « /usr/local/etc/suricata/rules/ » :
Retournez sur l’interface d’administration WEB d’OpnSense et rechargez les règles de Suricata en suivant le chemin dans la barre latérale : « Services » -> « Détection d’intrusion » -> « Administration » -> « Règles ». Recherchez-les dans vos listes de règles et vérifiez bien qu’elles soient en statut « Enabled » :
Section 2 : Test scan NMAP sur poste client Linux & verification des alertes dans Suricata :
Rendez-vous sur votre poste client Linux et ouvrez un terminal, tapez les commandes suivantes :
sudo apt install nmap -y
#Pour lancer notre analyse furtive, nous utiliserons l'option -SS afin de #démarrer un scan SYN (Stealth), suivis de l'adresse IP de notre pare-feu.
sudo nmap -sS "L'adresseipdevotreparefeu"
Dirigez vous dans la section d’administration de votre Suricata dans les paramètres de votre interface WEB OpnSense et regardez dans l’onglet « Alerts », vous devriez avoir une alerte qui vient d’apparaître pour vous indiquer que Suricata à bien détecté le scan NMAP, cependant nous voulons aussi qu’il bloque le scan.
Allez dans l’onglet « Rules » de vos paramètres Suricata et tapez « nmap » dans la barre de recherche, selectionnez toutes les règle qui apparaissent et passez le statut de toutes ces règles de « alert » a « drop », appliquez les modification et actualisez vos règles :
Pour terminer, assurez vous d’avoir au moins une règle de blocage dans votre pare-feu OpnSense sur l’interface sur laquelle écoute Suricata pour effectuer un test, pour ma part j’ai créer une règle de pare-feu qui bloque tout trafic entrant qui écoute sur le port 8080.
Allez sur le poste client Linux, dans son terminal et tapez la commande suivante pour tenter de scanner spécifquement le port 8080 pour vérifier qu’en plus de recevoir l’alerte dans Suricata, vous aurez également le scan NMAP qui sera bloqué :
# - p pour scanner spécifiquement un port en particuler
nmap -p 8080 "L'adresseipdevotreparefeu"Lorsque vous voyez le statut « filtered » dans NMAP après avoir scanné un port, cela signifie que le paquet envoyé vers ce port a été intercepté par un dispositif de sécurité, tel qu’un pare-feu ou un IDS/IPS, sans que ce dernier n’ait donné de réponse explicite (ni accepté, ni rejeté). Cela montre que le pare-feu ou Suricata bloque le trafic, mais sans renvoyer une réponse claire indiquant que le port est « fermé ». Le statut « filtered » est donc généralement utilisé lorsque des règles de filtrage sont appliquées, mais qu’aucune réponse explicite n’est envoyée.
Laisser un commentaire