TUTO OBSOLETE

Sécuriser son serveur avec Prelude-IDS et Ossec

Prelude est un logiciel SIEM qui permet de superviser la sécurité des systèmes informatiques. Prelude collecte, trie, corrèle et affiche tous les événements de sécurité indépendamment des types d'équipements ou système surveillés.

Au-delà de sa capacité de traitement de tout type de journaux d’événements (journaux système, syslog, fichiers de configuration...etc), Prelude est nativement compatible avec de nombreuses sondes anti-intrusion open-source (snort, ossec... etc) grâce à l'utilisation du format IDMEF.

Liens utiles :

https://www.prelude-siem.org/
http://fr.wikipedia.org/wiki/Prelude

Installation

Actuellement la version la plus récente du projet est la 1.2.5 mais celle des dépôts de Debian date de 2012 (1.0.1) donc nous allons devoir compiler Prelude à la main. Voici la liste des 6 composants à installer :

- Prelude Manager : c'est le module qui traite et centralise les alertes système

LibPrelude : Librairie qui fournie l'API de Prelude

LibpreludeDB : Librairie qui fournie une couche d'abstraction pour le stockage des alertes IDMEF

Prelude-LML : Analyseur/collecteur de log

Prelude-Correlator : Moteur de correlation des alertes système

Prewikka WebUI : Interface web officielle de prelude

Compilation et installation de Libprelude :

On doit d'abord installer quelques pré-requis :

apt-get install python2.7-dev libpcre3-dev swig pkg-config

# Sous Debian 7 :
apt-get install libgnutls-dev

# Sous Debian 8 :
apt-get install libgnutls28-dev

Ensuite on télécharge l'archive puis on configure la compilation :

cd /tmp
wget --no-check-certificate https://www.prelude-siem.org/attachments/download/351/libprelude-1.2.5.tar.gz
tar -xzf libprelude-1.2.5.tar.gz
cd libprelude-1.2.5

./configure --without-perl --without-lua --with-python=/usr/bin/python2.7

Après avoir configuré la compilation de libprelude, assurez-vous que le support de Python est activé :

*** Dumping configuration ***
    - Generate documentation   : no
    - LUA binding              : no
    - Perl binding             : no
    - Python binding           : yes
    - Ruby binding             : no
    - Easy bindings            : yes

Pour finir l'installation de libprelude, exécutez les commandes suivantes :

# On inclus la librairie cstddef
sed -i '1 i\#include <cstddef>' bindings/python/_PreludeEasy.cxx

make
make install

Compilation et installation de LibpreludeDB :

Pour activer le support de MySQL, installez le paquet libmysqlclient-dev :

apt-get install libmysqlclient-dev

Ensuite on télécharge l'archive puis on configure la compilation :

cd /tmp
wget --no-check-certificate https://www.prelude-siem.org/attachments/download/352/libpreludedb-1.2.5.tar.gz
tar -xzf libpreludedb-1.2.5.tar.gz
cd libpreludedb-1.2.5

# Variable d'environnement obligatoire sinon le linker ne trouvera pas libprelude
export LD_LIBRARY_PATH=/usr/local/lib

./configure --without-perl

Après avoir configuré la compilation de libpreludeDB, assurez-vous que le support de MySQL est activé :

*** Dumping configuration ***
    - Generate documentation      : no
    - Enable MySQL plugin         : yes
    - Enable PostgreSQL plugin    : no
    - Enable SQLite3 plugin       : no
    - Perl binding                : no
    - Python binding              : yes

Pour finir l'installation de libprelude, exécutez les commandes suivantes :

make
make install

Création de la base de donnée Prelude

Prelude stock toutes les informations collectées dans une base de donnée. Donc nous allons créer une nouvelle base nommée "prelude" ainsi qu'un nouvel utilisateur lui aussi nommé "prelude" :

# Connexion au serveur MySQL en tant que root
mysql -u root -p

# Création de la base de données "prelude"
mysql> CREATE database prelude;

# Création de l'utilisateur "prelude" et ajout des permissions
mysql> CREATE USER 'prelude'@'localhost' IDENTIFIED BY 'MOT DE PASSE';
mysql> GRANT USAGE ON *.* TO 'prelude'@'localhost';
mysql> GRANT ALL PRIVILEGES ON prelude.* TO 'prelude'@'localhost';

# On quitte la console MySQL
mysql> exit

# Création des tables
mysql -u prelude prelude -p < /usr/local/share/libpreludedb/classic/mysql.sql

Compilation et installation de Prelude Manager :

Pour activer le support du format IDMEF XML et de la technique "d'emballage TCP", installez les paquets suivants :

apt-get install libxml2-dev libwrap0-dev

Ensuite on télécharge l'archive puis on configure la compilation :

cd /tmp
wget --no-check-certificate https://www.prelude-siem.org/attachments/download/356/prelude-manager-1.2.5.tar.gz
tar -xzf prelude-manager-1.2.5.tar.gz
cd prelude-manager-1.2.5

./configure

Après avoir configuré la compilation de Prelude Manager, assurez-vous que le support de XML et TCP Wrapper est activé :

*** Dumping configuration ***
    - TCP wrapper support    : yes
    - XML plugin support     : yes
    - Database plugin support: yes

Pour finir l'installation de Prelude Manager, exécutez les commandes suivantes :

make
make install

Installation de Prelude Correlator :

Téléchargez l'archive puis lancez l'installateur :

cd /tmp
wget --no-check-certificate https://www.prelude-siem.org/attachments/download/353/prelude-correlator-1.2.5.tar.gz
tar -xzf prelude-correlator-1.2.5.tar.gz
cd prelude-correlator-1.2.5

python2.7 setup.py install --record correlator_files.txt

# Si l'installation de Prelude Correlator se passe mal, vous pouvez utiliser la commande suivante
# pour supprimer tous les fichiers créés par l'installateur :
# cat correlator_files.txt | xargs rm -rf

Compilation et installation de Prelude-LML :

Tout d'abord installez le paquet suivant :

apt-get install libicu-dev

