Comment utiliser psad pour détecter les tentatives d'intrusion réseau sur un VPS Ubuntu
Introduction
Être capable de détecter une activité réseau pouvant indiquer une tentative d'intrusion peut vous aider à prendre les mesures appropriées avant qu'un événement ne se produise. Des systèmes de détection d'intrusion sont disponibles pour cette raison spécifique.
Les systèmes de détection d'intrusion sont utilisés pour consigner les connexions suspectes et signaler lorsqu'il semble qu'une activité inhabituelle se déroule. Certains programmes sont utilisés uniquement comme système de notification, tandis que d'autres peuvent activement tenter de bloquer le trafic qui semble vouloir causer du tort.
L'outil psad, qui signifie Port Scan Attack Detection, est un logiciel qui surveille activement les journaux de votre pare-feu pour déterminer si un événement d'analyse ou d'attaque est en cours. Il peut alors alerter les administrateurs ou prendre des mesures actives pour dissuader la menace.
Dans ce guide, nous explorerons comment installer et configurer psad sur un VPS Ubuntu 12.04. Les procédures devraient être assez similaires sur d'autres distributions.
Installer psad
Le système de détection d'intrusion psad est disponible dans les référentiels par défaut d'Ubuntu, il peut donc être facilement acquis via apt :
sudo apt-get update sudo apt-get install psad
Afin de configurer la livraison du courrier pour alerter l'administrateur, il vous sera demandé de configurer le serveur de messagerie postfix.
Dans la plupart des cas, vous pouvez sélectionner « Site Internet », puis entrer le nom de domaine associé à votre serveur. Ce sera la partie domaine du nom utilisé dans le champ "De" dans les e-mails générés par psad.
Configurer les règles IPTables
La façon dont psad détecte l'activité sur les ports de votre serveur consiste à surveiller les journaux produits par une application de pare-feu. Ubuntu est livré avec le pare-feu iptables par défaut, mais il est complètement non configuré et ne surveille ni ne bloque rien par défaut.
Bien que vous puissiez vous contenter de taper les commandes suivantes pour simplement activer la journalisation, nous ferons une configuration plus robuste :
sudo iptables -A INPUT -j LOG sudo iptables -A FORWARD -j LOG
Si vous avez entré les règles ci-dessus, videz les règles avant de configurer afin que nous puissions repartir de zéro.
sudo iptables -F
Vous pouvez voir les règles actuelles (qui ne devraient inclure que les politiques par défaut à ce stade), en tapant :
sudo iptables -S
-P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT
Nous pouvons maintenant commencer à ajouter nos règles, principalement à la chaîne INPUT. Nous voulons dire à iptables de supprimer les connexions dont nous n'avons pas besoin ou que nous ne voulons pas. Nous devons ajouter les règles pour autoriser explicitement nos connexions autorisées avant d'ajouter des restrictions.
La première règle autorisera tout le trafic généré par notre serveur, dirigé vers notre serveur. Ce type de connexion est généralement utilisé pour que les services communiquent entre eux et se transmettent facilement des informations :
sudo iptables -A INPUT -i lo -j ACCEPT
Ensuite, nous voulons ajouter une règle pour autoriser explicitement tout le trafic lié à une connexion existante. Cela permettra à nos sessions en cours de se poursuivre sans interruption :
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Ensuite, nous pouvons ajouter les services que nous souhaitons garder ouverts au public. Pour SSH, nous pouvons ajouter une ligne comme celle-ci :
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
Si nous avons un serveur Web fonctionnant sur le port par défaut 80, nous pouvons ajouter une règle comme celle-ci :
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
Ajoutez tous les autres ports pour les services légitimes accessibles au public que vous souhaitez laisser ouverts avec la même syntaxe :
sudo iptables -A INPUT -p protocol --dport port_num -j ACCEPT
Une fois que vous avez terminé d'ajouter les services légitimes, nous supprimerons toutes les connexions restantes. Tout ce qui respecte cette règle ne correspondait pas à nos règles qui s'appliquaient au trafic légitime.
Avant de faire cela, nous devons ajouter la règle qui indique à iptables de commencer à enregistrer le trafic. Cela obligera iptables à consigner le trafic qui n'a pas encore été traité.
sudo iptables -A INPUT -j LOG
Nous devrions également ajouter cette règle à la chaîne de transfert au cas où nous finirions par transférer le trafic ailleurs.
sudo iptables -A FORWARD -j LOG
Enfin, supprimons tout le trafic superflu qui n'a pas encore trouvé de correspondance. Nous pouvons le faire en ajoutant une règle qui correspond à tout dans la chaîne jusqu'à la fin comme ceci :
sudo iptables -A INPUT -j DROP
Ou, nous pouvons utiliser la fonctionnalité de politique intégrée pour configurer ce qui se passe lorsqu'un paquet passe dans la chaîne sans correspondre à aucune règle :
sudo iptables -P INPUT DROP
Les résultats sont fonctionnellement exactement les mêmes.
Une chose à noter est que si jamais vous avez besoin de vider votre iptables et que vous mettez en place une politique DROP (au lieu de l'ajouter en règle générale en bas de la chaîne), vous devez inverser la politique avant de vider :
sudo iptables -P INPUT ACCEPT sudo iptables -F
Si vous ne le faites pas, vos règles iptables seront vidées et seule la politique par défaut consistant à supprimer tous les paquets entrants restera. Cela coupera tout le trafic réseau entrant sur votre serveur, y compris le trafic provenant de votre connexion SSH.
Par défaut, iptables ne maintient pas ses règles entre les redémarrages, donc après avoir testé votre configuration et être sûr qu'elle fait ce que vous voudriez, vous pouvez télécharger et activer un outil qui rend ces règles persistantes :
sudo apt-get install iptables-persistent sudo service iptables-persistent start
Configurer psad pour détecter les scans
Maintenant que nous avons un ensemble de règles iptables configuré avec ce que l'on appelle une politique de « suppression par défaut », nous pouvons commencer à configurer psad pour commencer à analyser les journaux.
Ouvrez le fichier de configuration principal de psad avec les privilèges root :
sudo nano /etc/psad/psad.conf
Les premières choses que vous devez modifier se trouvent en haut du fichier. Vous devez modifier le paramètre EMAIL_ADDRESSES pour qu'il corresponde aux adresses e-mail que vous souhaitez notifier lorsqu'un rapport est généré. Vous devez également modifier le HOSTNAME pour qu'il corresponde à votre domaine afin qu'il référence la bonne machine :
EMAIL_ADDRESSES [email protected], [email protected]; HOSTNAME your_domain.com;
Assurez-vous de terminer chacune de vos lignes par un point-virgule (;) pour que psad lise correctement le fichier.
Une section que vous voudrez probablement consulter est celle des déclarations de « niveaux de danger ». Ces niveaux permettent à psad de catégoriser les niveaux de menace.
Ils sont automatiquement déterminés par le nombre de paquets impliqués dans un événement, mais vous pouvez également affecter certains types de trafic à un certain niveau de danger. Les seuils par défaut pour chaque niveau à atteindre sont :
DANGER_LEVEL1 5; DANGER_LEVEL2 15; DANGER_LEVEL3 150; DANGER_LEVEL4 1500; DANGER_LEVEL5 10000;
Vous pouvez modifier ces niveaux en fonction du niveau de sensibilité que vous souhaitez que psad utilise pour les alertes.
Vous pouvez également configurer la sensibilité de psad via le paramètre PORT_RANGE_SCAN_THRESHOLD. Cela détermine le nombre de ports dans une plage qui doivent être analysés avant qu'une alerte ne soit déclenchée. Par défaut, une alerte est déclenchée après l'analyse de deux ports.
PORT_RANGE_SCAN_THRESHOLD 1;
L'une des choses les plus importantes à configurer est le paramètre IPT_SYSLOG_FILE, car il ne pointe actuellement pas vers un fichier que syslog utilise par défaut.
Modifiez ceci pour qu'il pointe vers le fichier syslog, où psad aura en fait l'occasion de consulter les journaux actifs :
IPT_SYSLOG_FILE /var/log/syslog;
Si vous utilisez certains ports pour des choses comme port knocking, vous devez dire à psad d'ignorer les tentatives sur ces ports afin de ne pas déclencher d'alertes via des activités de routine :
IGNORE_PORTS ports_or_range_to_ignore;
Vous pouvez également ignorer les messages basés sur d'autres éléments via les paramètres IGNORE_PROTOCOLS, IGNORE_INTERFACES et IGNORE_LOG_PREFIXES nommés de manière appropriée.
Si vous constatez que vous recevez trop souvent des alertes, vous pouvez définir le seuil des e-mails en ajustant le niveau à atteindre avant l'envoi d'un e-mail :
MIN_DANGER_LEVEL 1; # Controls psad logging and email alerts EMAIL_ALERT_DANGER_LEVEL 1; # Applies only for email alerts
Vous pouvez également limiter directement le nombre d'e-mails en définissant ceci :
EMAIL_LIMIT 0;
Zéro signifie qu'il n'y a pas de limite. Cette limite correspond au nombre d'e-mails pouvant être générés par des menaces à partir d'une seule adresse IP.
Pour le moment, enregistrons et fermons le fichier.
Implémenter la détection d'intrusion psad
Maintenant que nous avons une configuration psad de base en place, avec des capacités d'alerte, nous pouvons mettre en œuvre nos politiques et activer notre système.
Avant de commencer, nous devons mettre à jour les définitions de signature de psad afin qu'il puisse reconnaître correctement les types d'attaque connus. Faites-le en appelant :
sudo psad --sig-update
Cela récupérera les derniers fichiers et mettra à jour la base de données.
Maintenant, nous devons redémarrer le service pour utiliser ces mises à jour et implémenter nos modifications de configuration. Taper:
sudo service psad restart
Cela mettra en œuvre notre surveillance des journaux. Pour voir l'état actuel des événements détectés psad, tapez :
sudo service psad status
[+] psadwatchd (pid: 3737) %CPU: 0.0 %MEM: 0.0
Running since: Fri Jan 10 15:36:04 2014
[+] psad (pid: 3735) %CPU: 0.0 %MEM: 0.3
Running since: Fri Jan 10 15:36:04 2014
Command line arguments: [none specified]
Alert email address(es): [email protected]
[+] Version: psad v2.1.7
[+] Top 50 signature matches:
[NONE]
[+] Top 25 attackers:
[NONE]
[+] Top 20 scanned ports:
[NONE]
[+] iptables log prefix counters:
[NONE]
Total packet counters: tcp: 0, udp: 0, icmp: 0
[+] IP Status Detail:
[NONE]
Total scan sources: 0
Total scan destinations: 0
[+] These results are available in: /var/log/psad/status.out
Comme vous pouvez le voir, rien n'a encore été trouvé. Nous pouvons également voir que les événements détectés sont enregistrés dans des fichiers situés dans /var/log/psad/.
Effectuer un test d'analyse des ports
Depuis un autre ordinateur, nous devrions essayer de scanner les ports de notre serveur pour générer des hits sur le pare-feu. Nous pouvons le faire avec l'utilitaire nmap.
Nous ferons une analyse du port SYN tcp à partir d'une autre machine. Nous lui dirons de supposer que notre hôte est opérationnel en lui passant l'option -PN :
sudo nmap -PN -sS server_domain_or_ip
Starting Nmap 5.51 ( http://nmap.org ) at 2014-01-10 15:54 EST Nmap scan report for server_domain_or_ip Host is up (0.013s latency). Not shown: 999 filtered ports PORT STATE SERVICE 22/tcp open ssh Nmap done: 1 IP address (1 host up) scanned in 6.84 seconds
Comme vous pouvez le voir, cette analyse indique ce que j'ai configuré pour mon pare-feu. Chaque port est étiqueté comme "filtré" indiquant qu'il est protégé par un pare-feu, à l'exception du port SSH, qui est exposé.
Sur votre serveur, vous devez relancer la commande status :
sudo service psad status
Vous devriez voir une liste d'alertes beaucoup plus longue. Comme l'événement n'était qu'une analyse de 1 000 ports, il a déclenché une correspondance de signature pour de nombreuses menaces différentes. Pour une attaque plus pointue, qui se concentre sur un port ou un point d'entrée spécifique, la signature serait beaucoup plus utile.
Si vous avez configuré des alertes par e-mail, vous devriez également avoir reçu un ou deux e-mails. Si vous avez un domaine associé à l'ordinateur à partir duquel vous avez numérisé, vous devriez voir un rapport "qui est" sur le propriétaire associé à la numérisation.
Vous pouvez l'utiliser pour tenter de contacter le propriétaire de l'adresse IP ou peut-être le FAI ou le fournisseur d'hébergement.
Mettre en œuvre la prévention des intrusions
Maintenant que nous avons vérifié que nous pouvons détecter une activité essayant d'accéder à notre serveur, nous pouvons éventuellement implémenter un mécanisme de prévention où psad peut automatiquement modifier les règles iptables pour interdire les scanners.
Avant de faire cela, nous devrions jeter un œil au fichier auto_dl :
sudo nano /etc/psad/auto_dl
Ce fichier spécifie quel niveau de danger nous devrions automatiquement définir certaines adresses IP. Par exemple, si nous avons un attaquant qui essaie continuellement de sonder notre système, nous pouvons le mettre automatiquement au niveau de danger 5 :
attacker_ip 5;
D'un autre côté, vous pouvez essentiellement exempter certaines adresses IP de provoquer une réaction de psad. Nous pourrions ajouter le localhost ici et le définir sur "0" si nous n'avions pas explicitement ajouté de règle dans nos iptables.
Pour nos besoins, puisque nous allons configurer psad pour bloquer automatiquement le trafic d'une adresse IP de menace détectée, nous devons ajouter notre ordinateur personnel à cette liste afin de ne pas nous verrouiller :
local_computer_ip 0;
Enregistrez et fermez le fichier lorsque vous avez terminé.
Ouvrez à nouveau le fichier de configuration psad :
sudo nano /etc/psad/psad.conf
Recherchez le paramètre nommé ENABLE_AUTO_IDS. C'est la règle qui permet à psad de modifier notre pare-feu pour bloquer certaines adresses. Si vous voulez le faire automatiquement, vous pouvez le changer comme ceci :
ENABLE_AUTO_IDS Y;
Ensuite, nous voulons décider ce qui constitue un niveau de menace suffisamment important pour bloquer l'IP incriminée. Nous pouvons le faire en ajustant ce paramètre :
AUTO_IDS_DANGER_LEVEL 5;
Une autre option importante est le temps total de blocage en secondes :
AUTO_BLOCK_TIMEOUT 3600;
Cela les bloquera pendant une heure par défaut.
Tester la prévention des intrusions
Nous pouvons tester comment cela fonctionne en nous interdisant temporairement. Dans le même fichier de configuration, nous allons définir ces paramètres :
ENABLE_AUTOIDS Y; AUTO_IDS_DANGER_LEVEL 4; AUTO_BLOCK_TIMEOUT 60;
Cela activera la configuration automatique du pare-feu, définira le seuil au niveau de danger 4, que nous atteignons avec une analyse SYN normale, et définira le temps de blocage pendant 60 secondes.
Enregistrez et fermez le fichier.
Ouvrez le fichier auto_dl si vous avez ajouté votre adresse IP personnelle et commentez-le temporairement.
# local_computer_ip 0;
Maintenant, redémarrez psad pour lui faire relire ces fichiers :
sudo service psad restart
Depuis votre ordinateur personnel, vous pouvez relancer l'analyse que vous avez effectuée la dernière fois :
sudo nmap -PN -sS server_domain_or_ip
À ce stade, après quelques secondes, si vous êtes connecté à votre machine psad via SSH, votre connexion devrait être interrompue. Vous ne pourrez plus vous reconnecter pendant 60 secondes.
En effet, psad a pris des mesures lorsque votre analyse a atteint suffisamment de ports pour atteindre le niveau de danger 4. Il a modifié les règles iptables pour détourner le trafic vers d'autres chaînes qui bloquaient temporairement votre IP.
Une fois que vous êtes en mesure de vous reconnecter, vous pouvez voir les restes de ce détournement en consultant vos règles iptable :
sudo iptables -S
-P INPUT DROP -P FORWARD ACCEPT -P OUTPUT ACCEPT -N PSAD_BLOCK_FORWARD -N PSAD_BLOCK_INPUT -N PSAD_BLOCK_OUTPUT -A INPUT -j PSAD_BLOCK_INPUT -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -j LOG -A FORWARD -j PSAD_BLOCK_FORWARD -A FORWARD -j LOG -A OUTPUT -j PSAD_BLOCK_OUTPUT
Comme vous pouvez le voir, plus de chaînes ont été créées et toutes les entrées ont été dirigées vers l'une de ces chaînes. Pendant l'interdiction, cette chaîne aurait abandonné les tentatives de connexion pour l'IP de votre connexion domestique.
Maintenant que vous avez testé cette fonctionnalité, revenez à ce que vous souhaitez utiliser. Vous devriez probablement augmenter la durée de l'interdiction si vous prévoyez d'utiliser réellement cette fonctionnalité. De plus, vous devez rajouter les adresses IP auxquelles vous savez que vous vous connecterez :
local_computer_ip 0;
ENABLE_AUTOIDS Y; AUTO_IDS_DANGER_LEVEL 5; AUTO_BLOCK_TIMEOUT 3600;
N'oubliez pas de redémarrer psad lorsque vous avez terminé de configurer votre service pour une application réelle :
sudo service psad restart
N'oubliez pas que certains types d'attaques peuvent usurper l'adresse IP source. Cela signifie qu'un attaquant qui soupçonne que vous avez activé la fonctionnalité de blocage automatique pourrait vous amener à interdire accidentellement des sites ou des services légitimes. Soyez très prudent et pesez les coûts et les avantages de ce type de configuration.
Conclusion
En configurant correctement un outil de détection d'intrusion réseau comme psad, vous augmentez vos chances d'obtenir les avertissements nécessaires sur les menaces avant qu'un problème ne se produise réellement. Des outils comme psad peuvent vous avertir à l'avance et traiter automatiquement certaines situations.
La clé pour utiliser psad efficacement est de configurer les niveaux de danger et les alertes par e-mail de manière appropriée, puis de suivre tout problème. Cet outil, couplé à d'autres ressources de détection d'intrusion comme tripwire peut fournir une assez bonne couverture pour pouvoir détecter les tentatives d'intrusion.
