Nicolas SURRIBAS

Développement / Réseau / Sécurité Informatique

outils

Tutoriel : Mise en place de Foswiki sur openSUSE 12.2

Rédigé par devloop - -

Introduction

Dans le présent article nous allons voir comment mettre en place le logiciel de wiki Foswiki sur un système Linux openSUSE 12.2.

La version de Foswiki utilisée pour ce tutoriel est la 1.1.5. Les éditeurs de Foswiki comptent apporter différentes modifications à leur système pour la prochaine version, par conséquence si vous installez une version supérieure à la 1.1.5, référez vous d'abord aux release notes de la version concernée afin de vous lancer dans ce tutoriel.

La version d'openSUSE utilisée dans cet article est la 12.2 sur un système 32 bits. Le serveur web utilisé est un Apache 2.

Présentation de Foswiki

Foswiki est, comme son nom l'indique, un logiciel collaboratif d'édition d'articles (wiki) qui est libre et open-source (Free and Open Source).
Il est né d'un fork du système de wiki TWiki avec lequel il est resté compatible.

Plusieurs particularités de Foswiki en font un système intéressant à utiliser : il est gratuit, développé en Perl et Javascript et n'utilise pas de base de données par défaut (même si cela est semble t-il possible).

Il dispose d'un système de gestion de versions des articles qui se base sur GNU RCS, un système largement éprouvé dont la première version remonte à 1982.

Il inclut de base différents mécanismes de sécurité dont un wiki peut avoir besoin : gestion de droits avancés par ACL (notion de droits, de groupes et d'utilisateurs), systèmes anti-spam dont les captchas ou l'obfuscation des adresses emails, gestion de blacklist ou notion d'IPs autorisées, protection contre les attaques CSRF...
Il permet aussi de régler facilement la visibilité du wiki sur Internet pour empêcher par exemple l'indexation par les moteurs de recherche.

Il est extensible via de nombreux plugins, dispose d'un outil de recherche performant, un système de compression et de mise en cache des articles, la génération de statistiques et enfin il est multi-langue.

Installation des pré-requis

Dans le présent article nous allons procéder à l'installation de Foswiki 1.1.5 ainsi qu'à l'installation de tous les logiciels nécessaires à son fonctionnement. Cela inclut l'installation d'Apache 2, de RCS ainsi que différents modules Perl.

En fonction du système d'exploitation que vous utilisez, des logiciels déjà présents, etc, vous aurez sans doute à adapter quelque peu les étapes décrites ici.
Dans le cas d'une installation dite "minimale serveur" d'openSUSE (sans interface graphique), le MTA Exim nécessaire à l'envoi de mails est présent par défaut ce qui n'est peut-être pas le cas sur un système Debian.

Maintenant que vous êtes prêt, ouvrez un shell en tant qu'utilisateur root sur le système et installez les paquets suivants (21Mo au total) avec zypper :
zypper in apache2 apache2-mod_perl rcs perl-CGI-Session perl-HTML-Parser perl-HTML-Tree perl-URI perl-Digest-SHA1 perl-Authen-SASL gcc make
Les paquets gcc et make nous permettent de compiler les modules Perl supplémentaires via CPAN. Lancez ces deux commandes :
cpan -i Crypt::Eksblowfish::Bcrypt
Si vous lancez CPAN pour la première fois, plusieurs questions vous seront posées. Vous pouvez répondre yes à toutes les questions.
cpan -i Crypt::PasswdMD5

Activation d'Apache 2

Maintenant que la serveur web Apache est installé, nous allons faire en sorte qu'il soit prêt à accueillir Foswiki :
a2enmod status
a2enmod perl
a2enmod rewrite
systemctl enable apache2.service
systemctl start apache2.service
Notez que le module status n'est pas nécessaire mais très pratique pour s'assurer du bon fonctionnement du serveur.
Ouvrez votre navigateur préféré (ou w3m en ligne de commande) à l'adresse http://127.0.0.1/server-status/ afin de vérifier que le serveur est bien lancé.

Déploiement de Foswiki

Placez vous dans le dossier où vous souhaitez mettre Foswiki et téléchargez y l'archive de Foswiki depuis le site officiel.
Ici nous allons faire en sorte que le répertoire de base de Foswiki soit /srv/www/htdocs/wiki et qu'il soit accessible par l'url /wiki.
Une fois l'archive téléchargée, décompressez là :
tar zxvf Foswiki-1.1.5.tgz
mv Foswiki-1.1.5 wiki
cd wiki
On récupère ensuite l'extension permettant de faire tourner Foswiki avec mod_perl (plus performant qu'en CGI).
wget http://foswiki.org/pub/Extensions/ModPerlEngineContrib/ModPerlEngineContrib.tgz
tar zxvf ModPerlEngineContrib.tgz
On rectifie finalement les droits sur Foswiki afin que le serveur Apache puisse y accéder.
cd ..
chown -R wwwrun.www wiki

Configuration d'Apache 2

Maintenant nous devons indiquer à Apache comment il doit traiter les scripts présents dans Foswiki.
Cela comprend leur exécution par mod_perl ainsi que la redirection des URLs via mod_rewrite.

Heureusement pour nous, Foswiki a mis en place sur son site un générateur de configuration d'Apache.

Rendez-vous sur la page et remplissez le formulaire selon vos besoins.
Attention ! Si vous faites une erreur (même petite) dans la configuration, elle peut potentiellement s'avérer difficile à comprendre par la suite donc vérifiez à deux fois et si vous avez un doute référez vous à la documentation de Foswiki ou basez vous sur ma configuration qui est la suivante :
  • Hostname : opensuse.net
  • URL Path : /wiki
  • Short URLs enable
  • Runtime engine : mod_perl
  • user names that are allowed to access configure : admin
  • Login Manager : TemplateLogin
  • Location of .htpasswd file : /srv/www/htdocs/wiki/data/.htpasswd
  • Page to return when authentication fails : UserRegistration
