GuiguiAbloc

Ce billet est né d’une demande de mon ami « Poupinade » qui connaissant mon goût pour les challenges divers et variés, me demanda avec fourberie innocemment comment je ferais, moi, pour intercepter des erreurs applicatives dans Nagios.

Nagios est un outil de surveillance système et réseau. Largement éprouvé, il est déployé fréquemment pour monitorer les équipements, services etc…

Pour moi, il reste un outil d’alerte et doit être utilisé comme tel. Je ne pense pas que ce soit à lui de remonter des informations détaillées sur un problème quelconque, mais de permettre au « superviseur » de débrancher sur un autre outil s’il veut peaufiner la cause de la panne/alerte (ceux qui utilisent un Nagios avec plus de 1000 hôtes et une dizaine de services par machine me comprendront aisément ).

Je ne m’étendrais pas sur Nagios ici, encore moins sur son installation et son paramétrage.

Vous trouverez de nombreuses références et tutos sur le Nain Ternet pour vous aider à sa mise en place.

La problématique qui se pose ici est de permettre d’être informer rapidement en cas d’erreur dans les logs d’une application.

Car oui on peut surveiller le bon fonctionnement du serveur httpd, de la Base de Données, du lien réseau etc… , mais il peut arriver qu’un autre problème surgisse et que Nagios ne supervise pas.

Je simplifie à l’extrême le concept « application » et prenant comme exemple une application « web », libre à vous d’adapter ce billet à autre chose.

Dans les exemples qui suivront et pour la maquette d’architecture choisie, j’ai pris un simple site en php (en l’occurrence un FlySpray ) qui me sert au suivi de mes « travaux » (a la manière d’OVH).

Les erreurs rencontrées par une « application » sont dans la majorité des cas lisibles dans un fichier de log dédié.

Première chose, faire « tomber » les erreurs php dans le log d’erreur du Vhost d’apache :

Edition du php.ini :
 
error_reporting  =  E_ALL & ~E_NOTICE
display_errors = On
 
Configuration du vhost :
 
ServerName application.guiguiabloc.fr
DocumentRoot /var/www/application
ErrorLog /var/log/apache2/application-error.log
LogLevel warn
CustomLog /var/log/apache2/application-access.log combined

Toujours a des fins de test, je simule une erreur critique, la perte de liaison avec le serveur de base de données.
En l’occurrence, j’ajoute une entrée dans le /etc/hosts du serveur httpd avec une fausse adresse IP vers le serveur Mysql, ce qui génère l’erreur suivante :

[Sun Mar 15 17:27:09 2009] [error] [client 192.168.0.2] PHP Warning:  mysqli_real_connect():
(HY000/2003): Can't connect to MySQL server on 'mysql-serveur' (113) in /var/www/application/adodb/drivers/adodb-mysqli.inc.php on line 108

Erreur je l’avoue très sournoise, Nagios me disant que mon serveur Mysql répond très bien et que le réseau entre le serveur applicatif et le serveur de base de données est opérationnel.

Comment surveiller ce genre de fichier et alerter Nagios quand quelque chose se produit ?

• SEC Simple Event Correlator

SEC est un programme écrit en Perl, extrêmement puissant et configurable à souhait, qui permet de scruter des fichiers de logs et d’y détecter des événements divers et variés.

Le site est ICI

Côté installation sur le serveur applicatif, pas de soucis :

srv-appli:/usr/local/src# wget http://prdownloads.sourceforge.net/simple-evcorr/sec-2.5.1.tar.gz
srv-appli:/usr/local/src# tar xzvf sec-2.5.1.tar.gz
srv-appli:/usr/local/src# cd sec-2.5.1
srv-appli:/usr/local/src/sec-2.5.1# mkdir /usr/local/bin/sec
srv-appli:/usr/local/src/sec-2.5.1# mkdir /usr/local/bin/sec/etc
srv-appli:/usr/local/src/sec-2.5.1# cp sec.pl /usr/local/bin/sec/

Une configuration toute simple :

srv-appli:/usr/local/bin/sec/etc# cat sec.conf
type=Single
ptype=RegExp
pattern=error
desc=$0
action=shellcmd  /opt/nagios/libexec/eventhandlers/submit_check_result_via_nsca srv-appli  'Application' 2 "$0"

