Comment installer Suricata sur le flux CentOS 8

Introduction

Suricata est un outil de surveillance de la sécurité du 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 interrompre le trafic lorsqu'il détecte des paquets ou des demandes suspects vers un nombre quelconque de services différents exécutés sur un serveur.

Par défaut, Suricata fonctionne comme un système de détection d'intrusion (IDS) passif pour rechercher le trafic suspect sur un serveur ou un réseau. Il générera et enregistrera des alertes pour une enquête plus approfondie. Il peut également être configuré comme un système de prévention des intrusions (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 de passerelle dans un réseau pour analyser tout le trafic réseau entrant et sortant d'autres systèmes, ou vous pouvez l'exécuter localement sur des machines individuelles dans l'un ou l'autre mode.

Dans ce didacticiel, vous apprendrez à installer Suricata et à personnaliser certains de ses paramètres par défaut sur Centos 8 Stream en fonction de vos besoins. Vous apprendrez également à 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 à tester si Suricata fonctionne correctement lorsqu'il détecte des demandes et des données suspectes dans une réponse.

Conditions préalables

Selon la configuration de votre réseau et la façon dont vous comptez utiliser Suricata, vous aurez peut-être besoin de plus ou moins de CPU et de RAM pour votre serveur. En règle générale, plus vous prévoyez d'inspecter de trafic, plus vous devez allouer de ressources à Suricata. Dans un environnement de production, prévoyez d'utiliser au moins 2 processeurs et 4 ou 8 Go de RAM pour commencer. À partir de là, 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 s'exécute, vous aurez besoin de :

• Un serveur Centos 8 Stream avec 2 processeurs ou plus, un utilisateur sudo non root et un pare-feu activé. Pour le configurer, vous pouvez suivre notre tutoriel Configuration initiale du serveur avec CentOS Linux 8.

Sinon, si vous envisagez d'utiliser Suricata sur un hôte de passerelle pour surveiller et protéger plusieurs serveurs, vous devrez vous assurer que la mise en réseau de l'hôte est correctement configurée.

Si vous utilisez DigitalOcean, vous pouvez suivre ce guide sur Comment configurer une gouttelette en tant que passerelle VPC. Ces instructions devraient également fonctionner pour la plupart des serveurs CentOS, Fedora et autres serveurs dérivés de RedHat.

Étape 1 - Installation de Suricata

Pour commencer à installer Suricata, vous devrez ajouter les informations du référentiel de logiciels de l'Open Information Security Foundation (OISF) à votre système CentOS. Vous pouvez utiliser le dnf copr enable commande pour le faire. Vous devrez également ajouter le référentiel Extra Packages for Enterprise Linux (EPEL).

Pour activer les projets communautaires (copr) sous-commande pour le dnf outil de package, exécutez ce qui suit :

sudo dnf install 'dnf-command(copr)'

Vous serez invité à installer des dépendances supplémentaires, ainsi qu'à accepter la clé GPG pour la distribution CentOS Linux. Presse y et ENTER à chaque fois pour terminer l'installation du copr forfait.

Exécutez ensuite la commande suivante pour ajouter le référentiel OISF à votre système et mettre à jour la liste des packages disponibles :

sudo dnf copr enable @oisf/suricata-6.0

Presse y et ENTER lorsque vous êtes invité à confirmer que vous souhaitez ajouter le référentiel.

Ajoutez maintenant le epel-release package, qui mettra à disposition des packages de dépendances supplémentaires pour Suricata :

sudo dnf install epel-release

Lorsque vous êtes invité à importer la clé GPG, appuyez sur y et ENTER accepter.

Maintenant que les référentiels de logiciels requis sont activés, vous pouvez installer le suricata paquet utilisant le dnf commande:

sudo dnf install suricata

Lorsque vous êtes invité à ajouter la clé GPG pour le référentiel OISF, appuyez sur y et ENTER. Le package et ses dépendances vont maintenant être téléchargés et installés.

Ensuite, activez le suricata.service afin qu'il s'exécute au redémarrage de votre système. Utilisez le systemctl commande pour l'activer :

sudo systemctl enable suricata.service

Vous devriez recevoir une sortie comme celle-ci 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:

sudo systemctl stop suricata.service

L'arrêt de Suricata garantit que lorsque vous modifiez et testez le fichier de configuration, toutes les modifications que vous apportez seront validées et chargées au redémarrage de Suricata.

Étape 2 - Configuration de Suricata pour la première fois

Le package Suricata 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 abandonné, seulement enregistré. Laisser ce mode par défaut est une bonne idée lorsque vous apprenez Suricata. Une fois que vous avez configuré et intégré Suricata dans votre environnement, et que vous avez une bonne idée des types de trafic dont il vous alertera, vous pouvez choisir d'activer le mode IPS.