Cochez aussi les deux recommandations anti-spam et cliquez sur Update config file pour obtenir votre fichier de configuration.
Enregistrez-le par exemple sous le nom foswiki_apache.conf et placez le dans /etc/apache2/vhosts.d (a2ensite n'est plus présent dans openSUSE 12.2). Si vous ne disposez pas de PHP sur votre système, retirez la ligne faisant référence à php_admin_flag sous peine d'avoir une erreur au lancement d'Apache.

Protéger le script configure

La page /wiki/bin/configure est le centre vital de Foswiki qui sera géré par l'administrateur. Il est important que l'on protège cette page par mot de passe comme on l'a sélectionné dans lors de la génération de la configuration d'Apache.

Définissez un mot de passe pour le compte admin avec cette commande (remplacez s3cr3t par le mot de passe de votre choix, choisissez le fort) :
htpasswd2 -cbm /srv/www/htdocs/wiki/data/.htpasswd admin s3cr3t

Configuration de base de Foswiki

Rendez-vous maintenant à l'adresse http://127.0.0.1:8080/wiki/.

Foswiki index

Cliquez sur Configure Foswiki et saisissez les identifiants pour notre compte admin.
Foswiki configure script
Vous devrez valider les chemins d'accès aux fichiers que Foswiki a deviné pour vous. N'hésitez pas à afficher les options expert ou à vous servir des infos-bulles.

Fowiki validate path

Quand vous avez bien tout vérifié, cochez la case Change password (normalement ça se déclenche même décoché la première fois) et cliquez sur Save changes.

Cette étape est primordiale car elle va permettre de générer le fichier lib/LocalSite.cfg qui contient votre configuration Foswiki et aussi de créer l'utilisateur AdminUser qui correspond au root dans les ACL de Foswiki.
A ce sujet, Foswiki dispose d'une fonctionnalité similaire à sudo qui permet de s'identifier temporairement comme AdminUser si vous êtes connecté avec un autre utilisateur, le temps de réaliser une opération privilégiée.

La validation de ces paramètres vous amènera à encore d'autres paramètres de configuration avec probablement des erreurs et des avertissements à corriger.
Rien de grave ! C'est normal à cette étape de la configuration. Prenez juste soin à remplir les champs demandés par Foswiki.
Menu de configuration Foswiki
Dans la section Security and Authentication, choisissez l'encodage bcrypt pour les mots de passe (on a installé le module via CPAN, autant en profiter) et cochez NeedVerification sous Registration.

Cela implique que nous configurions l'envoi de mails qui est demandé par Foswiki.
Entrez une adresse email qui servira d'expéditeur pour les mails de vérifications envoyés aux nouveaux inscrits.
Saisissez aussi les paramètres SMTP (serveur, username, password) correspondant à cette adresse email.
Sauvez les paramètres. Vous pouvez ensuite retourner dans cette section si vous voulez faire un test d'envoi de mail (un bouton est prévu à cet effet)

Mettez de côté pour le moment les paramètres de Tuning et d'Internationalisation : on a plus important à faire pour le moment.

Patcher Foswiki

La version 1.1.5 de Foswiki a un bug connu qui nous concerne malheureusement du moment où l'on souhaite utiliser une langue autre que l'anglais.
Si l'on ne patche pas ce bug, il sera impossible de sauvegarder les articles une fois passé Foswiki en français.

Ouvrez le fichier lib/Foswiki/UI/Manage.pm, allez à la ligne 508 et remplacez
eq 'Cancel'
par
ne ''
Et idem à la ligne 518, remplacez
eq 'Save'
par
ne ''
Sauvegardez le script. Attention le fichier est en lecture seule par défaut.

On va ensuite rectifier un autre bug qui est du à un changement dans le langage de programmation Perl.

Ouvrez le fichier lib/Foswiki/Search/InfoCache.pm et faites une recherche sur le mot length qui devrait vous amenez vers la ligne 249 qui correspond à cette instruction :
$this->{count} = length @{ $this->{list} };
remplacez simplement length par scalar et sauvez le fichier.

Bravo

Redémarrez le serveur Apache :
systemctl restart apache2.service
Rendez vous sur /wiki : Ça y est votre Foswiki est actif :)
Vous pouvez si vous le souhaiter retourner sur configure, section Internationalisation et remplacer en_US.ISO-8859-1 par fr_FR.ISO-8859-1.

En cas d'erreur vous trouverez des logs dans le dossier working/logs de Foswiki mais les plus intéressants seront peut-être les logs d'Apache.
Pensez aussi à surveiller les logs d'Exim.

Classé dans : Non classé - Mots clés : outils, linux

Initiation au système de détection d'intrusion Samhain

Rédigé par devloop - -

Présentation de Samhain