Ensuite on télécharge l'archive puis on configure la compilation :

cd /tmp
wget --no-check-certificate https://www.prelude-siem.org/attachments/download/354/prelude-lml-1.2.5.tar.gz
wget --no-check-certificate https://www.prelude-siem.org/attachments/download/355/prelude-lml-rules-1.2.5.tar.gz
tar -xzf prelude-lml-1.2.5.tar.gz
cd prelude-lml-1.2.5

./configure

Après avoir configuré la compilation de Prelude-LML, assurez-vous que le support de libICU est activé :

*** Dumping configuration ***
    - Enable TLS support         : yes
    - Favor libICU over Iconv    : yes

Pour finir l'installation de Prelude-LML, exécutez les commandes suivantes :

make
make install

Installation de Prewikka :

Installation des pré-requis :

apt-get install python-cheetah python-setuptools python-cairo python-netaddr gettext

Téléchargez l'archive puis lancez l'installateur :

cd /tmp
wget --no-check-certificate https://www.prelude-siem.org/attachments/download/357/prewikka-1.2.5.tar.gz
tar -xzf prewikka-1.2.5.tar.gz
cd prewikka-1.2.5

python2.7 setup.py install --record prewikka_files.txt --prefix /usr/local

# Si l'installation de Prewikka se passe mal, vous pouvez utiliser la commande suivante
# pour supprimer tous les fichiers créés par l'installateur :
# cat prewikka_files.txt | xargs rm -rf

Création de la base de donnée Prewikka

Tout comme Prelude, Prewikka stock toutes les informations collectées dans une base de donnée. Donc nous allons créer une nouvelle base nommée "prewikka" ainsi qu'un nouvel utilisateur lui aussi nommé "prewikka" :

# Connexion au serveur MySQL en tant que root
mysql -u root -p

# Création de la base de données "prewikka"
mysql> CREATE database prewikka;

# Création de l'utilisateur "prewikka" et ajout des permissions
mysql> CREATE USER 'prewikka'@'localhost' IDENTIFIED BY 'MOT DE PASSE';
mysql> GRANT USAGE ON *.* TO 'prewikka'@'localhost';
mysql> GRANT ALL PRIVILEGES ON prewikka.* TO 'prewikka'@'localhost';

# On quitte la console MySQL
mysql> exit

# Création des tables
mysql -u prewikka prewikka -p < /usr/local/share/prewikka/database/mysql.sql

Configuration de Prewikka

Editez le fichier de configuration prewikka.conf :

# vim /usr/local/etc/prewikka/prewikka.conf

# ATTENTION : Pour que prewikka soit en français, votre système doit avoir le pack de langue fr_FR.utf8
# Vous pouvez le vérifier avec la commande : locale -a
# Si ce n'est pas le cas, utilisez la commande
# dpkg-reconfigure locales et ajoutez les packs suivants :
# - fr_FR
# - fr_FR@euro
# - fr_FR.utf8
default_locale: fr_FR
encoding: utf8

[interface]
software: Prewikka
place: CompanyRoxxorDeluxe
title: Interface Web de Prelude-IDS

# Paramètres de connexion à la base de donnée Prelude
[idmef_database]
type: mysql
host: localhost
user: prelude
pass: MOT DE PASSE DE L UTILISATEUR MYSQL PRELUDE
name: prelude

# Paramètres de connexion à la base de donnée Prewikka
[database]
type: mysql
host: localhost
user: prewikka
pass: MOT DE PASSE DE L UTILISATEUR MYSQL PREWIKKA
name: prewikka

# Par défaut le mot de passe est 'admin', changez-le immédiatement !!
[auth loginpassword]
expiration: 60
initial_admin_user: admin
initial_admin_pass: admin

# Facultatif mais peut servir en cas de debug
[log file]
level: debug
file: /tmp/prewikka.log

Maintenant il faut ajouter un nouveau script init.d pour pouvoir démarrer/arrêter Prewikka quand on le souhaite :

# vim /etc/init.d/prewikka

#!/bin/bash

### BEGIN INIT INFO
# Provides:          prewikka
# Required-Start:    $local_fs $remote_fs $network $syslog $named
# Required-Stop:     $local_fs $remote_fs $network $syslog $named
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# X-Interactive:     true
# Short-Description: Prewikka est l'interface officielle de Prelude-IDS
### END INIT INFO

# Variables couleurs
CSI="\033["
CEND="${CSI}0m"
CGREEN="${CSI}1;32m"

# PID du processus
PID=$(netstat -tlnp | awk '/:8000 */ {split($NF,a,"/"); print a[1]}')

# Variable d'environnement PYTHONPATH
export PYTHONPATH=/usr/local/lib/python2.7/dist-packages:/usr/local/bin/prewikka-httpd

start() {

  echo -n "Démarrage de Prewikka..."
  /usr/local/bin/prewikka-httpd &
  echo -e " ${CGREEN}[OK]${CEND}"

}

stop() {

  echo -n "Arrêt de Prewikka..."
  kill -9 $PID
  echo -e " ${CGREEN}[OK]${CEND}"

}

status() {

  if [[ $PID -gt 0 ]]; then
    echo -e "Prewikka est actuellement en service ${CGREEN}[OK]${CEND}"
  else
    echo "Prewikka n'est pas en service..."
  fi

}

case "$1" in
start)
  start
  ;;
stop)
  stop
  ;;
restart)
  stop
  start
  ;;
status)
  status
  ;;
*)
  echo "Utilisation: $0 {start|stop|restart|status}"
  exit 1
  ;;
esac

exit 0

Rendez le script exécutable :

chmod +x /etc/init.d/prewikka

Puis démarrez Prewikka avec la commande suivante :

# Démarrage du service
service prewikka start
Démarrage de Prewikka... [OK]

# Vous pouvez vérifier que Prewikka est bien en cours d'exécution avec :
service prewikka status
Prewikka est actuellement en service [OK]

Une fois le service démarré, l'interface web est accessible via l'adresse suivante :

IP_DU_SERVEUR:8000

