La vie avec OSSEC est assez facile, le produit est, d'origine, très bien paramétré. Les options fournies par défaut permettent déjà une analyse très fine des événements qui se passent dans vos machines. 
J'ai fait les tests avec : 
- un ossec serveur sur une Centos 5.5 
- un agent Windows sur une machine XP 
- un agent Linux sur une machine Debian. 
L'installation étant détaillée par ailleurs je n'y reviendrais pas, la bonne chose est que pour un petit réseau (moins de 10 machines) il n'y a pas besoin de retoucher le paramétrage. Le système est parfois un peu bavard (pas mal de mails) mais toutes les informations sont là : 
- les "login", on s'intéressera surtout aux login refusés ... 
- les fichiers modifiés (attributs, taille ....), certains fichiers sont peut-être superflus, mais on s'y habitue. 
- l'installation de logiciels est parfaitement repérée, que ce soit pas "yum update" ou "apt-get upgrade". 

Pour la partie interface Web, qui paraît un peu "spartiate au début", on peut faire rapidement un grand nombre d'interrogations ciblées : 
- y-a-t-il eu des tentatives de connexion multiples 
- Quels comptes ont été modifiés 
Les principaux critères de sélection sont (d'autres sont disponibles tels que le numéro de la règle ayant repéré l'erreur) : 
- fourchette date/heure

Note : cet article est ancien (historique presque) voir la dernière version ici. 
L'installation pour tests a été faite sur une machine Centos 5.5 virtualisée avec XEN. 
Après récupération des sources (pour moi version 2.4.1) et détarage dans un répertoire d'installation il suffit de lancer le script "install.sh" 
Après le choix de la langue (fr pour moi) un récapitulatif de votre système s'affiche 
=====================================================================

====================================================================== 
On appuye bien sûr sur entrée ... et l'on doit alors choisir l'option d'installation entre : 
serveur    serveur d'analyse OSSEC 
agent    agent transmettant à un serveur     
local    machine indépendante 
Pour cette première approche je choisis "local" 
Pour le répertoire d'installation je garde "/var/ossec". Je configure les alertes par Email et saisis une adresse mail valide en précisant le serveur de mail à utiliser (localhost) puisque j'ai un serveur Postfix local. 
Je précise ensuite que je veux démarrer le démon de controle d'intégrité et le moteur de détection de rootkit. 
=======================================================================

============================================================================= 
J'ajoute ici les adresses IP que je ne veux pas voir bannir lors des tests ... 
=============================================================================

============================================================================= 
Ensuite la compilation commence et est très courte . 
=============================================================================

============================================================================= 
Un script de démarrage "/etc/init.d/ossec" a été ajouté et activé correctement dans la machine. 
Un petit reboot pour valider le tout et ça repart, on peut au passage voir le démarrage de OSSEC. Un premier mail de lancement est aussitôt envoyé, c'est une alerte de niveau 3 (les niveaux vont de 1 à 15, 15 étant l'alerte maxi) me signalant le démarrage du démon : 
OSSEC HIDS Notification. 
2010 Jun 29 14:06:13 
Received From:machine.domaine->ossec-monitord 
Rule: 502 fired (level 3) -> "Ossec server started." 
Portion of the log(s): 
ossec: Ossec started. 
--END OF NOTIFICATION 

Je me connecte en "root" sur la machine, nouvelle alerte de niveau 4 cette fois. 
Je me connecte avec un autre utilisateur cela déclenche un nouveau mail de "first time user logged in". Une autre connexion avec le même utilisateur ne déclenche aucun mail. Tout cela semble bel et bon. 
 

Installation d'un agent sur une machine Linux, ici une distribution Debian, l'installation se fait à  partir des sources car il n'existe pas de paquet(s) Debian pour OSSEC. Les sources sont les mêmes que pour toute version Linux/Unix. 
Après détarage de l'archive on se rends dans le répertoire "ossec-hids-2.4.1" et on lance le script "install.sh". 
Je viens d'intégrer une nouvelle machine dans le système en version 2.7.1 sans aucun problème, les srcipts de comportent de manière identique. 
Après le choix de la langue (fr pour moi) un récap du système s'affiche, Entrée pour continuer : 
===================================================================

======================================================================= 
Il faut ensuite se rendre sur le serveur pour "ajouter" l'agent à  l'aide de la commande "/var/ossec/bin/manage_agents" : 
=======================================================================

=================================================================== 
On redémarre le service OSSEC sur le serveur et ... pas de message. 
Les échanges étant authentifiés il faut ensuite procéder à  l'échange de clefs qui se fait par le même outil, sur le serveur : 
=====================================================================

===================================================================== 
Sur l'agent on lance l'outil de management et on copiera la clef : 
=====================================================================

