NagiosQL, une interface de configuration graphique pour Nagios

février 09, 2007  |   Blog   |     |   Commentaires fermés sur NagiosQL, une interface de configuration graphique pour Nagios

Nagios ne fournit pas nativement d’interface de configuration graphique : les objets et services supervisés sont définis dans de multiples fichiers interdépendants.

Lorsque ce nombre d’objets grandit ou que l’on veut permettre au plus grande nombre de pouvoir administrer Nagios, une interface graphique devient nécessaire.

De nombreuses extensions ont été développées et on peut en trouver une liste assez conséquente ici.

Après avoir rapidement essayé Nag2web et Fruity (que j’ai renoncé à installer car PHP 5.x est un pré-requis “dur” à cause de l’utilisation des notions objets, et la migration PHP 4.x vers PHP 5.x sur une machine mutualisée n’est pas sans risque), j’ai choisi NagiosQL.

Il est possible d’importer les fichiers de configuration (si ils sont déjà au format Nagios 2.x). Ceux-ci permettent de remplir une base de données MySQL qui sera ensuite le coeur du système. L’interface graphique permet de modifier la base; ensuite les fichiers utilisés par Nagios sont générés à la volée.

L’installation de NagiosQL est simplissime, pourvu que les (modestes) pré-requis soient respectés :

  • Apache 1.3.x/2.0.x
  • PHP Version 4.1 ou plus récent
  • MySQL Version 4 ou plus récent officiellement (je n’ai eu aucun souci à l’installer sur une version 3.x)
  • Module PHP Pear HTML_Template_IT Version 1.1 (http://pear.php.net)
  • Nagios Version 2.x (1.x n’est pas supportée)

Certains inconvénients demeurent néanmoins, tels que l’absence d’une fonction de recherche.

L’avantage majeur reste la facilité avec laquelle on peut modifier la base de NagiosQL (via par exemple phpMyAdmin). On peut également noter que le développement semble s’être arrêté en 2005.
Du point de vue de la sécurité, on peut noter (au moins) un point noir :
le compte (en général nobody sous LAMP) faisant tourner le serveur HTTP doit disposer de droits étendus : permissions d’écrire les fichiers hosts,services, mais surtout miscommand.cfg, de relancer Nagios,etc.. Ceci permet donc à un utilisateur en théorie de faire tourner n’importe quel script (lire : attaque) sur une machine de supervision !

On doit donc mettre en oeuvre une batterie de mesures annexes (défense en profondeur) :

  • Publication en HTTPs
  • Renforcement du mot de passe (notamment de celui d’admin par défaut)
  • Idéalement instance Apache dédiée afin d’éviter les attaques multivecteur (compromission par des sites web/ftp vulnérables hébergés sur la même plateforme)
  • Scrutation régulière des logs
  • Filtrage des accès IP sur le serveur Web
  • Mise à jour fréquente de sécurité
  • Etc…

Les commentaires sont fermés.