Cet article détaille l’installation et configuration de l’IDS Suricata sur un Raspberry Pi pour surveiller votre réseau local. Afin de surveiller l’ensemble des équipements de votre réseau local, nous utiliserons la fonctionnalité « port mirroring » d’un switch manageable ainsi qu’un petit routeur Wifi connecté à ce switch.
Au sommaire :
- 1 Repérez des activités anormales sur votre réseau local avec le système de détection d’intrusion (IDS) Suricata sur Raspberry Pi
- 1.1 Présentation
- 1.2 Matériel nécessaire
- 1.3 Architecture
- 1.4 Installation de Suricata sur votre Raspberry Pi
- 1.5 Utiliser Suricata en mode service
- 1.6 Éviter la perte de paquets
- 1.7 Exploiter les fichiers de logs de Suricata
- 1.8 Gérer les règles
- 1.9 Mise à jour de la version de Suricata
- 1.10 Utilisation des ressources du Raspberry Pi
- 1.11 Configuration du port mirroring sur le switch Zyxel GS1200-5
- 1.12 Configuration du routeur Wifi
- 2 Conclusion
- 3 Sources
Repérez des activités anormales sur votre réseau local avec le système de détection d’intrusion (IDS) Suricata sur Raspberry Pi
Présentation
Suricata est un IDS (Intrusion Detection System) réseau basé sur des détections par signatures. Il analyse le trafic réseau afin d’y détecter des activités anormales et les tentatives d’intrusion.
Un Raspberry Pi est un hôte parfait pour Suricata dans le cadre d’un petit réseau local.
Afin de surveiller tous les équipements de votre réseau, l’IDS doit être en mesure d’en analyser tout le trafic. Ceci est possible grâce à l’utilisation d’un switch manageable supportant la fonction « port mirroring » permettant de dupliquer le trafic de tous les équipements et de l’envoyer vers l’IDS.
Afin de pouvoir également surveiller le trafic des équipements sans fil, il est nécessaire d’utiliser un petit routeur Wifi. Ce routeur doit être relié à un port du switch afin que le trafic Wifi soit également dupliqué vers l’IDS par la fonction « port mirroring ».
Matériel nécessaire
- Raspberry Pi 3B ou Pi 4 – Modèle B
- Switch manageable avec port mirroring Zyxel GS1200
- Routeur Wifi TP-LINK TL-WR902AC
Architecture
L’IDS doit être capable d’analyser les trames provenant de tous les équipements de votre réseau.
Pour cela il faut que tous vos équipements soient reliés au switch qui utilise la fonction port mirroring pour transmettre toutes les trames reçues des « mirrored port » vers le « analysis port ». Le Raspberry Pi sur lequel l’IDS Suricata est installé est bien entendu relié sur cet « analysis port ».
Si vous souhaitez également surveiller vos équipement connectés via le réseau Wifi, il ne faudra pas les connecter au réseau Wifi de la box internet mais utiliser un petit routeur Wifi également connecté au switch sur un « mirrored port ».
Mon réseau local est le 192.168.1.0/24 et tous mes équipements y compris ceux qui sont connectés via le point d’accès Wifi appartiennent à ce réseau local.
Installation de Suricata sur votre Raspberry Pi
Installez Raspberry Pi OS ou Raspberry Pi OS Lite sur votre Raspberry Pi (Modèle 3B ou 4) disponible sur le site https://www.raspberrypi.org/software/
Installer l’IDS open source Suricata
Préparer l’installation en installant les dépendances nécessaires :
|
1 |
sudo apt install libpcre3 libpcre3-dbg libpcre3-dev build-essential libpcap-dev libyaml-0-2 libyaml-dev pkg-config zlib1g zlib1g-dev make libmagic-dev libjansson-dev rustc cargo python-yaml python3-yaml liblua5.1-dev |
Télécharger les sources de Suricata :
|
1 |
wget https://www.openinfosecfoundation.org/download/suricata-6.0.1.tar.gz |
PS : La dernière version en juin 2021 est 6.0.2, voir le chapitre sur la mise à jour des versions de Suricata.
Décompresser les sources :
|
1 |
tar -xvf suricata-6.0.1.tar.gz |
Se placer dans le dossier Suricata :
|
1 |
cd $HOME/suricata-6.0.1/ |
Configurer l’installation du logiciel :
|
1 |
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-nfqueue --enable-lua |
Compiler suricata :
|
1 |
make |
Installer suricata :
|
1 |
sudo make install |
Se placer dans le dossier suricata-update :
|
1 |
cd $HOME/suricata-6.0.1/suricata-update/ |
Compiler suricata-update :
|
1 |
sudo python setup.py build |
Installer suricata-update :
|
1 |
sudo python setup.py install |
Se placer dans le dossier Suricata :
|
1 |
cd $HOME/suricata-6.0.1/ |
Finaliser l’installation de suricata en y incluant ses règles :
|
1 |
sudo make install-full |
Mettre à jour les règles de suricata :
|
1 |
sudo suricata-update |
Configurer Suricata
Configurer suricata en éditant le fichier suricata.yaml :
|
1 |
sudo vi /etc/suricata/suricata.yaml |
Modifier la variable HOME_NET afin qu’elle contienne votre réseau local, par exemple :
|
1 |
HOME_NET: "[192.168.0.0/24]" |
Lancer Suricata
Lancer suricata avec la commande suivante :
|
1 |
sudo suricata -c /etc/suricata/suricata.yaml -i eth0 -S /var/lib/suricata/rules/suricata.rules |
-c <chemin> : fichier de configuration à utiliser
-i <interface> : interface Ethernet à surveiller
-S <chemin> : fichier contenant les règles à utiliser
Tester Suricata
Afin de tester le bon fonctionnement de suricata, il est utile de rajouter une règle qui affiche un avertissement à chaque réception d’un ICMP Echo (ping). Il faudra supprimer cette règle après ce test.
Ajouter la règle suivante dans /var/lib/suricata/rules/suricata.rules
|
1 |
alert icmp any any -> any any (msg: "ICMP Packet found"; sid: 1; rev: 1;) |
Afficher le contenu du fichier de log :
|
1 |
sudo tail -f /var/log/suricata/fast.log |
Vous devriez voir dans le fichier de log l’alerte suivante :
|
1 |
01/23/2021-21:22:26.898963 [**] [1:1:1] ICMP Packet found [**] [Classification: (null)] [Priority: 3] {ICMP} 192.168.1.16:8 -> 192.168.1.25:0 |
Voici d’autres façons de tester le bon fonctionnement de Suricata :
- Aller sur ce site avec un navigateur depuis un équipement de votre réseau local :
http://testmynids.org/uid/index.html
Doit produire l’alerte suivante :
|
1 |
02/03/2021-16:13:42.020071 [**] [1:2100498:7] GPL ATTACK_RESPONSE id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 31.3.245.133:80 -> 192.168.1.10:46196 |
Utiliser Suricata en mode service
Afin de pouvoir utiliser Suricata en tant que service, il faut créer le fichier « /etc/systemd/system/suricata.service » :
|
1 |
sudo vi /etc/systemd/system/suricata.service |
Avec le contenu suivant :
|
1 2 3 4 5 6 7 8 9 10 |
# Sample Suricata systemd unit file. [Unit] Description=Suricata Intrusion Detection Service After=network.target syslog.target [Service] ExecStart=/usr/bin/suricata -c /etc/suricata/suricata.yaml -i eth0 -S /var/lib/suricata/rules/suricata.rules ExecReload=/bin/kill -HUP $MAINPID ExecStop=/bin/kill $MAINPID [Install] WantedBy=multi-user.target |
Et ensuite activer ce nouveau service avec la commande :
|
1 |
sudo systemctl enable suricata.service |
Nous pouvons maintenant utiliser Suricata en tant que service, et le démarrer avec la commande :
|
1 |
sudo systemctl start suricata.service |
Pour le stopper :
|
1 |
sudo systemctl stop suricata.service |
Pour le relancer :
|
1 |
sudo systemctl restart suricata.service |
Pour vérifier l’état du service :
|
1 |
sudo systemctl status suricata.service |
Le service se lancera maintenant automatiquement au démarrage du Raspberry Pi.
Éviter la perte de paquets
Suricata peut nécessiter quelques optimisations afin de fonctionner de façon optimale sur votre réseau. Cela dépend bien entendu du nombre d’équipements à surveiller et du trafic
généré.
Vérifier que la variable capture.kernel_drops dans le fichier /var/log/suricata/stats.log ne soit pas trop élevée. Idéalement elle doit rester à 0 et donc ne pas être affichée dans la liste des compteurs.
Dans le cas ci-dessus, 21617 paquets sur 2310188 ont été perdus, soit environ 1 %. C’est
acceptable mais cette perte peut être évitée.
Vous pouvez par exemple augmenter la valeur de la variable « ring-size » dans le fichier de configuration « /etc/suricata/suricata.yaml« . Attention, il faut bien entendu supprimer le « # » devant la variable dans le fichier suricata.yaml. Cette modification est en général suffisante pour éviter de perdre des paquets.
Modifier la valeur de ring-size en changeant la ligne suivante dans le fichier /etc/suricata/suricata.yaml :
|
1 |
#ring-size: 2048 |
par :
|
1 |
ring-size: 30000 |
Après avoir augmenté cette variable à 30000, je n’observe plus de perte de paquets, même avec 7.8 millions de paquets reçus.
Je vous invite à lire la documentation de Suricata pour régler finement les paramètres de configuration ayant un impact sur lesperformances du logiciel
Exploiter les fichiers de logs de Suricata
Suricata génère des fichiers de log dans le répertoire /var/log/suricata. En plus du trafic réseau et des activités suspectes qu’il détecte, Suricata logue également des informations de service et des statistiques sur le trafic réseau. Sur un Raspberry Pi il faudra prêter attention à la taille des logs générés qui peuvent rapidement saturer la carte SD utilisée pour leur stockage. Il faudra mettre en place un mécanisme de rotation de log afin d’éviter tout problème.
Les différents fichiers de logs
Voici les 4 fichiers de log générés par Suricata :
- suricata.log : messages de démarrage de Suricata
- stats.log : statistiques sur votre trafic réseau
- fast.log : activités suspectes découvertes par Suricata
- eve.json : trafic de votre réseau local ainsi que les activités suspectes au format JSON
Fichier de log des activités suspectes
Pour visualiser en direct les activités suspectes détectées par Suricata, il suffit de jeter un œil au fichier fast.log :
|
1 |
sudo tail -n 100 -f /var/log/suricata/fast.log |
Voici un exemple d’activités suspectes détectées par Suricata enregistrées dans le fichier fast.log :
|
1 2 3 |
01/29/2021-19:25:45.132975 [**] [1:2025012:3] ET MALWARE Powershell commands sent B64 3 [**] [Classification: A Network Trojan was detected] [Priority: 1] {TCP} XXX.XXX.XXX.XXX:80 -> 192.168.1.22:45986 01/29/2021-19:26:10.183249 [**] [1:2013147:3] ET SHELLCODE Possible %u4141%u4141 UTF-16 Heap Spray Attempt [**] [Classification: Executable code was detected] [Priority: 1] {TCP} XXX.XXX.XXX.XXX:80 -> 192.168.1.22:45986 01/31/2021-10:08:08.889128 [**] [1:2002157:12] ET CHAT Skype User-Agent detected [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 192.168.1.2:53937 -> XXX.XXX.XXX.XXX:80 |
Rotation des fichiers de logs
La taille du fichier de log eve.json peut devenir rapidement très importante et occuper tout l’espace de la carte SD. L’utilisation du mécanisme logrotate intégré à Linux est très utile pour éviter ceci. Nous allons le configurer pour qu’il journalise les log de Suricata pendant 10 jours tout en limitant la taille de chaque fichier à 1 GB. Ainsi les logs ne pourront pas occuper plus de 10 GB sur la carte SD tout en ayant un historique sur les 10 derniers jours. Les historiques plus anciens sont automatiquement supprimés.
Créer un fichier « /etc/logrotate.d/suricata » ayant le contenu suivant :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
/var/log/suricata/*.log /var/log/suricata/*.json { daily maxsize 1G rotate 10 missingok nocompress create sharedscripts postrotate systemctl restart suricata.service endscript } |
Afin de vérifier que la rotation est correctement configurée et qu’elle fonctionne, vous pouver la forcer manuellement avec la commande :
|
1 |
sudo logrotate -f /etc/logrotate.conf |
Vous devriez alors bien voir les logs journalisés dans le répertoire /var/log/suricata/
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
pi@raspberrypi3:~ $ ls -l /var/log/suricata/ total 30024 drwxr-xr-x 2 root root 4096 Jan 23 18:17 certs -rw-r--r-- 1 root root 0 Feb 2 15:03 eve.json -rw-r--r-- 1 root root 5162813 Feb 2 15:03 eve.json.1 -rw-r--r-- 1 root root 19174088 Feb 2 14:44 eve.json.2 -rw-r--r-- 1 root root 0 Feb 2 15:03 fast.log -rw-r--r-- 1 root root 354 Feb 2 14:45 fast.log.1 -rw-r--r-- 1 root root 1944 Feb 2 14:35 fast.log.2 drwxr-xr-x 2 root root 4096 Jan 23 18:17 files -rw-r--r-- 1 root root 0 Feb 2 15:03 stats.log -rw-r--r-- 1 root root 550978 Feb 2 15:03 stats.log.1 -rw-r--r-- 1 root root 5810640 Feb 2 14:44 stats.log.2 -rw-r--r-- 1 root root 965 Feb 2 15:03 suricata.log -rw-r--r-- 1 root root 1737 Feb 2 15:03 suricata.log.1 -rw-r--r-- 1 root root 1740 Feb 2 14:44 suricata.log.2 |
Fichier de log du trafic réseau
La taille du fichier de log du trafic réseau « eve.json » peut devenir importante en fonction du trafic de votre réseau.
Si seules les alertes du fichier fast.log vous intéressent, désactivez les logs du fichier eve.json dans le fichier de configuration /etc/suricata/suricata.yaml. Mais attention, vous n’aurez pas de logs vous permettant d’analyser la cause des alertes.
|
1 2 |
- eve-log: enabled: no |
Gérer les règles
L’efficacité de l’IDS Suricata repose sur la bonne gestion des règles. Il faut à la fois éviter les faux positifs et s’assurer que les règles utilisées sont à jour et permettent de détecter les menaces récentes.
Les règles de Suricata activées par défaut génèrent de nombreux faux positifs (alertes qui ne sont pas de réels problèmes). Je recommande de laisser tourner Suricata quelques heures en utilisant normalement vos équipements et d’analyser finement les alertes du fichier fast.log et désactiver certaines règles. Par exemple si vous utilisez Dropbox ou Skype sur votre réseau vous devrez désactiver les règles correspondantes afin de ne pas générer d’alertes inutiles pour votre réseau.
Afin de renforcer la sécurité de vos installations, vous pouvez également avoir besoin d’ajouter de nouvelles sources de règles ou de créer vos propres règles.
Nous allons voir comment gérer ceci dans les chapitres suivants.
Format des règles
Chaque règle Suricata est composée de la façon suivante :
action en-tête options
L’action correspond à l’action effectuée en cas de détection (alert, drop, pass…).
L’en-tête permet de définir le protocole (tcp, http, ftp, dns, tls…) ainsi que l’adresse IP et le port de la source et de la destination du trafic impliqué dans l’alerte.
Les options de la règle sont indiquées entre parenthèses et séparées par des virgules. Certaines options ont des paramètres, qui sont spécifiés par leur mot clé suivi de deux points et de la valeur du paramètres.
Les règles sont identifiées par leur identifiant de signature, le paramètre sid.
Par exemple, voici la règle 2012647 relative à l’utilisation de Dropbox :
|
1 2 |
# alert tls [108.160.162.0/20,162.125.0.0/16,192.189.200.0/23,199.47.216.0/22,205.189.0.0/24,209.99.70.0/24,45.58.64.0/20] 443 -> $HOME_NET any (msg:"ET POLICY Dropbox.com Offsite File Backup in Use"; flow:established,from_server; content:"|55 04 03|"; content:"|0d|*.dropbox.com"; distance:1; within:14; threshold: type limit, count 1, seconds 300, track by_src; reference:url,www.dropbox.com; reference:url,dereknewton.com/2011/04/dropbox-authentication-static-host-ids/; classtype:policy-violation; sid:2012647; rev:5; metadata:created_at 2011_04_07, updated_at 2019_01_16;) |
Vous pouvez jeter un œil aux règles en éditant le fichier de règle de Suricata :
|
1 |
sudo vi /var/lib/suricata/rules/suricata.rules |
Désactiver certaines règles
En fonction de votre utilisation, certaines règles doivent être désactivées. Par exemple, si vous autorisez l’utilisation de Dropbox au sein de votre réseau, la règle de SID 2012647 doit être désactivée.
Éditer le fichier qui contient les règles à désactiver :
|
1 |
sudo vi /etc/suricata/disable.conf |
Ajouter la liste des règles à désactiver, identifiées par leur identifiant de signature (SID).
Voici un exemple de règles que j’ai désactivé sur mon installation :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
# suricata-update - disable.conf 1:2012647 # Dropbox 1:2013504 # APT package management 1:2210044 # SURICATA STREAM Packet with invalid timestamp 1:2029706 # COVID 1:2029707 # COVID 1:2029709 # COVID 1:2027865 # DNS Query to .cloud 1:2210054 # SURICATA STREAM excessive retransmissions 1:2260000 # Applayer Mismatch protocol both directions 1:2210020 # STREAM ESTABLISHED packet out of window 1:2016150 # INFO Session Traversal Utilities for NAT 1:2027758 # DNS Query for .cc 1:2002157 # CHAT Skype User-Agent detected |
Si besoin il est possible de désactiver toutes les règles appartenant à un même type de classification classtype. Par exemple, la classification Generic Protocol Command Decode génère beaucoup trop d’alertes à mon goût et il est possible de désactiver toutes les règles de cette classification.
|
1 2 3 4 |
# suricata-update - disable.conf # Disable all rules from protocol command decode class type re:classtype:protocol-command-decode |
Ensuite il faut mettre à jour les règles (cf.Mettre à jour les règles).
Ajouter une nouvelle source de règles
Il est possible d’ajouter de nouvelles règles provenant d’une source particulière.
Tout d’abord mettre à jour la liste de sources disponibles :
|
1 |
sudo suricata-update update-sources |
Ensuite visualiser les sources disponibles :
|
1 |
sudo suricata-update list-sources |
Afin de vérifier quelles sont les sources qui sont déjà activées, lancer la commande suivante :
|
1 |
sudo suricata-update list-enabled-sources |
Activer une nouvelle source, par exemple la source de règles oisf/trafficid.
|
1 |
sudo suricata-update enable-source oisf/trafficid |
Ensuite il faut mettre à jour les règles (cf.Mettre à jour les règles).
Mettre à jour les règles
Afin d’intégrer la détection des dernières menaces, il faut régulièrement mettre à jour les règles de Suricata en lançant les commandes suivantes :
|
1 |
sudo suricata-update update-sources |
|
1 |
sudo suricata-update --disable-conf=/etc/suricata/disable.conf |
Il suffit ensuite de relancer le service Suricata :
|
1 |
sudo systemctl restart suricata.service |
Mettre à jour les règles automatiquement la nuit
Vous pouvez utiliser un cron (table de planification sous Linux) pour mettre à jour les règles suricata automatiquement toutes les nuits.
Editer le fichier des planifications avec la commande :
|
1 |
crontab -e |
Et insérer la ligne suivante à la fin du fichier :
|
1 |
37 1 * * * sudo suricata-update --disable-conf=/etc/suricata/disable.conf && sudo systemctl restart suricata.service |
Avec cette ligne, nous configurons cron pour qu’il mette à jour les règles toutes les nuits à 1h37 du matin et qu’il relance le service suricata ensuite.
Mise à jour de la version de Suricata
Vérifier si une nouvelle version de Suricata est disponible avec la commande :
|
1 |
sudo suricata-update check-versions |
Si une nouvelle version est disponible, ici nous voyons que la version 6.0.2 est disponible pour remplacer la version 6.0.1 :
|
1 2 3 4 5 |
6/6/2021 -- 15:59:03 - -- Using data-directory /var/lib/suricata. 6/6/2021 -- 15:59:03 - -- Using Suricata configuration /etc/suricata/suricata.yaml 6/6/2021 -- 15:59:03 - -- Using /usr/share/suricata/rules for Suricata provided rules. 6/6/2021 -- 15:59:03 - -- Found Suricata version 6.0.1 at /usr/bin/suricata. 6/6/2021 -- 15:59:03 - -- Suricata version 6.0.1 is outdated. Please upgrade to 6.0.2. |
L’installation de la nouvelle version se déroule comme pour une installation normale , et si vous le souhaitez vous pouvez le faire dans le même dossier.
L’utilisation d’une variable contenant la dernière version de Suricata sera très utile pour les prochaines mises à jour. Il suffira de modifier le contenu de cette variable et les commandes suivantes seront identiques.
|
1 |
export LATEST_SURICATA=6.0.2 |
Télécharger les nouvelles sources de Suricata :
|
1 |
wget https://www.openinfosecfoundation.org/download/suricata-$LATEST_SURICATA.tar.gz |
Décompresser les sources :
|
1 |
tar -xvf suricata-$LATEST_SURICATA.tar.gz |
Se placer dans le dossier Suricata :
|
1 |
cd $HOME/suricata-$LATEST_SURICATA/ |
Configurer l’installation du logiciel :
|
1 |
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-nfqueue --enable-lua |
Compiler suricata :
|
1 |
make |
Installer suricata :
|
1 |
sudo make install |
et redémarrer le service tout simplement :
|
1 |
sudo systemctl restart suricata |
Utilisation des ressources du Raspberry Pi
A titre d’information, voici la consommation des ressources d’un Raspberry Pi 3 Modèle B faisant tourner Suricata.
Utilisation du processeur
En moyenne 27 % de CPU utilisés :
Utilisation de la mémoire
569 MB de mémoire utilisés :
Utilisation de la carte SD
2.6GB de disque utilisés :
Configuration du port mirroring sur le switch Zyxel GS1200-5
L’IDS Suricata tourne sur le Raspberry Pi qui est relié au port 5 du switch. Les équipements à surveiller sont reliés aux ports 1 à 4 du switch.
Afin de permettre d’analyser le trafic de tous les équipements reliés à ce switch, il faut configuré le port 5 comme monitor port et les ports 1 à 4 en tant que mirrored port dans leurs deux directions entrantes et sortantes.
Ainsi tous le trafic entrant ou sortant des ports 1 à 4 du switch sera recopié (mirrored) vers le port 5 afin d’être analysé par notre IDS Suricata tournant sur le Raspberry Pi.
Notez qu’il est également possible d’utiliser un TAP réseau qui permet de dupliquer le trafic qui circule sur un câble pour l’envoyer vers notre dispositif d’écoute. Le principe du TAP Ethernet est décrit sur cet article.
Configuration du routeur Wifi
Le routeur Wifi est relié à un mirrored port du switch, il doit être configuré en mode Access Point. Ainsi les équipements qui y seront reliés en Wifi se trouveront sur le même réseau local et pourront être surveillés par notre IDS.
Voir la documentation du routeur si besoin, mais la configuration est très simple car il suffit de déclarer le mode d’opération Access Point et d’utiliser le type de LAN Smart IP (DHCP).
Conclusion
Merci stéphane pour cet article très complet qui permettra aux lecteurs intéressés par ce sujet de se lancer dans la détection d’intrusion grâce à un Raspberry Pi et à Suricata.
Si vous mettez cette solution en oeuvre, n’hésitez pas à laisser vos impressions et vos remarques dans la zone des commentaires ci-dessous.
===================== UPDATE 29 mars 2022 ======================
Des modifications sont disponibles avec l’évolution des versions de Suricata.
Pour rester au courant des dernières modifications, visitez la page de Stéphane : https://tutoduino.fr/tutoriels/ids-suricata-raspberry-pi/
Sources
Ping : Détection d’intrusion (IDS) avec Suricata sur Raspberry Pi – Framboise 314, le Raspberry Pi à la sauce française…. – Jhc Info
Bonjour,
Comme toujours très intéressant.
Que faire si l’on a un TP-Link WiFi Mesh Deco M9 Plus raccordé sur sa Bbox ?
Merci
Bonjour,
Il est tout d’abord indispensable d’ajouter un switch qui gère le port mirroring afin de dupliquer tous les paquets qui transitent par ce switch et de les envoyer à l’IDS. Ensuite il faut tout simplement relier le câble Ethernet du TP-Link Wifi Mesh Deco M9 sur un port du switch plutôt que sur la box.
Si cet équipement gère le mode point d’accès il faut le configurer ainsi. Sinon le seul inconvénient du mode routeur c’est que tous les équipements reliés via ce routeur Wifi seront visibles avec la même adresse IP (celle de ce routeur Wifi) par l’IDS.
C’est le gros avantage du petit routeur Wifi que j’utilise dans le tuto. Car comme son nom ne l’indique pas, il n’est pas utilisé comme un routeur mais comme un simple point d’accès. Ce qui fait que les équipements reliés à ce point d’accès Wifi appartiennent au même réseau LAN que le switch et apparaissent bien avec leur adresse IP.
Voilà j’espère avoir répondu à la question.
Pour un non-spécialiste ce n’est pas évident.
Mais je te remercie de ton éclairage.
Je vais relire cela à mon aise…
Salut,
Merci beaucoup, bonne lecture pour un dimanche matin 🙂
Si le suricata ecoute deja que le wan en qq sorte, c’est déjà pas mal non ?, surveiller l’interne, est ce vraiment important ? (je manque de port sur le sw manageable et 2 wifi en routeur (pas en ap). Mais je pense que je vais essayer voir ce que ça donne. Merci pour l’article
Oui si vous pouvez surveiller le WAN avec un IDS s’est déjà très bien, en général les menaces sont plutôt externes sur un petit réseau local à la maison (cadre de cet article).
Ok merci
petit reseal local de quasi 60 devices, vive l’inutile donc indispensable ^^
Bonjour a tous,
J’ai mis en place la solution ce weekend, avec un élément actif de chez HP.
Par contre perte énorme du débit lan.
Sans la surveillance des ports je suis en copie local à environ 70mb/s avec la surveillance je tombe à 5mb/s
Bonjour,
Par curiosité quel est cet élément actif de chez HP ?
Avec la configuration du tuto je n’ai pas remarqué de perte de débit LAN.
Re,
C’est un HP 1810-24 full gigabit.
Le port utilisé pour analyser le trafic est bien configuré en GB ?
Car je lis ceci sur un forum : Also another important factor. HP port mirror is limiting. Say you port mirror all your switch to a port which is 100mbit. Your whole network will run at the speed of 100mbit at best. https://www.reddit.com/r/networking/comments/1opeoq/port_mirroring_hp18108g_not_sure_if_im/
https://support.hpe.com/hpesc/public/docDisplay?docId=kc0123166en_us&docLocale=en_US
Re,
Effectivement le Switch bascule en 100 au lieu de 1000.
Merci bien.
Cordialement,
Merci pour l’article.
La principale découverte pour moi reste le Zyxel GS1200 qu’on trouve à moins de 25€ sur amazon !
Car effectivement, comme souligné au début de l’article, le principale prérequis pour utiliser un IDS, c’est de pouvoir dupliquer le flux réseau que l’on veut superviser. Un TAP cuivre coûte plus de 200€ (dispositif dédié pour dupliquer un flux réseau), un switch manageable même grand publique, c’est souvent autour de 50€
Septique quant à la puissante du RPI3 pour analyser un flux gigabit (surtout que le port ethernet plafonne à environ 300 M/s), mais l’article me pousse à essayer (sur mon réseau domestique). Le but étant de choper des bruits fonds malveillant, pas forcément quand il y a un pic de charge.
Bonjour,
Oui le Pi 3 est limitant surtout à cause de son Ethernet 100 Mbit/s qui passe par un hub USB interne. Cependant sur un petit réseau local cela me suffit pour surveiller quelques PC, tablettes et smartphones.
Le Pi 4 semble en effet une bonne alternative avec son Ethernet Gbit/s et un processeur plus puissant. Je vais l’utiliser par la suite. Autre point plus important est l’utilisation intensive de la SD pour les logs. Il est préférable d’installer un disque SSD sur le Pi pour éviter qu’elle ne tombe en panne au bout de 6 mois…
Ping : Spot suspicious activity on your local network with Suricata Intrusion Detection System (IDS) on Raspberry Pi – Juliana Fajardini
Ping : Spot suspicious activity on your local network with Suricata Intrusion Detection System (IDS) on Raspberry Pi – Juliana Fajardini
Franchement top ! Je suis sur RPI4 avec boot sur un SSD120Go + SW qui fait le job du mirroring !
La prochaine étape serait de faire tourner un ELK pour exploiter l’ensemble 🙂
Je suis à la recherche d’un tuto pour installer la stack …. si vous avez quelque chose je suis preneur !
Ensuite on ira exploiter le eve.json ….
Merci pour votre commentaire. 🙂
Oui un tuto sur l’installation de la suite ELK serait une suite logique à cet article…
Je mets ça sur ma todo pour les prochaines soirées et week-end 🙂
PS : pour les non initiés ELK (Elasticsearch + Logstash + Kibana) est une suite de logiciels qui simplifierait la recherche et la visualisation des informations contenues dans les fichiers de logs générés par Suricata
Il faut voir si SELKS fonctionne sur rpi mais j’ai comme un doute. Je l’ai testé il y a quelques années sur un vieux serveur (mais néanmoins bi-xeon et 16 Go) et ça ramait bien (java est gourmand et elastic search en io n’en parlons pas). Réseau plus conséquent il est vrai (~200 utilisateurs, switch HP 3800 pour le mirror).
Merci pour ce tuto très utile. J’ai complété cette installation de Suricata en ajoutant la couche ELK pour avoir un joli dashboard, qui me facilite quand même la tâche de surveillance.
Pour ElastricSearch et Kibana j’ai utilisé les images docker disponibles ici : https://gitlab.comwork.io/oss/elasticstack/elasticstack-arm
Pour Logstash, je me suis rabattu sur la version oss.6.8.16.deb qui tourne avec OpenJDK
Le tout fonctionne nickel sur une Raspberry 4 avec 8 GB de mémoire (je ne surveille que le traffic sur le réseau interne, pas sur le WAN, j’ai bande passante Internet 100 Mbps et 20-25 machines sur mon réseau local). Mon Pi tourne à environ 5% de CPU mais pas contre 3.5 GB de mémoire occupée (merci Java).
Peut-être une suggestion pour l’article: ajouter une mise à jour auto des règles de Suricata toutes les nuits.
Génial merci !
Je n’ai toujours pas eu le temps de traiter la partie ELK, dès que j’ai un moment je fais une deuxième partie consacrée à ELK sur Raspberry Pi.
Et oui, la mise à jour auto des règles Suricata est une excellente idée, je rajouterai ça bientôt.
Pour la mise à jour des règles automatiquement il suffit d’ajouter dans le cron de root:
0 3 * * * /usr/bin/suricata-update -q –reload-command=’kill -USR2 $(cat /var/run/suricata.pid)’
J’ai mis à jour le tuto pour mettre à jour les règles automatiquement la nuit.
Par contre je préfère éviter la méthode du kill du process et plutôt redémarrer le service.
Pour info il semble y avoir un problème avec le script du service: le PIDfile est créé à la racine avec pour nom @e_rundir@suricata.pid
Hum en effet… et en plus je ne vois pas quel est l’utilité de ce pidfile dans mon tuto 😉
Je met à jour le script ci-dessus en le supprimant.
Merci
Si si le pidfile est important, il faut simplement remplacer dans le script par /var/run/suricata.pid
Bonjour , merci beaucoup pour ce très bon article .
Quel serait le montage pour pouvoir rejeter en direct ces attaques que l’on détecte via Suricata ?
Placer une machine avec 2 cartes reseau en coupure avec Suricata installé ?
Est ce que PfSense – mais c’est un firewall uniquement , je crois – peut être utilisé en combinaison avec Suricata ? Ou bien Suricata peux gérer les 2 cartes ?
Merci encore pour votre article.
Bien cordialement
Emmanuel
Suricata peut travailler en mode IPS et copier les packets d’une interface vers une autre OU les dropper automatiquement si les packets matches une règle, cf. https://suricata.readthedocs.io/en/suricata-6.0.0/setting-up-ipsinline-for-linux.html#settings-up-ips-at-layer-2
Par contre je ne suis pas sûr des performances sur un Raspberry ! Si jamais tu fais ce montage tu pourrais nous tenir au courant, je trouve l’idée intéressante.
Merci pour votre réponse.
Par contre il faudra modifier le branchement de l’installation, l’architecture indiquée dans mon article ne permet que le mode IDS.
En effet le switch duplique tous les paquets qu’il reçoit sur ses ports « mirrored » pour les envoyer par son port « analysis » vers le Raspberry Pi.
Pour que le Raspberry Pi puisse jouer le rôle d’un IPS, il faut qu’il puisse intercepter les paquets en amont.
Et donc il faudrait placer le Rapsberry Pi juste derrière la box internet et devant le switch.
Le problème c’est que par nature les Raspberry Pi n’ont qu’un port Ethernet et ne permettent donc pas cette architecture.
J’ai acheté un Orange Pi R1 Plus pour faire des essais et cela fonctionne plutôt bien, cet équipement possède 2 ports Ethernet. Mais je ne conseille pas trop les Orange Pi car il y a quelques soucis de qualité au niveau hardware et la partie logicielle laisse vraiment à désirer…
Concernant le fine-tuning de Suricata pour éviter de dropper les packets, j’ai personnellement obtenu un bien meilleur résultat en augmentant simplement le max-pending-packets.
Ma conf avec un Pi4 pour une connexion 100 Mbps me permet de rester bien en dessous des 1% de drop (en conditions normales je suis en dessous de 0.1%:
threads: auto
use-mmap: yes
mmap-locked: yes
tpacket-v3: yes
max-pending-packets: 1500
A contrario augmenter le ring-size trop fort génère des instabilités avec pour conséquence Suricata qui crashe lamentablement et sans prévenir.
Ex. de stats:
————————————————————————————
Counter | TM Name | Value
————————————————————————————
capture.kernel_packets | Total | 9512273
capture.kernel_drops | Total | 4158
Merci pour ces informations 🙂
Finallement je suis parvenu à complètement éliminer les dropped packets (sur une connexion 100 Mbps) en augmentant le max-pending-packets et surtout en passant en runmode workers avec seulement 3 threads au lieu de 4 par défaut.
Assigner 4 threads à Suricata sur le Pi 4 qui a 4 cores, alors qu’il y a de nombreux autres process qui tournent notamment dans mon cas les instances docker pour ElasticSearch et Kibana, créé je pense parfois de la contention et provoque des dropped packets.
J’ai également du coup un system beaucoup moins chargé en cpu, ce qui me laisse penser que le Pi pourrait analyzer une plus grande bande passante sans soucis.
Bonsoir,
est-il possible d’y coupler OpenCanary ?
Merci pour les tests et retour (sur un article complémentaire 🙂 )
Bon réveillon
Le paquet « python-yaml » n’a pas de version susceptible d’être installée
décevant linux ,
a chaque fois que je me cogne un tuto c’est une galere fini avant la fin …
du coup 1ere ligne de commande j’ai une erreur ,
une petite aide ?
defois que , un petit script pour une installation facile ?
Bonjour,
Vous êtes sur quelle version de linux ?
Entrez la commande « uname -a » si vous ne le savez pas.
https://yaml.readthedocs.io/en/latest/install.html
Merci pour ce tutoriel… Je m’en suis inspiré pour installer Suricata sur un Odroid N2+ sur lequel j’ai ajouté une deuxième interface ethernet Gb via USB3 : l’interface native pour la connectivité normal de l’appareil sur le LAN, l’autre pour écouter le traffic en miroir depuis le routeur (plus exactement redirigé via des règles iptables tee, bien plus efficaces en performances pour mon routeur).
Quelques modifications que j’ai du apporter :
/etc/systemd/system/suricata.service :
________________________________________________
# Sample Suricata systemd unit file.
[Unit]
Description=Suricata Intrusion Detection Service
After=syslog.target network-online.target
[Service]
# Environment file to pick up $OPTIONS. On Fedora/EL this would be
# /etc/sysconfig/suricata, or on Debian/Ubuntu, /etc/default/suricata.
EnvironmentFile=-/etc/default/suricata
ExecStartPre=/bin/rm -f /var/run/suricata.pid
ExecStart=/usr/bin/suricata -c /etc/suricata/suricata.yaml –af-packet –pidfile /var/run/suricata.pid $OPTIONS
ExecReload=/bin/kill -USR2 $MAINPID
[Install]
WantedBy=multi-user.target
________________________________________________
Utiliser l’option -i dans la commande utilisait le mode pcap et non af-packet.
/etc/logrotate.d/suricata :
________________________________________________
/var/log/suricata/*.log /var/log/suricata/*.json
{
daily
maxsize 1G
rotate 10
missingok
nocompress
create
sharedscripts
postrotate
/bin/kill -HUP
cat /var/run/suricata.pid 2>/dev/null2>/dev/null || trueendscript
}
________________________________________________
Plutôt que d’utiliser systemctl pour redémarrer suricata (et donc perdre des paquets), le kill -HUP permet de ne pas toucher au processus mais de lui indiquer de travailler sur de nouveaux fichiers logs à la volée 😉
J’ai aussi un service pour adapter l’interface à l’écoute.