======================================================================= 
on peut alors démarrer le service sur la machine dont on vient d'installer l'agent. 
======================================================================= 
./ossec start 
Starting OSSEC HIDS v2.4.1 (by Trend Micro Inc.)... 
Started ossec-execd... 
Started ossec-agentd... 
Started ossec-logcollector... 
Started ossec-syscheckd... 
Completed. 
==========================================================================

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.

J'ai dernièrement passé la machine serveur de OSSEC de Debian 5 (Lenny) vers Debian 6 (Squeeze) et lors d'une mise à jour suivante OSSEC a refusé de démarrer avec un message "libmysqlclient_15 not found". 
J'ai vérifié la version installée, c'était la 16 qui avait désinstallé la 15. 
En attendant de tester une nouvelle version de OSSEC (2.5.1, version actuelle 2.4.1) j'ai cherché où trouver cette foutue librairie. 
Quelques recherches sur le site Debian m'ont montré que ce paquet était disponible dans "Lenny" sour le nom "libmysqlclient15off", le temps mettre la bonne ligne dans mon fichier "source.list" 
un "apt-get update" et un "apt-get install libmysqlclient15off" 
plus tard tout est OK. 
Ce paquet semble exister aussi pour Ubuntu dans certains depots "universe". 

Le prochain article sera consacré à l'upgrade de OSSEC 2.4.1 en 2.5.1 avec les problèmes pénibles (pas trop j'espère) d'une mise à niveau par un fichier "tar.gz" et donc une partie de compilation.

J'ai décidé d'upgrader mon installation de OSSEC de 2.4 en 2.6, il faut rester à la pointe du progrès. 
J'ai donc téléchargé le tar.gz de la 2.6 et je l'ai installé dans un petit coin tout propre. 
Là, dans le répertoire principal un joli petit script "install.sh" nous attends. 
Mais, d'abord sauvegardons le contenu "actuel" du logiciel : /var/ossec. 
Ensuite seulement on peut frapper le fatidique "./install.sh", Eh mais non, il faut d'abord activer l'accès Mysql. On va dans le répertoire "src" et on chante un petit truc comme "make setdb" et ... l'incantation fonctionne. Un petit "cd .." et le tentant "./install.sh" :

Il y a quelques hiéroglyphes mais je choisis bravement "fr".

La tuile, OSSEC utilise une vieille version de la librairie Mysql Client, heureusement que j'ai aussi de vieilles machines qui possèdent encore cette librairie, je copie le tout dans /usr/lib : 
lrwxrwxrwx 1 root root      24 Aug  2 23:19 libmysqlclient.so.15 -> libmysqlclient.so.15.0.0 
-rw-r--r-- 1 root root 1993916 Feb 17  2009 libmysqlclient.so.15.0.0 
lrwxrwxrwx 1 root root      26 Aug  2 23:19 libmysqlclient_r.so.15 -> libmysqlclient_r.so.15.0.0 
-rw-r--r-- 1 root root 2002908 Feb 17  2009 libmysqlclient_r.so.15.0.0 

C'est pas très beau (horrible ?) de faire ce genre de chose dans un beau système Debian bien ordonné mais un petit tour dans le fichier "Contents...." ne me montre aucune librairie en version 15 accessible dans les magasins où je me sers habituellement. Aux grands maux les grands moyens. 
Un petit "service ossec start" et aucun message d'insulte, tout est OK. 
Les processes OSSEC ont l'air "ps -ef | grep ossec" d'être là. Un petit tour par l'interface graphique pour constater que le serveur a repris contact avec ses clients préférés et que tout semble baigner dans le plus parfait bonheur. 

Au fait j'ai gardé le tar des librairies dans un magnifique répertoire de sauvegarde de vieux trucs, ça pèse quand même # 4Mo.