Ici, nous demandons à SEC de réagir sur la chaîne « error » (bien évidemment, vous pouvez affiner vos expression régulières…) et en cas de détection, d’exécuter la commande « /opt/nagios/libexec/eventhandlers/submit_check_result_via_nsca  » avec en paramètre, le nom du host dans Nagios, le nom du service, le code retour Nagios et le message d’erreur.

Auparavant, vous avez ajouté une entrée de type « Passive » dans Nagios :

# NSCA
define service{
        use         passive_checkservice
        host_name    srv-appli
        service_description    Application
        # ici la commande check_smtp n'a aucune signification particuliere
        # c'est simplement que sans check_command cela ne marche pas !
        check_command                check_smtp
      }

Et oui, ce type de fonctionnement implique que vous utilisez NSCA sur le serveur d’application (surveillance passive de Nagios, c’est le serveur d’appli qui envoie l’alerte)

Vous devez sur votre Nagios, avoir une entrée de ce genre

Ne reste plus qu’à lancer le script SEC :

srv-appli:/# perl -w /usr/local/bin/sec/sec.pl -conf=/usr/local/bin/sec/etc/sec.conf -input=/var/log/apache2/application-error.log -log /var/log/sec.log
SEC (Simple Event Correlator) 2.5.1
Reading configuration from /usr/local/bin/sec/etc/sec.conf
1 rules loaded from /usr/local/bin/sec/etc/sec.conf
Stdin connected to terminal, SIGINT can't be used for changing the logging level

On provoque l’erreur

Executing shell command '/opt/nagios/libexec/eventhandlers/submit_check_result_via_nsca srv-appli  'Application' 2 "[Tue Mar 17 11:13:34 2009] [error] [client 192.168.99.14] PHP Warning:  mysqli_real_connect(): (HY000/2003): Can't connect to MySQL server on 'mysql-serveur' (113) in /var/www/application/adodb/drivers/adodb-mysqli.inc.php on line 108"'
Child 10131 created for command '/opt/nagios/libexec/eventhandlers/submit_check_result_via_nsca srv-appli  'Application' 2 "[Tue Mar 17 11:13:34 2009] [error] [client 192.168.99.14] PHP Warning:  mysqli_real_connect(): (HY000/2003): Can't connect to MySQL server on 'mysql-serveur' (113) in /var/www/application/adodb/drivers/adodb-mysqli.inc.php on line 108"'
1 data packet(s) sent to host successfully.

Et l’alerte remonte dans Nagios :

Alerte Nagios

Cela fonctionne mais bon…

Premier point bloquant, cela signifie que l’on utilise la surveillance Passive de Nagios (NSCA) sur le srv-appli, ce qui n’est pas forcément le cas.

Deuxième point bloquant, si une deuxième erreur surgit à la suite (pas de chance hein :-p), c’est celle ci qui sera affichée dans Nagios.
Je peux très bien acquitter l’alarme et passer à côté d’un problème plus crucial…

Pour le test :

srv-appli:/# echo « [Mon Mar 17 14:25:42 2009] [error] Une autre erreur » >> /var/log/apache2/application-error.log

Donc, obligation d’aller sur le serveur, de vérifier le /var/log/Sec.log….

Autre solution

• PRELUDE IDS

Prelude est un « Security Information Management » (SIM) Universel. Prelude collecte, normalise, catégorise, agrège, corrèle et présente tous les événements sécurité indépendamment de la marque ou de la licence du produit dont ces événements sont issus : il est « Agentless ».

Cela tombe très bien, j’avais déjà écrit un billet sur Prelude l’année dernière

http://blog.guiguiabloc.fr/index.php/2008/01/27/installer-et-configurer-prelude/

Vous ne serez pas pas dépaysé.

Pour scruter nos logs, nous allons utiliser un des modules de Prelude : Prelude-lml

Ce n’est pas le rôle premier de ce logiciel (qui est surtout un centralisateur d’alertes IDS/NIDS), mais rien nous interdit de le détourner de sa voie.