Connectez-vous avez les identifiants définis dans le fichier de configuration de Prewikka :

Pour le moment l'interface est quasiment vide, c'est normal, nous n'avons pas encore configuré d'agent de surveillance. Nous allons voir ceci dans le partie suivante.

Installation des agents de surveillance

Prelude utilise un système de sonde/plugins installé en local ou sur un ensemble de machine afin de récupérer divers informations comme des audits, les alertes et les évènements système...etc Pour ajouter une nouvelle sonde, on va utiliser la commande prelude-admin.

Création du profil de Prelude-manager

Tout d’abord, il faut commencer par créer le profil du Prelude-Manager. Pendant la création du profil, prelude-admin va créer une clé privée/publique afin de sécuriser les échanges entre Prelude-Manager et la sonde. Mais le soucis, c'est que ça prend tu temps, énormement de temps car le système à besoin d'entropie pour pouvoir générer des nombres quasi-aléatoires.

Pour l'aider dans cette tâche, on va installer rng-tools (Hardware Random Generator) :

apt-get install rng-tools

Editez le fichier /etc/default/rng-tools et ajoutez ces deux lignes :

HRNGDEVICE=/dev/urandom
RNGDOPTIONS="-W 80% -t 20"

Et pour finir, lancez le service :

/etc/init.d/rng-tools start

On peut maintenant créer un nouveau profil :

prelude-admin add prelude-manager --uid 0 --gid 0

Ajout d'une sonde : Prelude-Correlator

Pour ajouter une nouvelle sonde, on va devoir utiliser deux commandes en parallèle, une pour générer un mot de passe unique (One-Time Password) et accepter la requête puis l'autre pour enregistrer la nouvelle sonde. Pour exécuter deux commandes en même temps, on va utiliser screen.

Installez-le si ce n'est pas déjà fait :

apt-get install screen

Maintenant entrez la commande screen puis appuyez sur [ESPACE] :

screen

On va splitter le terminal en deux parties avec la combinaison et créer un nouveau terminal dans la seconde fenêtre (attention screen est sensible à la casse) :

CTRL + a puis S     # On split le terminal en deux
CTRL + a puis TAB   # On change de fenêtre
CTRL + a puis c     # On créé une nouvelle fenêtre

A ce stade, vous devriez avoir deux consoles 0 bash / 1 bash :

RAPPEL : Pour vous déplacer d'une console à l'autre, il faut faire CTRL + a puis TAB.

Donc dans la première console, entrez la commande suivante :

prelude-admin registration-server prelude-manager

Dans la deuxième console, entrez cette commande pour enregistrer la sonde Prelude-Correlator :

prelude-admin register prelude-correlator "idmef:rw admin:r" localhost --uid 0 --gid 0

Ensuite entrez le mot de passe unique généré par l'utilitaire d'installation, une confirmation vous sera demandée dans l'autre console, acceptez en appuyant sur Y. Voila vous venez d'enregistrer votre première sonde !

Vous pouvez fermer les deux fenêtres splitées en tapant 'exit'

Ajout d'une sonde : Prelude-LML

Même principe qu'avez la sonde Prelude-Correlator, il faut exécuter les deux commandes ci-dessous en parallèle :

prelude-admin registration-server prelude-manager
prelude-admin register prelude-lml "idmef:rw admin:r" localhost --uid 0 --gid 0

Vérification de l'enregistrement des sondes :

Pour cela, on va utiliser la commande prelude-admin list -l :

# prelude-admin list -l

Profile            UID  GID  AnalyzerID       Permission       Issuer AnalyzerID
--------------------------------------------------------------------------------
prelude-correlator root root 1070801180844572 idmef:rw admin:r 1460371894460377
prelude-manager    root root 1460371894460377 n/a              n/a
prelude-lml        root root 857822342571350  idmef:rw admin:r 1460371894460377

Vous devriez avoir 3 profils distincts : prelude-manager, prelude-lml, prelude-correlator.

Configuration de Prelude-Manager :

Editez le fichier de configuration prelude-manager.conf puis ajoutez/modifiez les paramètres suivants :

# vim /usr/local/etc/prelude-manager/prelude-manager.conf

# Interface d'écoute
listen = 127.0.0.1

# Paramètres de connexion à la base de donnée
[db]
type = mysql
host = localhost
port = 3306
name = prelude
user = prelude
pass = xxxxxxxxxxxx

Configuration de Prelude-LML :

On va passer à la configuration de l'analyseur des fichiers de log, editez le fichier prelude-lml.conf :

# vim /usr/local/etc/prelude-lml/prelude-lml.conf

[prelude]
# Adresse du serveur maitre (dans notre cas il s'agit du même serveur)
server-addr = 127.0.0.1

[format=syslog]
time-format = "%b %d %H:%M:%S"
prefix-regex = "^(?P<timestamp>.{15}) (?P<hostname>\S+) (?:(?P<process>\S+?)(?:\[(?P<pid>[0-9]+)\])?: )?"

# Ajout des fichiers de log à analyser
file = /var/log/messages
file = /var/log/auth.log
file = /var/log/daemon.log
file = /var/log/mail.log
file = /var/log/syslog
file = /var/log/user.log

[Pcre]
ruleset=/usr/local/etc/prelude-lml/ruleset/pcre.rules

Ajout des règles de Prelude-LML :

Tout à l'heure, pendant les étapes de compilation, nous avons téléchargé les règles de détection de Prelude-LML, il ne faut pas oublier de les mettre au bon endroit :

cd /tmp
tar -xzf prelude-lml-rules-1.2.5.tar.gz
cd prelude-lml-rules-1.2.5
cp -r ruleset /usr/local/etc/prelude-lml/

Ajout des scripts init.d

Malheuresement, aucun script de gestion des services n'est fournit avec les tarball d'installation du site officiel. Mais on va ruser !

Une solution possible est de récupérer les scripts init.d fournit avec les paquets v1.0.1 depuis les dépôts officiels puis de les modifier pour qu'ils soient compatibles avec la version 1.2.5.

