Comment utiliser Tripwire pour détecter les intrusions sur un serveur sur un VPS Ubuntu

Introduction

La sécurité est un problème incroyablement complexe lors de l'administration de serveurs en ligne. Bien qu'il soit possible de configurer des pare-feu, des politiques fail2ban, de sécuriser les services et de verrouiller les applications, il est difficile de savoir avec certitude si vous avez effectivement bloqué toutes les attaques.

Un système de détection d'intrusion basé sur l'hôte (HIDS) fonctionne en collectant des informations sur le système de fichiers et la configuration de votre ordinateur. Il stocke ensuite ces informations pour les consulter et valider l'état actuel du système. Si des changements sont constatés entre l'état connu comme sain et l'état actuel, cela pourrait être un signe que votre sécurité a été compromise.

Un système de détection d'intrusion basé sur l'hôte populaire sur Linux est tripwire. Ce logiciel peut suivre de nombreux points de données du système de fichiers afin de détecter si des modifications non autorisées ont eu lieu.

Dans cet article, nous discuterons de la manière d'installer et de configurer tripwire sur une installation Ubuntu 12.04. En raison de la nature des systèmes de détection d'intrusion, il est préférable de suivre ce guide peu de temps après la création de votre serveur, afin que vous puissiez vérifier que le système de fichiers est propre.

Installer Tripwire

Heureusement, tripwire peut être trouvé dans les dépôts par défaut d'Ubuntu. Nous pouvons l'installer avec apt-get en tapant :

sudo apt-get update
sudo apt-get install tripwire

Cette installation passera en revue pas mal de configuration des packages requis.

Tout d'abord, il configurera l'application de messagerie qui est incluse en tant que dépendance. Si vous souhaitez configurer les notifications par e-mail, sélectionnez « site Internet ».

Il vous demandera si vous voulez sélectionner des phrases de passe pendant l'installation. Sélectionnez « oui » pour chacune de ces invites. Il demandera si vous pouvez reconstruire le fichier de configuration. Sélectionnez « oui ». Il posera une question similaire concernant le fichier de politique. Répondez encore une fois « oui ».

Ensuite, il vous sera demandé de choisir et de confirmer une phrase de passe pour la clé du site. Tripwire utilise deux clés pour sécuriser ses fichiers de configuration.

• clé du site : Cette clé est utilisée pour sécuriser les fichiers de configuration. Nous devons nous assurer que les fichiers de configuration ne sont pas modifiés, sinon l’ensemble de notre système de détection ne peut pas être fiable. Comme les mêmes fichiers de configuration peuvent être utilisés pour plusieurs serveurs, cette clé peut être utilisée sur plusieurs serveurs.

• clé locale : Cette clé est utilisée sur chaque machine pour exécuter les binaires. Cela est nécessaire pour s'assurer que nos binaires ne sont pas exécutés sans notre consentement.

Vous choisirez d'abord et confirmerez une phrase de passe pour la clé du site, puis pour la clé locale. Assurez-vous de choisir des phrases de passe solides.

Initialiser la base de données

Après l'installation, vous devez initialiser et configurer votre installation. Comme la plupart des programmes de sécurité, Tripwire est livré avec des paramètres par défaut génériques mais stricts qui peuvent nécessiter un ajustement pour votre installation spécifique.

Tout d'abord, si vous n'avez pas choisi oui pour créer un fichier de politique pendant l'installation, vous pouvez le faire maintenant en exécutant la commande :

sudo twadmin --create-polfile /etc/tripwire/twpol.txt

Vous serez invité à saisir la phrase secrète du site que vous avez configurée précédemment.

Cela crée un fichier de politique chiffré à partir du fichier en texte clair que nous avons spécifié dans le répertoire /etc/tripwire/. Ce fichier chiffré est ce que Tripwire lit réellement lorsqu'il effectue ses vérifications.

Nous pouvons maintenant initialiser la base de données que Tripwire utilisera pour valider notre système. Cela utilise le fichier de politique que nous venons d'initialiser et vérifie les points qui y sont spécifiés.

