Comment configurer Suricata en tant que système de prévention des intrusions (IPS) sur Rocky Linux 8
Introduction
Dans ce didacticiel, vous apprendrez à configurer le mode IPS (Intrusion Prevention System) intégré de Suricata sur Rocky Linux 8. 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 Rocky Linux 8.
Si vous avez encore besoin d'installer Suricata, vous pouvez suivre Comment installer Suricata sur Rocky Linux 8
Vous devriez également avoir le ET Open Ruleset téléchargé à l'aide de la commande
suricata-updateet 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 commandednf:sudo dnf 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 règles, vous devez modifier le fichier /etc/suricata/suricata.yaml de Suricata pour inclure un chemin personnalisé vers vos signatures.
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 2001:DB8::1/32 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 2001:DB8::1/32 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é /var/lib/suricata/rules/local.rules. Ouvrez le fichier avec nano ou votre éditeur préféré :
sudo vi /var/lib/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 -> 2001:DB8::1/32 !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 2001:DB8::1/32 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 -> 2001:DB8::1/32 !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 -> 2001:DB8::1/32 !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 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 vi /etc/suricata/suricata.yaml
Trouvez la partie rule-files: de la configuration. Si vous utilisez vi, entrez 1879gg pour accéder à la ligne. L'emplacement exact dans votre fichier peut être différent, mais vous devez vous trouver dans la bonne région générale du fichier.
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. Assurez-vous de supprimer le commentaire # si vous prévoyez d'utiliser la signature suricata.rules dans votre configuration d'exécution finale.
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 changerez l'action par défaut pour vos signatures de alert ou log pour supprimer activement le 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 /var/lib/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 :
sudo vi /var/lib/suricata/rules/local.rules
/var/lib/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 -> 2001:DB8::1/32 !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 /var/lib/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 le fichier de configuration /etc/sysconfig/suricata de Suricata.
Ouvrez le fichier dans nano ou votre éditeur préféré :
sudo vi /etc/sysconfig/suricata
Trouvez la ligne OPTIONS="-i eth0 --user suricata" et commentez-la en ajoutant un # au début de la ligne. Ajoutez ensuite une nouvelle ligne OPTIONS="-q 0 -vvv --user suricata" qui indique à Suricata de fonctionner en mode IPS.
Votre fichier doit contenir les lignes suivantes en surbrillance lorsque vous avez terminé l'édition :
/etc/sysconfig/suricata
. . . # OPTIONS="-i eth0 --user suricata" OPTIONS="-q 0 -vvv --user suricata" . . .
Enregistrez et fermez le fichier. 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 Intrusion Detection Service
Loaded: loaded (/usr/lib/systemd/system/suricata.service; disabled; vendor preset: disabled)
Active: active (running) since Tue 2021-12-14 16:52:07 UTC; 6s ago
Docs: man:suricata(1)
Process: 44256 ExecStartPre=/bin/rm -f /var/run/suricata.pid (code=exited, status=0/SUCCESS)
Main PID: 44258 (Suricata-Main)
Tasks: 10 (limit: 11188)
Memory: 52.8M
CGroup: /system.slice/suricata.service
└─44258 /sbin/suricata -c /etc/suricata/suricata.yaml --pidfile /var/run/suricata.pid -q 0 -vvv --user suricata
. . .
Dec 14 16:52:07 suricata suricata[44258]: 14/12/2021 -- 16:52:07 - <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 ce changement, vous êtes maintenant prêt à envoyer du trafic vers Suricata en utilisant Firewalld à l'étape suivante.
Étape 4 - Configuration de Firewalld 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 Rocky Linux 8, Firewalld doit être installé et activé.
Pour ajouter les règles requises pour Suricata à Firewalld, vous devrez exécuter les commandes suivantes :
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 OUTPUT 0 -p tcp --sport 22 -j NFQUEUE --queue-bypass
Ces deux règles garantissent que le trafic SSH sur les interfaces IPv4 contournera 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.
Ajoutez les mêmes règles pour IPv6 à l'aide des commandes suivantes :
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 OUTPUT 0 -p tcp --sport 22 -j NFQUEUE --queue-bypass
Ensuite, ajoutez des règles FORWARD pour vous assurer que si votre serveur agit comme une passerelle pour d'autres systèmes, tout ce trafic ira également à Suricata pour traitement.
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
Les deux dernières règles INPUT et OUTPUT envoient tout le trafic restant qui n'est pas du trafic SSH à Suricata pour traitement.
sudo firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -j NFQUEUE sudo firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 1 -j NFQUEUE
Répétez les commandes pour le trafic IPv6 :
sudo firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 1 -j NFQUEUE sudo firewall-cmd --permanent --direct --add-rule ipv6 filter OUTPUT 1 -j NFQUEUE
Maintenant, rechargez Firewalld pour rendre les règles persistantes :
sudo firewall-cmd --reload
Remarque : Si vous utilisez un autre pare-feu comme iptables, vous devrez modifier ces règles pour qu'elles correspondent au format attendu par votre pare-feu.
À 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 /var/lib/suricata/rules/suricata.rules pour utiliser l'action drop si la signature y est incluse. Sinon, ajoutez la règle à votre fichier /var/lib/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 :
sudo jq 'select(.alert .signature_id==2100498)' /var/log/suricata/eve.json
Vous devriez recevoir une sortie comme celle-ci :
Output{
. . .
"community_id": "1:SbOgFh2T3DZvwsoyMH4xfxOoVas=",
"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.61.1",
"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é sur Rocky Linux 8. 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 pour diriger 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. .
