Introduction
Suricata est un outil de surveillance de sécurité réseau (NSM) qui utilise des ensembles de signatures créées par la communauté et définies par l’utilisateur (également appelées règles) pour examiner et traiter le trafic réseau. Suricata peut générer des événements de journal, déclencher des alertes et bloquer le trafic lorsqu’il détecte des paquets suspects ou des demandes vers un certain nombre de services différents s’exécutant sur un serveur.
Par défaut, Suricata fonctionne comme un système de détection d’intrusion (IDS) passif pour analyser le trafic suspect sur un serveur ou un réseau. Il générera et enregistrera des alertes pour une enquête ultérieure. Il peut également être configuré comme un système de prévention d’intrusion (IPS) actif pour enregistrer, alerter et bloquer complètement le trafic réseau qui correspond à des règles spécifiques.
Vous pouvez déployer Suricata sur un hôte passerelle dans un réseau pour analyser tout le trafic entrant et sortant des autres systèmes, ou vous pouvez l’exécuter localement sur des machines individuelles dans l’un ou l’autre mode.
Dans ce tutoriel, vous apprendrez comment installer Suricata et comment personnaliser certains de ses paramètres par défaut sur Centos 8 Stream pour répondre à vos besoins. Vous apprendrez également comment télécharger des ensembles de signatures existants (généralement appelés ensembles de règles) que Suricata utilise pour analyser le trafic réseau. Enfin, vous apprendrez comment tester si Suricata fonctionne correctement lorsqu’il détecte des demandes suspectes et des données dans une réponse.
Prérequis
En fonction de votre configuration réseau et de l’utilisation que vous envisagez de faire de Suricata, vous pouvez avoir besoin de plus ou moins de CPU et de RAM pour votre serveur. En général, plus le trafic que vous prévoyez d’inspecter est important, plus vous devez allouer de ressources à Suricata. Dans un environnement de production, prévoyez d’utiliser au moins 2 CPU et 4 ou 8 Go de RAM pour commencer. Ensuite, vous pouvez augmenter les ressources en fonction des performances de Suricata et de la quantité de trafic que vous devez traiter.
Si vous envisagez d’utiliser Suricata pour protéger le serveur sur lequel il est exécuté, vous aurez besoin de :
- Un serveur Centos 8 Stream avec 2 CPU ou plus, un utilisateur non root avec sudo et un pare-feu activé. Pour configurer cela, vous pouvez suivre notre tutoriel Configuration initiale du serveur avec CentOS Linux 8.
Sinon, si vous prévoyez d’utiliser Suricata sur un hôte passerelle pour surveiller et protéger plusieurs serveurs, vous devrez vous assurer que la configuration réseau de l’hôte est correcte.
Si vous utilisez DigitalOcean, vous pouvez suivre ce guide sur Comment configurer un droplet en tant que passerelle VPC. Ces instructions devraient fonctionner pour la plupart des serveurs CentOS, Fedora et autres serveurs dérivés de RedHat également.
Étape 1 — Installation de Suricata
Pour commencer l’installation de Suricata, vous devrez ajouter les informations du référentiel logiciel de la Open Information Security Foundation (OISF) à votre système CentOS. Vous pouvez utiliser la commande dnf copr enable pour cela. Vous devrez également ajouter le référentiel Extra Packages for Enterprise Linux (EPEL).
Pour activer la sous-commande Projets Communautaires (copr) pour l’outil de paquets dnf, exécutez ce qui suit :
Vous serez invité à installer quelques dépendances supplémentaires, ainsi qu’à accepter la clé GPG pour la distribution Linux CentOS. Appuyez sur y et sur ENTRÉE à chaque fois pour terminer l’installation du paquet copr.
Ensuite, exécutez la commande suivante pour ajouter le référentiel OISF à votre système et mettre à jour la liste des paquets disponibles :
Appuyez sur y et sur ENTRÉE lorsque vous êtes invité à confirmer que vous souhaitez ajouter le référentiel.
Maintenant, ajoutez le paquet epel-release, ce qui rendra disponibles certains paquets de dépendance supplémentaires pour Suricata :
Lorsque vous êtes invité à importer la clé GPG, appuyez sur y et sur ENTRÉE pour accepter.
Maintenant que vous avez activé les référentiels logiciels requis, vous pouvez installer le paquet suricata à l’aide de la commande dnf :
Lorsque vous êtes invité à ajouter la clé GPG pour le référentiel OISF, appuyez sur y puis sur ENTRÉE. Le paquet et ses dépendances seront maintenant téléchargés et installés.
Ensuite, activez le service suricata.service afin qu’il s’exécute lors du redémarrage de votre système. Utilisez la commande systemctl pour l’activer :
Vous devriez recevoir une sortie similaire à celle ci-dessous indiquant que le service est activé :
OutputCreated symlink /etc/systemd/system/multi-user.target.wants/suricata.service → /usr/lib/systemd/system/suricata.service.
Avant de passer à la section suivante de ce tutoriel, qui explique comment configurer Suricata, arrêtez le service en utilisant systemctl :
Arrêter Suricata garantit que lorsque vous éditez et testez le fichier de configuration, toutes les modifications que vous apportez seront validées et chargées lors du prochain démarrage de Suricata.
Étape 2 — Configuration initiale de Suricata
Le paquet Suricata provenant des référentiels OISF est livré avec un fichier de configuration qui couvre une grande variété de cas d’utilisation. Le mode par défaut pour Suricata est le mode IDS, donc aucun trafic ne sera bloqué, seulement enregistré. Laisser ce mode défini sur la valeur par défaut est une bonne idée pendant que vous apprenez Suricata. Une fois que vous avez configuré Suricata et l’avez intégré dans votre environnement, et que vous avez une bonne idée des types de trafic sur lesquels il vous alertera, vous pouvez choisir d’activer le mode IPS.
Cependant, la configuration par défaut a encore quelques paramètres que vous devrez peut-être modifier en fonction de votre environnement et de vos besoins.
(Facultatif) Activation de l’identifiant de flux communautaire
Suricata peut inclure un champ ID de communauté dans sa sortie JSON pour faciliter la correspondance des enregistrements d’événements individuels avec des enregistrements dans des ensembles de données générés par d’autres outils.
Si vous prévoyez d’utiliser Suricata avec d’autres outils comme Zeek ou Elasticsearch, ajouter l’identifiant de communauté maintenant est une bonne idée.
Pour activer l’option, ouvrez /etc/suricata/suricata.yaml en utilisant vi ou votre éditeur préféré :
Recherchez la ligne 120 qui indique # Identifiant de flux communautaire. Si vous utilisez vi, tapez 120gg pour accéder directement à la ligne. En dessous de cette ligne se trouve la clé community-id. Définissez-la sur true pour activer le paramètre :
. . .
# Identifiant de flux communautaire
# Ajoute un champ 'community_id' aux enregistrements EVE. Ils sont censés donner
# à des enregistrements un ID de flux prévisible qui peut être utilisé pour faire correspondre des enregistrements à
# la sortie d'autres outils tels que Zeek (Bro).
#
# Prend une 'seed' qui doit être la même sur tous les capteurs et outils
# pour rendre l'identifiant moins prévisible.
# activer/désactiver la fonctionnalité de l'identifiant de communauté.
community-id: true
. . .
Maintenant, lorsque vous examinez les événements, ils auront un ID comme 1:S+3BA2UmrHK0Pk+u3XH78GAFTtQ= que vous pouvez utiliser pour corréler les enregistrements entre différents outils NMS.
Enregistrez et fermez le fichier /etc/suricata/suricata.yaml. Si vous utilisez vi, vous pouvez le faire avec ESC, puis :x, puis ENTER pour enregistrer et quitter le fichier.
Détermination de(s) interface(s) réseau à utiliser
Vous pouvez avoir besoin de remplacer l’interface réseau par défaut ou les interfaces que vous souhaitez que Suricata inspecte le trafic. Le fichier de configuration fourni avec le paquet Suricata OISF inspecte par défaut le trafic sur un périphérique appelé eth0. Si votre système utilise une interface réseau par défaut différente, ou si vous souhaitez inspecter le trafic sur plus d’une interface, vous devrez alors modifier cette valeur.
Pour déterminer le nom de périphérique de votre interface réseau par défaut, vous pouvez utiliser la commande ip comme suit:
Le drapeau -p formate la sortie pour qu’elle soit plus lisible, et le drapeau -j imprime la sortie au format JSON.
Vous devriez recevoir une sortie comme celle-ci:
Output[ {
"dst": "default",
"gateway": "203.0.113.254",
"dev": "eth0",
"protocol": "static",
"metric": 100,
"flags": [ ]
} ]
La ligne dev indique le périphérique par défaut. Dans cet exemple de sortie, le périphérique est l’interface eth0 en surbrillance. Votre sortie peut afficher un nom de périphérique tel que ens... ou eno.... Quel que soit le nom, prenez-en note.
Vous pouvez maintenant modifier la configuration de Suricata et vérifier ou changer le nom de l’interface. Ouvrez le fichier de configuration /etc/suricata/suricata.yaml à l’aide de vi ou de votre éditeur préféré:
Faites défiler le fichier jusqu’à ce que vous arriviez à une ligne qui indique af-packet: vers la ligne 580 environ. Si vous utilisez vi, vous pouvez également vous rendre directement à la ligne en entrant 580gg. Sous cette ligne se trouve l’interface par défaut que Suricata utilisera pour inspecter le trafic. Modifiez la ligne pour correspondre à votre interface comme dans l’exemple en surbrillance qui suit:
# Prise en charge de la capture haute vitesse sous Linux
af-packet:
- interface: eth0
# Nombre de threads de réception. "auto" utilise le nombre de cœurs
#threads: auto
# Identifiant de cluster par défaut. AF_PACKET répartira les paquets en fonction du flux.
cluster-id: 99
. . .
Si vous souhaitez inspecter le trafic sur des interfaces supplémentaires, vous pouvez ajouter plus d’objets YAML - interface: eth.... Par exemple, pour ajouter un périphérique nommé enp0s1, descendez jusqu’au bas de la section af-packet vers la ligne 650 environ. Pour ajouter une nouvelle interface, insérez-la avant la section - interface: default comme dans l’exemple en surbrillance suivant:
# Pour la configuration d'eBPF et XDP incluant le contournement, le filtrage et l'équilibrage de charge, veuillez
# consulter le fichier doc/userguide/capture-hardware/ebpf-xdp.rst pour plus d'informations.
- interface: enp0s1
cluster-id: 98
- interface: default
#threads : auto
#use-mmap : non
#tpacket-v3 : oui
Assurez-vous de choisir une valeur de cluster-id unique pour chaque objet - interface.
Gardez votre éditeur ouvert et passez à la section suivante où vous configurerez le rechargement des règles en direct. Si vous ne souhaitez pas activer ce paramètre, vous pouvez enregistrer et fermer le fichier /etc/suricata/suricata.yaml. Si vous utilisez vi, vous pouvez le faire avec ESC, puis :x et ENTER pour enregistrer et quitter.
Configuration du rechargement des règles en direct
Suricata prend en charge le rechargement des règles en direct, ce qui signifie que vous pouvez ajouter, retirer et modifier des règles sans avoir à redémarrer le processus Suricata en cours. Pour activer l’option de rechargement en direct, faites défiler jusqu’au bas du fichier de configuration et ajoutez les lignes suivantes :
. . .
detect-engine:
- rule-reload: true
Avec ce paramètre en place, vous pourrez envoyer le signal système SIGUSR2 au processus en cours, et Suricata rechargera toutes les règles modifiées en mémoire.
A command like the following will notify the Suricata process to reload its rulesets, without restarting the process:
La partie $(pidof suricata) de la commande invoque un sous-shell et trouve l’ID du processus du démon Suricata en cours d’exécution. La première partie de la commande sudo kill -usr2 utilise l’utilitaire kill pour envoyer le signal SIGUSR2 à l’ID de processus renvoyé par le sous-shell.
Vous pouvez utiliser cette commande chaque fois que vous exécutez suricata-update ou lorsque vous ajoutez ou modifiez vos propres règles personnalisées.
Enregistrez et fermez le fichier /etc/suricata/suricata.yaml. Si vous utilisez vi, vous pouvez le faire avec ESC, puis :x et ENTER pour confirmer.
Étape 3 — Mise à jour des jeux de règles Suricata
À ce stade du tutoriel, si vous démarriez Suricata, vous recevriez un message d’avertissement comme celui-ci dans les journaux indiquant qu’il n’y a pas de règles chargées :
Output<Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /var/lib/suricata/rules/suricata.rules
Par défaut, le package Suricata comprend un ensemble limité de règles de détection (dans le répertoire /etc/suricata/rules), donc activer Suricata à ce stade ne détecterait qu’une quantité limitée de trafic malveillant.
Suricata inclut un outil appelé suricata-update qui peut récupérer des jeux de règles auprès de fournisseurs externes. Exécutez-le comme suit pour télécharger un ensemble de règles à jour pour votre serveur Suricata :
Vous devriez recevoir une sortie comme celle-ci :
Output19/10/2021 -- 19:31:03 - <Info> -- Using data-directory /var/lib/suricata.
19/10/2021 -- 19:31:03 - <Info> -- Using Suricata configuration /etc/suricata/suricata.yaml
19/10/2021 -- 19:31:03 - <Info> -- Using /usr/share/suricata/rules for Suricata provided rules.
. . .
19/10/2021 -- 19:31:03 - <Info> -- No sources configured, will use Emerging Threats Open
19/10/2021 -- 19:31:03 - <Info> -- Fetching https://rules.emergingthreats.net/open/suricata-6.0.3/emerging.rules.tar.gz.
100% - 3062850/3062850
. . .
19/10/2021 -- 19:31:06 - <Info> -- Writing rules to /var/lib/suricata/rules/suricata.rules: total: 31011; enabled: 23649; added: 31011; removed 0; modified: 0
19/10/2021 -- 19:31:07 - <Info> -- Writing /var/lib/suricata/rules/classification.config
19/10/2021 -- 19:31:07 - <Info> -- Testing with suricata -T.
19/10/2021 -- 19:31:32 - <Info> -- Done.
Les lignes en surbrillance indiquent que suricata-update a récupéré les règles gratuites des menaces émergentes ET Open Rules et les a enregistrées dans le fichier /var/lib/suricata/rules/suricata.rules de Suricata. Cela indique également le nombre de règles qui ont été traitées, dans cet exemple, 31011 ont été ajoutées et parmi celles-ci, 23649 étaient activées.
Ajout de fournisseurs de règles
L’outil suricata-update peut récupérer des règles auprès de divers fournisseurs de jeux de règles gratuits et commerciaux. Certains jeux de règles comme celui d’ET Open que vous avez déjà ajouté sont disponibles gratuitement, tandis que d’autres nécessitent un abonnement payant.
Vous pouvez répertorier l’ensemble par défaut des fournisseurs de règles en utilisant le drapeau list-sources pour suricata-update comme ceci :
Vous recevrez une liste de sources comme suit :
Output. . .
19/10/2021 -- 19:27:34 - <Info> -- Adding all sources
19/10/2021 -- 19:27:34 - <Info> -- Saved /var/lib/suricata/update/cache/index.yaml
Name: et/open
Vendor: Proofpoint
Summary: Emerging Threats Open Ruleset
License: MIT
. . .
Par exemple, si vous souhaitez inclure le jeu de règles tgreen/hunting, vous pouvez l’activer en utilisant la commande suivante :
Ensuite, exécutez à nouveau suricata-update et le nouvel ensemble de règles sera ajouté, en plus des règles existantes d’ET Open et de toutes les autres que vous avez téléchargées.
Étape 4 — Validation de la configuration de Suricata
Maintenant que vous avez modifié le fichier de configuration de Suricata pour inclure l’ID de communauté facultatif, spécifier l’interface réseau par défaut, et activé le rechargement dynamique des règles en direct, il est conseillé de tester la configuration.
Suricata dispose d’un mode de test intégré qui vérifiera le fichier de configuration et toutes les règles incluses pour la validité. Validez vos modifications de la section précédente en utilisant le drapeau -T pour exécuter Suricata en mode test. Le drapeau -v affichera des informations supplémentaires, et le drapeau -c indique à Suricata où trouver son fichier de configuration:
Le test peut prendre un certain temps en fonction de la quantité de CPU que vous avez allouée à Suricata et du nombre de règles que vous avez ajoutées, alors soyez prêt à attendre une minute ou deux pour qu’il se termine.
Avec l’ensemble de règles ET Open par défaut, vous devriez recevoir une sortie comme celle-ci:
Output21/10/2021 -- 15:00:40 - <Info> - Running suricata under test mode
21/10/2021 -- 15:00:40 - <Notice> - This is Suricata version 6.0.3 RELEASE running in SYSTEM mode
21/10/2021 -- 15:00:40 - <Info> - CPUs/cores online: 2
21/10/2021 -- 15:00:40 - <Info> - fast output device (regular) initialized: fast.log
21/10/2021 -- 15:00:40 - <Info> - eve-log output device (regular) initialized: eve.json
21/10/2021 -- 15:00:40 - <Info> - stats output device (regular) initialized: stats.log
21/10/2021 -- 15:00:46 - <Info> - 1 rule files processed. 23879 rules successfully loaded, 0 rules failed
21/10/2021 -- 15:00:46 - <Info> - Threshold config parsed: 0 rule(s) found
21/10/2021 -- 15:00:47 - <Info> - 23882 signatures processed. 1183 are IP-only rules, 4043 are inspecting packet payload, 18453 inspect application layer, 107 are decoder event only
21/10/2021 -- 15:01:13 - <Notice> - Configuration provided was successfully loaded. Exiting.
21/10/2021 -- 15:01:13 - <Info> - cleaning up signature grouping structure... complete
S’il y a une erreur dans votre fichier de configuration, le mode de test générera un code d’erreur spécifique et un message que vous pouvez utiliser pour aider à dépanner. Par exemple, inclure un fichier de règles qui n’existe pas appelé test.rules générerait une erreur comme celle-ci:
Output21/10/2021 -- 15:10:15 - <Info> - Running suricata under test mode
21/10/2021 -- 15:10:15 - <Notice> - This is Suricata version 6.0.3 RELEASE running in SYSTEM mode
21/10/2021 -- 15:10:15 - <Info> - CPUs/cores online: 2
21/10/2021 -- 15:10:15 - <Info> - eve-log output device (regular) initialized: eve.json
21/10/2021 -- 15:10:15 - <Info> - stats output device (regular) initialized: stats.log
21/10/2021 -- 15:10:21 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /var/lib/suricata/rules/test.rules
Avec cette erreur, vous pourriez ensuite modifier votre fichier de configuration pour inclure le bon chemin, ou corriger les variables invalides et les options de configuration.
Une fois que votre mode test Suricata s’est terminé avec succès, vous pouvez passer à l’étape suivante, qui consiste à démarrer Suricata en mode daemon.
Étape 5 — Exécution de Suricata
Maintenant que vous avez une configuration Suricata valide et un ensemble de règles, vous pouvez démarrer le serveur Suricata. Exécutez la commande systemctl suivante :
Vous pouvez examiner l’état du service en utilisant la commande systemctl status :
Vous devriez recevoir une sortie similaire à ce qui suit :
Output● suricata.service - Suricata Intrusion Detection Service
Loaded: loaded (/usr/lib/systemd/system/suricata.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2021-10-21 18:22:56 UTC; 1min 57s ago
Docs: man:suricata(1)
Process: 24588 ExecStartPre=/bin/rm -f /var/run/suricata.pid (code=exited, status=0/SUCCESS)
Main PID: 24590 (Suricata-Main)
Tasks: 1 (limit: 23473)
Memory: 80.2M
CGroup: /system.slice/suricata.service
└─24590 /sbin/suricata -c /etc/suricata/suricata.yaml --pidfile /var/run/suricata.pid -i eth0 --user suricata
Oct 21 18:22:56 suricata systemd[1]: Starting Suricata Intrusion Detection Service..
Oct 21 18:22:56 suricata systemd[1]: Started Suricata Intrusion Detection Service.
. . .
Comme avec la commande du mode test, Suricata prendra une minute ou deux pour charger et analyser l’ensemble des règles. Vous pouvez utiliser la commande tail pour surveiller un message spécifique dans les journaux de Suricata indiquant qu’il a fini de démarrer :
Vous recevrez plusieurs lignes de sortie, et le terminal peut sembler bloqué pendant que Suricata se charge. Continuez d’attendre la sortie jusqu’à ce que vous receviez une ligne comme celle-ci :
Output19/10/2021 -- 19:22:39 - <Info> - All AFP capture threads are running.
Cette ligne indique que Suricata est en cours d’exécution et prêt à inspecter le trafic. Vous pouvez quitter la commande tail en utilisant CTRL+C.
Maintenant que vous avez vérifié que Suricata est en cours d’exécution, l’étape suivante de ce tutoriel consiste à vérifier si Suricata détecte une demande vers une URL de test conçue pour générer une alerte.
Étape 6 — Test des règles Suricata
Le jeu de règles ET Open que vous avez téléchargé contient plus de 30000 règles. Une explication complète de la façon dont les règles Suricata fonctionnent et comment les construire dépasse le cadre de ce tutoriel introductif. Un tutoriel ultérieur de cette série expliquera le fonctionnement des règles et comment créer les vôtres.
Pour les besoins de ce tutoriel, il suffit de tester si Suricata détecte un trafic suspect avec la configuration que vous avez générée. Le Guide de démarrage rapide de Suricata recommande de tester la règle ET Open avec le numéro 2100498 en utilisant la commande curl.
Exécutez ce qui suit pour générer une requête HTTP, qui renverra une réponse correspondant à la règle d’alerte de Suricata:
La commande curl renverra une réponse comme suit:
Outputuid=0(root) gid=0(root) groups=0(root)
Ces données de réponse d’exemple sont conçues pour déclencher une alerte, en prétendant renvoyer la sortie d’une commande comme id qui pourrait s’exécuter sur un système distant compromis via un shell web.
Maintenant, vous pouvez vérifier les journaux de Suricata pour une alerte correspondante. Deux journaux sont activés avec la configuration par défaut de Suricata. Le premier est dans /var/log/suricata/fast.log et le second est un journal lisible par machine dans /var/log/suricata/eve.log.
Examen de /var/log/suricata/fast.log
Pour vérifier une entrée de journal dans /var/log/suricata/fast.log correspondant à votre demande curl, utilisez la commande grep. En utilisant l’identifiant de règle 2100498 de la documentation de démarrage rapide, recherchez les entrées qui correspondent en utilisant la commande suivante :
Si votre demande utilisait IPv6, alors vous devriez recevoir une sortie comme celle-ci, où 2001:DB8::1 est l’adresse IPv6 publique de votre système :
Output10/21/2021-18:35:54.950106 [**] [1:2100498:7] GPL ATTACK_RESPONSE id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 2600:9000:2000:4400:0018:30b3:e400:93a1:80 -> 2001:DB8::1:34628
Si votre demande utilisait IPv4, alors votre journal devrait avoir un message comme celui-ci, où 203.0.113.1 est l’adresse IPv4 publique de votre système :
Output10/21/2021-18:35:57.247239 [**] [1:2100498:7] GPL ATTACK_RESPONSE id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 204.246.178.81:80 -> 203.0.113.1:36364
Remarquez la valeur 2100498 mise en évidence dans la sortie, qui est l’identifiant de signature (sid) que Suricata utilise pour identifier une règle.
Examen de /var/log/suricata/eve.log
Suricata enregistre également des événements dans /var/log/suricata/eve.log (surnommé le journal EVE) en utilisant JSON pour formater les entrées.
La documentation de Suricata recommande d’utiliser l’utilitaire jq pour lire et filtrer les entrées dans ce fichier. Installez jq si vous ne l’avez pas sur votre système en utilisant la commande dnf suivante :
Une fois que vous avez installé jq, vous pouvez filtrer les événements dans le journal EVE en recherchant la signature 2100498 avec la commande suivante :
La commande examine chaque entrée JSON et affiche celles qui ont un objet alert, avec une clé signature_id qui correspond à la valeur 2100498 que vous recherchez. La sortie ressemblera à ce qui suit :
Output{
"timestamp": "2021-10-21T19:42:47.368856+0000",
"flow_id": 775889108832281,
"in_iface": "eth0",
"event_type": "alert",
"src_ip": "203.0.113.1",
"src_port": 80,
"dest_ip": "147.182.148.159",
"dest_port": 38920,
"proto": "TCP",
"community_id": "1:vuSfAFyy7oUq0LQC5+KNTBSuPxg=",
"alert": {
"action": "allowed",
"gid": 1,
"signature_id": 2100498,
"rev": 7,
"signature": "GPL ATTACK_RESPONSE id check returned root",
"category": "Potentially Bad Traffic",
. . .
}
Remarquez la ligne "signature_id": 2100498, en surbrillance, qui est la clé que jq recherche. Remarquez également la ligne "community_id": "1:vuSfAFyy7oUq0LQC5+KNTBSuPxg=", en surbrillance dans la sortie JSON. Cette clé est l’identifiant de flux commun généré que vous avez activé dans le fichier de configuration de Suricata.
Chaque alerte générera un identifiant de flux commun unique. D’autres outils de gestion de réseau peuvent également générer le même identifiant pour permettre la corrélation d’une alerte Suricata avec la sortie d’autres outils.
A matching log entry in either log file means that Suricata successfully inspected the network traffic, matched it against a detection rule, and generated an alert for subsequent analysis or logging. A future tutorial in this series will explore how to send Suricata alerts to a Security Information Event Management (SIEM) system for further processing.
Étape 7 — Gestion des alertes Suricata
Une fois que vous avez configuré et testé les alertes, vous pouvez choisir comment les gérer. Pour certains cas d’utilisation, enregistrer les alertes à des fins d’audit peut être suffisant ; ou vous pouvez préférer adopter une approche plus active pour bloquer le trafic en provenance de systèmes générant des alertes répétées.
Si vous souhaitez bloquer le trafic en fonction des alertes générées par Suricata, une approche consiste à utiliser les entrées du journal EVE, puis à ajouter des règles de pare-feu pour restreindre l’accès à votre système ou à vos systèmes. Vous pouvez utiliser l’outil jq pour extraire des champs spécifiques d’une alerte, puis ajouter des règles UFW ou IPtables pour bloquer les requêtes.
Encore une fois, cet exemple est un scénario hypothétique utilisant des données de requête et de réponse délibérément élaborées. Votre connaissance des systèmes et des protocoles auxquels votre environnement devrait pouvoir accéder est essentielle pour déterminer quel trafic est légitime et quel trafic peut être bloqué.
Conclusion
Dans ce tutoriel, vous avez installé Suricata à partir des dépôts de logiciels de l’OISF. L’installation de Suricata de cette manière garantit que vous pouvez recevoir des mises à jour chaque fois qu’une nouvelle version de Suricata est publiée. Après avoir installé Suricata, vous avez modifié la configuration par défaut pour ajouter un ID de flux commun à utiliser avec d’autres outils de sécurité. Vous avez également activé le rechargement en direct des règles et téléchargé un ensemble initial de règles.
Une fois que vous avez validé la configuration de Suricata, vous avez lancé le processus et généré un trafic HTTP de test. Vous avez vérifié que Suricata pouvait détecter du trafic suspect en examinant les deux journaux par défaut pour vous assurer qu’ils contenaient une alerte correspondant à la règle que vous testiez.
Pour plus d’informations sur Suricata, visitez le Site officiel de Suricata. Pour plus de détails sur l’une des options de configuration que vous avez configurées dans ce tutoriel, consultez le Guide de l’utilisateur de Suricata.
Maintenant que vous avez installé et configuré Suricata, vous pouvez passer au prochain tutoriel de cette série Comprendre les signatures de Suricata où vous apprendrez comment rédiger vos propres règles personnalisées Suricata. Vous découvrirez différentes façons de créer des alertes, voire même comment bloquer le trafic entièrement, en fonction de critères tels que les paquets TCP/IP invalides, le contenu des requêtes DNS, les requêtes et réponses HTTP, et même les poignées de main TLS.
Source:
https://www.digitalocean.com/community/tutorials/how-to-install-suricata-on-centos-8-stream