Comment configurer Suricata en tant que système de prévention des intrusions (IPS) sur Debian 11

Introduction

Dans ce didacticiel, vous apprendrez à configurer le mode IPS (Intrusion Prevention System) intégré de Suricata sur Debian 11. Par défaut, Suricata est configuré pour fonctionner comme un système de détection d'intrusion (IDS), qui ne génère que des alertes et enregistre le trafic suspect. Lorsque vous activez le mode IPS, Suricata peut supprimer activement le trafic réseau suspect en plus de générer des alertes pour une analyse plus approfondie.

Avant d'activer le mode IPS, il est important de vérifier quelles signatures vous avez activées et leurs actions par défaut. Une signature mal configurée ou une signature trop large peut entraîner la suppression du trafic légitime vers votre réseau, voire vous empêcher d'accéder à vos serveurs via SSH et d'autres protocoles de gestion.

Dans la première partie de ce tutoriel, vous vérifierez les signatures que vous avez installées et activées. Vous apprendrez également à inclure vos propres signatures. Une fois que vous saurez quelles signatures vous souhaitez utiliser en mode IPS, vous convertirez leur action par défaut pour supprimer ou rejeter le trafic. Une fois vos signatures en place, vous apprendrez à envoyer du trafic réseau via Suricata à l'aide de la cible iptables netfilter NFQUEUE, puis à générer du trafic réseau non valide pour vous assurer que Suricata le supprime comme prévu.

Conditions préalables

Si vous avez suivi cette série de tutoriels, vous devriez déjà avoir Suricata en cours d'exécution sur un serveur. Si vous devez encore installer Suricata, vous pouvez suivre l'un de ces tutoriels en fonction du système d'exploitation de votre serveur :

• Comment installer Suricata sur Debian 11

• Vous devriez également avoir le ET Open Ruleset téléchargé à l'aide de la commande suricata-update et inclus dans vos signatures Suricata.

• L'outil de traitement JSON en ligne de commande jq. Si vous ne l'avez pas installé à partir d'un didacticiel précédent, vous pouvez le faire à l'aide de la commande apt :

  sudo apt update
  sudo apt install jq
  

Vous pouvez également avoir des signatures personnalisées que vous aimeriez utiliser à partir du didacticiel précédent Comprendre les signatures Suricata.

Étape 1 - Inclure des signatures personnalisées

Les didacticiels précédents de cette série ont exploré comment installer et configurer Suricata, ainsi que comment comprendre les signatures. Si vous souhaitez créer et inclure vos propres signatures, vous devez modifier le fichier /etc/suricata/suricata.yaml de Suricata pour les ajouter.

Trouvons d'abord les adresses IP publiques de votre serveur afin que vous puissiez les utiliser dans vos signatures personnalisées. Pour trouver vos IP, vous pouvez utiliser la commande ip :

ip -brief address show

Vous devriez recevoir une sortie comme celle-ci :

Outputlo               UNKNOWN        127.0.0.1/8 ::1/128 
eth0             UP             203.0.113.5/20 10.20.0.5/16 2604:a880:cad:d0::dc8:4001/64 fe80::94ad:d4ff:fef9:cee0/64 
eth1             UP             10.137.0.2/16 fe80::44a2:ebff:fe91:5187/64

Votre ou vos adresses IP publiques seront similaires aux adresses IP 203.0.113.5 et 2604:a880:cad:d0::dc8:4001/64 en surbrillance dans la sortie.

Créons maintenant la signature personnalisée suivante pour analyser le trafic SSH vers les ports non SSH et incluez-la dans un fichier appelé /etc/suricata/rules/local.rules. Ouvrez le fichier avec nano ou votre éditeur préféré :

sudo nano /etc/suricata/rules/local.rules

Copiez et collez la signature suivante :

Signature de trafic SSH non valide

alert ssh any any -> 203.0.113.5 !22 (msg:"SSH TRAFFIC on non-SSH port"; flow:to_client, not_established; classtype: misc-attack; target: dest_ip; sid:1000000;)
alert ssh any any -> 2604:a880:cad:d0::dc8:4001/64 !22 (msg:"SSH TRAFFIC on non-SSH port"; flow:to_client, not_established; classtype: misc-attack; target: dest_ip; sid:1000001;)

