L'objectif de ce document est de décrire les éléments de sécurité de chaque composant de Pandora FMS, afin que l'administrateur les connaisse et sache comment les utiliser pour mettre en œuvre une architecture plus sécurisée, conformément aux réglementations telles que PCI/DSS, ISO 27001, ENS, LOPD ou similaires. En plus d'une description spécifique des mécanismes de sécurité de chaque élément de Pandora FMS, les risques possibles et la manière de les atténuer, en utilisant les outils dont dispose Pandora FMS ou d'autres mécanismes possibles.
Ces points s'appliquent aux normes internationales telles que PCI/DSS, ISO 27001, National Security Scheme, LOPD, entre autres. Ils peuvent vous aider à réaliser une mise en œuvre sécurisée de Pandora FMS dans votre environnement.
Vulnérabilités et sauvegardes possibles
Vulnérabilités et sauvegardes possibles
Vulnérabilités et sauvegardes possibles
Vulnérabilités et sauvegardes possibles
Vulnérabilités et sauvegardes potentielles
Le durcissement (hardening) ou la sécurisation des systèmes est un point clé de la stratégie de sécurité globale d'une entreprise. En tant que fabricants, nous émettons une série de recommandations pour une installation sécurisée de tous les composants de Pandora FMS, basée sur une plateforme standard RHEL7 ou son équivalent Centos7. Ces mêmes recommandations sont valables pour tout autre système de supervision basé sur GNU/Linux.
Pour accéder au système, des utilisateurs à accès nominatif seront créés, sans privilèges et avec un accès restreint à leurs besoins. Idéalement, l'authentification de chaque utilisateur devrait être intégrée à un système de double authentification, basé sur des jetons. Des alternatives gratuites et sécurisées telles que Google Authenticator® sont disponibles et peuvent être intégrées à GNU/Linux, mais elles dépassent le cadre de ce guide. Envisagez sérieusement de les utiliser.
S'il est nécessaire de créer d'autres utilisateurs pour les applications, il doit s'agir d'utilisateurs sans accès à distance (pour ce faire, désactivez leur shell ou une méthode équivalente).
Dans le cas où certains utilisateurs doivent avoir des droits d'administrateur, la commande sudo est utilisée.
Il vous suffit d'être connecté au réseau ou de configurer votre système yum pour utiliser un serveur proxy.
Cette commande peut causer des problèmes potentiels en cas de modification des bibliothèques, des configurations, etc. Il est important de ne pas sauter la mise à niveau du système, surtout lors de la mise en production du système. Si vous vérifiez un système de production déjà actif, vous pouvez avoir besoin de mettre à jour uniquement les composants critiques, par exemple ceux qui présentent une vulnérabilité. Par exemple, si vous voulez mettre à jour uniquement mysql-server, utilisez la commande avec le nom du paquet que vous voulez mettre à jour.
yum update mysql-server
La mise à niveau du système est un processus qui doit être effectué périodiquement. En utilisant l'inventaire des paquets système, vous pouvez vérifier la présence de versions vulnérables et exécuter des mises à jour d'urgence.
Vous devez avoir le journal de sécurité /var/log/secure
actif et superviser ces journaux (logs) avec le monitoring (que nous verrons plus tard).
Par défaut, CentOS est livré avec cette option activée. Sinon, vérifiez /etc/rsyslog.conf
ou /etc/syslog.conf
.
Nous vous recommandons de prendre les logs du système d'audit et de les collecter avec un système de gestion de logs externe, Pandora FMS peut le faire facilement et il sera utile d'établir des alertes ou de les revoir de manière centralisée en cas de besoin.
Le serveur SSH vous permet de vous connecter à distance à vos systèmes GNU/Linux pour exécuter des commandes, il s'agit donc d'un point critique qui doit être sécurisé en faisant attention aux points suivants (pour ce faire, modifiez le fichier /etc/ssh/sshd_config
et redémarrez ensuite le service).
#Port22 -> Port 31122
#PermitRootLogin yes -> PermitRootLogin no
#AllowTcpForwarding yes -> AllowTcpForwarding no
#PermitTunnel no -> PermitTunnel no
/home/artica/.ssh/authorized_keys
et voyez de quelles machines vous êtes issus. Supprimez-la si vous pensez qu'il ne devrait pas y en avoir.Banner /etc/issue.net
Port d'écoute. Si le serveur MySQL doit desservir l'extérieur, vérifiez simplement que les informations d'identification de root sont sécurisées. Si MySQL ne sert qu'un élément interne, assurez-vous qu'il n'écoute que sur localhost :
netstat -an | grep 3306 | grep LIST tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN
Dans ce cas, il s'agit d'une écoute pour tous, vous devez vous en assurer. Pour ce faire, éditez le fichier /etc/my.cnf
et dans la section [mysqld]
ajoutez la ligne suivante :
bind-address = 127.0.0.1
Et vérifiez à nouveau qu'il écoute, mais maintenant seulement sur localhost après avoir redémarré le service :
netstat -an | grep 3306 | grep LIST tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN
Mot de passe MySQL
Connectez-vous à la console MySQL avec un utilisateur privilégié :
mysql –h host –u root –p
Vérifiez que le mot de passe est sécurisé et qu'on vous a demandé un mot de passe. Si ce n'est pas le cas, réglez-le avec la commande :
mysqladmin password
Cette mesure de sécurité est essentielle pour protéger vos bases de données non seulement contre les attaques extérieures, mais aussi contre les utilisations abusives par des utilisateurs internes.
ServerTokens Prod
Ajoutez la ligne ci-dessus au fichier:
/etc/httpd/conf/httpd.conf
(RHEL)./etc/apache2/conf-enabled/pandora_security.conf
(Ubuntu server)pour cacher la version du serveur web (Apache, Nginx) dans les en-têtes d'information du serveur.
Afin de sécuriser le moteur d'application sur lequel fonctionne Pandora FMS, il peut être nécessaire, dans certains environnements particulièrement sensibles à la sécurité, de sécuriser l'accès à l'application afin que les cookies de session ne soient transmis qu'en SSL.
Pour ce faire, incluez la configuration tokens suivante dans le fichier php.ini
:
session.cookie_httponly = 1 session.cookie_secure = 1
L'application ne fonctionnera pas si elle est utilisée sur HTTP (sans cryptage).
Cette technique, qui peut être très exhaustive, consiste simplement à éliminer tout ce qui n'est pas nécessaire dans le système. De cette manière, vous évitez d'éventuels problèmes à l'avenir avec des applications mal configurées dont vous n'avez pas vraiment besoin. Pour simplifier l'approche de cette pratique, considérerez uniquement les applications qui ont un port ouvert sur la machine, pour ce faire, exécutez la commande suivante :
netstat -tulpn
Il devrait retourner un résultat pour chaque port d'écoute, quelque chose de similaire à ceci, mais pas le même :
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 996/master tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 75171/httpd tcp 0 0 0.0.0.0:31122 0.0.0.0:* LISTEN 872/sshd tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 75097/mysqld tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 75171/httpd tcp 0 0 0.0.0.0:6099 0.0.0.0:* LISTEN 7721/Xvfb tcp6 0 0 :::4444 :::* LISTEN 7726/java tcp6 0 0 :::34599 :::* LISTEN 7726/java tcp6 0 0 :::6099 :::* LISTEN 7721/Xvfb
Si vous avez désactivé IPv6, vous ne devriez pas voir de lignes tcp6, à moins qu'il ne s'agisse de services qui ont été démarrés en mode ipv6 et qui ont été laissés non démarrés après avoir effectué un changement de système avec sysctl.
Vous devez étudier chaque port et connaître l'application qui se cache derrière. Dans ce cas, 443, 80 semblent provenir du service http
, mais pour en être sûr, nous allons analyser quels processus système utilisent chaque port. Pour ce faire, nous allons utiliser la commande lsof, qui devra être installée avec yum car elle n'est pas installée par défaut.
Les services qui écoutent sur localhost (127.0.0.1
) sont plus sûrs que ceux qui écoutent sur toutes les adresses IP (0.0.0.0
) et certains d'entre eux, s'ils écoutent en clair, vous devriez essayer de les sécuriser pour qu'ils n'écoutent que localhost. Dans cet exemple d'écran, cela a été fait par exemple pour MySQL (3306).
Par exemple, vous voyez que le processus principal de postfix est en cours d'exécution. Comme vous n'avez pas besoin de ce service, désinstallez-le du système :
yum remove postfix
En examinant le PID de chacun des processus en question (voir l'étape précédente), vous verrez le processus qui se trouve sur ce port :
ps aux | grep 7726 root 7726 0.1 8.5 3258724 248608 ? Sl Mar09 60:01 /usr/bin/java -jar /usr/lib/pwr/selenium-server-standalone-2.53.1.jar -host 185.247.117.28 -port 4444 -firefoxProfileTemplate /opt/firefox_profile root 79041 0.0 0.0 112716 960 pts/4 S+ 11:54 0:00 grep --color=auto 7726
Et si vous n'utilisez pas ce service, vous pouvez le supprimer.
Ce processus “ d'investigation ” des processus doit être exhaustif et répétitif dans le temps. Au moyen du système d'inventaire des processus de Pandora FMS, vous devez vérifier qu'aucun nouveau processus n'est lancé au fil du temps. Un port d'écoute dans un serveur est quelque chose de très important du point de vue de la sécurité, c'est comme une fenêtre à l'avant du bâtiment. Vous pouvez penser qu'elle est fermée et sûre, mais une fenêtre sera toujours un point d'entrée possible pour un intrus qualifié et motivé.
Il est recommandé de configurer la synchronisation horaire du système :
yum install ntpdate echo "ntpdate 0.us.pool.ntp.org"> /etc/cron.daily/ntp chmod 755 /etc/cron.daily/ntp
Le système doit avoir un agent logiciel Pandora FMS installé et lancé contre notre serveur. Pour le système d'exploitation MS Windows®, à partir de la version 761, les exécutables d'installation sont signés.
Les contrôles actifs suivants sont recommandés en plus des contrôles standard :
module_plugin grep_log_module /var/log/messages Syslog \.\* module_plugin grep_log_module /var/log/secure Secure \.\*
Une fois l'agent logiciel installé, au moins les informations suivantes doivent être définies manuellement dans l'onglet de l'agent :
Le plugin officiel permet de surveiller de manière proactive la sécurité de l'agent, à chaque exécution, presque en temps réel, en proposant des vérifications qui peuvent nous alerter de certains événements pertinents de manière proactive.
Ce plugin est destiné à fonctionner uniquement sur des machines GNU/Linux modernes. Il est prêt à fonctionner sur 64 bits et 32 bits.
Il contient une version personnalisée de John the ripper 1.8 + des correctifs Contrib avec des binaires 32 et 64 statiques. Le concept principal du plugin est d'être monolithique, de détecter ce qui peut être renforcé et d'essayer de résoudre les différences entre les distros sans rien demander à l'administrateur, de sorte que le déploiement pourrait être le même pour n'importe quel système, sans tenir compte des versions, des distros ou de l'architecture.
Ce plugin vérifiera: