| Scroll Ignore | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
|
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 votre infrastructure, nous conseillons des stratégies de protection adaptée.
| Info |
|---|
Une grande partie de la sécurisation de la base repose sur la limitation de l'écoute des requêtes sur la boucle locale ( localhost ). |
Infrastructure mono-serveur
Si vous n'avez qu'une seule machine pour votre 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 ).
| Code Block | ||||||
|---|---|---|---|---|---|---|
|
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 :
| Code Block |
|---|
# 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.
Pour des raisons d'uniformité et de sécurité, Shinken désactive par défaut la connexion vers MongoDB via une socket.
| Info |
|---|
Dans le cas de la rétention de données basé sur MongoDB, il est possible d'utiliser un tunnel SSH pour sécuriser la connexion entre les serveurs Shinken et le serveur MongoDB. Pour cela, voir la page suivante : Rétention Mongodb |
Sécurisation Via iptables
Voyons comment sécuriser vos connexions via les services "iptables" de Linux.
Activation chkconfig
Nous vous conseillons tout d'abord d'activer iptables comme service afin que ce dernier se charge dès le démarrage du serveur hébergeant MongoDB :
| Code Block |
|---|
chkconfig iptables on |
Autorisation des serveurs spécifiques
Il faut maintenant écrire nos règles de sécurisation (ACL) via les commandes iptables.
On autorise tout d'abord les connexions (entrantes et sortantes) avec les serveurs ayant comme IP x.x.x.x et y.y.y.y.y (pour notre exemple, avec port par défaut MongoDB 27017 - à adapter à votre environnement) :
| Code Block |
|---|
iptables -A INPUT -s 127.0.0.1,x.x.x.x,y.y.y.y.y -p tcp --destination-port 27017 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -d 127.0.0.1,x.x.x.x,y.y.y.y.y -p tcp --source-port 27017 -m state --state ESTABLISHED -j ACCEPT
|
| Info |
|---|
| Info : vous pouvez utiliser les notations CIDR, exemple : 10.10.10.10/24 ou 10.10.10.10/255.255.255.0 |
, 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 à votre base.
Infrastructure multi-serveur avec une base MongoDB commune
Dans le cas où vous avez plusieurs machines sur votre infrastructure, nous préconisons 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 ).
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
# 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, nous recommandons 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.
Infrastructure multi-serveur avec un cluster MongoDB
Ce chapitre suppose que vous soyez 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
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 ).
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
# 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.
| Info |
|---|
Cette configuration va provoquer une erreur dans la validation de la configuration des modules de rétention. Il faut autoriser "localhost" comme adresse valide avec l'option "mongodb_retention__database__bypass_banning_localhost_uri" de la configuration du module MongodbRetention ( voir la page Module MongodbRetention ( Rétention en base de données centralisée par royaume ) ). |
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) ).
- ( voir la page Haute disponibilité de la base MongoDB (mise en place d'un cluster) ).
- La mise en place du chiffrement des connexions.
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) :
| Code Block |
|---|
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 :
| Code Block |
|---|
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 :
| Code Block |
|---|
iptables -L |
Remise à zéro des règles :