Remplacez l'adresse IP publique de votre serveur par les adresses 203.0.113.5 et 2604:a880:cad:d0::dc8:4001/64 dans la règle. Si vous n'utilisez pas IPv6, vous pouvez ignorer l'ajout de cette signature dans cette règle et les suivantes.

Vous pouvez continuer à ajouter des signatures personnalisées à ce fichier local.rules en fonction de votre réseau et de vos applications. Par exemple, si vous souhaitez alerter sur le trafic HTTP vers des ports non standard, vous pouvez utiliser les signatures suivantes :

Trafic HTTP sur signature de port non standard

alert http any any -> 203.0.113.5 !80 (msg:"HTTP REQUEST on non-HTTP port"; flow:to_client, not_established; classtype:misc-activity; sid:1000002;)
alert http any any -> 2604:a880:cad:d0::dc8:4001/64 !80 (msg:"HTTP REQUEST on non-HTTP port"; flow:to_client, not_established; classtype:misc-activity; sid:1000003;)

Pour ajouter une signature qui vérifie le trafic TLS vers des ports autres que le 443 par défaut pour les serveurs Web, ajoutez ce qui suit :

Trafic TLS sur signature de port non standard

alert tls any any -> 203.0.113.5 !443 (msg:"TLS TRAFFIC on non-TLS HTTP port"; flow:to_client, not_established; classtype:misc-activity; sid:1000004;)
alert tls any any -> 2604:a880:cad:d0::dc8:4001/64 !443 (msg:"TLS TRAFFIC on non-TLS HTTP port"; flow:to_client, not_established; classtype:misc-activity; sid:1000005;)

Lorsque vous avez terminé d'ajouter des signatures, enregistrez et fermez le fichier. Si vous utilisez nano, vous pouvez le faire avec CTRL+X, puis Y et ENTER pour confirmer. Si vous utilisez vi, appuyez sur ESC puis :x puis ENTER pour enregistrer et quitter.

Maintenant que vous avez défini des signatures personnalisées, modifiez le fichier de configuration /etc/suricata/suricata.yaml de Suricata à l'aide de nano ou de votre éditeur préféré pour les inclure :

sudo nano /etc/suricata/suricata.yaml

Trouvez la partie rule-files: de la configuration. Si vous utilisez nano utilisez CTRL+_ puis entrez le numéro de ligne 1879. Si vous utilisez vi, entrez 1879gg pour accéder à la ligne.

Modifiez la section et ajoutez la ligne - local.rules en surbrillance suivante :

/etc/suricata/suricata.yaml

. . .
rule-files:
  - suricata.rules
  - local.rules
. . .

Enregistrez et quittez le fichier. Assurez-vous de valider la configuration de Suricata après avoir ajouté vos règles. Pour ce faire, exécutez la commande suivante :

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

Le test peut prendre un certain temps en fonction du nombre de règles que vous avez chargées dans le fichier suricata.rules par défaut. Si vous trouvez que le test prend trop de temps, vous pouvez commenter la ligne - suricata.rules dans la configuration en ajoutant un # au début de la ligne, puis exécutez à nouveau votre test de configuration.

Une fois que vous êtes satisfait des signatures que vous avez créées ou incluses à l'aide de l'outil suricata-update, vous pouvez passer à l'étape suivante, où vous basculerez l'action par défaut pour vos signatures d'alerte ou de journalisation vers une baisse active du trafic. .

Étape 2 - Configuration des actions de signature

Maintenant que vous avez testé vos signatures personnalisées et que vous travaillez avec Suricata, vous pouvez changer l'action en drop ou reject. Lorsque Suricata fonctionne en mode IPS, ces actions bloqueront activement le trafic invalide pour toute signature correspondante.

Ces deux actions sont décrites dans le didacticiel précédent de cette série, Comprendre les signatures Suricata. Le choix de l'action à utiliser vous appartient. Une action drop rejettera immédiatement un paquet et tous les paquets suivants qui appartiennent au flux réseau. Une action reject enverra au client et au serveur un paquet de réinitialisation si le trafic est basé sur TCP, et un paquet d'erreur ICMP pour tout autre protocole.

