Intégrité des fichiers et persistance
Les fichiers système qu'InfraFence surveille avec des empreintes SHA-256 de référence (comptes, sudoers, clés SSH, cron, unités systemd, ld.so.preload) et comment les modifications sont signalées.
Dernière mise à jour:
Les attaquants qui entrent cherchent à rester : une nouvelle clé SSH, une tâche cron, une unité systemd, une bibliothèque préchargée. L'agent conserve une empreinte SHA-256 des fichiers qu'ils utilisent et signale chaque modification.
Fichiers surveillés
| Fichiers | Gravité d'une modification |
|---|---|
/etc/sudoers, /etc/sudoers.d/* |
critique |
/root/.ssh/authorized_keys, /home/*/.ssh/authorized_keys |
critique |
/etc/ld.so.preload |
critique |
/etc/shadow, /etc/ssh/sshd_config |
avertissement |
/etc/crontab, /etc/cron.d/*, /var/spool/cron/crontabs/*, /var/spool/cron/* |
avertissement |
/etc/systemd/system/*.service, /etc/systemd/system/*.timer |
avertissement |
/etc/passwd, /etc/group, /etc/hosts, /etc/resolv.conf |
info |
Fonctionnement
- L'agent enregistre l'empreinte et la taille de chaque fichier à son démarrage, puis les compare toutes les 30 minutes.
- Une modification est signalée par un événement
integrity_changeavec le fichier, l'ancien et le nouveau SHA-256, et l'ancienne et la nouvelle taille. Le même fichier n'est pas signalé de nouveau pendant 6 heures. - Les fichiers de plus de 10 Mo sont ignorés.
- Les empreintes sont reprises à chaque démarrage de l'agent : une modification faite pendant que l'agent était arrêté n'est donc pas signalée.
- Un nouveau fichier dans un répertoire surveillé, par exemple un nouveau fichier dans
/etc/cron.d, est ajouté à la liste de surveillance et signalé à partir de sa prochaine modification.
L'écran Détections des plugins de panneaux d'hébergement affiche ces modifications à côté des détections de malwares.
Ce que dit l'analyse immédiate
L'analyse immédiate d'une modification lit le fichier et la façon dont il a changé, pas seulement l'événement :
| Fichier | Modification | Niveau |
|---|---|---|
authorized_keys de n'importe quel compte |
plus gros, ou du contenu dans un fichier qui était vide : une clé a probablement été ajoutée | Élevé |
authorized_keys |
même taille, contenu différent : une clé a peut-être été remplacée | Élevé |
authorized_keys |
plus petit ou vide : des clés ont été retirées | Faible |
/etc/sudoers, /etc/sudoers.d/* |
modifié / plus petit | Élevé / Moyen |
/etc/ld.so.preload |
contenu ajouté / vidé | Élevé / Moyen |
/etc/passwd, /etc/group |
plus gros / plus petit / même taille | Moyen / Faible / Moyen |
/etc/shadow |
toute modification | Moyen |
/etc/ssh/sshd_config |
toute modification | Moyen |
| fichiers cron, unités systemd | ajoutés ou modifiés / plus petits | Moyen / Faible |
programmes système dans /usr/bin, /usr/sbin, /bin, /sbin |
toute modification | Élevé |
/etc/hosts, /etc/resolv.conf |
toute modification | Faible |
Un fichier vidé se reconnaît à sa taille ou au SHA-256 d'un fichier vide (e3b0c442…). L'analyse montre la taille et l'empreinte avant et après, et les commandes pour vérifier le fichier : pour les clés SSH, les lister, comparer leurs empreintes avec ssh-keygen -lf et voir qui était connecté.
L'agent compare les fichiers toutes les 30 minutes, donc l'analyse cherche les sessions SSH sur le même serveur de 40 minutes avant l'événement à 10 minutes après. Elle dit alors, par exemple, « Il a changé pendant la session SSH de root depuis 203.0.113.9 (Italie) », ou qu'aucune session SSH n'a été enregistrée autour de la modification.
Marquer comme attendu
Quand la modification vient de vous ou d'un collègue, ouvrez l'incident et choisissez Marquer comme attendu, avec une note facultative. Les owners et les admins peuvent le faire ; les membres voient qui l'a marqué, quand, et la note. La modification ne compte plus comme ouverte ou critique, l'événement reste dans l'historique, Rouvrir l'annule, et les deux sont enregistrés dans le journal d'activité. Une modification ultérieure du même fichier est de nouveau ouverte. Avec l'agent 1.0.34 ou ultérieur, le plugin WHM et infrafence-agent panel affichent aussi la modification comme résolue. Voir Événements et activité pour la résolution des problèmes.
L'agent n'a besoin de rien : juste après avoir signalé une modification, il prend le nouveau contenu comme référence, donc la même modification n'est pas signalée de nouveau.
Surveiller, pas bloquer
L'intégrité des fichiers ne fait que signaler : elle ne restaure jamais un fichier. Combinée au risque des sessions SSH, une modification faite pendant une session SSH ouverte augmente le score de risque de cette session.