Samhain est un HIDS multiplateforme pour les systèmes UNIX, Linux et Windows (à travers l'utilisation de Cygwin). Il est sous licence libre GNU GPL.
Il fonctionne essentiellement comme un logiciel de vérification d'intégrité du système en surveillant en permanence les fichiers et en reportant toute modification qui a eu lieu.
Il possède toutefois d'autres fonctionnalités qui en font un outil de détection d'intrusion puissant.

Pourquoi utiliser Samhain plutot que X ou Y ?

L'un des avantages de Samhain est que son développement est toujours actif comparé à ses concurrents dont les dernières versions datent un peu : AIDE (février 2011), Tripwire (mars 2010), Osiris (janvier 2007) et Integrit (juin 2007).
De plus en terme de fonctionnalités, il se place largement au dessus des logiciels précédemment cités (voir plus loin).
Son seul vrai rival semble alors être OSSEC que je n'ai pas eu l'occasion de tester.

Pourquoi cet article ?

Tout d'abord les ressources en français sur ce logiciel manquent cruellement et n'entrent pas dans les détails.
Ensuite, malgré la documentation, un utilisateur novice se retrouve face à des questions auxquelles j'ai tenté de répondre dans le présent article.
Enfin c'est l'occasion de partager un point de vue sur un logiciel gratuit et open-source.

L'installation

La compilation du code source est simple et tout ce qu'il y a de plus classique sous Linux : un fichier configure et un makefile.
Toutefois avant de se lancer dans cette opération, je vous conseille vivement de lire la documentation (manuel, FAQ etc) et de faire le tour des fonctionnalités proposées car de nombreuses options du script configure permettent d'inclure des modules intéressants qui ne sont pas présents par défaut.
Pour voir les options de configuration disponibles, vous pouvez vous rendre sur cette page mais le mieux est probablement de lancer un ./configure --help pour lister la totalité des options disponibles dans la version que vous avez récupéré.

Parmi les options supplémentaires dédiées à la sécurité on notera entre autres la surveillance des programmes SetUID, la possibilité de surveiller les modules kernel (présence de rootkit), l'analyse des fichiers journaux, les vérifications sur les systèmes de fichiers montés, la surveillance des ports ouverts et la détection des processus cachés.
Sous Windows (avec Cygwin) un module permet de surveiller les clés de la base de registre.

Une autre des "killer features" pour les utilisateurs avancés est la possibilité de rendre Samhain furtif. On peut offusquer les données de log, dissimuler le fichier de configuration par stéganographie, renommer facilement les exécutables à la compilation ou utiliser un module kernel pour le cacher complètement au système.

Les administrateurs systèmes ne sont pas en reste avec certaines fonctionnalités comme la possibilité de tout loguer vers une base de données (à la place du fichier journal) ou vers un serveur de journalisation central.
Pour des mesures de sécurité ou parce que vous souhaitez monitorer plusieurs machines, vous pourrez en effet mettre en place le serveur de journalisation Yule qui fait partie du projet Samhain.

Pour aller encore plus loin, on citera également le logiciel Beltane qui est une console de gestion web (en PHP) permettant de surveiller efficacement des machines avec Samhain installé.

Samhain offre aussi un support de l'IDS Prelude, activable là aussi par une option de compilation.

Une fois le logiciel configuré puis installé (make) j'ai mis en place le script d'init par la commande make install-boot.

Configuration utilisée pour cet article

Dans mon cas, j'ai utilisé une configuration très basique : la base de Samhain (surveillance des fichiers) ainsi que la surveillance des ports et des processus.

J'ai tenté la première fois d'activer la surveillance des modules kernel mais j'ai obtenu une erreur de compilation. Comme j'avais des doutes sur mon utilisation de cette option (que se passe t-il quand on met à jour le kernel ou le module nVidia ?), je n'ai pas insisté et l'ai désactivé.

J'ai compilé aussi le support de vérification des fichiers SUID mais d'après la documentation ce module est assez gourmand en ressources. Il est toutefois possible de régler son utilisation du disque par des directives spéciales dans le fichier de configuration.

Je n'ai pas non plus utilisé le serveur de log Yule : la journalisation se fait ici en local dans un fichier de log (par défaut /var/log/samhain_log).

Fonctionnement général de Samhain

En tant que vérificateur d'intégrité du système, Samhain surveille tous les fichiers et dossiers présents sur votre système pour vous alerter des modifications. Pour cela il lui faut bien sûr une base initiale qui lui sert de référence et qui contient les noms des fichiers du système avec leur informations associées (taille, timestamps, propriétaires, permissions, attributs étendus...)

Cette base sous format binaire se situe dans le fichier /var/lib/samhain/samhain_file et est nommée "baseline database" ou encore "on-disk database" dans la documentation de Samhain.

Note : le fichier de configuration et cette base de données peuvent être signées cryptographiquement pour ajouter un niveau de sécurité. Voir l'annexe A3 ainsi que le chapitre 8 de la documentation.

Dès que Samhain détectera une modification par rapport à ce qui est enregistré dans la base, il l'indiquera à travers une ligne dans le journal de log.
Cela peut être l'ajout ou la disparition d'un fichier, un changement de taille, de permissions, une date de modification ou de dernier accès etc.

Première utilisation

Une fois Samhain installé sur la machine, il faut créer la base initiale.
On remplie cette base avec la commande suivante qui va scanner vos disques et mémoriser les caractéristiques de chaque fichier et dossier :
samhain -t init -p info
L'option -t permet de spécifier l'action à entreprendre (ici une initialisation) et l'option -p indique le niveau de verbosité à employer sur la sortie console (stdout).
Nous reviendrons plus tard sur cette notion de verbosité.

Le fichier de configuration

Tous les réglages pour fixer quels fichiers et répertoires surveiller et comment les surveiller ainsi que les réactions à produire en fonction des changements détectés sur le système sont définis dans un fichier de configuration unique : /etc/samhainrc.

Ce fichier de configuration en texte seul a une syntaxe très simple :
Ça se résume à des noms de sections dans lesquels se trouvent des couples clé/valeur séparées par le caractère égal (=).

Une section peut apparaître plusieurs fois. Le fichier de configuration fourni par défaut utilise d'ailleurs cette caractéristique pour regrouper les règles (couples clé/valeur) d'après l'emplacement des fichiers sur le disque.

Les commentaires (qui commencent par le caractères dièse) peuvent être utilisés pour mieux s'y retrouver.

Par exemple on écrira :
# --- règles pour /etc ---
[ReadOnly]
file=/etc/passwd

[Attributes]
file=/etc/mtab

# --- règles pour /var ---
[ReadOnly]
dir=/var/lib
[Attributes]
file=/var/tmp
[LogFiles]
file=/var/run/utmp
qui est plus lisible que :
[ReadOnly]
file=/etc/passwd
dir=/var/lib

[Attributes]
file=/etc/mtab
file = /var/tmp

[LogFiles]
file=/var/run/utmp
Ce sera plus efficace pour retrouver une règle ou trouver où en placer une supplémentaire.

Comme vous avez pu le remarquer, les clés les plus fréquentes sont file (quand il s'agit d'un fichier) et dir (pour un dossier). Quand à la valeur il s'agit du chemin vers la ressource concernée.

Les dossiers sont des cas particuliers car ils peuvent être traitées aussi comme des fichiers (sous Linux, tout est fichier).
Ainsi on peut activer une règle pour le contenu d'un dossier avec une clé dir, et une autre règle pour le dossier en lui même avec la clé file. Ca peut éviter des doublons dans le fichier de log car pour toute modification d'un fichier dans le dossier, le dossier en lui-même est aussi modifié (date de dernière modification)...

Il faut tout de même faire très attention aux règles qu'on emploie : si on ne surveille que le contenu du dossier et pas le dossier lui-même, Samhain risque par exemple de passer outre la détection d'une opération de création aussitôt suivie de suppression d'un même fichier : le contenu du dossier n'aura pas eu l'air de changer mais les propriétés du répertoire on gardé d'une trace de cette activité, il peut être utile de le signaler.

Concernant l'ordre dans lequel les règles sont prises en compte, c'est toujours la règle avec le chemin le plus spécifique (le plus proche du fichier concerné) qui l'emporte. L'ordre des sections n'a aucune importance. Les règles indiquées sous une section sont considérées comme en faisant partie.

Un exemple concret et applicable est présent dans le fichier de configuration par défaut :
[ReadOnly]
## for these files, only access time is ignored
dir = 99/etc

[Attributes]
## check permission and ownership
file = /etc/mtab
Il indique à Samhain de surveiller toute modification (sans les dates de dernier accès, section [ReadOnly]) sur les fichiers se trouvant dans /etc, sauf pour le fichier /etc/mtab dont il faut uniquement surveiller les permissions (section [Attributes]) car ce fichier est généré dynamiquement par le système, inutile de reporter les modifications sur son contenu.
On aurait très bien pu inverser les sections avec leurs clés associées, Samhain aurait appliqué les règles de la même façon.

Un autre point à connaître est le fait que si un dossier est à la fois dans une clé dir et une clé file, c'est la clé file qui prédomine.
S'il y a réellement une incohérence (le même couple clé/valeur dans deux sections différentes par exemple), Samhain générera un message d'erreur et refusera probablement de se lancer.

Les clés file et dir ne sont pas les seules clés disponibles mais sont celles auxquelles vous aurez le plus recourt.
Une page de documentation rassemble tout ce qu'il faut connaître sur la gestion des fichiers par Samhain.

Un chemin de fichier indiqué dans une clé file ou dir sera toujours complet, c'est à dire qu'il débutera par le caractère / indiquant la racine.
Les caractères spéciaux du shell Unix (*, ?, [...]) ainsi que d'autres éléments sont acceptés et permettent par exemple d'appliquer des règles à un groupe de fichier correspondant au même pattern.

Pour les clés dir, le chemin peut être précédé d'un indice de récursion (ou de profondeur) indiquant jusqu'à quel niveau de sous-dossier s'applique la règle.
Cet indice est un entier qui peut aller jusqu'à 99. Par défaut, en l'absence de cette indice, il est à 0, c'est à dire que la règle s'applique à tous les éléments directement dans le dossier mais pas aux sous-dossiers.
Un indice de -1 est un cas particulier qui permet de ne pas surveiller le contenu du dossier, quelque soit le niveau de profondeur.

La documentation de Samhain donne 3 exemples concrets pour illustrer cela :

Exemple 1 : Si vous voulez uniquement surveiller les fichiers dans un dossier mais pas l'inode du dossier lui-même, utilisez :
[ReadOnly]
dir = /u01/oracle/archive00
[IgnoreAll]
file = /u01/oracle/archive00
Exemple 2 : Si vous voulez surveiller un dossier, mais pas son contenu qui change fréquemment :
[Attributes]
file = /var/spool/mqueue
file = /tmp
[IgnoreAll]
dir=-1/var/spool/mqueue
dir=-1/tmp
Exemple 3 : Si vous souhaitez surveiller un dossier (en temps que fichier), tout en vous assurant qu'aucun fichier à l'intérieur ne soit supprimé mais pas les attributs actuels de ces fichiers :
[Attributes]
file = /root
[IgnoreAll]
dir=0/root

Les sections pour gérer les fichiers et dossiers

Maintenant que que nous avons vu les clés dir et file, regardons de plus près les sections disponibles.
L'utilisation de ces règles requiert une bonne connaissance des systèmes de fichiers que vous utilisez.
Je vous invite à ce sujet à consulter la page Wikipedia sur les MAC times (modification/access/change).

La section [ReadOnly] permet comme son nom l'indique de surveiller les fichiers qui ne sont pas sensés changer, si ce n'est leur date de dernier accès.
Sont surveillés : le propriétaire, le groupe, les permissions, le type de fichier, le numéro de périphérique, les hard-links (ou lien matériel), les liens symboliques (soft-links), le numéro d'inode, la somme de contrôle, la taille, la date de dernière modification et la date de changement (ctime).
C'est probablement le paramétrage de surveillance le plus complet que vous utiliserez. C'est très pratique pour les fichiers statiques que l'on trouve dans /etc, /bin, /usr...

La section [IgnoreNone] est encore plus radicale car elle surveille le dernier accès (atime). En revanche elle ne prend pas le compte le temps de changement (ctime).
La documentation propose d'utiliser ce paramètre comme un pot de miel pour pirates : placer sur votre système un fichier au nom alléchant (ex: bank_accounts.xls) et indiquer son chemin dans la section [IgnoreNone] pour remonter toute lecture du fichier leurre.

La section [Attributes] permet comme son nom l'indique de surveiller les changements sur les droits (propriétaire, groupe, permissions), le type de fichier et le numéro de périphérique.
Elle ferme les yeux sur les changements de taille et de date.
On peut par exemple utiliser cette section pour surveiller un fichier de base de données : son contenu va changer en permanence, inutile donc de surveiller les modifications. En revanche un changement de propriétaire ou de droit d'accès (passage en exécutable) est suspicieux.

La section [LogFiles] vérifie les fichiers journaux dont la taille peut varier en grandissant ou en diminuant. Tout est surveillé sauf les dates, la taille du fichier et la signature.

La section [GrowingLogFiles] est identique à la précédente sauf que Samhain s'assure que la taille du fichier ne va pas diminuant.

La section [IgnoreAll] ignore toutes les métadonnées concernant un fichier. Elle ne permet que de s'assurer de la présence du fichier.

La section [PreLink] est utilisée pour les librairies préchargées (voir Prelink sur Wikipedia). Je n'en ai pas personnellement l'utilité.

Les sections [UserX] (X allant de 0 à 4 inclus) sont des sections supplémentaires qui par défaut reportent toute modification.

Les sections spécifiques

Les autres sections permettent de fixer des options sur le fonctionnement de Samhain et de ses modules.

La section [EventSeverity] permet de définir le niveau d'alerte renvoyé pour chaque manquement à une règle donnée. Dans cette section on pourra par exemple placer les lignes suivantes :
SeverityReadOnly=crit
SeverityGrowingLogs=warn
SeverityIgnoreAll=info
Les niveaux d'alerte sont décris au chapitre 4.1.1 de la documentation.

La section [Log] est en lien direct avec la précédente. Elle permet de définir des seuils pour chaque méthode de journalisation.
Si une alerte est levée, elle sera journalisée sur tous les systèmes de log dont le seuil est inférieur ou égal au niveau de l'alerte.
Ainsi si le seuil est défini à "warn", les alertes de niveau "info" ne seront pas logués tandis que les alertes de niveau "warn" et "crit" seront historisées.

Dans cette section on utilisera par exemple des clés/valeurs de cette façon :
MailSeverity=crit
LogSeverity=warn
PrintSeverity=info
Ici les alertes de niveau "info" ou supérieures sont envoyées à la console.
Les alertes de niveau "warn" ou supérieures sont conservées dans un fichier.
Les alertes "crit" ou supérieures feront l'objet d'un email envoyé à l'administrateur.
Dans mon cas j'ai défini PrintSeverity à none. J'utilise généralement X mais en cas de plantage je veux pouvoir utiliser la console (Ctrl+Alt+F1) sans être ennuyé.

La section [PortCheck] permet de vérifier les ports ouverts sur la machine. Il faut l'activer avec PortCheckActive=yes.
Par défaut les ports TCP 0 à 65535 sont scannés à un intervalle de secondes définie par la clé PortCheckInterval.
On peut spécifier les ports qui doivent normalement être ouvert avec la clé PortCheckRequired. Celle-ci prend comme valeur une interface (IP) suivi d'un port (ou d'un service) séparé par un slash avec le protocole. On peut spécifier une liste de port/protocole en les séparant par des virgules.