Utilisons les règles personnalisées de la section précédente et convertissons-les pour utiliser l'action drop, car le trafic auquel elles correspondent est susceptible d'être une analyse du réseau ou une autre connexion invalide.

Ouvrez votre fichier /etc/suricata/rules/local.rules à l'aide de nano ou de votre éditeur préféré et remplacez l'action alert au début de chaque ligne du fichier par drop :

/etc/suricata/rules/local.rules

drop ssh any any -> 203.0.113.5 !22 (msg:"SSH TRAFFIC on non-SSH port"; classtype: misc-attack; target: dest_ip; sid:1000000;)
drop ssh any any -> 2604:a880:cad:d0::dc8:4001/64 !22 (msg:"SSH TRAFFIC on non-SSH port"; classtype: misc-attack; target: dest_ip; sid:1000001;)
. . .

Répétez l'étape ci-dessus pour toutes les signatures en /etc/suricata/rules/suricata.rules que vous souhaitez convertir en mode drop ou reject.

Remarque : Si vous avez exécuté suricata-update dans le didacticiel prérequis, vous pouvez avoir plus de 30 000 signatures incluses dans votre suricata.rules file.

Si vous convertissez chaque signature en drop ou reject, vous risquez de bloquer l'accès légitime à votre réseau ou à vos serveurs. Au lieu de cela, laissez les règles dans suricata.rules pour le moment et ajoutez vos signatures personnalisées à local.rules. Suricata continuera à générer des alertes pour le trafic suspect décrit par les signatures dans suricata.rules pendant son exécution en mode IPS.

Après avoir collecté quelques jours ou semaines d'alertes, vous pouvez les analyser et choisir les signatures pertinentes à convertir en drop ou reject en fonction de leur sid.

Une fois que vous avez configuré toutes les signatures avec l'action que vous souhaitez qu'elles effectuent, l'étape suivante consiste à reconfigurer puis à redémarrer Suricata en mode IPS.

Étape 3 - Activation du mode nfqueue

Suricata fonctionne en mode IDS par défaut, ce qui signifie qu'il ne bloquera pas activement le trafic réseau. Pour passer en mode IPS, vous devrez modifier les paramètres par défaut de Suricata.

Utilisez la commande systemctl edit pour créer un nouveau fichier de remplacement systemd :

sudo systemctl edit suricata.service

Ajoutez les lignes en surbrillance suivantes au début du fichier, entre les commentaires :

systemctl modifier suricata.service

### Editing /etc/systemd/system/suricata.service.d/override.conf
### Anything between here and the comment below will become the new contents of the file

[Service]
ExecStart=
ExecStart=/usr/bin/suricata -c /etc/suricata/suricata.yaml --pidfile /run/suricata.pid -q 0 -vvv
Type=simple

### Lines below this comment will be discarded
. . .

• La ligne ExecStart= efface la commande systemd par défaut qui démarre un service. La ligne suivante définit la nouvelle commande ExecStart à utiliser.
• La ligne Type=simple garantit que systemd peut gérer le processus Suricata lorsqu'il s'exécute en mode IPS.

Enregistrez et fermez le fichier. Si vous utilisez nano, vous pouvez le faire avec CTRL+X, puis Y et ENTER pour confirmer. Si vous utilisez vi, appuyez sur ESC puis :x puis ENTER pour enregistrer et quitter.

Rechargez maintenant systemd pour qu'il détecte les nouveaux paramètres de Suricata :

sudo systemctl daemon-reload

Vous pouvez maintenant redémarrer Suricata en utilisant systemctl :

sudo systemctl restart suricata.service

Vérifiez l'état de Suricata à l'aide de systemctl :

sudo systemctl status suricata.service

Vous devriez recevoir une sortie comme celle-ci :