Je vous passe l’installation du module sur le serveur d’application ainsi que son enregistrement dans le Prelude Manager, tout est expliqué dans le billet précité.

srv-appli:/# prelude-adduser register prelude-lml "idmef:w admin:r" IP_Prelude_Manager --uid 1000 --gid 1000
prelude-manager:/:# prelude-adduser registration-server prelude-manager
 
... - prelude-lml registration to IP_Prelude_Manager successful

Une configuration succincte pour nos tests :

prelude-lml.conf :
 
file = /var/log/apache2/application-error.log
 
/etc/prelude-lml/ruleset/pcre.rules :
 
regex=(\[error\]);              include = appli.rules;
include = single.rules;
 
/etc/prelude-lml/ruleset/appli.rules :
 
#LOG:[Sun Mar 15 17:27:09 2009] [error] [client 192.168.0.1] PHP Warning:  mysqli_real_connect(
):
 
regex=\[error\] \[client ([\d\.]+)\] ; \
 classification.text=server error; \
 id=44100; \
 revision=1; \
 analyzer(0).name=Appli; \
 analyzer(0).manufacturer=blog.guiguiabloc.fr; \
 analyzer(0).class=Service; \
 assessment.impact.severity=high; \
 assessment.impact.completion=failed; \
 assessment.impact.type=other; \
 assessment.impact.description=Erreur applicative; \
 source(0).node.address(0).category=ipv4-addr; \
 source(0).node.address(0).address=$1; \
 source(0).service.iana_protocol_name=tcp; \
 source(0).service.iana_protocol_number=6; \
 target(0).service.iana_protocol_name=tcp; \
 target(0).service.iana_protocol_number=6; \
 last;

Je ne m’étendrais pas sur les expressions régulières, ni sur les normes IDMEF utilisées (cela prendrait un billet complet) et je vous invite à consulter ses pages :

https://trac.prelude-ids.org/wiki/PreludeLml

http://www.rfc-editor.org/rfc/rfc4765.txt

http://www.gscore.org/blog/index.php/post/2007/08/13/IDMEF-for-dummies-part-1

On reproduit de nouveau l’erreur qui maintenant est interceptée par Prelude-lml et envoyée au Manager

Report Prelude

Déjà plus classieux comme système de centralisations, non

Et là vous me dites « Et comment je le sais tout cela dans Nagios ????? »

Grâce à la communauté Nagios

http://www.nagiosexchange.org/cgi-bin/page.cgi?g=Detailed%2F2287.html;d=1

Vous y trouverez le check_prelude.pl , fonctionnant en NRPE, qui vous permet d’aller vérifier le nombre d’entrées HIGH ou MEDIUM dans la base Mysql Prelude

Nagios remontera donc une alerte Critique ou Warning que vous acquitterez (ou pas :-p) avant d’aller vous connecter sur le Prelude Manager et vérifier la teneur exacte du message d’erreur applicatif et de le supprimer dès sa résolution.

Tout ceci est bien sûr un simple exercice de style, à prendre comme une piste de travail.
Je suis certain que vous trouverez d’autres solutions à mettre en oeuvre.

Amusez vous bien

Suite de l’installation du NIDS SNORT.

Prérequis :

Vous devez disposer de Tcpdump et de Libpcap sur votre machine.

Un coup d’apt-get , Swup, Yum ou compilation a la mimine vous mettra aux normes.

La compil’ de Snort ne devrait pas vous poser de soucis.

Comme nous allons l’utiliser avec Prelude, n’oubliez pas de le passer en argument :

$ ./configure –enable-prelude –with-mysql

(bien sur, je vous passe la création de la base MySQL…)

Créer le répertoire /etc/snort/rules (s’il n’existe pas) et télécharger les règles sur le site de SNORT.

Pour info, il existe plusieur sortes de fichiers de règles pour SNORT (entendre par règle, les filtres d’analyse):

Communautaire, Certifié par SNORT, avec ou sans enregistrement, payant ou non.

Je ne peux que vous conseiller de prendre au moins les règles communautaire et celles ne nécessitant qu’un enregistrement sur le site de Snort.

Une fois récupérées, décompressez les dans /etc/snort/rules.