N'exécutez pas les commandes ci-dessous, c'est seulement pour vous montrer comme on procéde pour récupérer un fichier spécifique présent dans un paquet debian :

apt-get download prelude-manager
dpkg --extract prelude-manager_1.0.1-4_i386.deb prelude-manager
cd prelude-manager
cp etc/init.d/prelude-manager /etc/init.d/prelude-manager

J'ai mis les 3 scripts init.d sur Gist, entrez les commandes suivantes pour les ajouter au dossier /etc/init.d :

cd /etc/init.d

wget https://gist.githubusercontent.com/hardware/92ffda173ed4db68be6f/raw/89e146a5869b09f53863a13f90f146b5d76a408f/prelude-manager
wget https://gist.githubusercontent.com/hardware/e21731a31e03721a4633/raw/72eb18e8da30c8972def826e35f520f5d8926f46/prelude-lml
wget https://gist.githubusercontent.com/hardware/ae6969680e5ba2c6579a/raw/c527bd432b5f52e3192d118f701a88742753ef54/prelude-correlator

chmod +x prelude-manager prelude-lml prelude-correlator

Démarrage des services

Il ne reste plus qu'à démarrer les services :

service prelude-manager      start
service prelude-lml          start
service prelude-correlator   start
service prewikka             restart

Exécutez les commandes suivantes pour que les services démarrent automatiquement lors du boot :

update-rc.d prelude-manager      defaults
update-rc.d prelude-lml          defaults
update-rc.d prelude-correlator   defaults
update-rc.d prewikka             defaults

Vérification du fonctionnement des sondes

Bon maintenant que tout est enfin en place, on va vérifier à partir de Prewikka, que toutes les sondes sont bien actives et opérationnelles.

Connectez-vous à l'interface web de Prelude :

IP_DU_SERVEUR:8000

Vérifiez que les 3 agents sont bien en marche :

Maintenant il ne vous reste plus qu'à attendre que des évènements notables surviennent sur votre serveur (une connexion, un changement de mot de passe, une attaque par brute-force, une application qui génére des erreurs...etc). Pour visualiser alertes en cours, cliquez sur "Alertes" :

Grâce à ce screen, on peut voir que mon serveur (scofield.meshup.net) à subit 4 attaques par Brute Force, plus de 20 tentatives de connexion, une IP reconnue par DSHIELD (donc un vilain qui a déjà été repéré auparavant) et tout ceci en l'espace d'une heure

Cliquez sur une alerte pour voir tous les détails :