Output● suricata.service - Suricata IDS/IDP daemon
     Loaded: loaded (/lib/systemd/system/suricata.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/suricata.service.d
             └─override.conf
     Active: active (running) since Wed 2021-12-15 14:35:21 UTC; 38s ago
       Docs: man:suricata(8)
             man:suricatasc(8)
             https://suricata-ids.org/docs/
   Main PID: 29890 (Suricata-Main)
      Tasks: 10 (limit: 2340)
     Memory: 54.9M
        CPU: 3.957s
     CGroup: /system.slice/suricata.service
             └─29890 /usr/bin/suricata -c /etc/suricata/suricata.yaml --pidfile /run/suricata.pid -q 0 -vvv

. . .
Dec 15 14:35:21 suricata suricata[29890]: 15/12/2021 -- 14:35:21 - <Notice> - all 4 packet processing threads, 4 management threads initialized, engine started

Notez la ligne active (running) en surbrillance qui indique que Suricata a redémarré avec succès.

Avec cette modification, vous êtes maintenant prêt à envoyer du trafic vers Suricata à l'aide du pare-feu UFW à l'étape suivante.

Étape 4 - Configuration d'UFW pour envoyer du trafic vers Suricata

Maintenant que vous avez configuré Suricata pour traiter le trafic en mode IPS, l'étape suivante consiste à diriger les paquets entrants vers Suricata. Si vous avez suivi les didacticiels prérequis pour cette série et que vous utilisez un système Ubuntu 20.04, le pare-feu non compliqué (UFW) doit être installé et activé par défaut.

Pour ajouter les règles requises pour Suricata à UFW, vous devrez modifier les fichiers de pare-feu dans /etc/ufw/before.rules et /etc/ufw/before6.rules directement.

Ouvrez le premier fichier en utilisant nano ou votre éditeur préféré :

sudo nano /etc/ufw/before.rules

Vers le début du fichier, insérez les lignes suivantes en surbrillance :

/etc/ufw/before.rules

. . .
# Don't delete these required lines, otherwise there will be errors
*filter
:ufw-before-input - [0:0]
:ufw-before-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-not-local - [0:0]
# End required lines

## Start Suricata NFQUEUE rules
-I INPUT 1 -p tcp --dport 22 -j NFQUEUE --queue-bypass
-I OUTPUT 1 -p tcp --sport 22 -j NFQUEUE --queue-bypass
-I FORWARD -j NFQUEUE
-I INPUT 2 -j NFQUEUE
-I OUTPUT 2 -j NFQUEUE
## End Suricata NFQUEUE rules

# allow all on loopback
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT
. . .

Enregistrez et quittez le fichier lorsque vous avez terminé de le modifier. Ajoutez maintenant les mêmes lignes à la même section dans le fichier /etc/ufw/before6.rules.

Les deux premières règles INPUT et OUTPUT sont utilisées pour contourner Suricata afin que vous puissiez vous connecter à votre serveur en utilisant SSH, même lorsque Suricata n'est pas en cours d'exécution. Sans ces règles, une signature incorrecte ou trop large pourrait bloquer votre accès SSH. De plus, si Suricata est arrêté, tout le trafic sera envoyé à la cible NFQUEUE, puis abandonné puisque Suricata n'est pas en cours d'exécution.

La règle suivante FORWARD garantit que si votre serveur agit comme une passerelle pour d'autres systèmes, tout ce trafic ira également à Suricata pour traitement.

Les deux dernières règles INPUT et OUTPUT envoient tout le trafic restant qui n'est pas du trafic SSH à Suricata pour traitement.

Redémarrez UFW pour charger les nouvelles règles :

sudo systemctl restart ufw.service

Remarque : Si vous utilisez un autre pare-feu, vous devrez modifier ces règles pour qu'elles correspondent au format attendu par votre pare-feu.

Si vous utilisez iptables, vous pouvez insérer ces règles directement à l'aide des commandes iptables et ip6tables. Cependant, vous devrez vous assurer que les règles sont persistantes lors des redémarrages avec un outil comme iptables-persistent.

Si vous utilisez firewalld, les règles suivantes dirigeront le trafic vers Suricata :

sudo firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 22 -j NFQUEUE --queue-bypass
sudo firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -j NFQUEUE
sudo firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 0 -p tcp --dport 22 -j NFQUEUE --queue-bypass
sudo firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 1 -j NFQUEUE

sudo firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 0 -j NFQUEUE
sudo firewall-cmd --permanent --direct --add-rule ipv6 filter FORWARD 0 -j NFQUEUE

sudo firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -p tcp --sport 22 -j NFQUEUE --queue-bypass
sudo firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 1 -j NFQUEUE
sudo firewall-cmd --permanent --direct --add-rule ipv6 filter OUTPUT 0 -p tcp --sport 22 -j NFQUEUE --queue-bypass
sudo firewall-cmd --permanent --direct --add-rule ipv6 filter OUTPUT 1 -j NFQUEUE

sudo firewall-cmd --reload

À ce stade du didacticiel, Suricata est configuré pour s'exécuter en mode IPS et votre trafic réseau est envoyé à Suricata par défaut. Vous pourrez redémarrer votre serveur à tout moment et vos règles Suricata et pare-feu seront persistantes.

La dernière étape de ce didacticiel consiste à vérifier que Suricata supprime correctement le trafic.

Étape 5 - Tester le trafic invalide

Maintenant que Suricata et votre pare-feu sont configurés pour traiter le trafic réseau, vous pouvez tester si Suricata supprimera les paquets correspondant à vos signatures personnalisées et autres incluses.

Rappelez la signature sid:2100498 du didacticiel précédent, qui est modifiée dans cet exemple en paquets correspondants drop :

sid:2100498

drop ip any any -> any any (msg:"GPL ATTACK_RESPONSE id check returned root"; content:"uid=0|28|root|29|"; classtype:bad-unknown; sid:2100498; rev:7; metadata:created_at 2010_09_23, updated_at 2010_09_23;)

Recherchez et modifiez la règle dans votre fichier /etc/suricata/rules/suricata.rules pour utiliser l'action drop si la signature y est incluse. Sinon, ajoutez la règle à votre fichier /etc/suricata/rules/local.rules.

Envoyez à Suricata le signal SIGUSR2 pour qu'il recharge ses signatures :

sudo kill -usr2 $(pidof suricata)

Testez maintenant la règle en utilisant curl :

curl --max-time 5 http://testmynids.org/uid/index.html

Vous devriez recevoir une erreur indiquant que la requête a expiré, ce qui indique que Suricata a bloqué la réponse HTTP :

Outputcurl: (28) Operation timed out after 5000 milliseconds with 0 out of 39 bytes received

Vous pouvez confirmer que Suricata a supprimé la réponse HTTP en utilisant jq pour examiner le fichier eve.log :

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

Vous devriez recevoir une sortie comme celle-ci :

Output{
. . .
  "community_id": "1:Z+RcUB32putNzIZ38V/kEzZbWmQ=",
  "alert": {
    "action": "blocked",
    "gid": 1,
    "signature_id": 2100498,
    "rev": 7,
    "signature": "GPL ATTACK_RESPONSE id check returned root",
    "category": "Potentially Bad Traffic",
    "severity": 2,
    "metadata": {
      "created_at": [
        "2010_09_23"
      ],
      "updated_at": [
        "2010_09_23"
      ]
    }
  },
  "http": {
    "hostname": "testmynids.org",
    "url": "/uid/index.html",
    "http_user_agent": "curl/7.68.0",
    "http_content_type": "text/html",
    "http_method": "GET",
    "protocol": "HTTP/1.1",
    "status": 200,
    "length": 39
  },
. . .

La ligne "action": "blocked" en surbrillance confirme que la signature correspond et Suricata a abandonné ou rejeté la requête HTTP de test.

Conclusion

Dans ce didacticiel, vous avez configuré Suricata pour bloquer le trafic réseau suspect à l'aide de son mode IPS intégré. Vous avez également ajouté des signatures personnalisées pour examiner et bloquer le trafic SSH, HTTP et TLS sur les ports non standard. Pour lier le tout, vous avez également ajouté des règles de pare-feu qui dirigent le trafic via Suricata pour le traitement.

Maintenant que Suricata est installé et configuré en mode IPS, et que vous pouvez écrire vos propres signatures qui alertent ou suppriment le trafic suspect, vous pouvez continuer à surveiller vos serveurs et réseaux et à affiner vos signatures.

Une fois que vous êtes satisfait de vos signatures et de votre configuration Suricata, vous pouvez continuer avec le dernier didacticiel de cette série, qui vous guidera tout au long de l'envoi de journaux de Suricata vers un système de gestion des événements de sécurité et d'information (SIEM) construit à l'aide de la pile élastique. .