Afin de me familiariser avec Modsec j'ai commencé par réaliser l'installation dans une VM abritant une copie des sites en exploitation. 
Une petite photo des lieux : 
VM avec Debian 9 un processeur et 1,2Go de mémoire.

Pré-requis : mod_unique_id contenu dans le paquet : libapache-session-perl qui installe en plus les 4 paquets suivants : 
libcgi-fast-perl libcgi-pm-perl libfcgi-perl

Ensuite j'ai juste ajouté le paquet libapache2-mod-security2 qui m'installe le paquet modsecurity-crs. Les premiers test sont OK et les temps de réponse semblent corrects, c'est à dire sans altération preceptible.
Lorsque j'ai tenté d'utiliser "git" pour effectuer la mise à jour des règles Owasp j'ai essuyé un échec. Le paquet est modsecurity-crs est "incorrect" car il ne permet pas la mise à jour par git du contenu du répertoire directement depuis le site OWASP ? 
J'ai donc renommé par sécurité le répertoire "incorrect" /usr/share/modsecutity-crs puis chargé le "bon" par git : 
cd /usr/share 
git clone https://github.com/SpiderLabs/owasp-modsecurity-crs.git 
Ceci m'a créé un répertoire owasp-modsecurity-crs ce qui m'a obligé à :

• - corriger le fichier /etc/apache2/mods-available/security2.conf en remplaçant  
  "IncludeOptional /usr/share/modsecurity-crs/owasp-crs.load"  
  par  
  "IncludeOptional /usr/share/owasp-modsecurity-crs/crs-setup.conf"
• - dans ce même fichier ajouter : 
  "Include /usr/share/owasp-modsecurity-crs/rules/*.conf"
• - dans le répertoire "/usr/share/owasp-modsecurity-crs" faire : 
  cp crs-setup.conf.example crs-setup.conf
• - Pour la mise à jour des règles il suffira ensuite de lancer la commande : 
  /usr/share/owasp-modsecurity-crs/util/upgrade.py --crs 
  ou, pour la mise à jour des informations "geoip" : 
  /usr/share/owasp-modsecurity-crs/util/upgrade.py --geoip 
  Attention il m'a fallu modifier le script "upgrade.py" pour remplacer : 
  "https://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz' 
  par : 
  "https://geolite.maxmind.com/download/geoip/database/GeoLite2-Country.tar.gz"

Avant activation du module :

• - vérifier que dans /etc/apache2/mods-enabled les liens existent bien, cette action a du être réalisée lors de l'installation initiale :
  •     security2.conf -> ../mods-available/security2.conf
  •     security2.load -> ../mods-available/security2.load
• Si cela n'est pas fait --> "a2enmod security2"
• - dans /etc/modsecurity
  • - copier modsecurity.conf-recommended sur modsecurity.conf
  • - activer le module dans "modsecurity.conf" : vérifier que "SecStatusEngine" est bien "on".
• - relancer apache

Le "error.log" de Apache devrait montrer l'activation de modsecurity. 
Pour mieux "voir" ce qui se passe il est intéressant de mettre la valeur de "SecDebugLogLevel" à 1. 
Par défaut seul le mode "DETECTIONONLY" est activé, il faut donc mettre "SecRuleEngine" à "On" pour activer le mode normal (celui qui bloque les vilaines requêtes ...). 
Je n'ai pas fait d'autres modifications dans ce fichier.

Pour obtenir un log en "JSON" j'ai modifié quelques lignes du fichier "/etc/modsecurity/modsecurity.conf" : 
# DEBUT 
# définitif pour ne voir que "Relevant" 
SecAuditEngine RelevantOnly 
# provisoire pour tout voir 
SecAuditEngine on 
# SecAuditLogRelevantStatus "^(?:5|4(?))" 
SecAuditLogRelevantStatus "^(?:5|4(?!04))" 
# Log everything we know about a transaction. 
# SecAuditLogParts ABDEFHIJZ 
SecAuditLogParts ABFHZ 
SecAuditLogFormat JSON 
SecAuditLogType Serial 
# FIN

Après un "systemctl restart apache2" tout semble fonctionner correctement ... mais l'analyse des fichiers de log de Modsec est assez ardue et je vais essayer de construire quelques outils facilitant la récupération, le stockage, le traitement et l'archivage de ces données. 
Depuis ce test j'ai installé Modsec sur la machine en exploitation et cela repère quelques malins qui tentent des accès douteux réalisés en HTTPS, pour le HTTP Suricata assisté de quelques règles "perso" bloque ou au moins repère la plupart des attaques. 
Le logiciel de gestion des événements générés par Modsec est en cours de réalisation commence à bien fonctionner. 
Ce petit logiciel est constitué d'un module Python qui analyse le fichier d'audit réalisé par modsecurity et inscrit les données dans une base Mysql/MariaDB. 
Quelques progammes en PHP permettent d'afficher et de classifier les événements "repérés" par notre ami modsecurity et de bloquer immédiatement les méchants" à l'aide du pare-feu. 
On peut aussi les "dénoncer", par exemple sur Abuseipdb (AbuseIPDB), pour limiter leur nuisance et intégrer ces IP dans un firewall pour leur bloquer l'accès aux applications maison.

