OSSEC : sur un "vrai" serveur

Je n'ai pas pu tenir et disposant de quelques temps j'ai décidé de tenter l'installation de OSSEC sur mon serveur de mail.
C'est un serveur permanent (basse consommation cf ) qui supporte déjà plein de trucs, mais c'est la seule machine en fonctionnement continu et donc apte à gérer les agents à déposer dans les autres machines. Comme c'est aussi la passerelle vers Internet, elle doit être particulièrement surveillée.

Installer le logiciel serveur.
Installer le support MYSQL :
cd ..../ossec.../src
make setdb

Error: PostgreSQL client libraries not installed.

Info: Compiled with MySQL support.

Installer "libz et libz-devel" par un petit coup de "apt-get install zlib1g zlig1g-dev ".

Il ne reste plus alors qu'à lancer la procédure d'installation.

./install.sh

Qui se déroule avec un petit problème car gcc me dit méchamment qu'il ne reconnait pas le switch "-R".
Sur cette machine est installé "ZIMBRA" (Serveur mail et webmail) et ,je ne sais pas pourquoi, toutes les définitions de répertoires de librairies (par exemple : -L/usr/lib) étaient préfixés -R/usr/lib, ce qui m'a obligé à mettre un "front end" bidon pour "gcc" dont voici le script (facile !) :
=========================================================
#!/bin/bash
PARAM=`echo $* |  sed 's\ /-R/\ -L/g'`
/usr/bin/gcc $PARAM
==========================================================
C'est tout et la compilation se termine bien. On passe alors à la partie Mysql :

• Créer un utilisateur dans la base MySql, c'est facile avec mysql-admin.
• Créer le schéma de base de données,
  
• Donner les droits adéquats au user
  
• Lancer le script de création des tables :
  cd .../ossec..../src/dbd_os
  mysql --user=osssec_user --password=ossec_mot_de_passe -D nom_de_la_base <mysql.schema
  

• Ajouter dans /var/ossec/etc/ossec.conf le morceau (choisi) juste après "<ossec_config>" et avant <global> :

 <database_output>
    <hostname>localhost</hostname>
    <port>3306</port>
    <username>ossec_user</username>
    <password>ossec_mot_de_passe</password>
    <database>ossec_base</database>
    <type>mysql</type>
  </database_output>

• Surtout ne pas oublier l'incantation à "/var/ossec/bin/ossec-control enable database"   avant de lancer le service.

Installer l'interface WEB

• Décompresser l'archive dans "/var/www"
• Aller dans le répertoire "/var/www/ossec_......"  pour exécuter le script "setup.sh"
• Ne pas oublier (comme moi la première fois), d'affecter le user de lancement de Apache (www-data pour Debian) dans le groupe "ossec" (et redémarrer Apache), sinon vous n'obtiendrez que des messages d'insulte de type "access denied" ou au mieux un message "No agent available" dans l'interface alors même que le mails sont émis normalement et que tout semble baigner.
  
• Mettre en place le petit fichier de déclaration pour Apache (/etc/apache2/conf.d pour Debian, /etc/httpd/conf.d pour les redhat like) :

#
# This configuration file allows the manual to be accessed at
# http://localhost/ossec/
#
AliasMatch ^/ossec(?:/(?:de|en|fr|ja|ko|ru))?(/.*)?$ "/var/www/ossec$1"

<Directory "/var/www/ossec">
    Options Indexes
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

Tester le résultat.
Premier lancement.
C'est horrible ! Tous les messages inscrits par ZIMBRA dans "/var/log/syslog ou /var/log/messages" déclenchent un mail d'anomalie de quoi saturer rapidement une boite mail. Je stoppe donc rapidement le service OSSEC.
Après une petite réflexion un plan d'action se dessine :
Actions à réaliser :
1) modifier les paramètres de rsyslog dasn "/etc/rsyslog.conf" (utilisé par défaut sur ce serveur)

