OSSEC : sur un "vrai" serveur

OSSEC : sur un "vrai" serveur jpp

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.

OSSEC : la vie en vrai

OSSEC : la vie en vrai jpp

J'ai donc installé OSSEC sur un serveur "réel" et je l'ai laissé fonctionner quelques temps sans toucher au paramétrage. 
Sur ce même serveur tournent quelques outils de sécurité (AIDE et TIGER), Je vais pouvoir comparer les résultats. 
Le plus de OSSEC est le signalement rapide par mail des problèmes. Une détection par l'IDS (Snort) est signalée rapidement. 
Après un ou deux jours j'ai constaté que la surveillance de certains répertoires n'était pas installée par défaut, seuls les répertoires "etc" et la gamme des "bin" étaient surveillés, j'y ai donc ajouté (fichier /var/ossec/etc/ossec.conf) les répertoires "/lib" et "/usr/lib". 
Les lignes considérées sont actuellement les suivantes : 
   <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories> 
   <directories check_all="yes">/bin,/sbin,/lib,/usr/lib</directories> 
J'attends les résultats des prochains passages. 
J'ai aussi essayé de mettre sous surveillance le serveur FTP (proftpd) car il existe des éléments de configuration prévus pour lui mais mis en commentaires. Je les ai donc activés et, là aussi, j'attends les résultats, il suffit qu'un petit malin vienne "titiller" ce FTP pour que je puisse vérifier si la détection est correcte. 
On pourra alors voir si la "réponse active" bloque bien les IP de ces offenseurs. 
 

OSSEC : après quelques semaines

OSSEC : après quelques semaines jpp