Cependant, la configuration par défaut comporte encore quelques paramètres que vous devrez peut-être modifier en fonction de votre environnement et de vos besoins.

(Facultatif) Activation de l'ID de flux communautaire

Suricata peut inclure un champ Community ID dans sa sortie JSON pour faciliter la mise en correspondance d'enregistrements d'événements individuels avec des enregistrements dans des ensembles de données générés par d'autres outils.

Si vous envisagez d'utiliser Suricata avec d'autres outils comme Zeek ou Elasticsearch, ajouter l'identifiant communautaire maintenant est une bonne idée.

Pour activer l'option, ouvrez /etc/suricata/suricata.yaml utilisant vi ou votre éditeur préféré :

sudo vi /etc/suricata/suricata.yaml

Trouvez la ligne 120 qui se lit # Community Flow ID. Si vous utilisez vi taper 120gg aller directement à la ligne. Au-dessous de cette ligne se trouve le community-id clé. Réglez-le sur true pour activer le paramètre :

/etc/suricata/suricata.yaml

. . .
      # Community Flow ID
      # Adds a 'community_id' field to EVE records. These are meant to give
      # records a predictable flow ID that can be used to match records to
      # output of other tools such as Zeek (Bro).
      #
      # Takes a 'seed' that needs to be same across sensors and tools
      # to make the id less predictable.

      # enable/disable the community id feature.
      community-id: true
. . .

Maintenant, lorsque vous examinez des é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 /etc/suricata/suricata.yaml dossier. Si vous utilisez vi, vous pouvez le faire avec ESC et alors :x alors ENTER pour enregistrer et quitter le fichier.

Détermination de la ou des interfaces réseau à utiliser

Vous devrez peut-être remplacer l'interface ou les interfaces réseau par défaut sur lesquelles vous souhaitez que Suricata inspecte le trafic. Par défaut, le fichier de configuration fourni avec le package OISF Suricata inspecte le trafic sur un appareil appelé eth0. Si votre système utilise une interface réseau par défaut différente ou si vous souhaitez inspecter le trafic sur plusieurs interfaces, vous devrez modifier cette valeur.

Pour déterminer le nom de périphérique de votre interface réseau par défaut, vous pouvez utiliser le ip commande comme suit :

ip -p -j route show default

La -p flag formate la sortie pour qu'elle soit plus lisible, et le -j flag 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 dev ligne indique le périphérique par défaut. Dans cet exemple de sortie, le périphérique est en surbrillance eth0 interface. Votre sortie peut afficher un nom de périphérique tel que ens... ou eno.... Quel que soit son nom, notez-le.

Vous pouvez maintenant modifier la configuration de Suricata et vérifier ou modifier le nom de l'interface. Ouvrez le /etc/suricata/suricata.yaml fichier de configuration à l'aide vi ou votre éditeur préféré :

sudo vi /etc/suricata/suricata.yaml

Faites défiler le fichier jusqu'à ce que vous arriviez à une ligne qui lit af-packet: autour de la ligne 580. Si vous utilisez vi vous pouvez également accéder directement à la ligne en saisissant 580gg. Sous cette ligne se trouve l'interface par défaut que Suricata utilisera pour inspecter le trafic. Modifiez la ligne pour qu'elle corresponde à votre interface, comme dans l'exemple en surbrillance suivant :

/etc/suriata/suricata.yaml

# Linux high speed capture support
af-packet:
  - interface: eth0
    # Number of receive threads. "auto" uses the number of cores
    #threads: auto
    # Default clusterid. AF_PACKET will load balance packets based on flow.
    cluster-id: 99
. . .

Si vous souhaitez inspecter le trafic sur des interfaces supplémentaires, vous pouvez en ajouter d'autres - interface: eth... Objets YAML. Par exemple, pour ajouter un périphérique nommé enp0s1, faites défiler vers le bas de la af-packet section vers la ligne 650 environ. Pour ajouter une nouvelle interface, insérez-la avant le - interface: default section comme l'exemple en surbrillance suivant :

/ec/suricata/suricata.yaml

    #  For eBPF and XDP setup including bypass, filter and load balancing, please
    #  see doc/userguide/capture-hardware/ebpf-xdp.rst for more info.

  - interface: enp0s1
    cluster-id: 98

  - interface: default
    #threads: auto
    #use-mmap: no
    #tpacket-v3: yes

Assurez-vous de choisir un cluster-id valeur pour chaque - interface objet.

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 /etc/suricata/suricata.yaml dossier. Si vous utilisez vi, vous pouvez le faire avec ESC, alors :x et ENTER pour sauvegarder 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, supprimer et modifier des règles sans avoir à redémarrer le processus Suricata en cours d'exécution. Pour activer l'option de rechargement en direct, faites défiler jusqu'au bas du fichier de configuration et ajoutez les lignes suivantes :