Après quelques semaines beaucoup d'anomalies ont été interceptées par Modsec, voici un petit tableau statistique des résultats sur le port 443 : 
 
On voit que la majorité des détections sont dues à des "scanners de sites" ou à des "bad bots" qui cherchent inlassablement de nouveaux sites. Un certain nombre de ces "Bad bots" réalisent probablement des actions de reconnaissances pour action ultérieure. 
Remarque : la partie "pirates" ne concerne que le HTTPS, la plupart des attaques exécutées en HTTP sont stoppées par Suricata dans lequel j'ai ajouté un fichier de règles lorsque je rencontre des tentatives non détectées, par exemple il existe des "tests" non détectés au milieu d'une attaque plus vaste. Il est bon d'ajouter la description de ces événements dans une règle Suricata. Ces règles sont souvent plus faciles à écrire que les règles de Modsecurity mais ne peuvent détecter des attaques en HTTPS.

Mise à jour juillet 2016 pour la version 3 (3.0.1 pour être précis). 
Il faut maintenant installer des choses sérieuses : "make", "wget" et "git" si ce n'est déjà fait ainsi que la triplette "mysql-client","mysql-server" ainsi que "libmysqld-dev" , je fonctionne actuellement avec MariaDB. 
J'ai créé un utilisateur "suricata" avec un mot de passe du même métal pour faire tourner le tout sans droits "root". 
Ensuite télécharger le tar.gz (1.4.1 lors des premiers tests 3.0.1 à ce jour) dans un répertoire tranquille : 
wget http://www.openinfosecfoundation.org/download/suricata-3.0.1.tar.gz ou plus récent visible sur https://oisf.net/ 
suivi d'un : tar -xvf suricata-3.0.1.tar.gz 
Il faut charger quelques dépendances spécifiques :

• pkg-config
• libpcap-dev
• libpcre3-dev
• libyaml-dev
• libnet1-dev
• libcap-ng-dev
• libmagic-dev
• libhtp-dev
• zlib1g-dev
• libjansson4  libjansson-dev
• libnfnetlink0 libnfnetlink-dev
• libnetfilter-queue-1 libnetfilter-queue-dev

Un apt-get install de toute la liste suffit. 
Ensuite le "./configure" magique permet de commencer le travail et le récap en fin d'exécution permet de vérifier si toutes les options nous conviennent :

Suricata Configuration:    AF_PACKET support:                       yes    PF_RING support:                         no    NFQueue support:                         no    IPFW support:                            no    DAG enabled:                             no    Napatech enabled:                        no    Unix socket enabled:                     no    libnss support:                          no    libnspr support:                         no    libjansson support:                      no    Prelude support:                         no    PCRE jit:                                no    libluajit:                               no    libgeoip:                                no    Non-bundled htp:                         no    Old barnyard2 support:                   no    CUDA enabled:                            no    Suricatasc install:                      yes    Unit tests enabled:                      no    Debug output enabled:                    no    Debug validation enabled:                no    Profiling enabled:                       no    Profiling locks enabled:                 no  Generic build parameters:    Installation prefix (--prefix):          /usr/local    Configuration directory (--sysconfdir):  /usr/local/etc/suricata/    Log directory (--localstatedir) :        /usr/local/var/log/suricata/    Host:                                    i686-pc-linux-gnu    GCC binary:                              gcc    GCC Protect enabled:                     no    GCC march native enabled:                yes    GCC Profile enabled:                     no  To build and install run 'make' and 'make install'.  You can run 'make install-conf' if you want to install initial configuration  files to /usr/local/etc/suricata/. Running 'make install-full' will install configuration  and rules and provide you a ready-to-run suricata.  To install Suricata into /usr/bin/suricata, have the config in  /etc/suricata and use /var/log/suricata as log dir, use:  ./configure --prefix=/usr/ --sysconfdir=/etc/ --localstatedir=/var/

Pour plus de sécurité (isolation dans un répertoire spécifique) je vais lancer la configuration avec les options suivantes : 
./configure --prefix=/opt/suricata \ 
            --sysconfdir=/opt/suricata/ \ 
            --localstatedir=/opt/suricata/ 
Le log final contient :

Generic build parameters:    Installation prefix (--prefix):          /opt/suricata    Configuration directory (--sysconfdir):  /opt/suricata/suricata/    Log directory (--localstatedir) :        /opt/suricata/log/suricata/

Ce n'est pas tout à fait ce que je voulais et je corrige "un peu" le Makefile (aux environs de la ligne 245) pour obtenir un "arbre" de répertoires sous /opt/suricata :

e_localstatedir = /opt/suricata/run  e_logdir = /opt/suricata/log  e_logfilesdir = /opt/suricata/log/files  e_magic_file = /usr/share/file/magic  e_rundir = /opt/suricata/run/  e_sysconfdir = /opt/suricata/etc  e_sysconfrulesdir = /opt/suricata/etc/rules

