De nos jours, les CMS (Joomla, Wordpress, etc) accessibles par Internet font l'objet de tentatives d'exploitation de failles de sécurité en permanence. Si les CMS ne sont pas constamment à jour, le risque est grand que des failles non colmatées soient exploitées et utilisées à des fins malveillantes (spams, attaques sur d'autres sites, etc). C'est pour cette raison que nous utilisons Linux Malware Detect alias maldet pour détecter les malwares. Cependant, même si cela nous permet de traiter le symptôme, la faille qui a permis d'implanter le malware est toujours présente. C'est là qu'intervient l'outil Sysdig.
Sysdig
Sysdig est un outil permettant d'inspecter l'activité « bas niveau » d'un serveur, directement au sein du noyau Linux. Il capture en temps réel tous les événements qui se produisent (lecture/écriture, changement de permissions, etc). Sur un système en production, il est évidemment impossible d'exploiter directement le volume d'information que cela représente. Ça tombe bien, Sysdig est équipé de nombreux filtres :
- processus
- fichiers
- événements
- utilisateurs/groupes
- …
Mise en œuvre
Utilisation d'un filtre Sysdig custom
Les capacités de Sysdig peuvent être étendues via des scripts en Lua nommés « chisels ». Cela permet d'effectuer des traitements avancés sur le flux d'information que Sysdig renvoie. Nous avons repris un chisel existant, fourni avec l'outil, et l'avons modifié pour nos besoins :
Chez Debian, les chisels sont situés dans /usr/share/sysdig/chisels/.
Transformer Sysdig en service
Un des inconvénients de Sysdig est qu'il n'est pas conçu pour fonctionner en tant que service mais uniquement pour être lancé manuellement. On peut remédier à ça en définissant un service systemd
[Unit]
Description=Sysdig Service
After=network.target
[Service]
ExecStart=/usr/bin/sysdig -c spyfile_sysnove
[Install]
WantedBy=multiuser.target
Utilisation pratique
Et voilà, une fois le service installé et lancé, la sortie de Sysdig sera récupérée par le journal de systemd :
# journalctl -u sysdig
-- Logs begin at mar. 2017-01-03 13:02:06 CET. --
janv. 03 16:26:27 hostname sysdig[12859]: 16:21:08.570927985 php-cgi(2874) 8B /var/www/clients/client1/web368/web/wp-content/malware.php
…
Une fois qu'un malware est détecté, il n'y a plus qu'à consulter le journal pour retrouver la date et l'heure précises de l'écriture du fichier. En explorant le journal, il est possible de trouver d'autres intrusions non détectées pour un même site web.
Une fois qu'on a la date et l'heure exacte, il est alors possible d'explorer les journaux d'accès du serveur web pour trouver quelle page a été utilisée pour déposer le malware (formulaire de contact ou d'upload mal protégés par exemple).
Cet outil nous a permis de nettoyer en profondeur des hébergements mutualisés de centaines de Wordpress qui n'étaient pas systématiquement maintenus à jour.
