Surveillance : Suricata
Surveillance : Suricata jppPetites mises à jour pour la version 3.0, notamment le fichier de paramètres "suricata.yaml".
En 2020 on est passé en 4.1, en 2023 en 6.0 et en 2024 en 7.0.
La surveillance d'un réseau est une condition indispensable de la sécurité. Après le Firewall qui assure une sécurité "passive" il peut être intéressant d'installer un système d'analyse des flux réseau. Le plus connu de ces logiciels dans le domaine OpenSource est Snort et son cochon mascotte.
J'ai déjà installé Snort (paquet Debian standard) avec l'option stockage dans une base Mysql et affichage des résultats à l'aide du logiciel "Base" fourni par le paquet Debian Acidbase.
J'ai découvert dans un magazine (MISC pour ne pas le citer) un nouveau (enfin presque) logiciel effectuant ce type de travail et j'ai décidé de le tester. Petit problème il n'existe pas de paquet Debian et il faut donc charger, compiler et installer tout ce petit monde.
Je n'entrerais pas dans les discussions (vous avez dit troll ?) au sujet d'une lutte (d'influence) entre Snort et Suricata au sujet des performances et de la compatibilité des règles.
Pour mémoire il s'agit de :
- Suricata qui fournit la partie analyse réseau
- Snorby qui fournit l'interface utilisateur (WEB) que j'ai remplacé par un développement personnel Snorbis car ce "vieux" logiciel ne fonctionnait plus avec les dernières versions de Ruby, j'ai donc développé un petit logiciel "Snorbis" qui le remplace.
- Barnyard2 qui interface Suricata et la base de données.
Barnyard2 n'est plus mis à jour et ne fonctionne plus, j'ai développé un interface (Python) pour charger les données dans la base "Snorbis".
Note : Snorby est obsolète et impossible à mettre à jour (utilisation d'une version très ancienne de Ruby) et je prépare une application équivalente baptisée "Snorbis "(note 2024 : qui fonctionne correctement depuis des années).
Les opérations seront donc séparées en trois parties principales, on installe Snorby avant Barnyard car Snorby initialise la base de données. Cette base est très semblable à celle de Snort ... avec quelques bricoles en plus.
Après un premier test "à blanc" sur un portable (Debian 6.0), le test suivant a été réalisé sur une machine virtuelle "vierge" afin de bien faire ressortir toutes les dépendances.
La MV (avec KVM bien sûr!) a été installée sur une Debian (6.0) a été utilisée pour initialiser cette machine avec le minimum et "gcc4.7" sans oublier "ln -s /usr/bin/gcc4.7 /usr/bin/gcc" et "g++4.7" avec son petit lien en "g++".
En ce qui concerne la gestion des règles je présenterai, peut-être, plus tard quelque chose couvrant ce sujet.
Suricata : installation
Suricata : installation jppMise à jour juillet 2016 pour la version 3 (3.0.1 pour être précis).
Il faut maintenant installer des choses sérieuses : "make", "wget" et "git" si ce n'est déjà fait ainsi que la triplette "mysql-client","mysql-server" ainsi que "libmysqld-dev" , je fonctionne actuellement avec MariaDB.
J'ai créé un utilisateur "suricata" avec un mot de passe du même métal pour faire tourner le tout sans droits "root".
Ensuite télécharger le tar.gz (1.4.1 lors des premiers tests 3.0.1 à ce jour) dans un répertoire tranquille :
wget http://www.openinfosecfoundation.org/download/suricata-3.0.1.tar.gz ou plus récent visible sur https://oisf.net/
suivi d'un : tar -xvf suricata-3.0.1.tar.gz
Il faut charger quelques dépendances spécifiques :
- pkg-config
- libpcap-dev
- libpcre3-dev
- libyaml-dev
- libnet1-dev
- libcap-ng-dev
- libmagic-dev
- libhtp-dev
- zlib1g-dev
- libjansson4 libjansson-dev
- libnfnetlink0 libnfnetlink-dev
- libnetfilter-queue-1 libnetfilter-queue-dev
Un apt-get install de toute la liste suffit.
Ensuite le "./configure" magique permet de commencer le travail et le récap en fin d'exécution permet de vérifier si toutes les options nous conviennent :
| Suricata Configuration: AF_PACKET support: yes PF_RING support: no NFQueue support: no IPFW support: no DAG enabled: no Napatech enabled: no Unix socket enabled: no libnss support: no libnspr support: no libjansson support: no Prelude support: no PCRE jit: no libluajit: no libgeoip: no Non-bundled htp: no Old barnyard2 support: no CUDA enabled: no Suricatasc install: yes Unit tests enabled: no Debug output enabled: no Debug validation enabled: no Profiling enabled: no Profiling locks enabled: no Generic build parameters: Installation prefix (--prefix): /usr/local Configuration directory (--sysconfdir): /usr/local/etc/suricata/ Log directory (--localstatedir) : /usr/local/var/log/suricata/ Host: i686-pc-linux-gnu GCC binary: gcc GCC Protect enabled: no GCC march native enabled: yes GCC Profile enabled: no To build and install run 'make' and 'make install'. You can run 'make install-conf' if you want to install initial configuration files to /usr/local/etc/suricata/. Running 'make install-full' will install configuration and rules and provide you a ready-to-run suricata. To install Suricata into /usr/bin/suricata, have the config in /etc/suricata and use /var/log/suricata as log dir, use: ./configure --prefix=/usr/ --sysconfdir=/etc/ --localstatedir=/var/ |
Pour plus de sécurité (isolation dans un répertoire spécifique) je vais lancer la configuration avec les options suivantes :
./configure --prefix=/opt/suricata \
--sysconfdir=/opt/suricata/ \
--localstatedir=/opt/suricata/
Le log final contient :
| Generic build parameters: Installation prefix (--prefix): /opt/suricata Configuration directory (--sysconfdir): /opt/suricata/suricata/ Log directory (--localstatedir) : /opt/suricata/log/suricata/ |
Ce n'est pas tout à fait ce que je voulais et je corrige "un peu" le Makefile (aux environs de la ligne 245) pour obtenir un "arbre" de répertoires sous /opt/suricata :
| e_localstatedir = /opt/suricata/run e_logdir = /opt/suricata/log e_logfilesdir = /opt/suricata/log/files e_magic_file = /usr/share/file/magic e_rundir = /opt/suricata/run/ e_sysconfdir = /opt/suricata/etc e_sysconfrulesdir = /opt/suricata/etc/rules |
Je lance enfin le "make" qui se déroule sans ennuis ... de même pour le "make install" ... qui m'installe un arbre de répertoires "convenable", enfin qui me convient, "make install-conf" installe la config de base puis "make install-full" télécharge et installe un jeu de règles standard.
Image de mon arbre de répertoires :
| drwxrwsr-x 9 root suricata 4096 2013-05-06 14:39 . drwxrwsr-x 18 root staff 4096 2013-05-06 13:40 .. drwxr-xr-x 2 root suricata 4096 2013-05-07 16:29 bin drwxr-xr-x 3 root suricata 4096 2013-05-07 17:09 etc drwxr-xr-x 3 root suricata 4096 2013-05-06 14:37 include drwxr-xr-x 4 root suricata 4096 2013-05-06 15:10 lib drwxrwxr-x 3 root suricata 4096 2013-05-07 17:14 log drwxrwxr-x 2 root suricata 4096 2013-05-07 16:07 run drwxr-sr-x 3 root suricata 4096 2013-05-06 14:37 share |
J'ai donné au user "suricata" les droits "group" sur l'ensemble des répertoires de /opt/suricata et les droits d'écriture sur les répertoires "log" et "run".
Il faut ensuite réaliser un script de démarrage car je n'en ai pas trouvé de disponible (mon exemplaire est disponible par le lien en bas de page).
Il faut ensuite légèrement modifier le fichier "etc/suricata.yaml" pour l'adapter à la structure de mes répertoires. J'ai désactivé l'option "fast log" qui consomme trop d'espace pour mes besoins de test sur un portable. J'ai aussi réduit la fréquence de stockage des statistiques à 30 minutes.
Après le lancement du produit on peut constater l'arrivée de quelques alertes ... mais elles sont au format "Unified2" et donc illisibles il faut utiliser un interface pour les rendre compréhensibles. Le projet conseille "Barnyard2" qui les enregistre dans une base de données (ici Mysql) et que je vais essayer au prochain épisode.
Le paramétrage du fichier de configuration est très bien expliqué (au moins pour les options "courantes") dans le fichier suricata.yaml.
Vous trouverez ces fichiers en attachement, mes quelques modifications du fichier YAML sont précédées d'un commentaire #JPP.
Suricata : statistiques
Suricata : statistiques jppUne petite statistique (sur 30 jours 26/11/2018 au 26/12/2018) sur les événements "bloqués" par Suricata : 
La grande majorité des rejets (j'utilise "drop" pour la plupart des événements) sont dus à des attaques sur le site WEB, Ces attaques sont, en général, le fait de "script-kiddies" utilisant des outils en kit, en effet on retrouve très souvent les mêmes motifs dans les URL testées. Il y a aussi des attaques ciblées visant un défaut qui vient d'être divulgué, il en existe un actuellement sur /wp-login.php qui revient très souvent depuis début décembre.
Note 2021 : les accès sur /wp-login.php existent toujours, j'en voit passer plusieurs par jour, tant en HTTPS qu'en HTTP.
Ceci semble prouver qu'une mise à jour régulière des logiciels est importante, je trouve régulièrement référence à des "exploits" adaptés à des versions antérieures à celles installées dans mes systèmes.
Les attaques sur SMTP sont le plus souvent le fait de spammeurs recherchant des serveurs "open relay", en existe-t-il encore ?
Suricata version 2.0
Suricata version 2.0 jppUne nouvelle version (2.0) de Suricata "chauffait" depuis quelques temps et je l'ai chargée et compilée sans aucune nouvelle dépendance.
Le 25 juin 2014 sortie de la version 2.0.2 : téléchargeable ici. (obsolete en 2017)
Le 23 septembre 2014 sortie de la version 2.0.4 : téléchargeable ici. (obsolete en 2017)
La version 2.0.4 se compile et s'exécute comme la version 2.0.2 (même paramétrage).
A titre indicatif je "configure" avec le script suivant avant de lancer le "make" fatidique :
#!/bin/bash
PFX='--prefix=/opt/suricata/ '
CFG='--sysconfdir /opt/suricata/etc/ '
LOC='--localstatedir=/opt/suricata/var '
OPTIONS='--enable-gccprotect --enable-geoip --enable-nfqueue --enable-unix-socket'
./configure $PFX $CFG $LOC $OPTIONS 2>&1 | tee LOG_CONFIGURE
Les options permettent d'utiliser des filtres "géographiques" et d'utiliser le mode IPS (utilisation de NFQUEUE).
A première vue le paramétrage existant en 1.4 est parfaitement fonctionnel et le système tourne normalement. Il semble qu'une légère amélioration de performance soit présente, mais cela n'est pas transcendant et de toutes façons je suis limité par la liaison internet sur laquelle le maximum théorique #8Mo/s est atteint régulièrement.
Le fonctionnement en IPS est parfait et la mise en place de quelques "drop" permet de se débarrasser de quelques accès intempestifs. Le seul "manque" est que les "drops" ne laissent pas une trace spécifique dans l'interface de visualisation. De même le fichier "drop.log" ne contient aucune référence à la règle ayant provoqué le rejet et n'est pas affecté à un niveau de danger particulier ce qui est un peu dommage.
Il faut maintenant étudier la doc pour profiter des nouvelles fonctionnalités.
Suricata version 3.0
Suricata version 3.0 jppLa version 3.0 est, au point de vue de la compilation de de l'utilisation peu différente de la version 2, j'ai mis à jour la page correspondant à l'installation.
Actuellement Suricata est "en exploitation" chez moi et tourne sur la machine servant de pont vers Internet.
Le fonctionnement est effectué en mode IPS et permet de bloquer quelques empêcheurs de surfer en rond et de repérer les tentatives d'accès du style "phpmyadmin" ... et d'autres. Au moment de Heartbleed un grand nombre de tentatives d'exploitation étaient visibles.
La machine dispose de deux interfaces "BR0" (vers le modem) "BR1" vers le réseau interne, les autres machines du réseau accèdent toutes à Internet à travers un switch raccordé à "BR1". Suricata est utilisé en entrée et en sortie, tout est filtré !
Snorby permet de consulter l'historique des alertes et permet
- d'éliminer les faux positifs,
- de repérer les tentatives d'accès frauduleux.
Il est intéressant de "marquer" dans l'interface les noms DNS des serveurs "sûrs" afin de passer rapidement des alertes en "faux positif" ou de les détruire quand le responsable est "banni" par le pare-feu.
Suricata 3.0 : quelques tests
Suricata 3.0 : quelques tests jppLa dernière version de Suricata (3.1.1) à ce jour m'a semblé nettement plus performante que les précédentes et j'ai vu passer quelques téléchargements à très grande vitesse depuis une machine située "derrière" le portail internet. Cette machine a parfois téléchargé à #40Mo/seconde, les sources du noyau en à peine plus de deux secondes ... vive la fibre. Quand je me rappelle le premier chargement de noyau Linux sur mon vieil Amiga 2000 avec un modem 33.6 qui durait des heures pour des sources beaucoup plus petites. La compilation durait 11/12 heures ... aujourd'hui elle passe en moins de 10 minutes environ avec un corei7 !!!
Un premier test entre deux machines munies de Suricata 3.1.1, un corei3 à 3.3Ghz et un corei5 à 3.5Ghz donnent une vitesse de presque 64Mo/seconde (63.9,63.7,63.8 sur trois essais. Le corei3 utilise 100% de cpu, le corei5 moins de 80%.
| A = corei5 5675 3,1GHz | |||||
| B = corei3 3220 3,3GHz | |||||
| RUNMODE : WORKERS | |||||
| Suricata | %CPU | ||||
| A | B | A | B | Moy MO/s | |
| A → B | 113,0 | ||||
| B → A | 113,0 | ||||
| A → B | oui | 101 | 58,0 | ||
| B → A | oui | 102 | 59,3 | ||
| A → B | oui | 102 | 60,1 | ||
| B → A | oui | 101 | 57,3 | ||
| A → B | oui | oui | 100 | 100 | 56,1 |
| B → A | oui | oui | 97 | 101 | 56,8 |
| RUNMODE : AUTOFP | |||||
| Suricata | %CPU | ||||
| A | B | A | B | Moy MO/s | |
| A → B | 113,0 | ||||
| B → A | 113,0 | ||||
| A → B | oui | 160 | 54,1 | ||
| B → A | oui | 150 | 54,3 | ||
| A → B | oui | 155 | 57,0 | ||
| B → A | oui | 162 | 53,0 | ||
| A → B | oui | oui | 150 | 160 | 45,8 |
| B → A | oui | oui | 150 | 160 | 46,1 |
| ECARTS % : Workers / AUTOFP | |||||
| Suricata | %CPU | % ecart | |||
| A | B | A | B | ||
| A → B | 100,00% | ||||
| B → A | 100,00% | ||||
| A → B | oui | 107,34% | |||
| B → A | oui | 109,28% | |||
| A → B | oui | 105,38% | |||
| B → A | oui | 108,11% | |||
| A → B | oui | oui | 122,40% | ||
| B → A | oui | oui | 123,05% | ||
Les valeurs "moyennes" sont la moyenne de trois essais.
On arrive quand même à des résultats intéressants en réel, par exemple le chargement des sources du kernel (sur la machine A reliée directement au routeur Internet) se passe en :
Saving to: ‘linux-4.7.5.tar.xz’
linux-4.7.5.tar.xz 100%[====================================================================>] 86,23M 51,4MB/s in 1,7s
Ce qui est très correct, 86Mo en moins de 2 secondes ! Et le même quelques jours après :
wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.7.6.tar.xz
--2016-09-30 23:01:48-- https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.7.6.tar.xz
Resolving cdn.kernel.org (cdn.kernel.org)... 151.101.60.69
Connecting to cdn.kernel.org (cdn.kernel.org)|151.101.60.69|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 90432088 (86M) [application/x-xz]
Saving to: ‘linux-4.7.6.tar.xz’
linux-4.7.6.tar.xz 100%[=====================>] 86,24M 54,0MB/s in 1,6s
2016-09-30 23:01:49 (54,0 MB/s) - ‘linux-4.7.6.tar.xz’ saved [90432088/90432088]Et le 17/10/2016 :
Resolving cdn.kernel.org (cdn.kernel.org)... 151.101.120.69
Connecting to cdn.kernel.org (cdn.kernel.org)|151.101.120.69|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 90413036 (86M) [application/x-xz]
Saving to: ‘linux-4.7.8.tar.xz’
linux-4.7.8.tar.xz 100%[=====================>] 86,22M 57,1MB/s in 1,5s 2016-10-17 21:31:20 (57,1 MB/s) - ‘linux-4.7.8.tar.xz’ saved [90413036/90413036]
On continue le 13/12/2016 : une version plus loin (3.1.3) la vitesse depuis une machine de "deuxième niveau" (toujours derrière le frontal Internet) :
Saving to: ‘linux-4.9.tar.xz’linux-4.9.tar.xz 100%[==================================>] 88,88M 87,3MB/s in 1,0s
2016-12-13 21:05:15 (87,3 MB/s) - ‘linux-4.9.tar.xz’ saved [93192404/93192404]
J'attends la suite ... que voici
Octobre 2017 :
wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.13.7.tar.xz
--2017-10-15 13:55:36-- https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.13.7.tar.xz
Resolving cdn.kernel.org (cdn.kernel.org)... 151.101.121.176, 2a04:4e42:1d::432
Connecting to cdn.kernel.org (cdn.kernel.org)|151.101.121.176|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 100594128 (96M) [application/x-xz]
Saving to: ‘linux-4.13.7.tar.xz’
linux-4.13.7.tar.xz 100%[==================================>] 95,93M 102MB/s in 0,9s
2017-10-15 13:55:37 (102 MB/s) - ‘linux-4.13.7.tar.xz’ saved [100594128/100594128]
Saving to: ‘linux-4.13.8.tar.xz’
linux-4.13.8.tar.xz 100%[==================================>] 95,92M 107MB/s in 0,9s
Ces deux derniers résultats depuis une machine de mon réseau "interne" sur une machine "SSD" only.
Suricata version 4.0
Suricata version 4.0 jppLa dernière version de Suricata est la 4.0.0 parue au début du quatrième trimestre 2017. J'ai attendu quelque peu avant de l'installer et la 4.0.1 était sortie, c'est donc celle que j'ai installée.
La compilation et l'installation sont identiques à celles des versions 3.x. Je n'ai pas non plus eu besoin de modifier les fichiers de paramétrage et tout a fonctionné au premier lancement.
J'ai aussi installé la version 4.0.4 de février 2018 sans plus de problèmes.
Snorby Gui alertes
Snorby Gui alertes jppLe couple Suricata/Barnyard2 détecte les événements réseau notables et les insère dans une base Mysql/MariaDB.
C'est bien, mais pour visualiser ces alertes un outil sympa est "Snorby" : c'est une interface WEB très complète et assez agréable à utiliser. Son développement n'étant plus assuré cela risque de poser problème.
Je l'utilise depuis un bon moment et j'ai presque toujours eu des problèmes lors de son installation ou lors de changement de version de système, même en changeant de machine j'ai rencontré des difficultés.
Quelques articles résument des années d'utilisation.
Juillet 2018, ce logiciel est toujours en cours d'utilisation ...
Janvier 2019, Snorby n'a pas supporté les dernières mises à jour du système et je ne suis pas arrivé à le faire refonctionner ...
J'ai donc réalisé un nouveau logiciel permettant de le remplacer, ainsi est né Snorbis. qui utilise les mêmes tables alimentées par Barnyard2 que Snorby.
Suricata version 4.1
Suricata version 4.1 jppDécembre 2018 : Je suis en train de tester la version 4.1 de Suricata.
La compilation et les premiers tests se sont fort bien passés, la suite bientôt, j'ai profité de ces tests pour valider l'installation de "Snorbis" destiné à remplacer Snorby qui, malheureusement, n'est plus maintenu.
J'ai perdu pas mal de temps sur ce sujet car je me suis aussi occupé d'un outil destiné à gérer les résultats de Modsec dont je reparlerais plus tard.
Note mars 2019 : cette version fonctionne depuis quelques mois sans encombre.
Snorbis : remplacer Snorby
Snorbis : remplacer Snorby jppCette application sans prétentions présentera :
- La même base de données que Snorby en y ajoutant une historisation dans des tables séparées des tables courantes, ainsi seules les anomalies non expliquées sont visibles dans les écrans de contrôle.
- Quelques statistiques
- Quelques fonctions d'automatisation destinées à simplifier en l'automatisant le traitement des "faux positifs" et des "anomalies normales" telles que les messages causés par une machine Debian effectuant sa mise à jour.
Le principe adopté est de ne pas utiliser de Framework pour limiter les dépendances, seul PHP7 et quelques librairies "de base" sont utilisées dans mes différents traitements.
Cela avance bien, mais sans aucun framework c'est un peu un travail de fourmi ... Publication prévue pour avril 2020 le temps de peaufiner la doc et d'éradiquer les derniers bugs.
NOTE février 2021 : Suricata ayant supprimé la sortie "unified2" la base de données "snorby" ne sera donc plus alimentée, je suis en train de mettre au point un petit logiciel (Programme Python) pour alimenter une base équivalente et utiliser cette application légèrement modifiée.
Voir quelques écrans