Pour vous aider, je vous joint mon propre fichier snort.conf.

Bien sur, modifier le à votre convenance…

snort

Il ne vous reste plus qu’à tester :

/sbin/ifconfig eth4 up
/sbin/ifconfig eth4 -arp
/usr/local/bin/snort -c /etc/snort/snort.conf -i eth4 &

Si vous décidez d’utiliser Barnyard (qui fait office de tampon entre Snort et MySQL afin de soulager votre NIDS), il vous faut créer un fichier /etc/snort/barnyard.conf (après avoir compilerBarnyard forcément )

Voici mon fichier barnyard.conf :

barnyard.conf

Et un exemple de lancement de l’ensemble :

#!/bin/bash
/sbin/ifconfig eth4 up
/sbin/ifconfig eth4 -arp
/usr/bin/snort -Dq -u snort -g snort -c /etc/snort/snort.conf -i eth4
/usr/local/bin/barnyard -c /etc/snort/barnyard.conf -g /etc/snort/gen-msg.map -s /etc/snort/sid-msg.map -d /var/log/snort -f snort.log -w /etc/snort/bylog.waldo &

Pour vous aider dans l’installation et le paramétrage, quelques sites :

http://www.trustonme.net/didactels/187.html

http://www.howtoforge.com/intrusion_detection_base_snort

Bon courage

Prelude, ou Prelude-IDS, est un système de détection d’intrusion (IDS) hybride composé de types de détecteurs hétérogènes :

• un NIDS : NetWork Intrusion Detection System ;
• un HIDS : Host based Intrusion Detection System
• un LML : Log Monitoring Lackey.

Son installation n’étant pas totalement aisée et pour aider mon ami « Argos » qui peine dessus :-p , voici une petite check-list pour vous aider.
Principe de fonctionnement

Prelude est décliné en plusieurs modules:

* libprelude : le module général, obligatoire
* libpreludedb : pour l’interconnexion avec une base de données
* prelude-manager : le serveur qui centralise les informations
* prelude-lml : module d’analyse des logs
* prelude-pflogger: module d’analyse des logs pf (*BSD)
* prewikka : le front-end prelude

Depuis la version 0.9, Prelude n’inclue plus d’IDS.

Télécharger sur http://www.prelude-ids.org/ :

libprelude-0.9.14.tar.gz prelude-lml-0.9.10.tar.gz prelude-pflogger-0.9.0-rc2.tar.gz
libpreludedb-0.9.12.tar.gz prelude-manager-0.9.8.tar.gz prewikka-0.9.11.4.tar.gz

NB: Bien évidemment, changer les numéros des version par les dernières disponibles

Les IDS :

http://la-samhna.de/samhain/samhain-current.tar.gz

http://www.snort.org/dl/current/snort-2.7.0.tar.gz (non détaillé aujourd’hui, j’expliquerais plus en détails le fonctionnement de Snort dans un autre billet)

Packages pré-requis (exemple pour Debian, a adapter à votre distribution) :

apt-get install libpcap-dev flex byacc gtk-doc-tools libssl-dev mysql-server libmysqlclient10-dev
libxml2-dev libpcre3-dev libfam-dev gnutls-bin libgcrypt11-dev libgnutls11-dev libgpg-error-dev
libopencdk8-dev libtasn1-2-dev libxmlsec1 libxmlsec1-gnutls

Attention version de libgnutls-dev en 1.0.7 minimum

Egalement python et python-dev

Installation de libprelude

libprelude-0.9.14# ./configure –enable-gtk-doc

Dumping configuration
Generate documentation : yes
Libtool dynamic loader : Convenience
Perl binding : yes
Python binding : yes

make make install

Ou sur Debian (Testing)

apt-get install libprelude2 libprelude-dev

Installation de preludedb

libpreludedb-0.9.12# ./configure

make et make install

Editer /etc/ld.so/conf et ajouter /usr/local/lib
executer : ldconfig

Mysql

mysql> create database prelude ;
Query OK, 1 row affected (0.06 sec)
mysql> GRANT ALL PRIVILEGES ON prelude.* TO prelude@’localhost’ IDENTIFIED BY ‘prelude’;
Query OK, 0 rows affected (0.05 sec)