Exemple (présent dans la documentation) :
PortCheckRequired = 192.168.1.128:22/tcp,25/tcp,80/tcp,portmapper/tcp,portmapper/udp
Le même formatage sera utilisé avec les clés PortCheckOptional, PortCheckIgnore et PortCheckSkip.
La clé PortCheckIgnore spécifie les ports ouverts pour lesquels aucune alerte ne sera relevée. Toutefois le scan sur ces ports à tout de même lieu.
Si vous souhaitez que Samhain ne scanne pas du tout un port donné, il faut avoir recours à PortCheckSkip.

Brièvement :
  • La section [SuidCheck] permet de configurer le module de surveillances des fichiers SetUID. Des clés/valeurs spécifiques sont décrites dans la documentation comme la clé SuidCheckFps qui spécifie le nombre de fichiers à surveiller par secondes.
  • La section [Kernel] permet de gérer le module de détection de rootkits.
  • La section [Utmp] surveille les activités des comptes utilisateurs (connexion/déconnexion).
  • La section [Database] permet de configurer l'utilisation d'une base de données.
  • La section [External] permet d'appeler des scripts et programmes externes.
  • La section [ProcessCheck] cherche des processus cachés.
  • La section [Mounts] vérifie les disques montés.
  • La section [Logmon] est dédiée à la surveillance de fichiers journaux. On peut par exemple lever une alerte si une ligne correspondant à une expression régulière est trouvée dans un journal.
  • Enfin la section [Registry] permet de mettre en place une surveillance du registre Windows.
  • Les clés et valeurs possibles pour ces modules sont indiquées dans la documentation ou à décommenter dans le fichier samhainrc fournit avec le logiciel.

    La section [Misc]

    Cette section offre des options de configuration très utiles. La plus importante étant sans doute la clé "Daemon" indiquant à Samhain s'il doit se lancer ou nom en tant que démon.
    Personnellement je l'ai laissé à "yes" ce qui est probablement plus sûr mais vous pouvez très bien préférer de lancer Samhain en tache crontab avec cette option à "no".

    La clé "SetFileCheckTime" défini l'intervalle de temps (en secondes) entre deux vérifications complètes du système.

    Les clés "SetMailAddress", "SetMailRelay" et "MailSubject" sont comme vous le devinez dédiées à l'envoi d'alertes par email.

    Les clés "IgnoreAdded" et "IgnoreMissing" parlent d'elles même. On peut les utiliser pour les fichiers au nom prédéterminés qui apparaissent temporairement (fichier cache d'une application par exemple)

    Les clés "Redef*" permettent de réécrire le fonctionnement d'une section pour ajouter ou retirer des vérifications par rapport à ce qui est fait par défaut.
    La valeur doit être un ensemble de mots clés précédé d'un signe '+' (ajout) ou d'un '-' (retrait).

    Les mots clés sont :
    CHK (checksum)
    TXT (stocker le contenu du fichier dans la base)
    LNK (lien symbolique)
    HLN (hardlink)
    INO (inode)
    USR (utilisateur propriétaire)
    GRP (groupe)
    MTM (mtime)
    ATM (atime)
    CTM (ctime)
    SIZ (taille du fichier)
    RDEV (numéro de périphérique)
    MOD (file mode)
    PRE (Linux; prelinked binary)
    SGROW (file size is allowed to grow)
    AUDIT (Linux; report who changed the file)
    On écrira par exemple :
    RedefReadOnly = -INO,-USR,-GRP
    Ces réécritures doivent apparaître avant les sections concernées. Il est alors préférable de mettre la section [Misc] en tête de fichier.

    La clé "FileNamesAreUTF8" permet d'indiquer à Samhain s'il risque de croiser des noms de fichiers Unicode. En 2011, je vous conseille de le mettre à "yes". On trouve souvent sur le systèmes des noms de fichiers certificats avec des accents... Sans cette option vous risquez d'obtenir des messages "Weird Filename" dans vos logs.

    Le fichier samhainrc fournit par défaut offre une configuration quasi prête à l'emploi mais il faut par exemple changer les noms de fichiers pour l'adapter aux choix propres à la distribution.
    Par exemple le fichier /var/lib/logrotate/status du samhainrc peut être /var/lib/logrotate.status sur votre système.

    Le fichier de log

    Le fichier journal est par défaut /var/log/samhain_log. Au format texte uniquement, il contient un message par ligne.
    Au début vous passerez beaucoup de temps à analyser vos logs car cela vous permettra de peaufiner votre samhainrc pour définir ce qui est une activité normale et ce qu'il faut surveiller.

    Le format des alertes présentes dans le fichier de log est relativement simple à comprendre. Voici à titre d'exemple une alerte que j'ai relevé dans mon log (coupée pour plus de lisibilité) :
    CRIT   :  [2011-04-29T18:41:19+0200] msg=<POLICY [ReadOnly] ---I-M--T->,
    path=</etc/init.d/postfix>,
    mode_old=<-rw-r--r-->, mode_new=<-rwxr-xr-x>,
    attr_old=<------------>, attr_new=<------------>,
    inode_old=<1290353>, inode_new=<1291538>,
    ctime_old=<[2011-03-18T18:20:09]>, ctime_new=<[2011-04-21T14:28:53]>,
    mtime_old=<[2011-02-23T01:13:10]>, mtime_new=<[2011-03-30T22:52:47]>,
    Ici nous avons une alerte de niveau critique (CRIT) qui a été remontée le 24 avril 2011 à 18h41.
    Le fichier /etc/init.d/postfix qui était marqué ReadOnly a été modifié.

    L'inode a été changé ainsi que les dates et les permissions.
    Derrière la section à laquelle se reporte l'alerte se trouve une suite de caractère avec des tirets.

    Ces caractères indiquent rapidement les points qui font l'objet d'une modification.
    Les caractères sont 'C' pour 'checksum', 'L' pour (soft) 'link', 'D' pour 'device number', 'I' pour 'inode', 'H' pour (le nombre de) 'hardlinks', 'M' pour 'mode', 'U' pour 'user' (propriétaire), 'G' pour 'group', 'T' pour 'time' (tous confondus) et 'S' pour 'size'.

    Voici un récapitulatif sous forme de tableau que j'ai récupéré sur le forum de Samhain :
    |==================================
    |Pos|Ltr| Meaning
    | 0 | C | checksum
    | 1 | L | link (soft)
    | 2 | D | rdev (device number)
    | 3 | I | inode
    | 4 | H | hardlinks (number of)
    | 5 | M | mode
    | 6 | U | user (owner)
    | 7 | G | group (owner)
    | 8 | T | atime, ctime, mtime (any)
    | 9 | S | size
    |==================================
    Dans l'alerte, Samhain nous indique aussi les anciennes valeurs qu'il avait en mémoire pour chaque nouvelle valeur.
    Dans mon cas, cette modification fait suite à une mise à jour de Postfix.
    En dehors du changement évident des dates et de l'inode (le fichier a été écrasé), je l'avais désactivé avant la mise à jour avec chmod -x /etc/init.d/postfix, ce qui n'est pas très propre (j'aurais du utiliser chkconfig à la place).
    La mise à jour a donc remis le flag d'exécution sur le fichier.

    Recharger la configuration

    Si vous avez modifié votre fichier samhainrc, il faut dire au programme qu'il doit recharger le fichier de configuration. Vous pouvez bien sûr le stopper et le relancer mais ce n'est pas très propre (voir plus loin).

    Il est possible de recharger la configuration alors que Samhain est en train de tourner (en démon par exemple). Pour cela il faut lui envoyer le signal SIGHUP.
    Récupérer le PID du programme et lancez la commande kill -s SIGHUP <pid de samhain>.
    En ce qui me concerne cette commande ne fonctionne pas correctement puisque le processus arrête de loguer... mais il semble qu'il s'agisse d'un bogue qui a été depuis corrigé.

    Mettre à jour la base de données (baseline database)

    Lorsque Samhain se lance, il charge le fichier de configuration en mémoire ainsi que le base de référence (/var/lib/samhain/samhain_file).
    Quand ensuite il rencontre une modification, il la reporte dans les logs... mais la base n'est pas mise à jour. C'est à l'administrateur d'effectuer cette mise à jour.

    Cette opération de mise à jour fonctionne de manière très basique : il ne s'agit pas d'un "dump" des modifications reportées par Samhain vers la base mais d'un nouveau scan complet du système pour la mettre à jour.

    Du coup, si vous stoppez puis relancez Samhain sans avoir mis la base à jour, vous aurez une incidence au niveau des logs puisque Samhain va reprendre la base de référence non mise à jour et reporter dans les logs les modifications qu'il avait déjà reporté par le passé. Pour peu que Samhain ait fonctionné longtemps, cela va vous générer des logs considérables.
    Il est donc important d'effectuer une mise à jour de la base avant de relancer le démon ou d'éteindre votre machine ou encore de temps en temps en cas de plantage du système.

    L'opération de mise à jour de la base s'effectue en théorie par la commande samhain -t update.
    Seulement il y a des éléments à prendre en considération :
    • Samhain est très protecteur avec son fichier de log. La commande d'update n'aboutira pas car le démon Samhain a posé un verrou dessus. On peut stopper Samhain, mettre à jour la base puis relancer Samhain mais ce n'est pas la bonne méthode. Il est préférable d'effectuer l'update avec les options -l none -p warn. Ainsi l'update n'écrira pas sur le fichier de log (-l none) mais à la place affichera les messages dans la console (-p warn).
    • en l'absence d'options passées en ligne de commande, Samhain prend pour références les options du fichier de configuration. Si vous lancez l'update et que samhainrc indique qu'il doit se lancer en démon, l'update se lancera aussi en démon. On utilisera alors l'option --foreground pour éviter cela.
    Au final, on peut lancer une mise à jour de la base malgré que Samhain soit en train de tourner en démon avec cette commande :
    samhain -t update -l none -p warn --foreground

    Faire la rotation des logs (logrotate)

    Comme Samhain verrouille le fichier de log, l'opération de rotation ne se fera pas simplement.
    Il faut signaler à Samhain de retirer temporairement son verrou en lui envoyant un signal SIGTTIN.
    Il rend alors l'accès au fichier journal possible pendant un laps de temps de 3 secondes.
    Un script pour réaliser cette opération est fourni dans la documentation.

    La sécurité de Samhain

    L'ensemble du chapitre 11 de la documentation couvre la sécurité de Samhain lui-même, c'est à dire les difficultés qu'aurait un pirate à passer inaperçu et effacer ses traces sur un système sur lequel Samhain est installé.
    Cette sécurité semble vraiment excellente. La seule vrai possibilité pour un pirate serait à mon avis d'exploiter une configuration laxiste de Samhain (par exemple une arborescence de fichier non surveillée dans laquelle le pirate pourrait placer ses binaires).
    Le chapitre 11 donne aussi quelques astuces pour renforcer la sécurité de base.

    Trouver de l'aide

    La documentation officielle, les pages de manuel, les exemples dans le fichier samhainrc sont autant de secours pour votre utilisation de Samhain.
    Si malgré ça vous ne trouvez pas de réponses à vos questions, vous pouvez être aidé sur le forum officiel.

    Mon fichier samhainrc pour openSUSE

    A titre d'annexe vous trouverez mon fichier samhainrc que j'utilise sur ma distribution GNU/Linux openSUSE.

    Sur ce, bonne sécurisation à tous !

    Site officiel du projet Samhain

    Classé dans : Non classé - Mots clés : outils, linux

    mansteg : stéganographie dans les manpages

    Rédigé par devloop - -

    Les pages de manuel UNIX, les manpages, se situent généralement dans l'arborescence /usr/share/man et sont stockées compressées (gzippées). Elles permettent d'obtenir des informations sur des commandes ou sur des fonctions du langage C et bien plus encore, le tout en utilisant la commande 'man'.
    Si l'on décompresse l'une de ces pages de manuel on découvre des lignes de textes dans un langage de mise en forme nommé Troff.
    J'ai développé un petit outil de stéganographie qui utilise les manpages pour dissimuler des informations.
    mansteg utilise en effet la possibilité d'insérer des commentaires dans un document troff, commentaires qui ne sont pas visibles lors du rendu de la page de manuel.
    Pour cacher un message, mansteg va l'encoder en base64, le découper en blocks de 64 octets et placer le résultat sous forme de lignes de commentaires dans une page de manuel.
    L'avantage de cette méthode est qu'il n'y a aucune contrainte de taille comme c'est souvent le cas avec les outils de stéganographie.

    Prenons en exemple avec le texte suivant :
    Steganography is the art and science of writing hidden messages in such a way that no one apart from the intended recipient knows of the existence of the message; this is in contrast to cryptography, where the existence of the message itself is not disguised, but the content is obscured.
    que nous allons dissimuler dans la page de manuel de la commande wget (/usr/share/man/man1/wget.1.gz) :
    python hide.py message.txt /usr/share/man/man1/wget.1.gz
    Pour étudier le résultat on décompresse wget.1.gz (gunzip wget.1.gz) et on affiche son contenu. Les premières lignes sont :
    .\" U3RlZ2Fub2dyYXBoeSBpcyB0aGUgYXJ0IGFuZCBzY2llbmNlIG9mIHdyaXRpbmcg
    .\" aGlkZGVuIG1lc3NhZ2VzIGluIHN1Y2ggYSB3YXkKdGhhdCBubyBvbmUgYXBhcnQg
    .\" ZnJvbSB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGtub3dzIG9mIHRoZSBleGlzdGVu
    .\" Y2Ugb2YgdGhlCm1lc3NhZ2U7IHRoaXMgaXMgaW4gY29udHJhc3QgdG8gY3J5cHRv
    .\" Z3JhcGh5LCB3aGVyZSB0aGUgZXhpc3RlbmNlIG9mIHRoZQptZXNzYWdlIGl0c2Vs
    .\" ZiBpcyBub3QgZGlzZ3Vpc2VkLCBidXQgdGhlIGNvbnRlbnQgaXMgb2JzY3VyZWQu
    .\" Cg==
    .\" ****************************************************************
    .\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.3
    .\"
    .\" Standard preamble:
    .\" ========================================================================
    .de Sh \" Subsection heading
    On retrouve notre message encodé, suivi d'une série d'astérisques, ajoutés par mansteg pour délimiter nos commentaires des commentaires déjà présents, puis le début de la page de manuel à proprement parler.

    Pour récupérer notre message, rien de plus simple :
    # python extract.py /usr/share/man/man1/wget.1.gz
    Steganography is the art and science of writing hidden messages in such a way
    that no one apart from the intended recipient knows of the existence of the
    message; this is in contrast to cryptography, where the existence of the
    message itself is not disguised, but the content is obscured.
    Les données sont très facilement récupérables pour quelqu'un qui aurait vu le 'truc' étant donné que l'algorithme base64 est réversible est utilisé couremment. Il est donc préférable de crypter le document à cacher avant de l'insérer dans une page de manuel, par exemple avec gpg. C'est développé en Python et téléchargeable ici :
    mansteg.tar.bz2

    Un script de sauvegarde de vos fichiers de configuration sous Linux

    Rédigé par devloop - -

    Quoi de plus agréable quand on change de distribution d'avoir à disposition ses fichiers de configuration précieusement conservés ?
    Quand on passe du temps à paufiner la configuration du serveur d'affichage ou de son éditeur de texte préféré, l'idée de perdre ces fameux fichiers donne des sueurs froides.

    Seulement lorsque l'on souhaite faire une sauvegarde de ces fichiers on doit tout faire à la main et surtout on a toujours tendance à en oublier quelques uns .
    Cette pour cetre raison que j'ai bricolé un petit script Bash qui rassemble vos fichiers de conf et en fait un belle archive tar.bz2 prête à être copiée à l'abris des crashs.
    Vous pouvez télécharger le script en question ici : saveconfig.sh
    Ce script est très facilement personnalisable. Il se divise en deux sections : la première contient les commandes (le script à proprement parler) et la seconde partie est une liste de fichiers à sauvegarder.
    Vous pouvez aussi bien ajouter des noms de fichiers que de répertoires. Dans tous les cas il faut donner le chemin complet à partir de la racine (/).
    Si vous indiquez un répertoire, tout son contenu sera copié... donc réflechissez bien à ce que vous rajoutez ! Il est peut-être préférable de donner des noms de fichiers appartenant à un même répertoire plutôt que de donner le répertoire entier (je pense en particulier aux répertoires cachées utilisés par les navigateurs et qui contiennent le cache de votre navigation).

    Lancé en utilisateur lambda, saveconfig.sh enregistre les fichiers de configuration du système (dans /etc, /usr...).
    Lancé en root, le script va en plus enregistrer la configuration de chaque utilisateur "humain" (dont l'uid est supérieur ou égal à 500)
    Les fichiers de configuration des utilisateurs doivent être indiqués à l'aide du mot clé _USER_ qui sera remplacé lors de l'utilisation du script par le répertoire home de cet utilisateur (rien de bien compliqué, vous comprendrez facilement en regardant la liste des fichiers par défaut).

    Petite note : saveconfig.sh ne garde pas en mémoire les permissions des fichiers... mais c'est facilement modifiable en modifiant les arguments passés à tar et cp.
    Le script a besoin de bash, awk, tar et bzip2 pour fonctionner.

    Télécharger saveconfig.sh

    Classé dans : Non classé - Mots clés : outils, linux

    dvscan.py : Un scanneur de port en Python

    Rédigé par devloop - -

    dvscan est un scanneur de port simple mais efficace capable de révéler quels ports sont ouverts, fermés ou filtrés sur une machine.

    Il se lance en ligne de commande et prend comme argument l'adresse IP ou le nom d'hôte de la machine.
    Un second argument optionnel permet de spécifier un timeout (en secondes) pour chaque test d'ouverture d'un port.

    Le code utilise des threads, lui permettant de scanner plusieurs ports en même temps. Il ne scanne que des numéros de ports bien connus mais le code source peu être facilement modifié pour rajouter des numéros de ports.

    Télécharger dvscan.py

    Classé dans : Non classé - Mots clés : outils