L'ancienne machine était très économique mais son processeur 32bits commençait à dater, par exemple les nouvelles versions de ZIMBRA ne se font plus qu'en 64bits. 
Il était donc nécessaire de passer sur une carte mère 64bits avec un Corei3 en version ECO TDP de 35W maxi dans le même boitier. Je passe l'installation (toujours Debian) pour en arriver à OSSEC en version 2.7. 
L'installation par elle même n'a pas changé, voir les chapitres précédents. 
Toutefois, pour changer un peu, je n'ai pas intégré OSSEC dans la base MYSQL de ZIMBRA mais j'ai utilisé une base PostgreSQL. 
La procédure est identique (on travaille dans les répertoires "sources" et non dans les répertoires d'installation du logiciel) :

cd mes_sources_OSSEC/src 
make setdb 
cd .. 
./install.sh

cd  répertoire_d_installation 
./bin/ossec-control enable database 

Il faut alors, comme pour MYSQL mettre en place (au début du fichier etc/ossec.conf le paramétrage de notre base PostgreSQL, par exemple en début de fichier :

<ossec_config> 
  <database_output> 
    <hostname>127.0.0.1</hostname> 
    <port>5432</port> 
    <username>mon_user_ossec</username> 
    <password>le_password_qui_tue</password> 
    <database>ma_base_ossec</database> 
    <type>postgresql</type> 
  </database_output> 
</ossec_config>

Note 2019 : La version décrite ici est ancienne et incompatible avec les version récentes (>2.9) de Ossec, il est possible d'utiliser la version décrite ici pour Ossec >= 3.0.

En installant la nouvelle version 2.7 j'ai cherché un interface Web un peu plus "sexy" que l'ancien interface d'OSSEC. En cherchant un peu je suis tombé sur AnaLogi et j'ai décidé de le tester, mais comme indiqué dans l'article précédent pas de PostgreSql avec AnaLogi. 
Note 2018, Analogi n"est plus compatible avec les versions de OSSEC >= 2.9.3,  voir ici. 
On le trouve à l'URL suivante : https://github.com/ECSC . 
L'installation est assez simple, on dézippe le machin dans un coin et on se débrouille pour que Apache soit capable de le trouver (si vous préférez Nginx cela ne devrait pas poser de problèmes). 
Ajouter dans "sites-available" le fichier "ANALOGI" contenant :

<VirtualHost 127.0.0.1:83> 
    ServerAdmin webmaster@localhost 
    ServerName  analogi.xxxx.xxx 
    Include /etc/apache2/sites-available/ANALOGI_body 
</VirtualHost> 
L'adresse en 127.0.0.1 est due à l'utilisation de "haproxy" pour aiguiller les requêtes, vous pouvez bien entendu mettre directement une adresse visible de l'extérieur.

Le fichier ANALOGI_body contient :

#       "Body" du site AnaLogi 
        DocumentRoot /opt/AnaLogi     
        <Directory /> 
                Options FollowSymLinks 
                AllowOverride None 
        </Directory> 
        <Directory /opt/AnaLogi> 
                Options Indexes FollowSymLinks MultiViews 
                AllowOverride None 
                Order allow,deny 
                allow from all 
        </Directory> 
        DirectoryIndex  index.php 
        ErrorLog /var/log/apache2/ANALOGI_error.log 
        # Possible values include: debug, info, notice, warn, error, crit, 
        # alert, emerg. 
        LogLevel warn 
        LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" personnel 
        CustomLog /var/log/apache2/ANALOGI_access.log personnel

Créer ensuite le lien adéquat de "sites-enabled" vers "sites-available" et relancer Apache.

La page d'accueil présente dès le lancement un récapitulatif des résultats : 
 
En bas les principaux "problèmes" rencontrés, ces liens sont cliquables et mènet à une page détail. 
La recherche est donc très rapide. 
La zone "Filters" permet de :

• Limiter la période,
• Effectuer une statistique par source (machine)
• Par chemin (répertoire d'origine des informations)
• Par niveau.
• Par règle.

La zone "Top Loc" donne la principale origine des messages. la zone "Rare" signale les événements un peu originaux qui peuvent être les plus intéressants. 
Les liens cliquables mènent sur une page détail qui présente une courbe en fonction du temps et le détail des alertes en partie basse. 

L'exemple affiché ici concerne des tentatives de relais de mail avec toujours le même emmerdeur qui veut envoyer un mail à "therichsheickc@yahoo.com" , la plupart des serveurs ne sont pas en relais ouvert ce genre de "truc" est donc un peu inutile.

La période d'affichage est réglée par défaut à 72 heures ce qui est beaucoup pour moi, mais il est très facile de modifier cette valeur : 
Fichier = config.php 
Ligne à modifier : "$glb_hours=72;" 
Je l'ai mis à 12 heures ce qui me semble suffisant.

En bref je suis enchanté de cet interface qui simplifie grandement la vérification des anomalies interceptées par OSSEC, à utiliser et conseiller sans modération.

Analogi fonctionne encore en version 2.8.x de OSSEC.

J'ai voulu passer à la dernière version, la 2.9 mais cela m'a posé quelques problèmes car le schéma de la base  de données est différent. Il faut donc "laisser tomber" l'ancienne base et en créer une nouvelle et perdre l'historique à moins de se lancer dans une reprise de données (qui, par ailleurs, ne semble pas trop complexe). 
J'ai installé ensuite le serveur à partir du package Debian fourni par "Atomic corp" en version 2.9.3. 
Mon interface favori (ANALOGI) ne fonctionne plus (schéma de base différent) mais j'ai trouve une version améliorée d'ANALOGI (adaptée à la 2.8) téléchargeable : https://github.com/NunesGodinho/OSSEC-WUI et je suis en train d'en tirer une version adaptée au nouveau schéma de base de données en y ajoutant quelques fonctionnalités. 
Je vais la tester sur la future version 3.0 de OSSEC ( voir les résultats ici)  avant de la diffuser, car le schéma de base de données est identique à celui présent en version 2.9.3.

Test complet de Ossec V3.0.0 stable. 
Cela va me permettre de tester la nouvelle version de l'interface OSSEC_GUI en version adaptée pour la 3.0.  
Cette version est issue de Analogi et de OSSEC_WUI,cCette nouvelle version reste compatible avec la 2.9.3 au niveau de la base de données.

Note juin 2018 : la version adaptée de l'interface est disponible, voir ici.

J'avais beaucoup apprécié l'interface Analogi qui permettait de suivre assez agréablement les événements enregistrés par OSSEC, j'avais d'ailleurs écrit un article sur ce logiciel. 
Lorsque j'ai migré mes systèmes en 2.9 cet interface agréable ne fonctionnait plus du fait de la différence de structure de la base de données. 
J'ai cherché un produit équivalent plus récent (Analogi n'est plus maintenu depuis longtemps) et j'avais trouvé une version dérivée baptisée OSSEC WUI que l'on peut trouver sur github.

Malheureusement cette version utilise le schéma de base de données antérieur. J'ai donc décidé de repartir de cette version en l'adaptant au nouveau schéma de la base. J'ai ensuite vu paraître une nouvelle version d'Ossec (version V3.0) et je me suis dépêché de la tester pour bien vérifier si le schéma de la base avait évolué. J'ai vite constaté que ce schéma était resté identique (à celui de la version 2.9.3) et je me suis penché un peu plus sur OSSEC-WUI pour l'améliorer encore et y ajouter quelques fonctions statistiques, la possibilité de détruire des rangs spécifiques et séparer la réorganisation de la base de données de l'application "Management". 
J'ai aussi pensé à une fonctionnalité nouvelle, fonctionner selon deux modes :

• Mode "running" directement à partir de la base alimentée par OSSEC, les événements une fois expliqués et/ou résolus peuvent être supprimés ce qui permet de n'avoir que peu d'alertes "actives". Rassurez vous ils ne sont pas perdus mais reportés dans une deuxième base de données.
• Mode "history" qui fonctionne à partir de la base de sauvegarde avec exactement les mêmes fonctionnalités.

Voir quelques images d'écrans.

Afin de "sécuriser" les données, surtout les données archivées, j'ai ajouté une fonction d'authentification avec trois niveaux de responsabilité :

1. Niveau lecture seule
2. Niveau "delete autorisé" sur la base "running"
3. Niveau "Admin" qui a tous les droits sur les deux modes, y compris pour la mise à jour des utilisateurs.

Note 2018/06/09 cette version baptisée "OSSEC-GUI-3.0" est disponible sur github en release V3.0.

Le projet contient toutes les doc d'installation des différentes possibilités :

• Installation "simple"
• Installation avec ou sans mode "historique"
• Mise en place possible d'une l'authentification

J'espère que les docs sont OK, sinon il est facile de signaler les problèmes dans Github.

Petit ennui : Les agents n'envoient plus rien au serveur. 
Depuis environ le 11 avril les données des clients ne sont plus reçues par la machine serveur. 
L'analyse des logs montre un message, un peu cryptique, après chaque redémarrage : 
getaddrinfo: Name or service not known 
Sans autre explication et aidé par quelques congés j'ai presque un mois pour trouver une solution ! 
En fait il m'aurait probablement suffi de porter mon attention sur la ligne suivante des logs : 
ossec-remoted(1206): ERROR: Unable to Bind port '1514' 
Qui m'aurait probablement ouvert les yeux ou au moins mis sur la piste. 
Je ne sais pas ce qu'il s'est passé aux environ du 11/04 mais "getaddrinfo" s'est mis à ne plus donner de résultat ??? alors que le DNS fonctionne parfaitement bien. 
La solution : mettre dans le fichier "/etc/hosts" une ligne avec l'adresse IP de communication avec les clients et le nom du serveur : "192.168.2.2 xxxxx xxxxx.yyy.zzz". 
C'est d'ailleurs ce que je fais en général, mais j'avais du l'oublier ici. 
Depuis OSSEC reçoit de nouveau les données des clients, la commande suivante permet de vérifier lla "bonne" ouverture du port UDP/1514 : 
lsof -Pn | grep UDP | grep :1514 
ossec-rem  9692         ossecr    4u     IPv4     41151085      0t0        UDP *:1514 
ossec-rem  9692  9694   ossecr    4u     IPv4     41151085      0t0        UDP *:1514 
..... 
Comme quoi il vaut mieux bien lire les logs en cas de problème !!!