Après quelques semaines la vie avec OSSEC se passe très bien. Le nombre de messages n'est pas très élevé, sauf lors de mises à jour logicielles sur l'une des machines. Celle-ci déclenche en effet un certain nombre de messages pour : 
- la mise à jour elle-même (détection sur dpkg.log) 
- la modification des programmes (changement de l'empreinte) 
Les messages surviennent très rapidement après la mise à jour et, très souvent, les messages groupent un certain nombre de modifications ce qui réduit fortement leur nombre. 
On voit rapidement les tentatives d'accès indues, tous les "rigolos" qui essayent de forcer votre mot de passe SSH... ils essayent en général les users "Administrator" ou parfois "Administrateur", C'est bizarre celà me dit quelque chose ce genre de user... 
Toutes les erreurs de connexion, avec les mots de passe à la gomme qu'on est obligé d'utiliser il est vite fait de se mélanger les doigts et de frapper un mot de passe erroné. 
De même les tentatives d'accès sur le serveur FTP sont signalées et, en prime, OSSEC bloque l'IP correspondante pendant un temps paramétrable (600 secondes par défaut). 
La machine OSSEC étant aussi ma passerelle Internet il faut soigneusement mettre en "White list" les machines du réseau interne car si elles font des choses non prévues (ou "vilaines") leur IP est bloquée assez rapidement. 
J'ai ainsi constaté qu'un simple "apt-get update" va chercher des fichiers qui n'existent pas sur les serveurs et le proxy SQUID note soigneusement ces accès "loupés" ce qui déclenche un message et le blocage de l'IP "fautive", la White List est ici la bienvenue. 
Exemple de message OSSEC : 

OSSEC HIDS Notification.2010 Sep 14 23:29:39 
Received From: xxxxx->syscheck 
Rule: 550 fired (level 7) -> "Integrity checksum changed." 
Portion of the log(s): 
Integrity checksum changed for: '/etc/bind/db.192.1' 
Size changed from '1603' to '1657' 
Ownership was '0', now it is '105' 
Old md5sum was: '99bd18192e46198c2330a2f4b715fd00' 
New md5sum is : '146b5b6ddd094f633f1f55961ed17055' 
Old sha1sum was: 'aeacec95643c35ab23f9b45fdc0b4d137a04a38d' 
New sha1sum is : '39ccae1efc06a417b856242694fbe0931836b623' 
--END OF NOTIFICATION 
En effet j'ai procédé à une mise à jour d'un fichier de mon petit DNS interne, le signalement est rapide. 

OSSEC HIDS Notification. 2010 Sep 15 23:17:02 
Received From: (pcnic) 192.168.1.7->syscheck 
Rule: 550 fired (level 7) -> "Integrity checksum changed." 
Portion of the log(s): 
Integrity checksum changed for: 'ossec.conf' 
Size changed from '7554' to '7634' 
Old md5sum was: '91e2cfd5503cb7eeee496f6b83a195b4' 
New md5sum is : 'be35b5b28f893182a6c730e9533ed64d' 
Old sha1sum was: 'e0d47353e1d3339a7d4a5b080fb2853ed1ad8cc0' 
New sha1sum is : 'c25c7b4d2a6ea97c842f106df645874c5985a5ea' 
--END OF NOTIFICATION 
Là j'ai ajusté une règle pour modifier les conditions de syscheck sur le répertoire "c:\program files", la réaction a été très rapide car l'option "realtime" est activée sur les répertoires "sensibles". 
Pour les machines Windows j'attends le prochain "patch tuesday" pour voir ce qui est déclenché. 
En bref c'est un très bon logiciel qui semble très complet. Le paramétrage offre de grandes possibilités pour "filtrer" des messages superflus, le mot "error" dans un message logué est très mal vu ! Je suis abonné à une liste de distribution dont l'adresse de retour par défaut comporte le mot fatidique "error@....", une petite surcharge de règle et le tour est joué, les messages du log comportant un destinataire "error@...." ne déclenchent plus rien. 
Il faut essayer d'être assez précis dans ce type de filtre pour ne pas cacher de vrais "ERRORS". 
Ca y est, les patchs Windows sont arrivés et il y en a 11. Je déclenche cette mise à jour et je vais observer les messages de OSSEC dès leur arrivée. 
Tiens c'est curieux, déjà une heure de passée et aucun message ?!?! 
La machine en question vient de migrer sur un nouveau matériel à processeur ATOM et carte mini dans le même boitier que celui du petit frontal Internet pour un encombrement et une consommation  minimum. 
J'attends le prochain passage de patchs.

OSSEC : filtrage de regles

OSSEC : filtrage de regles jpp

Il arrive que certains messages pourtant "normaux" de votre système encombrent inutilement les mails envoyés par OSSEC. 
Certains logiciels laissent des traces dans les logs systèmes et OSSEC repère ces "anomalies", il est particulièrement sensible à certains mots "failed", "error" ... 
Si une de vos applications génère de tels messages il faut installer un filtre secondaire permettant d'éliminer ces "fausses alertes". 
Il faut alors récupérer le numéro de la règle offensée dans le message (la 1002 est particulièrement sensible) et créer une règle dépendante éliminant le cas gênant. 
Le fichier "local_rules.xml" est destiné à cet effet. 
Par exemple : 
Xen me génère régulièrement des messages "this function is not supported by the hypervisor: virConnectNumOfInterfaces" et c'est encore la règle 1002 qui repère ce truc. 
Il suffit d'ajouter dans le fichier local : 
  <rule id="101117" level="0"> 
    <if_sid>1002</if_sid> 
    <match>this function is not supported by the hypervisor: virConnectNumOfInterfaces</match> 
    <description>erreurs</description> 
  </rule> 
Il faut donner :

  • Un numéro à votre règle ( > 100000), ici 101117 et un niveau d'erreur. Un niveau à zéro annule la condition d'erreur <balise <rule...>. On pourrait aussi rendre une erreur plus grave en augmentant son LEVEL.
  • La règle offensée (ici la fameuse règle 1002) balise <if_sid>
  • Le texte du message, avec les blancs (je ne suis pas un spécialiste des expressions régulières ...)
  • Une description et c'est fini.

Un petit restart de OSSEC et le message ennuyeux s'évanouit ! 

Pour des messages plus complexes, comportant par exemple des parties variables il faut enchaîner deux règles dépendantes : 
  <rule id="101110" level="0"> 
    <if_sid>5104</if_sid> 
    <match>device tap</match> 
    <description>erreurs</description> 
  </rule> 
  <rule id="101111" level="0"> 
    <if_sid>101110</if_sid> 
    <match>entered promiscuous mode</match> 
    <description>erreurs</description> 
  </rule> 
Le message a intercepter comportait une partie variable : le numéro de "tap" concerné, rappel : je ne suis pas un spécialiste des expressions régulières ...). 
Bon filtrage ...