Archives par mot-clé : centreon enterprise server

Centreon Enterprise Server 2.2 : problème de droit sur la clé SSH

Encore un retour sur la dernière version de Centreon Enterprise Server, la version 2.2. Celui-ci concerne les droits sur la clé SSH. Tout d’abord un petit rappel: lors de l’utilisation de check_by_ssh pour superviser des serveurs Unix/Linux :

  1. un couple de clé SSH (sans passphrase) doit être créé sur le serveur de supervision
  2. un utilisateur doit ensuite être créé sur tous les serveurs supervisés ; généralement, cet utilisateur est dédié à la supervision (ce qui permet de contrôler finement les droits)
  3. les plugins de supervision doivent être installés sur tous les serveurs supervisés
  4. la clé SSH publique (créée en 1) doit être copiée sur tous les serveurs à superviser, dans le fichier ~/.ssh/authorized_keys de l’utilisateur (créé en 2)

Une « subtilité » : les outils SSH vérifient que les clés SSH et le authorized_keys ne peuvent pas être modifiées par n’importe qui sur un système. Cela afin d’éviter qu’un utilisateur mal intentionné ayant un compte donné sur un système puisse escalader ses droits en se connectant avec une clé SSH qu’il aurait lui-même générée. Exemple:

  • je suis utilisateur ctemple sur un système
  • je veux passer utilisateur root sur ce même système
  • je me rends compte que /root/ peut être modifié par n’importe qui (oui, je l’ai vu… plusieurs fois…)
  • je m’arrange alors pour ajouter ma clé SSH publique au fichier authorized_keys de root. Je peux le faire en modifiant les droits.
  • je fais un ssh, grâce à ma clé SSH publique je me connecte en root.

Afin d’éviter cela, le démon SSH vérifie que personne d’autre que l’utilisateur ne peut modifier:

  1. ses clés SSH
  2. son fichier authorized_keys
  3. le répertoire ~/.ssh
  4. le répertoire HOME

Sur Centreon Enterprise Server 2.2, l’utilisateur qui va se connecter aux serveurs à superviser est celui qui est utilisé par le démon de supervision, par l’ordonnanceur. Ici, l’ordonnanceur est centreon-engine et l’utilisateur est centreon-engine. Or, le HOME de l’utilisateur centreon-engine a par défaut les droits 775. Ce qui est potentiellement dangereux. Il est préférable de retirer les droits d’écritures au groupe. Pour cela, utiliser la commande:

chmod g-w /var/lib/centreon-engine

Attention : ce n’est pas une « faille de sécurité » à proprement parler. Ceci n’est dangereux que si quelqu’un a déjà un accès SSH sur le serveur de supervision, ce qui ne devrait jamais être le cas sauf pour les administrateurs de la supervision. Là, on ne se connecte jamais en SSH en tant qu’utilisateur centreon-engine sur le serveur de supervision, depuis un poste externe. Dans le cas contraire, l’accès est refusé.

Centreon Enterprise Server 2.2 : pas de supervision à l’installation

Depuis quelques mois déjà, Centreon Enterprise Server (ou CES) 2.2 est disponible au téléchargement. Il est possible que vous rencontriez un bug présent sur 30 à 40% des installations et qui génère les problèmes suivants :

  • la supervision reste désespérément vide
  • l’ajout de nouveaux services n’est pas pris en compte
  • les services ne sont pas supervisés

Vous avez beau re-généré les fichiers de configuration, redémarré cbd, centreon engine, redémarrer le serveur de supervision (mouahaha, ne faites pas ça 😉 ) la supervision est vide. Ou alors vos services ne sont pas supervisés. Que se passe-t’il? Vous êtes victimes d’un bug aléatoire. Celui-ci ne touche pas toutes les installations (30 à 40% selon mes tests). Comment le corriger (salement)?

Continuer la lecture de Centreon Enterprise Server 2.2 : pas de supervision à l’installation

Faire parvenir à un serveur Centreon-Syslog les messages d’un serveur Linux