Parce que ce fichier n'a pas encore été adapté à notre système, nous aurons beaucoup d'avertissements, de faux positifs et d'erreurs. Nous les utiliserons comme référence pour affiner notre fichier de configuration dans un instant.

La manière de base d'initialiser la base de données est d'exécuter :

sudo tripwire --init

Cela créera notre fichier de base de données et se plaindra des choses que nous devons ajuster dans la configuration.

Parce que nous voulons sauvegarder les résultats pour informer nos décisions de configuration, nous pouvons saisir toute instance où il est fait mention d'un fichier, et le mettre dans un fichier dans le répertoire de configuration de Tripwire. Nous pouvons exécuter la vérification et placer les fichiers listés dans un fichier appelé test_results dans notre répertoire de configuration Tripwire :

sudo sh -c 'tripwire --check | grep Filename > test_results'

Si nous consultons ce fichier, nous devrions voir des entrées qui ressemblent à ceci :

less /etc/tripwire/test_results

Filename: /etc/rc.boot
Filename: /root/mail
Filename: /root/Mail
Filename: /root/.xsession-errors
. . .

Configurez le fichier de politique pour correspondre à votre système

Maintenant que nous avons une liste de fichiers qui déclenchent le tripwire, nous pouvons parcourir notre fichier de politique et le modifier pour éliminer ces faux positifs.

Ouvrez la politique en texte clair dans votre éditeur avec les privilèges root :

sudo nano /etc/tripwire/twpol.txt

Effectuez une recherche pour chacun des fichiers qui ont été renvoyés dans le fichier test_results. Commentez toutes les lignes que vous trouvez qui correspondent.

Dans la section « Scripts de démarrage », vous devriez commenter la ligne /etc/rc.boot, car elle n’est pas présente dans un système Ubuntu :