Je lance enfin le "make" qui se déroule sans ennuis ... de même pour le "make install" ... qui m'installe un arbre de répertoires "convenable", enfin qui me convient, "make install-conf" installe la config de base puis "make install-full"  télécharge et installe un jeu de règles standard. 
Image de mon arbre de répertoires :

drwxrwsr-x  9 root suricata 4096 2013-05-06 14:39 .  drwxrwsr-x 18 root staff    4096 2013-05-06 13:40 ..  drwxr-xr-x  2 root suricata 4096 2013-05-07 16:29 bin  drwxr-xr-x  3 root suricata 4096 2013-05-07 17:09 etc  drwxr-xr-x  3 root suricata 4096 2013-05-06 14:37 include  drwxr-xr-x  4 root suricata 4096 2013-05-06 15:10 lib  drwxrwxr-x  3 root suricata 4096 2013-05-07 17:14 log  drwxrwxr-x  2 root suricata 4096 2013-05-07 16:07 run  drwxr-sr-x  3 root suricata 4096 2013-05-06 14:37 share

J'ai donné au user "suricata" les droits "group" sur l'ensemble des répertoires de /opt/suricata et les droits d'écriture sur les répertoires "log" et "run". 
Il faut ensuite réaliser un script de démarrage car je n'en ai pas trouvé de disponible (mon exemplaire est disponible par le lien en bas de page). 
Il faut ensuite légèrement modifier le fichier "etc/suricata.yaml" pour l'adapter à la structure de mes répertoires. J'ai désactivé l'option "fast log" qui consomme trop d'espace pour mes besoins de test sur un portable. J'ai aussi réduit la fréquence de stockage des statistiques à 30 minutes. 
Après le lancement du produit on peut constater l'arrivée de quelques alertes ... mais elles sont au format "Unified2" et donc illisibles il faut utiliser un interface pour les rendre compréhensibles. Le projet conseille "Barnyard2" qui les enregistre dans une base de données (ici Mysql) et que je vais essayer au prochain épisode. 
Le paramétrage du fichier de configuration est très bien expliqué (au moins pour les options "courantes") dans le fichier suricata.yaml. 
Vous trouverez ces fichiers en attachement, mes quelques modifications du fichier YAML sont précédées d'un commentaire #JPP.

• Télécharger le script : init_suricata (en mode IPS)
• Télécharger le fichier paramètres : suricata.yaml

Une petite statistique (sur 30 jours 26/11/2018 au 26/12/2018) sur les événements "bloqués" par Suricata : 
 