• la ligne  : *.*;auth,authpriv.none        -/var/log/syslog
  devient  :  *.*;auth,authpriv.none,mail,local0,local1    -/var/log/syslog
  

• la ligne  : mail,news.none        -/var/log/message
  devient  :      mail,news.none;\
  local0,local1;            -/var/log/messages
  

Ainsi les traces de ZIMBRA devraient être supprimées des logs "standard" et ne plus polluer les détections d'anomalies. Mais en contrepartie les actions de zimbra ne seront plus analysées.

2) Chercher un moyen d'analyser les logs de ZIMBRA.
Il faut pour cela créer un nouveau "parser" capable d'analyser les logs de Zimbra.
Heureusement Internet est là (http://www.zimbra.com/forums/administrators/39764-ossec-rules.html) et on y trouve exactement ce qu'il nous faut.
Le gars qui a écrit ces règles a l'air de savoir de quoi il parle, je lui fait donc confiance et intègre ces règles là ou il est dit de le faire.

Deuxième lancement.
C'est le pied ... les messages de Zimbra ne polluent plus les détections ... si, il reste une source de mails intempestifs, c'est l'analyse du fichier "auth.log" où les "sudo .... " de Zimbra génèrent encore une palanquée d'anomalies (deux ou trois toutes les deux minutes) il faut donc faire quelque chose car je veux pas traiter plus de 1000 messages par jour !
Là aussi un peu de réflexion et beaucoup de lecture de la doc (RTFM) permettent d'entrevoir une solution :
Modifier le comportement d'une règle standard. Cette possibilité est géniale et permet de traiter sans problème, et avec élégance,  des cas particuliers. C'est un gros plus de OSSEC par rapport à d'autres outils.
Il suffit de créer une règle (avec la plage de numérotation qui va bien (100000 à 110000) ). Je crée donc une règle "101001" qui référence la règle 5402 (if_sid) qui me cause des ennuis et ajoute une contrainte spécifique (match), si cette règle "matche" alors le niveau de l'erreur est ramené à zéro (pas d'erreur). Et ceci s'écrit :
  <rule id="101001" level="0">
    <if_sid>5402</if_sid>
    <match>COMMAND=/opt/zimbra/libexec/zmm</match>
    <description>Kill ZIMBRA SUDO </description>
  </rule>
Traduction : Si la règle 5402 est levée (les messages indiquent toujours le numéro de la règle qui les a déclenchés) et si la ligne "offensante" de log comporte la chaine "COMMAND=/opt/zimbra/libexec/zmm" alors le niveau d'erreur sera zéro.
A ajouter dans le groupe de règles dans lequel on a déjà intégré les règles "zimbra" du site mentionné au dessus.
Je ne suis pas un grand amateur de XML, mais à ce niveau là j'arrive à suivre.

On redémarre le service et on attend un peu pour voir si la modification est efficace. Après plusieurs minutes pas un seul mail à ce sujet, c'est gagné. Vite un petit test avec un autre "sudo" et ... il apparait dans la liste, c'est donc vraiment gagné.
Quelques messages générés par AMAVIS attirent mon attention, mais il ne s'agit "que" du traitement d'un mail dont l'adresse mail comporte le mot "error" !

Le stockage des données dans la base Mysql est réalisé avec un modèle de données simple qui promet une grande facilité de réalisation de requêtes ciblées. Ces requêtes sont surtout intéressantes dans un réseau important, mais ici on doit pouvoir effectuer quelques tests facilement.
L'interrogation avec "Mysql-browser" est facile car on accède immédiatement aux messages, obtenir la liste des connexions par machine et/ou par utilisateur sera super simple.

Quelques messages du firewall apparaissent, d'autres de "SNORT" : avec quelques " Destination Unreachable Communication with Destination Host is Administratively Prohibited [**][Classification: Misc activity] [Priority: 3] ".
En bref, après mes tests sur des machines virtuelles, cela marche assez bien dans le monde réel (a quelques adaptations faciles près) en promettant de pas noyer un pauvre administrateur sous un tas de fausses alertes.