/etc/suricata/suricata.yaml

. . .

detect-engine:
  - rule-reload: true

Avec ce paramètre en place, vous pourrez envoyer le SIGUSR2 signal système au processus en cours d'exécution, et Suricata rechargera toutes les règles modifiées en mémoire.

Une commande comme celle-ci indiquera au processus Suricata de recharger ses ensembles de règles, sans redémarrer le processus :

sudo kill -usr2 $(pidof suricata)

La $(pidof suricata) Une partie de la commande invoque un sous-shell et trouve l'ID de processus du démon Suricata en cours d'exécution. Le début sudo kill -usr2 une partie de la commande utilise le kill utilitaire pour envoyer le SIGUSR2 signal à l'ID de processus qui est 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 /etc/suricata/suricata.yaml dossier. Si vous utilisez vi, vous pouvez le faire avec ESC, alors :x et ENTER confirmer.

Étape 3 - Mise à jour des ensembles de règles Suricata

À ce stade du didacticiel, si vous deviez démarrer 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 inclut un ensemble limité de règles de détection (dans le /etc/suricata/rules répertoire), donc l'activation de Suricata à ce stade ne détecterait qu'une quantité limitée de mauvais trafic.

Suricata inclut un outil appelé suricata-update qui peut récupérer des ensembles 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 :

sudo suricata-update

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 suricata-update a récupéré les règles gratuites Emerging Threats ET Open Rules et les a enregistrées sur Suricata /var/lib/suricata/rules/suricata.rules dossier. Il 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 ont été activées.

Ajout de fournisseurs d'ensembles de règles

La suricata-update L'outil peut récupérer des règles auprès d'une variété de fournisseurs d'ensembles de règles gratuits et commerciaux. Certains ensembles de règles comme l'ensemble 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 de fournisseurs de règles par défaut à l'aide de la list-sources signaler à suricata-update comme ça:

sudo suricata-update list-sources

Vous recevrez une liste de sources comme celle-ci :

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 vouliez inclure le tgreen/hunting ruleset, vous pouvez l'activer à l'aide de la commande suivante :

sudo suricata-update enable-source tgreen/hunting

Puis cours suricata-update à nouveau et le nouvel ensemble de règles sera ajouté, en plus des règles ET Open existantes 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 des règles en direct, il est judicieux de tester la configuration.

Suricata a un mode de test intégré qui vérifiera la validité du fichier de configuration et de toutes les règles incluses. Validez vos modifications de la section précédente à l'aide de la -T drapeau pour exécuter Suricata en mode test. La -v flag imprimera des informations supplémentaires, et le -c flag indique à Suricata où trouver son fichier de configuration :

sudo suricata -T -c /etc/suricata/suricata.yaml -v

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 test générera un code d'erreur et un message spécifiques que vous pouvez utiliser pour vous aider à résoudre les problèmes. Par exemple, en incluant 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 pouvez alors modifier votre fichier de configuration pour inclure le chemin correct ou corriger les variables et les options de configuration non valides.

Une fois votre exécution en mode test Suricata terminée avec succès, vous pouvez passer à l'étape suivante, qui consiste à démarrer Suricata en mode démon.

Étape 5 - Exécution de Suricata

Maintenant que vous disposez d'une configuration et d'un ensemble de règles Suricata valides, vous pouvez démarrer le serveur Suricata. Exécutez ce qui suit systemctl commande:

sudo systemctl start suricata.service

Vous pouvez examiner l'état du service à l'aide de la systemctl status commande:

sudo systemctl status suricata.service

Vous devriez recevoir une sortie comme celle-ci :

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 pour la commande du mode test, il faudra une minute ou deux à Suricata pour charger et analyser toutes les règles. Vous pouvez utiliser le tail commande pour surveiller un message spécifique dans les journaux de Suricata indiquant qu'il a fini de démarrer :

sudo tail -f /var/log/suricata/suricata.log

Vous recevrez un certain nombre de lignes de sortie et le terminal peut sembler bloqué pendant le chargement de Suricata. Continuez à 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 le tail commande utilisant CTRL+C.

Maintenant que vous avez vérifié que Suricata est en cours d'exécution, l'étape suivante de ce didacticiel consiste à vérifier si Suricata détecte une requête vers une URL de test conçue pour générer une alerte.

Étape 6 - Test des règles Suricata

L'ensemble de règles ET Open que vous avez téléchargé contient plus de 30 000 règles. Une explication complète du fonctionnement des règles de Suricata et de leur construction dépasse le cadre de ce didacticiel d'introduction. Un didacticiel ultérieur de cette série expliquera comment fonctionnent les règles et comment créer les vôtres.

