Page History

Contexte

Pour stocker ses données, Shinken Entreprise utilise le système de base de données MongoDB.

Par défaut, un paramètre permet de n'autoriser que les connexions à destination de sa boucle locale 127.0.0.1 ( Voir le chapitre sécurisation via le paramètre bind_ip ).

Cependant, si vous souhaitez autoriser MongoDB à écouter les requêtes à destination de ses autres interfaces locales (afin que d'autres serveurs puissent se connecter sur la base MongoDB par exemple), nous vous conseillons alors de créer des règles Iptables afin de n'autoriser uniquement ces serveurs spécifiques. ( Voir le chapitre sécurisation via iptables ).

Sécurisation via le paramètre bind_ip

• Cette page montre comment sécuriser les données de la base.
• Selon l'infrastructure, il est conseillé des stratégies de protection adaptée.
  
  

Infrastructure avec un Mongo Standalone

Infrastructure mono-serveur

S'il n'y a qu'une seule machine pour l'installation de Shinken, la configuration par défaut de la base ( disponible dans le fichier /etc/mongod.conf ) lui permet seulement d'écouter les requêtes sur l'interface locale ( localhost ).

Lors de l'installation de Shinken, MongoDB est installé et le paramétrage par défaut est dans /etc/mongod.conf.

Par défaut, le paramètre bind_ip permettant de spécifier l'interface d'écoute de MongoDB est à 127.0.0.1 :

# Listen to local interface only. Comment out to listen on all interfaces.
bind_ip=127.0.0.1

Cela implique qu'aucun autre serveur ne pourra se connecter directement à la base MongoDB

Cette sécurisation est très bonne, mais il se peut que vous ayez besoin que vos démons Shinken accèdent à la base MongoDB alors que ces derniers sont sur des serveurs distants (dans une architecture distribuée par exemple, ou encore si vous souhaitez dédier un serveur pour vos bases).

Dans ce cas, vous aurez besoin de commenter la ligne "bind_ip" ou de spécifier une interface autre que l'interface locale. Si vous faites cela, n'importe qui pourra alors passer des requêtes MongoDB à destination du serveur hébergeant les bases de données. Pour ne pas ouvrir cette faille de sécurité, il est indispensable de sécuriser vos connexions via des règles de Firewall ou des connexions SSH.

Sécurisation Via iptables

Voyons comment sécuriser vos connexions via les services "iptables" de Linux.

Activation chkconfig

Autorisation des serveurs spécifiques

, seuls les démons de la machine pourrons interroger MongoDB sur la boucle locale ( localhost ).

C'est le moyen le plus simple de sécuriser l'accès à la base.

Infrastructure multi-serveur avec une base MongoDB commune

Dans le cas, où il y a plusieurs machines sur l'infrastructure, Shinken préconise de laisser la configuration par défaut de la base ( disponible dans le fichier /etc/mongod.conf ) qui limite l'écoute à l'interface locale ( localhost ).

# Listen to local interface only. Comment out to listen on all interfaces.
bind_ip=127.0.0.1

Pour que les démons, qui ne sont pas sur la machine qui héberge le MongoDB, puissent y accéder, il est recommandé d'utiliser des tunnels SSH.

• Ce système est intégré à Shinken et la mise en place des tunnels nécessite de simplement configurer les démons et modules qui se connectent à la base et de déployer la clé SSH de Shinken sur ces machines.

Cette approche à deux avantages :

• limite l'écoute de la base à l'interface locale,
• chiffre les connexions au serveur qui héberge la base MongoDB.

Il est possible d'utiliser les clés SSH crées lors de l'installation de Shinken pour faire ces tunnels ( voir la page Création automatique et gestion de la clé SSH de l'utilisateur shinken ).

Si pour une contrainte interne, vous avez besoin de chiffrer la connexion sur la boucle local ( NON RECOMMANDÉ )

Les étapes suivantes décrivent comment activer le chiffrement SSL pour les connexions entre Shinken et la base MongoDB.

Cette opération entraînera nécessairement une  indisponibilité  de Shinken le temps de redémarrer celui-ci ainsi que de la base MongoDB.

Création des certificats pour MongoDB et pour Shinken 

Les différents certificats doivent être émis pas la même autorité de certification.

Création des certificats de l'autorité de certification

Remplacer ORGANIZATION INC. par le nom de la société du client ( éventuellement ).

/opt/shinken/openssl/bin/openssl genrsa 2048 > ca-key.pem 
/opt/shinken/openssl/bin/openssl req -new -x509 -nodes -days 365000 -key ca-key.pem -out ca-cert.pem -subj "/C=FR/L=Paris/O=ORGANIZATION INC./OU=Shinken MongoDB CA/CN=Shinken MongoDB CA"

Création du certificat de MongoDB 

Exécuter les commandes suivantes : 

• en remplaçant SERVER par le nom du serveur MongoDB tel que définis dans la configuration de Shinken (  IP, localhost, nom DNS )
• en remplaçant ORGANIZATION INC. par la valeur utilisée pour le certificat de l'autorité de certification ci-dessus.
  
  

/opt/shinken/openssl/bin/openssl req -newkey rsa:2048 -nodes -keyout SERVER-key.pem -out SERVER-req.pem -subj "/C=FR/L=Paris/O=ORGANIZATION INC./OU=Shinken MongoDB Cluster/CN=SERVER"
/opt/shinken/openssl/bin/openssl x509 -req -days 365000 -set_serial "0x`openssl rand -hex 8`"-in SERVER-req.pem -out SERVER-cert.pem -CA ca-cert.pem -CAkey ca-key.pem
cat SERVER-key.pem SERVER-cert.pem > SERVER.pem

Il faut ensuite déployer le certificat sur le serveur MongoDB en adaptant la valeur SERVER :

rsync -avP --delete /etc/shinken/certs/mongodb/  SERVER:/etc/shinken/certs/mongodb/

Création du certificat de Shinken

• Remplacer le champ subjectAltName par la liste des serveurs hébergeant au moins un des démons Shinken suivants : Synchronizer, Broker ou Scheduler ( dans le cas de la retention MongoDB ).
• • Pour ajouter une IP : "IP:IP_DU_SERVEUR"
  • Pour ajouter un nom DNS : "DNS:NOM_DU_SERVEUR"

/opt/shinken/openssl/bin/openssl req -newkey rsa:2048 -nodes -keyout shinken-key.pem -out shinken-req.pem -subj "/C=FR/L=Paris" -addext 'subjectAltName = DNS:shinken-node1, IP:shinken-node2' 
/opt/shinken/openssl/bin/openssl x509 -req -days 365000 -set_serial "0x`openssl rand -hex 8`" -in shinken-req.pem -out shinken-cert.pem -CA ca-cert.pem -CAkey ca-key.pem

cat shinken-key.pem shinken-cert.pem > shinken.pem

Ensuite, il est nécessaire de déployer le certificat sur toutes les machines hébergeant au moins un des démons Shinken suivants : Synchronizer, Broker ou Scheduler ( dans le cas de la retention MongoDB ).

Dans la commande suivante, adapter la valeur SHINKEN_SERVER :  

rsync -avP /etc/shinken/certs/mongodb/shinken.pem SHINKEN_SERVER:/etc/shinken/certs/mongodb/

Activer le chiffrement SSL dans Shinken

Pour activer le chiffrement SSL dans Shinken, il faut préciser les paramètres de connexion dans le paramètre de l'uri de Mongo. 

• Tous les composants de Shinken qui se connectent à MongoDB doivent voir leur configuration modifiée sur le serveur de l'Arbiter.

• Voici la liste des éléments qui se connectent à MongoDB et dont la configuration doit être mise à jour :
  • Le démon Synchronizer : ( voir la page Paramètres globaux ( synchronizer.cfg ) ) ;
  • Le module event-manager-reader : ( voir la page Module event-manager-reader )  ;
  • Le module event-manager-writer :  ( voir la page Module event-manager-writer  )  ;
  • Le module Graphite-Perfdata  : ( voir la page Module Graphite-Perfdata )  ;
  • Le module MongoDB : ( voir la page Module MongoDB )  ;
  • Le module  MongodbRetention : ( voir la page Module MongodbRetention ( Rétention en base de données centralisée par royaume ) )  ;
  • Le module SLA du Broker : ( voir la page Module SLA )   ;
  • Le module SLA de la WebUI : ( voir la page Module SLA ( WebUI ) )   ;
  • Le module livedata-module-sla-provider ( voir la page Module livedata-module-sla-provider )  ;
  • Le collecteur de type discovery-import ( voir la page Collecteur de type discovery-import ( Scan NMAP ) ) ;

• Dans le cas de l'utilisation de l'outil tiers Grafana, il faut aussi modifier sur la ou les machines avec un carbon-cache le fichier de configuration /opt/graphite/conf/mongodb.conf  ( voir la page Grafana - v8.3.2 ) ;

Exemple d'uri qui active le chiffrement SSL : 

mongodb_uri=mongodb://localhost:27017/?safe=false&tls=true&tlsCertificateKeyFile=/etc/shinken/certs/mongodb/shinken.pem&tlsCAFile=/etc/shinken/certs/mongodb/ca-cert.pem

Forcer le chiffrement des connexions aux mongod

• Sur le serveur avec la base MongoDB, éditer /etc/mongod.conf pour ajouter le paragraphe en adaptant la valeur SERVER : 

  Code Block
  language text theme Emacs title /etc/mongod.conf
  net: ssl: mode: preferSSL PEMKeyFile: /etc/shinken/certs/mongodb/SERVER.pem CAFile: /etc/shinken/certs/mongodb/ca-cert.pem

Redémarrage des mongo et de Shinken pour prendre en compte les modifications

Il faut dans l'ordre :

• éteindre Shinken sur tous les serveurs :

  Code Block
  language text theme Emacs
  service shinken stop

• Redémarrer tous mongodb: 

  Code Block
  language text theme Emacs
  service mongod restart

• Redémarrer Shinken sur tous les serveurs : : 

  Code Block
  language text theme Emacs
  service shinken start

Infrastructure avec un cluster MongoDB

Infrastructure multi-serveur avec un cluster MongoDB

Ce chapitre suppose d'être déjà familier avec les composants d'un cluster MongoDB ( voir la page Haute disponibilité de la base MongoDB (mise en place d'un cluster) ).

Protection entre Shinken et mongos

Connexion de Shinken au cluster sur la boucle local ( 127.0.0.1 )

Vu qu'il faut un mongos sur chaque machine qui contient un démon ou un module de Shinken qui a besoin d'un accès au cluster MongoDB, il est possible de limiter l'écoute des mongos à l'interface locale ( localhost ). 

# Listen to local interface only. Comment out to listen on all interfaces.
bind_ip=127.0.0.1

Dans ce cas, dans la configuration de Shinken, toutes les connexions à la base se feront sur l'adresse localhost.

Si pour une contrainte interne, vous avez besoin de chiffrer la connexion sur la boucle local ( NON RECOMMANDÉ )

Ce chiffrement ne présente aucun réel gain de sécurité — les communications se faisant au sein d’une même machine — et entraîne une surcharge en ressources ainsi qu’une complexité accrue.Shinken déconseille fortement l’activation du SSL dans ce contexte ( voir la page  Activer le chiffrement ( SSL ) pour les communications d'un cluster MongoDB ).

Protection entre mongos et les mongod/mongo-configsrv

Cette protection est assurée par :

• La mise en place des règles de firewall qui permettront de limiter l'accès à la base ( voir la page Haute disponibilité de la base MongoDB (mise en place d'un cluster) ).
  
• La mise en place du chiffrement des connexions ( voir la page Activer le chiffrement ( SSL ) pour les communications d'un cluster MongoDB  ).

Activer l'authentification par mot de passe à la base de données MongoDB

Quelle que soit l'architecture, il est possible d'activer l'authentification par mot de passe à la base MongoDB :  

• Dans le cas d'un seul serveur ( voir la page MongoDB - activation de l'authentification par mot de passe ).
  
• Dans le cas d'un cluster MongoDB  ( voir la page Activer l'authentification par mot de passe dans un cluster MongoDB ).

Blocage des flux réseaux

Nous bloquons maintenant explicitement toutes les connexions (entrantes et sortantes) sur le port 27017 (port par défaut de MongoDB - attention, à adapter si vous avez changer le port) :

iptables -A INPUT -p tcp -s 0.0.0.0/0 --dport 27017 -j DROP
iptables -A OUTPUT -p tcp -d 0.0.0.0/0 --sport 27017 -j DROP

Vous pouvez également bloquer tous les autres flux avec "iptables -P INPUT DROP" et "iptables -P OUTPUT DROP"  (attention tout de même aux autres applications de votre serveur qui nécessitent peut être des accès réseaux également).

Persistance de vos règles

Il s'agit maintenant de sauvegarder votre configuration afin qu'elle ne se réinitialise pas au redémarrage du serveur.

Voici la commande à utiliser :

service iptables save

Faites un essai, et redémarrer votre serveur afin de confirmer que les règles d'accès sont toujours actives.

Commandes utiles

Liste des règles :

iptables -L

Remise à zéro des règles :