La grande majorité des rejets (j'utilise "drop" pour la plupart des événements) sont dus à des attaques sur le site WEB, Ces attaques sont, en général, le fait de "script-kiddies" utilisant des outils en kit, en effet on retrouve très souvent les mêmes motifs dans les URL testées. Il y a aussi des attaques ciblées visant un défaut qui vient d'être divulgué, il en existe un actuellement sur /wp-login.php qui revient très souvent depuis début décembre. 
Note 2021 : les accès sur /wp-login.php existent toujours, j'en voit passer plusieurs par jour, tant en HTTPS qu'en HTTP.

Ceci semble prouver qu'une mise à jour régulière des logiciels est importante, je trouve régulièrement référence à des "exploits" adaptés à des versions antérieures à celles installées dans mes systèmes. 
Les attaques sur SMTP sont le plus souvent le fait de spammeurs recherchant des serveurs "open relay", en existe-t-il encore ?

Une nouvelle version (2.0) de Suricata "chauffait" depuis quelques temps et je l'ai chargée et compilée sans aucune nouvelle dépendance. 
Le 25 juin 2014 sortie de la version 2.0.2 : téléchargeable ici. (obsolete en 2017) 
Le 23 septembre 2014 sortie de la version 2.0.4 : téléchargeable ici. (obsolete en 2017) 
La version 2.0.4 se compile et s'exécute comme la version 2.0.2 (même paramétrage). 
A titre indicatif je "configure" avec le script suivant avant de lancer le "make" fatidique : 
#!/bin/bash 
PFX='--prefix=/opt/suricata/ ' 
CFG='--sysconfdir /opt/suricata/etc/ ' 
LOC='--localstatedir=/opt/suricata/var ' 
OPTIONS='--enable-gccprotect --enable-geoip --enable-nfqueue --enable-unix-socket' 
./configure $PFX $CFG $LOC $OPTIONS 2>&1 | tee LOG_CONFIGURE

Les options permettent d'utiliser des filtres "géographiques" et d'utiliser le mode IPS (utilisation de NFQUEUE). 

A première vue le paramétrage existant en 1.4 est parfaitement fonctionnel et le système tourne normalement. Il semble qu'une légère amélioration de performance soit présente, mais cela n'est pas transcendant et de toutes façons je suis limité par la liaison internet sur laquelle le maximum théorique #8Mo/s est atteint régulièrement.

Le fonctionnement en IPS est parfait et la mise en place de quelques "drop" permet de se débarrasser de quelques accès intempestifs. Le seul "manque" est que les "drops" ne laissent pas une trace spécifique dans l'interface de visualisation. De même le fichier "drop.log" ne contient aucune référence à la règle ayant provoqué le rejet et n'est pas affecté à un niveau de danger particulier ce qui est un peu dommage.

Il faut maintenant étudier la doc pour profiter des nouvelles fonctionnalités.

La version 3.0 est, au point de vue de la compilation de de l'utilisation peu différente de la version 2, j'ai mis à jour la page correspondant à l'installation. 
Actuellement Suricata est "en exploitation" chez moi et tourne sur la machine servant de pont vers Internet. 
Le fonctionnement est effectué en mode IPS et permet de bloquer quelques empêcheurs de surfer en rond et de repérer les tentatives d'accès du style "phpmyadmin" ... et d'autres. Au moment de Heartbleed un grand nombre de tentatives d'exploitation étaient visibles. 
La machine dispose de deux interfaces "BR0" (vers le modem) "BR1" vers le réseau interne, les autres machines du réseau accèdent toutes à Internet à travers un switch raccordé à "BR1". Suricata est utilisé en entrée et en sortie, tout est filtré ! 
Snorby permet de consulter l'historique des alertes et permet

• d'éliminer les  faux positifs,
• de repérer les tentatives d'accès frauduleux.

Il est intéressant de "marquer" dans l'interface les noms DNS des serveurs "sûrs" afin de passer rapidement des alertes en "faux positif" ou de les détruire quand le responsable est "banni" par le pare-feu.

--2016-09-30 23:01:48--  https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.7.6.tar.xz
Resolving cdn.kernel.org (cdn.kernel.org)... 151.101.60.69
Connecting to cdn.kernel.org (cdn.kernel.org)|151.101.60.69|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 90432088 (86M) [application/x-xz]
Saving to: ‘linux-4.7.6.tar.xz’
linux-4.7.6.tar.xz  100%[=====================>]  86,24M  54,0MB/s   in 1,6s   
2016-09-30 23:01:49 (54,0 MB/s) - ‘linux-4.7.6.tar.xz’ saved [90432088/90432088]

La dernière version de Suricata est la 4.0.0 parue au début du quatrième trimestre 2017. J'ai attendu quelque peu avant de l'installer et la 4.0.1 était sortie, c'est donc celle que j'ai installée. 
La compilation et l'installation sont identiques à celles des versions 3.x. Je n'ai pas non plus eu besoin de modifier les fichiers de paramétrage et tout a fonctionné au premier lancement.

J'ai aussi installé la version 4.0.4 de février 2018 sans plus de problèmes. 
 

Le couple Suricata/Barnyard2 détecte les événements réseau notables et les insère dans une base Mysql/MariaDB. 
C'est bien, mais pour visualiser ces alertes un outil sympa est "Snorby" : c'est une interface WEB très complète et assez agréable à utiliser. Son développement n'étant plus assuré cela risque de poser problème.

Je l'utilise depuis un bon moment et j'ai presque toujours eu des problèmes lors de son installation ou lors de changement de version de système, même en changeant de machine j'ai rencontré des difficultés. 
Quelques articles résument des années d'utilisation. 
Juillet 2018, ce logiciel est toujours en cours d'utilisation ... 
Janvier 2019, Snorby n'a pas supporté les dernières mises à jour du système et je ne suis pas arrivé à le faire refonctionner ... 
J'ai donc réalisé un nouveau logiciel permettant de le remplacer, ainsi est né Snorbis.  qui utilise les mêmes tables alimentées par Barnyard2 que Snorby.
 

Décembre 2018 : Je suis en train de tester la version 4.1 de Suricata. 
La compilation et les premiers tests se sont fort bien passés, la suite bientôt, j'ai profité de ces tests pour valider l'installation de "Snorbis" destiné à remplacer Snorby qui, malheureusement, n'est plus maintenu. 
J'ai perdu pas mal de temps sur ce sujet car je me suis aussi occupé d'un outil destiné à gérer les résultats de Modsec dont je reparlerais plus tard.

Note mars 2019 : cette version fonctionne depuis quelques mois sans encombre.

Cette application sans prétentions présentera :

1. La même base de données que Snorby en y ajoutant une historisation dans des tables séparées des tables courantes, ainsi seules les anomalies non expliquées sont visibles dans les écrans de contrôle.
2. Quelques statistiques
3. Quelques fonctions d'automatisation destinées à simplifier en l'automatisant le traitement des "faux positifs" et des "anomalies normales" telles que les messages causés par une machine Debian effectuant sa mise à jour.

Le principe adopté est de ne pas utiliser de Framework pour limiter les dépendances, seul PHP7 et quelques librairies "de base" sont utilisées dans mes différents traitements. 
Cela avance bien, mais sans aucun framework c'est un peu un travail de fourmi ... Publication prévue pour avril 2020 le temps de peaufiner la doc et d'éradiquer les derniers bugs. 
NOTE février 2021 : Suricata ayant supprimé la sortie "unified2" la base de données "snorby" ne sera donc plus alimentée, je suis en train de mettre au point un petit logiciel (Programme Python) pour alimenter une base équivalente et utiliser cette application légèrement modifiée. 
Voir quelques écrans

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 
=====================================================================

OSSEC HIDS v2.4.1 Script d'installation - http://www.ossec.net      Vous êtes sur le point d'installer OSSEC HIDS.   Vous devez avoir une compilateur C préinstallé sur votre système.   Si vous avez des questions ou des commentaires, envoyez un email   à dcid@ossec.net (ou daniel.cid@gmail.com).       - Système: Linux machine.domaine 2.6.18-194.3.1.el5    - Utilisateur: root    - Hôte: machine.domaine    -- Appuyez sur Entrée pour continuer ou Ctrl-C pour annuler. --

====================================================================== 
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. 
=======================================================================

1- Quel type d'installation voulez-vous (serveur, agent, local ou aide) ? local    - Installation en local choisie.  2- Définition de l'environnement d'installation.   - Choisissez votre répertoire d'installation de OSSEC HIDS [/var/ossec]:      - L'installation sera faite sur  /var/ossec .  3- Configuration de OSSEC HIDS.    3.1- Voulez-vous une alerte par email ? (o/n) [o]: o     - Quel est votre adresse email ? xxxxxx@xxxxxx     - Quel est l'adresse IP ou le nom d'hôte de votre serveur SMTP ? localhost    3.2- Voulez-vous démarrer le démon de vérification d'intégrité ? (o/n) [o]: o     - Lancement de syscheck (démon de vérification d'intégrité).    3.3- Voulez-vous démarrer le moteur de détection de rootkit ? (o/n) [o]: o    3.4- La réponse active vous permet d'éxécuter des commandes         spécifiques en fonction d'évènement. Par exemple,         vous pouvez bloquer une adresse IP ou interdire         l'accès à un utilisateur spécifique.         Plus d'information sur :         http://www.ossec.net/en/manual.html#active-response              - voulez-vous démarrer la réponse active ? (o/n) [o]: o     - Par défaut, nous pouvons activer le contrôle d'hôte       et le pare-feu (firewall-drop). Le premier ajoute       un hôte dans /etc/hosts.deny et le second bloquera       l'hôte dans iptables (sous linux) ou dans ipfilter       (sous Solaris, FreeBSD ou NetSBD).     - Ils peuvent aussi être utilisés pour arrêter les scans       en force brute de SSHD, les scans de ports ou d'autres       formes d'attaques. Vous pouvez aussi les bloquer par       rapport à des évènements snort, par exemple.     - Voulez-vous activer la réponse pare-feu (firewall-drop) ? (o/n) [o]: o       - pare-feu (firewall-drop) activé (local) pour les levels >= 6     - liste blanche (white list) par défaut pour la réponse active :        - 192.168.1.x        - 192.168.1.y     - Voulez-vous d'autres adresses IP dans votre liste (white list) ? (o/n)? [n] o

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

3.6- Mise en place de la configuration pour analyser les logs suivants :      -- /var/log/messages      -- /var/log/secure      -- /var/log/maillog   - Si vous voulez surveiller d'autres fichiers, changez     le fichier ossec.conf en ajoutant une nouvelle valeur     de nom de fichier local.     Pour toutes vos questions sur la configuration,     consultez notre site web http://www.ossec.net .               --- Appuyez sur Entrée pour continuer ---

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

- Configuration correctement terminée.   - Pour démarrer OSSEC HIDS:          /var/ossec/bin/ossec-control start   - Pour arrêter OSSEC HIDS:          /var/ossec/bin/ossec-control stop   - La configuration peut être visualisée ou modifiée dans /var/ossec/etc/ossec.conf      Merci d'utiliser OSSEC HIDS.      Si vous avez des questions, suggestions ou si vous trouvez      un bug, contactez nous sur contact@ossec.net ou en utilisant la      liste de diffusion publique sur ossec-list@ossec.net      ( http://www.ossec.net/en/mailing_lists.html ).      Plus d'information peut être trouver sur http://www.ossec.net      ---  Appuyez sur Entrée pour finir (peut-être plus d'info plus bas). ---

============================================================================= 
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 : 
===================================================================

1- Quel type d'installation voulez-vous (serveur, agent, local ou aide) ? agent     - Installation de l'agent (client) choisie.    2- Définition de l'environnement d'installation.    - Choisissez votre répertoire d'installation de OSSEC HIDS [/var/ossec]:      - L'installation sera faite sur  /var/ossec .    3- Configuration de OSSEC HIDS.    3.1- Quelle est l'adresse IP de votre serveur OSSEC HIDS ?: 192.168.1.xxx     - Ajout de l'IP du Serveur 192.168.1.xxx    3.2- Voulez-vous démarrer le démon de vérification d'intégrité ? (o/n) [o]: o     - Lancement de syscheck (démon de vérification d'intégrité).    3.3- Voulez-vous démarrer le moteur de détection de rootkit ? (o/n) [o]: o     - Lancement de rootcheck (détection de rootkit).    3.4 - voulez-vous démarrer la réponse active ? (o/n) [o]: o    3.5- Mise en place de la configuration pour analyser les logs suivants :      -- /var/log/messages      -- /var/log/auth.log      -- /var/log/syslog      -- /var/log/xferlog      -- /var/log/mail.info      -- /var/log/squid/access.log      -- /var/log/dpkg.log      -- /var/log/snort/alert (snort-full file)   - Si vous voulez surveiller d'autres fichiers, changez     le fichier ossec.conf en ajoutant une nouvelle valeur     de nom de fichier local.     Pour toutes vos questions sur la configuration,     consultez notre site web http://www.ossec.net .     --- Appuyez sur Entrée pour continuer ---  ======================================================================  La compilation démarre et l'installation s'enchaîne pour se terminer en beauté ...  ======================================================================   - Le Système est Debian (Ubuntu or derivative).   - Script d'initialisation modifié pour démarrer OSSEC HIDS pendant le boot.   - Configuration correctement terminée.   - Pour démarrer OSSEC HIDS:          /var/ossec/bin/ossec-control start   - Pour arrêter OSSEC HIDS:          /var/ossec/bin/ossec-control stop    - La configuration peut ếtre visualisée ou modifiée dans /var/ossec/etc/ossec.conf      Merci d'utiliser OSSEC HIDS.      Si vous avez des questions, suggestions ou si vous trouvez      un bug, contactez nous sur contact@ossec.net ou en utilisant la      liste de diffusion publique sur ossec-list@ossec.net      ( http://www.ossec.net/en/mailing_lists.html ).      Plus d'information peut ếtre trouver sur http://www.ossec.net      ---  Appuyez sur Entrée pour finir (peut-être plus d'info plus bas). ---  ... ... ...   - Vous devez d'abord ajouter cet agent sur le serveur pour     qu'ils communiquent entre eux. Quand cela sera fait,     vous pourrez lancer l'outil 'manage_agents' pour     importer la clef d'authentification depuis le serveur.     /var/ossec/bin/manage_agents     Plus d'information sur:     http://www.ossec.net/en/manual.html#ma

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

/var/ossec/bin/manage_agents  ****************************************  * OSSEC HIDS v2.4.1 Agent manager.     *  * The following options are available: *  ****************************************     (A)dd an agent (A).     (E)xtract key for an agent (E).     (L)ist already added agents (L).     (R)emove an agent (R).     (Q)uit.  Choose your action: A,E,L,R or Q: A  - Adding a new agent (use '\q' to return to the main menu).    Please provide the following:     * A name for the new agent: com-k400     * The IP Address of the new agent: 192.168.1.xxx     * An ID for the new agent[001]: 001  Agent information:     ID:001     Name:xxxxxxxxx     IP Address:192.168.1.xxx  Confirm adding it?(y/n): y  Agent added.  ****************************************  * OSSEC HIDS v2.4.1 Agent manager.     *  * The following options are available: *  ****************************************     (A)dd an agent (A).     (E)xtract key for an agent (E).     (L)ist already added agents (L).     (R)emove an agent (R).     (Q)uit.  Choose your action: A,E,L,R or Q: q  ** You must restart the server for your changes to have effect.  manage_agents: Exiting ..

=================================================================== 
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 : 
=====================================================================

/var/ossec/bin/manage_agents  ****************************************  * OSSEC HIDS v2.4.1 Agent manager.     *  * The following options are available: *  ****************************************     (A)dd an agent (A).     (E)xtract key for an agent (E).     (L)ist already added agents (L).     (R)emove an agent (R).     (Q)uit.  Choose your action: A,E,L,R or Q: E  Available agents:     ID: 001, Name: com-k400, IP: 192.168.1.60  Provide the ID of the agent to extract the key (or '\q' to quit): 001  Agent key information for '001' is:  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  ** Press ENTER to return to the main menu.

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

/var/ossec/bin/manage_agents  ****************************************  * OSSEC HIDS v2.4.1 Agent manager.     *  * The following options are available: *  ****************************************     (I)mport key from the server (I).     (Q)uit.  Choose your action: I or Q: I  * Provide the Key generated by the server.  * The best approach is to cut and paste it.  *** OBS: Do not include spaces or new lines.  Paste it here (or '\q' to quit): xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  Agent information:     ID:001     Name:xxxxxxxxx     IP Address:192.168.2.xxx  Confirm adding it?(y/n): y  Added.  ** Press ENTER to return to the main menu.

======================================================================= 
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" :

** Para instalação em português, escolha [br]    ** è¦ä½¿ç”¨ä¸­æ–‡è¿›è¡Œå®‰è£ , 请选择 [cn].    ** Fur eine deutsche Installation wohlen Sie [de].    ** Για εγκατάσταση στα Ελληνικά, επιλέξτε [el].    ** For installation in English, choose [en].    ** Para instalar en Español , eliga [es].    ** Pour une installation en français, choisissez [fr]    ** Per l'installazione in Italiano, scegli [it].    ** 日本語でインストールします．選択して下さい．[jp].    ** Voor installatie in het Nederlands, kies [nl].    ** Aby instalować w języku Polskim, wybierz [pl].    ** Для инструкций по установке на русском ,введите [ru].    ** Za instalaciju na srpskom, izaberi [sr].    ** Türkçe kurulum için seçin [tr].    (en/br/cn/de/el/es/fr/it/jp/nl/pl/ru/sr/tr) [en]: fr

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

OSSEC HIDS v2.6 Script d'installation - http://www.ossec.net  Vous êtes sur le point d'installer OSSEC HIDS.  Vous devez avoir une compilateur C préinstallé sur votre système.  Si vous avez des questions ou des commentaires, envoyez un email  à dcid@ossec.net (ou daniel.cid@gmail.com).    - Système: Linux kmail 2.6.39    - Utilisateur: root    - Hôte: xxxxxx    -- Appuyez sur Entrée pour continuer ou Ctrl-C pour annuler. --  Après un appui sur entrée :   - Vous avez déjà installé ossec. voulez-vous le mettre à jour ? (o/n): o   - Voulez-vous mettre à jour les règles ? (o/n): o  Après 2 "o"+entrée la compilation démarre et  Starting OSSEC HIDS v2.6 (by Trend Micro Inc.)...  OSSEC analysisd: Testing rules failed. Configuration error. Exiting.  /var/ossec/bin/ossec-dbd: /usr/lib/libmysqlclient.so.15: version `libmysqlclient_15' not found  (required by /var/ossec/bin/ossec-dbd)  - Configuration correctement terminée.  - Pour démarrer OSSEC HIDS:          /var/ossec/bin/ossec-control start  - Pour arrêter OSSEC HIDS:          /var/ossec/bin/ossec-control stop  - La configuration peut être visualisée ou modifiée dans /var/ossec/etc/ossec.conf      Merci d'utiliser OSSEC HIDS.      Si vous avez des questions, suggestions ou si vous trouvez      un bug, contactez nous sur contact@ossec.net ou en utilisant la      liste de diffusion publique sur ossec-list@ossec.net      ( http://www.ossec.net/en/mailing_lists.html ).      Plus d'information peut être trouver sur http://www.ossec.net      ---  Appuyez sur Entrée pour finir (peut-ếtre plus d'info plus bas). ---

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 !!!

Cet article présente un tout petit ensemble de scripts permettant la création et la mise à jour d'un "set" comprenant toutes les classes d'adresses IP allouées à certains pays, le tout paramétrable par le fichier de configuration. 
J'utilisais comme source d'adresses le site "https://www.ipdeny.com" qui permet d'obtenir facilement les classes d'adresses allouées à chaque pays, mais, depuis quelques mois, les données ne semblent plus évoluer ... 
Je me suis donc mis à la recherche d'une nouvelle source et j'ai trouvé le site "https://ip2location.com" qui fournit plusieurs listes d'IP, certaines payantes, mais une version "LITE" est en accès libre. Comme je n'ai pas besoin d'une grande précision géographique (le pays me suffit) la version LITE me convient parfaitement. 
Le "set" constitué à partir de ces adresses est utilisé dans une règle iptables simple :

## Interface vers l'extérieur  IFEXT=eth0  TYP= ' -t mangle '  OPTLIM=' -m limit --limit 30/h --limit-burst 10 '  ......  iptables $TYP -A PREROUTING  -i $IFEXT                -j  PRE_EXT  ....... iptables $TYP -A PRE_EXT -m set --match-set BLOCK_COUNTRY src -j MARK --set-mark 97  iptables $TYP -A PRE_EXT -m mark --mark 97    $OPTLIM         -j LOG --log-tcp-options --log-prefix 'MSG=COUNTRY_PRE '  iptables $TYP -A PRE_EXT -m mark --mark 97                    -j DROP  ......

Le seul problème pour moi c'est que les données récupérées depuis IP2LOCATION ne sont pas en format CIDR mais sous forme de "ranges" tels que : 192.168.1.0-192.168.3.255 ce qui n'est pas exploitable facilement avec des "sets" qui préfèrent la notation CIDR. 
Heureusement quelqu'un a inventé et réalisé "ipcalc" qui réalise ce type d'opérations en un tour de main et si le range fourni ne peut être exprimé en une seule expression il en fournit plusieurs qui réalisent le truc, c'est tout simplement génial.

Afin d'automatiser la récupération des données et la construction du set j'ai réalisé un petit groupe de scripts qui réalisent les opérations suivantes :

• Récupération du fichier sur le site IP2LOCATION
• Dé-zipper les données
• Reformater les données reçues pour les soumettre à "ipcalc"
• Les soumettre à la sagacité d'ipcalc
• Mettre en forme les résultats pour charger un fichier "set" utilisable avec : 
  "ipset --restore MON_SET < Le_fichier_formaté"

Le fichier de configuration est assez simple et j'y ai inséré quelques commentaires pour faciliter le remplissage.

Le tout est disponible ici sous forme de "tar.gz". 
Ce paquet est à installer dans un petit endroit douillet d'où il sera facile à utiliser. 
Le paramétrage "exemple" est assez sévère pour beaucoup de pays mais ce site en français intéresse peu russes et chinois (bien qu'ils scannent régulièrement le serveur) et d'autres qui ne visent qu'à pirater un site de plus pour lui faire subir toutes sortes de choses désagréables ou même miner du bitcoin ... 
Une autre partie du filtrage est réalisé par Suricata et Modsecurity, chaque individu mal intentionné qui est pris dans le filet permet d'ajouter de nouvelles règles de filtrage ...

Script de récupération des fichiers "emerging threats" et de création du set IP.

Mon firewall fonctionne avec plusieurs "Sets" gérés par ipset et permet de rejeter directement un certain nombre de connexions le plus souvent indésirables ou qui ne lisent pas le français ! 
Le "remplissage" des sets a quelque peur évolué au cours du temps ... en fonction des analyses. 
J'ai quelques scripts qui analysent les résultats du firewall à travers les données présentes dans syslog. 
J'ai réalisé un premier tableau statistique en juin 2014 et j'ai voulu refaire la même analyse en octobre 2016, j'ai été surpris moi-même des résultats, l'accès à Internet s'est vraiment répandu dans le monde et énormément d'adresses IP différentes viennent "titiller" nos petites machines :

• Le tableau d'octobre 2016

​On remarque tout de suite le nombre de pays présents en 2016, beaucoup plus élevé qu'en 2014 (dommage j'ai perdu cette page), on passe de quelques dizaines de pays à quasiment l'intégralité du monde ! 
Il est vrai que mes critères de rejet sont maintenant beaucoup plus sévères (plus de ports "interdits") et utilisent plus de listes de "mauvaises"  IP et par ailleurs bloquent systématiquement plus de pays (Chine, Russie ... et les petits nouveaux Vietnam et Brésil).

Aucune "table" n'est définie par défaut comme avec "iptables", c'est à vous de les définir ! 
Rappel : 
Plus de différence entre IPV4 et IPV6, tout peut être traité dans le même flot, si on utilise des tables "inet", par défaut c'est "ip" (IPV4) qui est choisi, on peut aussi utiliser "ip6" pour du spécifique IPV6. 

Commandes disponibles : 
list 
  ruleset 
  tables [famille] 
  table [famille] <nom> 
  chain [famille] <table> <nom> 
add 
  table [famille] <nom> 
  chaine [famille] <table> <nom> [paramètres de la chaîne] 
  rule [famille] <table> <chaine> <paramètres de la règle> 
  element [famille] <table> <set> { 1..n elements } 
table [famille] <nom> (raccourci pour "add table`) 
insert 
  rule [famille] <table> <chaine> <paramètres de la règle> 