$ mysql -u prelude prelude -p < /usr/local/share/libpreludedb/classic/mysql.sql
Enter password:

Installation de Prelude Manager

prelude-manager-0.9.8# ./configure

make et make install

Editer /usr/local/etc/prelude-manager/prelude-manager.conf

prelude-adduser add prelude-manager –uid 0 –gid 0

Installation de Prelude-lml

Sous Debian (Testing)

apt-get install prelude-lml

Enregistrer l’IDS dans le Prelude-manager

prelude-adduser register prelude-lml « idmef:w admin:r » 127.0.0.1 –uid 1000 –gid 1000

Dans un autre terminal (aka nouvelle session ssh si à distance), lancer le service Prelude-manager :

prelude-adduser registration-server prelude-manager

Répondre aux questions (il s’agit d’un échange de clés TLS pour que le plugin s’authentifie sur le Prelude-Manager)

Editer le fichier /etc/prelude-lml/prelude-lml.conf

file = /var/log/messages
file = /var/log/syslog
file = /var/log/auth.log

et

[Pcre]
ruleset=/etc/prelude-lml/ruleset/pcre.rules

Dans le répertoire ruleset, éditer le fichier pcre.rules et commenter les champs de détection inutiles.

Installation de Samhain

$ ./configure  »’–with-prelude »’
$ make
# make install
# make install-boot

Editer /etc/samhainrc :

[Log]
PreludeSeverity=crit
PreludeClass=EVENT
[Misc]
PreludeProfile=samhain

Enregistrer l’IDS dans prelude :

prelude-adduser register samhain « idmef:w » 127.0.0.1 –uid 1000 –gid 1000

Dans un autre terminal, lancer le service serveur

prelude-adduser registration-server prelude-manager

Noter le one-shot password et répondre aux questions

Enter the one-shot password provided by the « prelude-adduser » program:
enter registration one-shot password:
confirm registration one-shot password:
connecting to registration server (127.0.0.1:5553)…
Anonymous authentication to registration-server successful.
Sending certificate request.
Receiving signed certificate.
Receiving CA certificate.
samhain registration to 127.0.0.1 successful.

Initialiser la base

samhain -t init (ou samhain -t update pour la mise à jour)

Puis lancer le service

samhain -t check

Installation de Prewikka

Prérequis : Les templates Cheetah sur http://cheetahtemplate.org/

Cheetah-2.0rc8#python setup.py install

Installation de Prewikka

prewikka-0.9.11.4#python setup.py install

Création de la base Mysql

mysql> CREATE database prewikka;
Query OK, 1 row affected (0.05 sec)

mysql> GRANT ALL PRIVILEGES ON prewikka.* TO prewikka@’localhost’ IDENTIFIED BY ‘prewikka’;
Query OK, 0 rows affected (0.03 sec)

$ mysql -u prewikka prewikka -p < /usr/share/prewikka/database/mysql.sql
Enter password:

Editer le fichier /etc/prewikka/prewikka.conf

Renseigner les noms et password des bases mysql

Créér les Vhost Apache :

<VirtualHost *:80>
ServerName my.server.org
Setenv PREWIKKA_CONFIG « /etc/prewikka/prewikka.conf »
<Location « / »>
AllowOverride None
Options ExecCGI
<IfModule mod_mime.c>
AddHandler cgi-script .cgi
</IfModule>
Order allow,deny
Allow from all
</Location>
Alias /prewikka/ /usr/share/prewikka/htdocs/
ScriptAlias / /usr/share/prewikka/cgi-bin/prewikka.cgi
</VirtualHost>

En cas de problèmes python, recompiler depuis les sources :

sources/libprelude-0.9.14/bindings/python# python setup.py install

Fichier de conf des clients :

/etc/prelude/default

Dans global.conf

NodeName = toto.machine.et

Dans client.conf

server_address = ip du prelude manager

Voila un petit aide mémoire qui ne se veut nullement un Tutoriel d’installation, je ne peux que vous inviter à lire le « Handbook » sur le site de Prélude qui contient toutes les informations nécessaires pour installer et configurer votre système.