(
rulename = “Boot Scripts”,
severity = $(SIG_HI)
)
{
/etc/init.d             -> $(SEC_BIN) ;
<span class=“highlight”>#</span>/etc/rc.boot            -> $(SEC_BIN) ;
/etc/rcS.d              -> $(SEC_BIN) ;

Il y avait beaucoup de fichiers dans le répertoire personnel /root qui devaient être commentés sur mon système. Tout ce qui n'est pas présent sur votre système doit être commenté :

(
rulename = “Root config files”,
severity = 100
)
{
/root                           -> $(SEC_CRIT) ; # Catch all additions to /root
<span class=“highlight”>#/root/mail                     -> $(SEC_CONFIG) ;</span>
<span class=“highlight”>#/root/Mail                     -> $(SEC_CONFIG) ;</span>
<span class=“highlight”>#/root/.xsession-errors         -> $(SEC_CONFIG) ;</span>
<span class=“highlight”>#/root/.xauth                   -> $(SEC_CONFIG) ;</span>
<span class=“highlight”>#/root/.tcshrc                  -> $(SEC_CONFIG) ;</span>
<span class=“highlight”>#/root/.sawfish                 -> $(SEC_CONFIG) ;</span>
<span class=“highlight”>#/root/.pinerc                  -> $(SEC_CONFIG) ;</span>
<span class=“highlight”>#/root/.mc                      -> $(SEC_CONFIG) ;</span>
<span class=“highlight”>#/root/.gnome_private           -> $(SEC_CONFIG) ;</span>
<span class=“highlight”>#/root/.gnome-desktop           -> $(SEC_CONFIG) ;</span>
<span class=“highlight”>#/root/.gnome                   -> $(SEC_CONFIG) ;</span>
<span class=“highlight”>#/root/.esd_auth                        -> $(SEC_CONFIG) ;</span>
<span class=“highlight”>#/root/.elm                     -> $(SEC_CONFIG) ;</span>
<span class=“highlight”>#/root/.cshrc                   -> $(SEC_CONFIG) ;</span>
/root/.bashrc                   -> $(SEC_CONFIG) ;
<span class=“highlight”>#/root/.bash_profile            -> $(SEC_CONFIG) ;</span>
<span class=“highlight”>#/root/.bash_logout             -> $(SEC_CONFIG) ;</span>
/root/.bash_history             -> $(SEC_CONFIG) ;
<span class=“highlight”>#/root/.amandahosts             -> $(SEC_CONFIG) ;</span>
<span class=“highlight”>#/root/.addressbook.lu          -> $(SEC_CONFIG) ;</span>
<span class=“highlight”>#/root/.addressbook             -> $(SEC_CONFIG) ;</span>
<span class=“highlight”>#/root/.Xresources              -> $(SEC_CONFIG) ;</span>
<span class=“highlight”>#/root/.Xauthority              -> $(SEC_CONFIG) -i ; # Changes Inode number on login</span>
<span class=“highlight”>#/root/.ICEauthority                -> $(SEC_CONFIG) ;</span>
}

La dernière partie de mon contrôle se plaignait des descripteurs de fichiers dans le système de fichiers /proc. Ces fichiers changent tout le temps, donc cela déclenchera régulièrement des faux positifs si nous laissons la configuration telle quelle.

Dans la section « Appareils et informations du noyau », vous pouvez voir que le système de fichiers /proc est listé pour être vérifié.

(
  rulename = "Devices & Kernel information",
  severity = $(SIG_HI),
)
{
        /dev            -> $(Device) ;
        /proc           -> $(Device) ;
}

Cependant, cela vérifiera chaque fichier sous celui-ci. Nous ne voulons pas particulièrement cela. Au lieu de cela, nous allons supprimer cette spécification et ajouter des options de configuration pour tous les répertoires sous /proc que nous voulons vraiment vérifier :

{
/dev                    -> $(Device) ;
#/proc                  -> $(Device) ;
/proc/devices           -> $(Device) ;
/proc/net               -> $(Device) ;
/proc/tty               -> $(Device) ;
/proc/sys               -> $(Device) ;
/proc/cpuinfo           -> $(Device) ;
/proc/modules           -> $(Device) ;
/proc/mounts            -> $(Device) ;
/proc/dma               -> $(Device) ;
/proc/filesystems       -> $(Device) ;
/proc/interrupts        -> $(Device) ;
/proc/ioports           -> $(Device) ;
/proc/scsi              -> $(Device) ;
/proc/kcore             -> $(Device) ;
/proc/self              -> $(Device) ;
/proc/kmsg              -> $(Device) ;
/proc/stat              -> $(Device) ;
/proc/loadavg           -> $(Device) ;
/proc/uptime            -> $(Device) ;
/proc/locks             -> $(Device) ;
/proc/meminfo           -> $(Device) ;
/proc/misc              -> $(Device) ;
}

Pendant que nous sommes dans cette partie du fichier, nous voulons également faire quelque chose avec le système de fichiers /dev/pts. Tripwire ne vérifiera pas cet emplacement par défaut car il est configuré pour vérifier /dev, et /dev/pts se trouve sur un système de fichiers séparé, dans lequel il n’entrera pas sauf indication contraire. Pour que Tripwire vérifie cela également, nous pouvons le nommer explicitement ici :

{
/dev                    -> $(Device) ;
<span class=“highlight”>/dev/pts                -> $(Device) ;</span>
#/proc                  -> $(Device) ;
/proc/devices           -> $(Device) ;
/proc/net               -> $(Device) ;
/proc/tty               -> $(Device) ;
. . .

La dernière chose que nous allons commenter sont les lignes /var/run et /var/lock afin que notre système ne signale pas les modifications normales du système de fichiers par les services :

(
rulename = “System boot changes”,
severity = $(SIG_HI)
)
{
<span class=“highlight”>#/var/lock              -> $(SEC_CONFIG) ;</span>
<span class=“highlight”>#/var/run               -> $(SEC_CONFIG) ; # daemon PIDs</span>
/var/log                -> $(SEC_CONFIG) ;
}

Enregistrez et fermez le fichier lorsque vous avez terminé de le modifier.

Maintenant que notre fichier est configuré, nous devons le mettre en œuvre en recréant le fichier de politique chiffré que Tripwire lit réellement :

sudo twadmin -m P /etc/tripwire/twpol.txt

Après cela est créé, nous devons réinitialiser la base de données pour appliquer notre politique :

sudo tripwire --init

Please enter your local passphrase:
Parsing policy file: /etc/tripwire/tw.pol
Generating the database...
*** Processing Unix File System ***
Wrote database file: /var/lib/tripwire/tripit.twd
The database was successfully generated.

Tous les avertissements que vous avez reçus précédemment devraient maintenant avoir disparu. S'il y a encore des avertissements, vous devriez continuer à éditer votre fichier /etc/tripwire/twpol.txt jusqu'à ce qu'ils disparaissent.

Vérifier la configuration

Si l'initialisation de votre base de données n'a signalé aucun fichier, alors votre configuration devrait correspondre à votre système à ce stade. Mais nous devrions effectuer une vérification pour voir à quoi ressemble le rapport de tripwire et s'il n'y a vraiment aucun avertissement :

La syntaxe de base pour un chèque est :

sudo tripwire --check

Vous devriez voir un rapport affiché sur votre écran précisant qu'aucune erreur ni modification n'a été trouvée sur votre système.

Une fois cela terminé, vous pouvez être assez confiant que votre configuration est correcte. Nous devrions nettoyer un peu nos fichiers pour supprimer les informations sensibles de notre système.

Nous pouvons supprimer le fichier test_results que nous avons créé :

sudo rm /etc/tripwire/test_results

Une autre chose que nous pouvons faire est de supprimer les fichiers de configuration en texte clair réels. Nous pouvons le faire en toute sécurité car ils peuvent être générés à volonté à partir des fichiers cryptés avec notre mot de passe.

Tout ce que nous avons à faire pour régénérer le fichier texte brut est de passer le fichier crypté à twadmin, de la même manière que nous l'avons fait pour générer la version cryptée. Nous le redirigeons simplement vers un fichier texte brut à nouveau :

sudo sh -c 'twadmin --print-polfile > /etc/tripwire/twpol.txt'

Testez ceci maintenant en déplaçant la version texte vers un emplacement de sauvegarde, puis recréez-la :

sudo mv /etc/tripwire/twpol.txt /etc/tripwire/twpol.txt.bak
sudo sh -c 'twadmin --print-polfile > /etc/tripwire/twpol.txt'

S'il a fonctionné correctement, vous pouvez maintenant supprimer en toute sécurité les fichiers texte simples :

sudo rm /etc/tripwire/twpol.txt
sudo rm /etc/tripwire/twpol.txt.bak

Configurer les notifications par e-mail

Nous configurerons Tripwire pour qu'il s'exécute tous les jours et nous mettrons également en place des notifications automatiques. Pendant le processus, nous pouvons tester comment mettre à jour la base de données lorsque nous apportons des modifications à notre système.

Nous utiliserons la commande mail pour envoyer nos notifications à notre adresse e-mail. Elle n'est pas installée sur notre système actuellement, donc nous devrons la télécharger depuis les dépôts.

Cela nous donne une excellente occasion de voir comment Tripwire réagit aux changements dans le système.

Installez les fichiers comme ceci :

sudo apt-get install mailutils

Maintenant que nous avons installé cette commande, faisons un test de la capacité de notre système à envoyer un rapport Tripwire. Ce rapport contiendra également des avertissements et des modifications, puisque nous venons d'installer un nouveau logiciel sans prévenir Tripwire :

sudo tripwire --check | mail -s “Tripwire report for uname -n” <span class=“highlight”>your_email@domain.com</span>

Vous devriez recevoir sous peu un rapport dans votre email avec des détails sur le nouveau logiciel de messagerie que vous venez d'installer pour envoyer le message ! C'est bien. Cela signifie que Tripwire détecte les changements dans le système de fichiers et que notre logiciel de messagerie fonctionne également.

Nous devrions maintenant « valider » les modifications du logiciel que nous avons apportées en effectuant une vérification interactive pour mettre à jour la base de données.

Nous pouvons faire cela en tapant :

sudo tripwire --check --interactive

Cela exécutera les mêmes tests que d'habitude, mais à la fin, au lieu d'afficher le rapport à l'écran, il est copié dans un fichier texte et ouvert avec l'éditeur par défaut.

Ce rapport entre dans beaucoup de détails sur chaque fichier qui a changé. En fait, sur ma machine, le rapport généré faisait 2 275 lignes. Cette quantité d'informations est extrêmement utile en cas de véritable problème de sécurité, mais dans notre cas, elle n'est généralement probablement pas très intéressante dans l'ensemble.

La partie importante se trouve près du haut. Après quelques informations introductives, vous devriez voir des lignes avec des cases à cocher pour chacun des fichiers ajoutés ou modifiés :

Rule Name: Other binaries (/usr/sbin)
Severity Level: 66
-------------------------------------------------------------------------------

Remove the "x" from the adjacent box to prevent updating the database
with the new values for this object.

Added:
[x] "/usr/sbin/maidag"

Modified:
[x] "/usr/sbin"
. . .

Ces cases à cocher indiquent que vous souhaitez mettre à jour la base de données pour permettre ces changements. Vous devriez rechercher chaque case qui contient un « x » et vérifier que ce sont des changements que vous avez effectués ou avec lesquels vous êtes d'accord.

Si vous n'êtes pas d'accord avec un changement, vous pouvez retirer le « x » de la case et ce fichier ne sera pas mis à jour dans la base de données. Cela fera que ce fichier déclenchera toujours Tripwire lors de la prochaine exécution.

Après avoir décidé quels changements de fichier sont acceptables, vous pouvez enregistrer et fermer le fichier.

À ce stade, il demandera votre phrase de passe locale afin que Tripwire puisse mettre à jour ses fichiers de base de données.

Si nous acceptons toutes les modifications, si nous relançons cette commande, le rapport devrait maintenant être beaucoup plus court et ne lister aucune modification.

Automatiser Tripwire avec Cron

Maintenant que nous avons vérifié que toutes ces fonctionnalités fonctionnent manuellement, nous pouvons configurer un cron job pour exécuter un contrôle tripwire chaque matin.

Nous utiliserons le crontab de root, car les modifications apportées au cronjob système peuvent être effacées lors des mises à jour du système.

Vérifiez si root possède déjà un crontab en exécutant cette commande :

sudo crontab -l

S'il y a un crontab, vous devriez le rediriger dans un fichier pour en faire une sauvegarde :

sudo sh -c 'crontab -l > crontab.bad'

Ensuite, nous pouvons éditer le crontab en tapant :

sudo crontab -e

Si c’est la première fois que vous utilisez crontab, il vous demandera quel éditeur vous souhaitez utiliser. Si vous n’avez pas de préférence pour un autre éditeur, nano est généralement un choix sûr.

Ensuite, vous serez dirigé vers un fichier où nous pouvons automatiser Tripwire. Comme nous exécuterons Tripwire quotidiennement, nous n'avons qu'à décider à quelle heure nous voulons qu'il fonctionne. En général, les services sont exécutés en dehors des heures de pointe pour ne pas perturber les heures d'affluence.

Le format que nous devons utiliser est min hour * * * command. La commande que nous voulons utiliser est la même que celle que nous avons utilisée pour envoyer notre rapport par e-mail auparavant. Nous n'avons pas besoin d'utiliser sudo puisque cela sera exécuté en tant que root.

Pour que Tripwire s'exécute à 3h30 tous les jours, nous pouvons placer une ligne comme celle-ci dans notre fichier :

30 3 * * * /usr/sbin/tripwire --check | mail -s “Tripwire report for uname -n” <span class=“highlight”>your_email@domain.com</span>

Vous pouvez ajuster cela selon vos préférences.

Conclusion

Vous devriez maintenant avoir un système de détection d'intrusion automatisé qui vous envoie des rapports concernant les changements sur votre système de fichiers. Vous devriez examiner régulièrement les rapports envoyés par e-mail et agir lorsqu'il y a des changements détectés, soit en mettant à jour la base de données de Tripwire pour approuver les changements, soit en enquêtant sur une activité suspecte.