delete 
  table [famille] <nom> 
  chain [famille] <table> <nom> 
  rule [famille] <table> <numero handle> 
  set [famille] <table> <set>     : il ne doit plus être référencé 
  element [famille] <table> <set> { 1..N elements a enlever } 
flush 
  table [famille] <nom> 
  chain [famille] <table> <nom> 

Remarques : 
La famille "ip" (ipv4) est prise par défaut. 
Attention à la syntaxe de "list" "list tables" et "list table ENTREE". 
Liste des familles de "tables" et l'outil iptables correspondant 
ip            iptables 
ip6          ip6tables 
inet         iptables and ip6tables 
arp          arptables 
bridge     ebtables 
Liste des "hooks" existants, tiens tiens ! Les noms me rappellent quelque chose : 
INPUT                    paquet entrant dans le système local 
OUTPUT                paquet sortant du système local 
FORWARD            paquet traversant 
PREROUTING      paquet entrant 
POSTROUTING    paquet sortant 
Liste des "types" de tables existants, là aussi les noms semblent familiers : 
filter        Valeur par défaut 
nat 
route      (mangle), ne semble utilisable qu'avec le hook "output". 
Ordres supportés par la commande "table" 
add 
delete 
list 
flush 
Ordres supportés par la commande "chain" : 
add 
create 
delete 
list 
flush 
rename 
Ordres supportés par la commande "rule" : 
add     ajoute une règle en fin de chaîne 
insert    ajoute une règle en début de chaîne 
delete    détruit une règle, utilisé avec un "handle" cf "nft -a list ...."

Ordres supportés par la commande "ruleset" : 
flush   efface tout 
list       liste tout

Destination des paquets 
accept 
reject 
drop 
snat 
dnat 
log 
counter 
return 
jump    <chaine> 
goto     <chaine> 

Quelques "mots clefs" pour les règles : 
oif       interface sortie suivi d'un numéro 
iif       interface entree suivi d'un numéro 
oifname    nom de l'interface de sortie 
iifname nom de l'interface d'entree 
type    suivi d'un type ICMP par exemple "echo-request" 
protocol tcp, udp ... 
daddr    adresse destination 
saddr    adresse source 
dport    port de destination 
sport    port source 
ct         connexion tracking + state ( NEW, ESTABLISHED, RELATED, INVALID) 
C'est un bon début.