You are here

Home › Sécurité, mesures, monitoring › OSSEC

OSSEC : la vie avec OSSEC

21 July, 2010 - 00:57 — jpp

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
- type d'événement (user account modified, authentication failure, system error, integrity checking).
Pour les tests d'intégrité la mise à jour d'une machine en déclenche un paquet, (une erreur pour chaque fichier modifié).
J'ai modifié sur le serveur OSSEC le fichier "/etc/inittab" (passage du niveau de démarrage 5 à 3 pas besoin de graphique sur le serveur OSSEC) j'ai très rapidement reçu un mail signalant cette modif :


 OSSEC HIDS Notification.
2010 Jul xx 14:52:01
Received From: xxxxxxxxxx-syscheck
Rule: 550 fired (level 7) - "Integrity checksum changed."
Portion of the log(s):


Integrity checksum changed for: '/etc/inittab'
Old md5sum was: '9d49303d50eb59151fc24eb0e3802232'
New md5sum is : '92a39a223f68e67e9e6c412443851aeb'
Old sha1sum was: '13b4a423b08d394b8efe3fc55ab2e5ca959a9f35'
New sha1sum is : '78ef239097844c223671e99a79d6b533dced8d3b'

 --END OF NOTIFICATION


La mise à jour (par apt-get upgrade) déclenche un mail de signalement me prévenant de la mise à jour de deux packages :

 OSSEC HIDS Notification.

2010 Jul xx 20:26:55

Received From: (xxxxxxxx) 192.168.1.xxx->/var/log/dpkg.log
Rule: 2902 fired (level 7) - "New dpkg (Debian Package) installed."
Portion of the log(s):


2010-07-xx 20:26:55 status installed libmozjs1d 1.9.0.19-3
OSSEC HIDS Notification.
2010 Jul xx 20:26:57
Received From: (xxxxxxxx) 192.168.1.xxx->/var/log/dpkg.log
Rule: 2902 fired (level 7) - "New dpkg (Debian Package) installed."
Portion of the log(s):
2010-07-xx 20:26:57 status installed xulrunner-1.9 1.9.0.19-3
--END OF NOTIFICATION


J'ai détruit un fichier superflu "/etc/toto" et j'ai reçu très rapidement le  mail m'informant de cette modification :

OSSEC HIDS Notification.
2010 Jul xx 20:19:29
Received From: (xxxxxxxx) 192.168.1.xxx-syscheck
Rule: 550 fired (level 7) - "Integrity checksum changed."
Portion of the log(s):

Integrity checksum changed for: '/etc/toto'
Size changed from '1705' to '0'
Old md5sum was: 'f3ec8dd540603dc954e1d99d97a127ab'
New md5sum is : 'd41d8cd98f00b204e9800998ecf8427e'
Old sha1sum was: '28e360b5b2ecd8550ab755e26f994232d278c0a8'
New sha1sum is : 'da39a3ee5e6b4b0d3255bfef95601890afd80709'
--END OF NOTIFICATION


En bref, bien que parfois un peu bavard OSSEC est un outil qui semble excellent, je vais probablement l'installer sur mon petit réseau pour être au courant de tout ce qui se trame dans ce petit univers théoriquement bien fermé.
Je pense qu'après quelques ajustement du niveau de quelques règles (les niveaux vont de 1 à 15) le système sera parfait.

J'avais configuré la "réponse active" sans mettre en "liste blanche" toutes mes machines et j'ai pu constater à mes dépends que cela fonctionnait très bien, après quelques erreurs de frappe dans un mot de passe je ne parvenais même plus à "pinger" la machine. En vérifiant "en direct" j'ai pu constater qu'une règle "iptables" avait été installée bloquant tous les accès depuis la machine fautive. OSSEC tient à jour sa liste de "réponses actives" et annulle la règle iptables apres un certain temps. Les petis malins qui tentent des attaques en force brute sur le port SSH vont en faire les frais.

Adapter la configuration :
C'est dans le fichier "/var/ossec/etc/ossec.conf" que se réalisent la plupart des personnalisations :

  • Configuration de la base de données (je vous engage à utiliser PostGresql ou Mysql) car il sera ensuite possible de développer des requêtes adhoc.
  • Configuration de l'envoi des mails (niveau, adresse expéditeur)
  • Configuration de la réponse active, notamment la durée d'éviction (défaut à 600 secondes)
  • Fichiers de "log" à prendre en compte, si vous avez un serveur apache qui utilise de nombreux fichiers de log (un ou deux par serveur virtuel) , c'est ici qu'il faudra les indiquer.
  • Commandes, par exemple celles de "réponse active", vous pouvez ici ajouter des commandes "privées" que vous voudriez voir exécuter dans certaines conditions.
  • La liste des fichiers (xml) de règles à prendre en compte, prudence en en supprimant car beaucoup de règles ont des dépendances dans d'autres fichiers. La moindre erreur empêche OSSEC de démarrer.


PS:
Je n'ai pas encore vu de niveau de messages supérieurs à 7, le niveau 15 doit être angoissant !

Dès mon retour de vacances je vais lancer une vague d'installation d'agents OSSEC sur toutes les machines qui traînent, le serveur est déjà choisi, cela lui fera une petite charge supplémentaire.


système: 
Linux
Windows
securité