On continue notre série d’articles sur Centreon-Syslog. Après avoir découvert Centreon-Syslog et comment supprimer les messages d’erreur générés au démarrage de RSyslog, nous allons voir comment faire parvenir les messages syslog d’un serveur Linux au serveur Centreon-Syslog. Cependant, pour éviter de saturer le réseau ou le serveur Centreon-Syslog, nous filtrerons les messages envoyés. Seuls ceux considérés comme intéressants seront envoyés. Les autres seront uniquement stockés en local. Dans cet article, je ne parle que de RSyslog et je pars du principe que Centreon-Syslog est installé et configuré par défaut sur un serveur Centreon Enterprise Server (CES) dont l’adresse IP est 192.168.0.11. Je nomme sender le serveur qui doit envoyer les messages syslog sur le serveur Centreon-Syslog.

Continuer la lecture de Faire parvenir à un serveur Centreon-Syslog les messages d’un serveur Linux

Centreon-Syslog : suppression des messages d’erreur au redémarrage de rsyslog

Suite de l’article précédent sur La découverte de Centreon-Syslog. Si vous redémarrez RSyslog, vous trouverez ces messages d’erreur dans /var/log/messages:

rsyslogd: WARNING: rsyslogd is running in compatibility mode. Automatically generated config directives may interfer with your rsyslog.conf settings. We suggest upgrading your config and adding -c3 as the first rsyslogd option.
rsyslogd: Warning: backward compatibility layer added to following directive to rsyslog.conf: ModLoad immark
rsyslogd: Warning: backward compatibility layer added to following directive to rsyslog.conf: MarkMessagePeriod 1200
rsyslogd: Warning: backward compatibility layer added to following directive to rsyslog.conf: ModLoad imuxsock

Pour supprimer ces erreurs, il faut modifier le fichier /etc/sysconfig/rsyslog et remplacer la ligne suivante:

SYSGLOD_OPTIONS="-c3"

Par:

SYSLOGD_OPTIONS="-c3"

La correction est mise en évidence en rouge. Sauvegarder le fichier et redémarrer rsyslog:

/etc/init.d/rsyslog restart

Bien entendu, j’ai prévenu le responsable de Centreon-Syslog pour qu’il corrige ce problème.

Centreon Syslog : découverte

Dans le cas d’erreurs systèmes ou de configuration, les serveurs Linux/Unix écrivent des messages dans des « logs ». Ce sont des fichiers textes contenant la date de l’erreur, sa criticité, le programme l’ayant généré et le message lui-même. C’est le fameux système syslog, généralement remplacé par ses successeurs rsyslog ou syslog-ng. Étant donné que ce sont des fichiers textes, ils sont lisibles par tous les outils systèmes comme sed/grep/awk/less/tail… L’enchaînement des commandes permet de filtrer et de rechercher le message d’erreur à une date et une heure précise et contenant le mot clé recherché. Les applications installées sur le système génèrent elles-aussi des messages d’erreur. Une bonne application doit envoyer ses messages à syslog afin qu’il les stocke dans ses fichiers.

Cependant, pour faire ces recherches, un compte administrateur est nécessaire sur le système. Admettons qu’un responsable d’application ait besoin de rechercher des messages dans les journaux, doit-il disposer d’un compte administrateur sur le serveur? Dans les services informatiques de taille moyenne, ce n’est pas problématique : les personnes installant les applications et les administrateurs sont les mêmes. Dans les services informatiques de taille plus importante, le responsable d’application n’a pas forcément les connaissances système suffisantes. Il ne doit pas avoir un compte administrateur pour éviter toute erreur de manipulation. De plus, si le serveur est partagé et pour des raisons de sécurité, ce responsable d’application ne doit pas non plus accéder à toutes les logs. La problématique est qu’il doit être suffisamment autonome pour éviter de solliciter les administrateurs systèmes… sans avoir accès à toutes les logs ni toutes les commandes systèmes. Comment lui donner un accès aux logs? La commande sudo, si bien configurée, est une première réponse. Mais elle ne sera pas simple à configurer.

Une autre solution est de centraliser la collecte de toutes les logs et de les présenter dans une application dédiée. Le mieux est encore d’intégrer cette interface directement dans l’outil de supervision. C’est possible avec Centreon et son module Centreon-Syslog. Cet article détaille l’utilisation de Centreon-Syslog. Continuer la lecture de Centreon Syslog : découverte