Prelude receuille énormement d'informations lors d'une alerte. Comme on peut le voir ci-dessus, nous avons l'heure précise à laquelle l'alerte a été déclanchée, sur quel serveur, avec une description précise et un niveau de gravité. Il y aussi le service qui est atteint (ici il s'agit de SSH), les alertes corrélées...etc.

Genial non ?

Prelude peut aussi générer des statistiques avec un top 10 des adresses ip suspectes, les ports scannés régulièrement, les types d'alertes...etc

Les types d'alertes générées :

Les niveaux de gravité :

Les groupes/règles :

Optimisation de la base de donnée

La taille de la base de donnée évolue en fonction du nombre d'évènements analysés par les agents. Il n'est pas anormal d'avoir plusieurs centaines de milliers d'entrées dans la BDD après un mois d'utilisation. Pour éviter cela, on va utiliser un script avec un tâche CRON pour que la suppression des alertes se fasse de manière automatique et périodique :

#!/bin/bash

set -e

DBTYPE="mysql"
DBHOST="localhost"
DBNAME="prelude"
DBUSER="prelude"
DBPASS="xxxxxx"

# Supprimer tous les évènements antérieur à 1 mois
KEEPINTERVAL="1 month"
DATE=$(date -d "now - $KEEPINTERVAL" +%Y-%m-%d)

# Suppression des alertes
/usr/local/bin/preludedb-admin delete alert     --criteria "alert.create_time     <= $DATE" "type=$DBTYPE host=$DBHOST name=$DBNAME user=$DBUSER pass=$DBPASS"

# Suppression des alertes de type heartbeat (vérification de fonctionnement de l'hôte)
/usr/local/bin/preludedb-admin delete heartbeat --criteria "heartbeat.create_time <= $DATE" "type=$DBTYPE host=$DBHOST name=$DBNAME user=$DBUSER pass=$DBPASS"

Créer un nouveau fichier nommé /usr/local/bin/prelude-del-events et ajouter le script ci-dessus dedans puis rendez-le exécutable :

chmod +x /usr/local/bin/prelude-del-events

Puis ajouter une nouvelle tâche qui se lance tous les jours à minuit par exemple:

# crontab -e

0 0 * * * /usr/local/bin/prelude-del-events > /dev/null 2>&1

Synchronisation des composants de Prelude

Les agents de Prelude peuvent parfois ne plus être synchronisés entre eux à cause le plus souvent d'une désynchronisation temporelle entre les serveurs. Pour éviter ce type de problème, il est conseillé d'utiliser le protocole NTP pour que vos serveurs soient synchronisés à la seconde près.

Je me suis fait un script pour relancer les composants de Prelude qui ne sont plus en service :

#!/bin/bash

CSI="\033["
CEND="${CSI}0m"
CGREEN="${CSI}1;32m"
CRED="${CSI}1;31m"

PL=$(ps -e | grep prelude-lml | wc -l)
PC=$(ps -e | grep prelude-correla | wc -l)
PREWIKKA_PID=$(netstat -tlnp | awk '/:8000 */ {split($NF,a,"/"); print a[1]}')
PRELUDE_MANAGER_PID=$(netstat -tlnp | awk '/:4690 */ {split($NF,a,"/"); print a[1]}')

# Vérification du fonctionnement de Prelude Manager
if [[ $PRELUDE_MANAGER_PID -gt 0 ]]; then
    echo -e "${CGREEN}[OK]${CEND} Prelude Manager est actuellement en service"
else
    echo -e "${CRED}[KO]${CEND} Prelude Manager n'est pas en service, démarrage imminent..."
    /etc/init.d/prelude-manager start
fi

# Vérification du fonctionnement de Prelude LML
if [[ $PL -eq 1 ]]; then
    echo -e "${CGREEN}[OK]${CEND} Prelude LML est actuellement en service"
else
    echo -e "${CRED}[KO]${CEND} Prelude LML n'est pas en service, démarrage imminent..."
    /etc/init.d/prelude-lml start
fi

# Vérification du fonctionnement de Prelude Correlator
if [[ $PC -eq 1 ]]; then
    echo -e "${CGREEN}[OK]${CEND} Prelude Correlator est actuellement en service"
else
    echo -e "${CRED}[KO]${CEND} Prelude Correlator n'est pas en service, démarrage imminent..."
    /etc/init.d/prelude-correlator start
fi

# Vérification du fonctionnement de Prewikka
if [[ $PREWIKKA_PID -gt 0 ]]; then
    echo -e "${CGREEN}[OK]${CEND} Prewikka est actuellement en service"
else
    echo "Prewikka n'est pas en service, démarrage imminent..."
    /etc/init.d/prewikka start
fi

exit 0

Créer un nouveau fichier nommé /usr/local/bin/prelude-check-components et ajouter le script ci-dessus dedans puis rendez-le exécutable :

chmod +x /usr/local/bin/prelude-check-components

Puis ajouter une nouvelle tâche qui se lance toutes les heures par exemple:

# crontab -e

0 * * * * /usr/local/bin/prelude-check-components > /dev/null 2>&1

Lancez le script manuellement :

/usr/local/bin/prelude-check-components

Si tous les composants sont en service, vous devriez avoir ceci :

[OK] Prelude Manager est actuellement en service
[OK] Prelude LML est actuellement en service
[OK] Prelude Correlator est actuellement en service
[OK] Prewikka est actuellement en service

BONUS : Accéder à Prewikka avec Nginx

Ajoutez un nouveau vhost :

# vim /etc/nginx/sites-enabled/prewikka.conf

upstream prewikka-upstream {
    server 127.0.0.1:8000 weight=1 fail_timeout=300s;
}

server {
   listen 80;
   server_name prelude.domain.tld;

   location / {

   proxy_set_header Host              $host;
   proxy_set_header Origin            http://$host;
   proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
   proxy_set_header X-Real-IP         $remote_addr;
   proxy_set_header X-Forwarded-Proto https;
   proxy_set_header Upgrade           $http_upgrade;
   proxy_set_header Connection        $http_connection;

   proxy_redirect     off;
   proxy_read_timeout 5m;

   proxy_pass http://prewikka-upstream;

   }

}

Puis redémarrez Nginx :

service nginx restart

Voila Prelude est maintenant accessible à partir d'une jolie URL :

http://prelude.domain.tld/

N'oubliez pas de changer l'interface d'écoute en modifiant la ligne suivante dans le fichier /etc/init.d/prewikka :

/usr/local/bin/prewikka-httpd -a 127.0.0.1 -p 8000 -c /usr/local/etc/prewikka/prewikka.conf &

ATTENTION : L'application Ajenti écoute aussi sur le port 8000, voir ce post pour plus d'info : http://mondedie.fr/d/5822/35

Ossec est un HIDS (Host-based Intrusion Detection System), son rôle est de détecter une intrusion en temps réel au sein d'un système informatique en s'appuyant sur différentes techniques comme l'analyse des logs, la vérification d'intégrité des fichiers système et des fichiers de configuration, en détectant les rootkits...etc.

C'est aussi un IPS (Intrusion Prevention System), il peut ainsi détecter les robots/scripts qui scannent les ports du serveur, les attaques de type Brute Force sur des services comme SSH, FTP, Nginx, Apache, Postfix...etc Il analyse aussi automatiquement toutes les requêtes HTTP(s) (POST/GET/PUT/DELETE) pour repérer l'exploitation de faille XSS, SQL en les comparant avec des patterns d'attaques connues.

Les adresses IP suspectes sont identifiées et bloquées automatiquement par "active response" et "firewall drop". Ossec ne fait pas dans la douceur

Ossec peut aussi fonctionner en mode Manager/Agents. Le manager correspond au serveur central de votre architecture qui détient toutes les règles de sécurité et la configuration principale de votre système et recueil les informations, les évènements, les tests d'intégrité et les audits provenant de tous agents associés au serveur maitre.

Dans ce tutoriel, pour des questions de simplicité, nous allons rester dans un schéma simple, avec un seul serveur à surveiller donc nous ne parlerons pas de la gestion des agents.

Pensez à mettre à jour votre système avant de commencer :

apt-get update && apt-get dist-upgrade

Installation d'Ossec

Liens utiles :
http://www.ossec.net/
http://en.wikipedia.org/wiki/OSSEC
http://ossec-docs.readthedocs.org/en/latest/index.html

On ne v'a pas passer par les dépôts d'AlienVault pour installer ossec, on va plutôt utiliser le script d'installation officiel fournit avec le tarball pour nous faire une installation aux petits oignons

Exécutez les commandes suivantes :

cd /tmp
wget https://bintray.com/artifact/download/ossec/ossec-hids/ossec-hids-2.8.3.tar.gz
tar xzf ossec-hids-2.8.3.tar.gz
cd ossec-hids-2.8.3/

# Ajout du support de Prelude si vous l'avez installé, ce n'est pas obligatoire
cd src && make setprelude && cd ..

# Deux librairies dev sont nécessaires pour la compilation (sous debian 8.1 en tout cas)
apt-get install libgcrypt20-dev libgnutls28-dev

Puis lancez le script d'installation :

./install.sh

Lors de l'installation, répondez à toutes les questions :

OSSEC HIDS v2.8.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 scofield 3.2.0-4-686-pae

Utilisateur: root

Hôte: hostname

-- Appuyez sur Entrée pour continuer ou Ctrl-C pour annuler. --

1- Quel type d'installation voulez-vous (serveur, agent, local ou aide) ? serveur

Installation du serveur 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 ? admin@domain.tld

Nous trouvons votre serveur SMTP sur: mail.domain.tld.

Voulez-vous l'utiliser ? (o/n) [o]: o

--- Serveur SMTP utilisé : mail.domain.tld.

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

- Réponse active activée.

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 :

xxx.xxx.xxx.xxx
xxx.xxx.xxx.xxx

Voulez-vous d'autres adresses IP dans votre liste (white list) ? (o/n)? [n]: n

3.5- Voulez-vous activer fonctionnalité syslog (port udp 514) ? (o/n) [o]: o

Fonctionnalité syslog activé.

3.6- Mise en place de la configuration pour analyser les logs suivants :
-- /var/log/messages
-- /var/log/auth.log
-- /var/log/syslog
-- /var/log/mail.info
-- /var/log/dpkg.log
-- /var/log/nginx/access.log (apache log)
-- /var/log/nginx/error.log (apache log)

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 .

Une fois la compilation terminée, vous devriez avoir ceci :

- 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
( [url]http://www.ossec.net/en/mailing_lists.html[/url] ).

Plus d'information peut être trouver sur [url]http://www.ossec.net[/url]

Configuration d'Ossec

Maintenant que l'installation est terminée, il faut le configurer. Cette étape n'est pas obligatoire, en fait Ossec est déjà opérationnel car il a été pré-configuré par le script d'installation. Il suffit juste de lancer tous les agents locaux avec la commande service ossec start pour voir Ossec en action

On va quand même prendre quelques minutes et jeter un coup d'oeil à l'arborescence et aux fichiers de configuration :

# ls -alX /var/ossec

dr-xr-x---  3 root  ossec 4096 Aug 30 18:02 active-response
dr-xr-x---  2 root  ossec 4096 Aug 30 17:05 agentless
dr-xr-x---  2 root  ossec 4096 Aug 30 17:05 bin
dr-xr-x---  3 root  ossec 4096 Aug 30 17:05 etc
drwxr-x---  5 ossec ossec 4096 Aug 30 17:05 logs
dr-xr-x--- 11 root  ossec 4096 Aug 30 17:05 queue
dr-xr-x---  4 root  ossec 4096 Aug 30 17:05 rules
drwxr-x---  5 ossec ossec 4096 Aug 30 17:07 stats
dr-xr-x---  2 root  ossec 4096 Aug 30 17:05 tmp
dr-xr-x---  3 root  ossec 4096 Aug 30 17:58 var

Description des répertoires importants :

active-response : Scripts exécutés par le module Active-response, par exemple firewall-drop.sh permettant de ban les ips suspectes.
bin : Contient tous les exécutables et binaires d'Ossec.
etc : Contient les fichiers de configuration.
logs : Contient les logs générés par les modules d'Ossec et les agents.
rules : Contient toutes les règles de sécurité.
var : Contient les fichiers de processus (PID) des agents.

Le fichier de configuration principal est stocké dans le répertoire /var/ossec/etc/ossec.conf. C'est un fichier XML qui permet de définir les règles à inclure, le/les adresses emails de notification, les fichiers à surveiller..etc. Je vais diviser le fichier de configuration par blocs pour mieux vous expliquer le rôle de chacun.

La configuration des alertes par email et des IPs White-listées se fait dans le block Global :

<global>
    <!-- Notifications par email -->
    <email_notification>yes</email_notification>
    <email_to>admin@domain.tld</email_to>
    <smtp_server>mail.domain.tld.</smtp_server>
    <email_from>ossecm@domaine.tld</email_from>

<!-- White List -->
<white_list>127.0.0.1</white_list>
<white_list>^localhost.localdomain$</white_list>
<white_list>xxx.xxx.xxx.xxx</white_list>
</global>

Vous devez installer un serveur smtp pour que les alertes puissent être envoyés par Ossec, allez voir l'installation de postfix dans ce tutoriel.

Configuration du reporting des alertes :

<alerts>
    <!-- On enregistrement l'évènement dans les logs à partir du niveau 1 -->
    <log_alert_level>1</log_alert_level>
    <!-- On envoie un email à partir du niveau 6 -->
    <email_alert_level>6</email_alert_level>
</alerts>

Ensuite vous pouvez choisir les règles à inclure pour qu'Ossec sache comment surveiller les services installés sur votre serveur. C'est à vous de choisir les règles qui conviennent le mieux à votre installation. La liste suivante est plutôt pertinente dans le cas d'un serveur sous Linux :

<rules>
    <include>rules_config.xml</include>
    <include>pam_rules.xml</include>
    <include>sshd_rules.xml</include>
    <include>telnetd_rules.xml</include>
    <include>syslog_rules.xml</include>
    <include>arpwatch_rules.xml</include>
    <include>named_rules.xml</include>
    <include>smbd_rules.xml</include>
    <include>vsftpd_rules.xml</include>
    <include>pure-ftpd_rules.xml</include>
    <include>proftpd_rules.xml</include>
    <include>ftpd_rules.xml</include>
    <include>hordeimp_rules.xml</include>
    <include>roundcube_rules.xml</include>
    <include>wordpress_rules.xml</include>
    <include>vpopmail_rules.xml</include>
    <include>vmpop3d_rules.xml</include>
    <include>courier_rules.xml</include>
    <include>web_rules.xml</include>
    <include>web_appsec_rules.xml</include>
    <include>apache_rules.xml</include>
    <include>nginx_rules.xml</include>
    <include>php_rules.xml</include>
    <include>mysql_rules.xml</include>
    <include>postgresql_rules.xml</include>
    <include>ids_rules.xml</include>
    <include>squid_rules.xml</include>
    <include>firewall_rules.xml</include>
    <include>postfix_rules.xml</include>
    <include>sendmail_rules.xml</include>
    <include>imapd_rules.xml</include>
    <include>mailscanner_rules.xml</include>
    <include>dovecot_rules.xml</include>
    <include>vpn_concentrator_rules.xml</include>
    <include>spamd_rules.xml</include>
    <include>trend-osce_rules.xml</include>
    <include>vmware_rules.xml</include>
    <include>ossec_rules.xml</include>
    <include>attack_rules.xml</include>
    <include>clam_av_rules.xml</include>
    <include>local_rules.xml</include>
</rules>

Le bloc suivant se nomme syscheck, il permet de configurer le module de vérification d'intégrité des fichiers système. Ossec analyse et enregistre le checksum des fichiers de configuration et des binaires puis vérifie tous les jours si des modifications ont été apportées en comparant les checksums de la journée précédente.

<syscheck>
    <!-- Fréquence de vérification en secondes -->
    <frequency>79200</frequency>

<!-- Répertoires à vérifier -->
<directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
<directories check_all="yes">/bin,/sbin</directories>

<!-- Répertoires et fichiers à ignorer -->
<ignore>/etc/mtab</ignore>
<ignore>/etc/mnttab</ignore>
<ignore>/etc/hosts.deny</ignore>
<ignore>/etc/mail/statistics</ignore>
<ignore>/etc/random-seed</ignore>
<ignore>/etc/adjtime</ignore>
<ignore>/etc/httpd/logs</ignore>
<ignore>/etc/utmpx</ignore>
<ignore>/etc/wtmpx</ignore>
<ignore>/etc/cups/certs</ignore>
<ignore>/etc/dumpdates</ignore>
<ignore>/etc/svc/volatile</ignore>
</syscheck>

Ensuite le bloc de configuration du module anti-rootkit/trojans. Ossec vérifie aussi la présence de Rootkit/Trojans en cherchant au sein du système des programmes vérolés en se basant sur des signatures/patterns référencés.

<rootcheck>
    <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
    <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>
    <system_audit>/var/ossec/etc/shared/system_audit_rcl.txt</system_audit>
    <system_audit>/var/ossec/etc/shared/cis_debian_linux_rcl.txt</system_audit>
</rootcheck>

Les réponses actives sont configurées dans des blocs nommé "active-response", on va prendre un exemple pour mieux comprendre :

<active-response>
    <command>firewall-drop</command>
    <location>local</location>
    <level>6</level>
    <timeout>600</timeout>
</active-response>

<command>
    <name>firewall-drop</name>
    <executable>firewall-drop.sh</executable>
    <expect>srcip</expect>
    <timeout_allowed>yes</timeout_allowed>
</command>

Cette réponse active exécute la commande local firewall-drop pour TOUS les évènements de niveau >= 6. Le script firewall-drop.sh ban les IPs associées à ces évènements pour une durée de 600 secondes (10 minutes).

Pour voir les adresses ip drop, vous pouvez utiliser iptables :

# iptables -L INPUT -v -n | less

Chain INPUT (policy ACCEPT 58M packets, 3173M bytes)
 pkts bytes target     prot opt in     out     source               destination
  203 19629 DROP       all  --  *      *       82.125.xx.xxx        0.0.0.0/0
    0     0 DROP       all  --  *      *       5.34.xxx.xxx         0.0.0.0/0
    0     0 DROP       all  --  *      *       96.27.xx.xx          0.0.0.0/0

Pour débannir une adresse IP, exécutez l'un de ces deux scripts (en fonction de l'AR qui a banni l'IP) :

/var/ossec/active-response/bin/host-deny.sh delete - ADRESSE IP
/var/ossec/active-response/bin/firewall-drop.sh delete - ADRESSE IP

Il ne manque plus qu'une chose à configurer, les fichiers de log à surveiller. Vous devez spécifier le format du fichier de log et son chemin :

<localfile>
    <log_format>syslog</log_format>
    <location>/var/log/messages</location>
</localfile>

<localfile>
    <log_format>syslog</log_format>
    <location>/var/log/auth.log</location>
</localfile>

<localfile>
    <log_format>apache</log_format>
    <location>/var/log/nginx/access.log</location>
</localfile>

<localfile>
    <log_format>apache</log_format>
    <location>/var/log/nginx/error.log</location>
</localfile>

...etc

Les règles de détection

Par défaut les règles de détection fonctionnent plutôt bien, généralement vous ne modifierez pas les règles vous même parce qu'elles sont adaptées à un grand nombre de cas de figure. Mais il peut arriver qu'une règle soit trop ou pas assez restrictive.

Je vais prendre un exemple tout bête qui m'est arrivé il y a quelques mois 😛. Je me suis fait ban par Ossec en téléchargeant un fichier volumineux contenu sur mon serveur avec IDM (Internet Download Manager). Le problème c'est qu'IDM ouvre plusieurs connexions HTTP/FTP vers le serveur distant pour pouvoir télécharger plus rapidement.

Par défaut, Ossec est configuré pour interdir ce genre d'utilisation en limitant le nombre de connexions. Si la limite est atteinte, l'active response drop l'adresse IP. On va regarder ensemble la règle qui définie cette action :

# rules/pure-ftpd_rules.xml

<rule id="11307" level="10" frequency="6" timeframe="60">
    <if_matched_sid>11301</if_matched_sid>
    <same_source_ip />
    <description>Multiple connection attempts from same source.</description>
    <group>recon,</group>
</rule>

<rule id="11301" level="3">
    <if_sid>11300</if_sid>
    <match>[INFO] New connection from</match>
    <description>New FTP connection.</description>
    <group>connection_attempt,</group>
</rule>

Explication :

Règle 11037 : SI le système détecte plus de 6 nouvelles connexions avec la même adresse IP dans un laps de temps inférieure à 60 secondes alors il déclenche une alerte de niveau 10. Ossec voit qu'une alerte de niveau 10 a été créée, l'active response se met donc en marche en dropant l'adresse ip à l'origine de la connexion.

Dans mon cas, j'ai juste eu à modifier la fréquence en la passant à 9 au lieu de 6 car mon IDM ouvre 8 connexions simultanément \o/

Maintenant vous vous posez peut-être la question suivante :

Mais comment trouver la règle qui pose problème ? Il y a des milliers de règles définies dans Ossec :/

Facile, normalement quand une alerte de niveau >= 6 est déclenchée, Ossec vous envoie automatiquement un email similaire à celui-ci :

OSSEC HIDS Notification.
2014 Aug 30 01:07:09

Received From: hostname->/var/log/pure-ftpd.log
Rule: 11307 fired (level 10) -> "Multiple connection attempts from same source."
Portion of the log(s):

Aug 30 01:07:08 hostname pure-ftpd[xxxx]: [INFO] New connection from xxx.xxx.xxx.xxx
Aug 30 01:07:08 hostname pure-ftpd[xxxx]: [INFO] New connection from xxx.xxx.xxx.xxx
Aug 30 01:07:08 hostname pure-ftpd[xxxx]: [INFO] New connection from xxx.xxx.xxx.xxx
Aug 30 01:07:08 hostname pure-ftpd[xxxx]: [INFO] New connection from xxx.xxx.xxx.xxx
Aug 30 01:07:08 hostname pure-ftpd[xxxx]: [INFO] New connection from xxx.xxx.xxx.xxx
Aug 30 01:07:08 hostname pure-ftpd[xxxx]: [INFO] New connection from xxx.xxx.xxx.xxx
Aug 30 01:07:08 hostname pure-ftpd[xxxx]: [INFO] New connection from xxx.xxx.xxx.xxx
Aug 30 01:07:08 hostname pure-ftpd[xxxx]: [INFO] New connection from xxx.xxx.xxx.xxx

--END OF NOTIFICATION

Il faut récupérer l'ID de la règle (ici 11307) et rechercher le fichier XML correspondant avec fgrep :

fgrep 'id="11307"' /var/ossec/rules/*.xml
/var/ossec/rules/pure-ftpd_rules.xml:  <rule id="11307" level="10" frequency="6" timeframe="60">

Bingo ! On peut maintenant éditer le fichier pure-ftpd_rules.xml et modifier la règle qui pose soucis

Les niveaux de gravité

Les règles de sécurité sont classées selon plusieurs niveau de gravité, de 00 (le minimum) à 16 (le maximum). Voici un petit récapitulatif des niveaux de gravité :

- 00 : À ignorer => Pas d'action à entreprendre

01 : N/S

02 : Notification système, non pertinant vis à vis de la sécurité du système

03 : Événements réussis / autorisés

04 : Les erreurs liées à une mauvaise configuration

05 : Erreurs générées par l'utilisateur

06 : Attaque à faible pertinence

07 : Événements non classés avec une certaine pertinence en matière de sécurité

08 : Événements se produisant pour la première fois

09 : Sources invalides (connexions répétées avec un user qui n'existe pas)

10 : Erreurs générés par plusieurs utilisateurs

11 : Erreurs d'intégrité système

12 : Événements de haute importance (erreurs kernel, attaques spécifiques...)

13 : Détection d'une ou de plusieurs attaques critiques

14 : Détection d'une ou de plusieurs attaques critiques avec correlation (outch :/)

15 : Extrème gravité, faux positif impossible, action à entreprendre immédiatement

16 : Le serveur a été compromis, vous avez perdu la partie. Vous pouvez recommencer si vous le souhaitez mais je vous conseil de vous reconvertir en tant que jardinier au Tibet, par exemple dans le région de Xizang. C'est très paisible là-bas, pas de serveur à surveiller, le pieds quoi 😀

Ajouter Ossec en tant que sonde de Prelude

On commence par modifier le fichier de configuration d'Ossec, /var/ossec/etc/ossec.conf, en ajoutant les 3 lignes suivantes dans la section Global :

<global>
    <!-- Configuration de prelude -->
    <prelude_output>yes</prelude_output>
    <prelude_profile>ossec</prelude_profile>
    <prelude_log_level>4</prelude_log_level>
</global>

Ensuite on ajoute un nouveau profil. C'est toujours le même principe qu'avez les autres sondes, il faut exécuter les deux commandes ci-dessous en parallèle :

prelude-admin registration-server prelude-manager
prelude-admin register ossec "idmef:rw admin:r" localhost --uid ossec --gid ossec

Puis on redémarre les services :

service prelude-manager restart
service prewikka restart
service ossec restart

Normalement vous devriez voir un nouvel agent apparaître sur Prewikka :

OSSEC Web User Interface

Ossec dispose aussi d'une interface web assez sommaire mais très utile pour visualiser les alertes. L'installation est très simple, exécutez les commandes suivantes :

cd /var/www
# Normalement le User-Agent est facultatif mais le site d'Ossec bloque les requêtes qui n'en n'ont pas...
wget --header="User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/31.0" http://www.ossec.net/files/ossec-wui-0.8.tar.gz
tar -xzf ossec-wui-0.8.tar.gz
mv ossec-wui-0.8 ossec
rm -rf ossec-wui-0.8.tar.gz
chown -R www-data:www-data ossec
usermod -a -G ossec www-data
chmod -R 770 /var/ossec/tmp
chgrp www-data /var/ossec/tmp

Ensuite ajoutez un nouveau vhost Nginx :

server {

   listen          80;
   server_name     ossec.domain.tld;
   root            /var/www/ossec;
   index           index.php;
   charset         utf-8;

   auth_basic "Ossec WEB UI";
   auth_basic_user_file /etc/nginx/passwd;

   location / {
      try_files $uri $uri/ index.php;
   }

   location ~* \.php$ {
        include         fastcgi_params;
        fastcgi_pass    unix:/var/run/php5-fpm.sock;
        fastcgi_index   index.php;
        fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
   }

}

Redémarrez Nginx :

service nginx restart

Vous pouvez maintenant accéder l'interface web d'Ossec :

On va en rester là pour l'instant avec Ossec, il vous reste encore pleins de choses à découvrir. N'hésitez pas à aller voir la documentation sur le site officiel pour en apprendre plus afin de créer vos propres règles, vos réponses actives, vos scripts...etc :

http://ossec-docs.readthedocs.org/en/latest/manual/index.html

Pour poser des questions ou discuter du tuto, c'est par ici