Pour les besoins de ce didacticiel, il suffit de tester si Suricata détecte le trafic suspect avec la configuration que vous avez générée. Le Suricata Quickstart recommande de tester la règle ET Open avec le numéro 2100498 en utilisant le curl commande.

Exécutez la commande suivante pour générer une requête HTTP, qui renverra une réponse correspondant à la règle d'alerte de Suricata :

curl http://testmynids.org/uid/index.html

La curl commande affichera une réponse comme celle-ci :

Outputuid=0(root) gid=0(root) groups=0(root)

Cet exemple de données de réponse est conçu pour déclencher une alerte, en faisant semblant de renvoyer la sortie d'une commande telle que id qui pourrait s'exécuter sur un système distant compromis via un shell Web.

Vous pouvez maintenant consulter les journaux de Suricata pour une alerte correspondante. Deux journaux sont activés avec la configuration par défaut de Suricata. Le premier est en /var/log/suricata/fast.log et le second est un identifiant lisible par machine /var/log/suricata/eve.log.

Examen /var/log/suricata/fast.log

Pour rechercher une entrée de journal dans /var/log/suricata/fast.log qui correspond à votre curl demande utiliser le grep commande. En utilisant le 2100498 identifiant de règle dans la documentation de démarrage rapide, recherchez les entrées qui lui correspondent à l'aide de la commande suivante :

grep 2100498 /var/log/suricata/fast.log

Si votre demande utilisait IPv6, 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 requête utilisait IPv4, votre journal devrait contenir 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

Notez le surligné 2100498 valeur dans la sortie, qui est l'ID de signature (sid) que Suricata utilise pour identifier une règle.

Examen /var/log/suricata/eve.log

Suricata enregistre également les é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 le jq utilitaire pour lire et filtrer les entrées de ce fichier. Installer jq si vous ne l'avez pas sur votre système en utilisant ce qui suit dnf commande:

sudo dnf install jq

Une fois que tu as jq installé, vous pouvez filtrer les événements dans le journal EVE en recherchant le 2100498 signature avec la commande suivante :

jq 'select(.alert .signature_id==2100498)' /var/log/suricata/eve.json

La commande examine chaque entrée JSON et imprime celles qui ont une alert objet, avec un signature_id clé qui correspond à la 2100498 valeur 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",
. . .
}

Notez le surligné "signature_id": 2100498, ligne, qui est la clé qui jq est à la recherche. Notez également le surligné "community_id": "1:vuSfAFyy7oUq0LQC5+KNTBSuPxg=", ligne dans la sortie JSON. Cette clé est l'identifiant de flux communautaire généré que vous avez activé dans le fichier de configuration de Suricata.

Chaque alerte générera un identifiant de flux communautaire unique. D'autres outils NMS peuvent également générer le même identifiant pour permettre le recoupement d'une alerte Suricata avec la sortie d'autres outils.

Une entrée de journal correspondante dans l'un ou l'autre des fichiers journaux signifie que Suricata a inspecté avec succès le trafic réseau, l'a comparé à une règle de détection et a généré une alerte pour une analyse ou une journalisation ultérieure. Un futur didacticiel de cette série explorera comment envoyer des alertes Suricata à un système SIEM (Security Information Event Management) pour un traitement ultérieur.

Étape 7 - Gestion des alertes Suricata

Une fois que vous avez configuré et testé les alertes, vous pouvez choisir comment vous souhaitez les gérer. Pour certains cas d'utilisation, la journalisation des alertes à des fins d'audit peut suffire ; ou vous préférerez peut-être adopter une approche plus active pour bloquer le trafic des systèmes qui génèrent 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 ou vos systèmes. Vous pouvez utiliser le jq outil pour extraire des champs spécifiques d'une alerte, puis ajouter des règles UFW ou IPtables pour bloquer les demandes.

Encore une fois, cet exemple est un scénario hypothétique utilisant des données de demande et de réponse délibérément conçues. Votre connaissance des systèmes et des protocoles auxquels votre environnement doit pouvoir accéder est essentielle pour déterminer quel trafic est légitime et lequel peut être bloqué.

Conclusion

Dans ce didacticiel, vous avez installé Suricata à partir des référentiels de logiciels 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 communautaire à utiliser avec d'autres outils de sécurité. Vous avez également activé le rechargement des règles en direct 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é du trafic HTTP de test. Vous avez vérifié que Suricata pouvait détecter le 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 Suricata. Pour plus de détails sur les options de configuration que vous avez configurées dans ce didacticiel, reportez-vous au Guide de l'utilisateur de Suricata.

Maintenant que Suricata est installé et configuré, vous pouvez passer au didacticiel suivant de cette série Comprendre les signatures Suricata où vous découvrirez comment écrire vos propres règles Suricata personnalisées. Vous découvrirez différentes manières de créer des alertes, ou même de supprimer complètement le trafic, 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.