Un nouveau compte apparaît sur un serveur web, puis un processus tente de lire une clé SSH. Un seul journal ne suffit pas à reconstruire la séquence : associez les événements d'audit Linux au contexte d'exécution fourni par Falco.
1. Préparer un pilote et une référence
Ce scénario suppose Linux x86_64, auditd déjà installé, Falco installé depuis son dépôt officiel avec un moteur de capture compatible, sudo et une destination de logs séparée. Commencez sur une machine de préproduction ; n'installez pas d'outils supplémentaires sur un hôte déjà suspect sans accord de l'équipe incident.
sudo auditctl -ssudo auditctl -lsudo systemctl status auditd --no-pagersudo falco --versionsudo ss -lntupgetent passwdNotez les services, comptes techniques, traitements de sauvegarde et lecteurs légitimes de fichiers sensibles. Dans auditctl, contrôlez lost, backlog et enabled : la valeur 2 signifie que les règles sont verrouillées jusqu'au redémarrage. Ne redémarrez pas un serveur suspect pour contourner ce verrou.
Flux proposé : noyau → auditd et Falco → collecteur protégé → alerte avec hôte, heure UTC, utilisateur et processus. Synchronisez les horloges et limitez l'accès aux logs, qui peuvent contenir des arguments confidentiels.
2. Ajouter des détections ciblées
Chargez ces règles temporaires pour les changements de comptes, de groupes et de permissions. Vérifiez auparavant que la clé guide_identity n'est pas déjà utilisée :
for f in /etc/passwd /etc/shadow /etc/group /etc/gshadow; do sudo auditctl -a always,exit -F arch=b64 -F path="$f" -F perm=wa -k guide_identitydonesudo auditctl -a always,exit -F arch=b64 -F path=/etc/shadow -F perm=r -k guide_readw surveille les écritures, a les attributs, r les lectures. Une écriture sur passwd mérite une corrélation avec useradd/usermod ; elle ne prouve pas une intrusion. Lire passwd est banal : réservez sa surveillance en lecture à une investigation ciblée, avec -F path=/etc/passwd -F perm=r.
Pour un dossier SSH existant, remplacez le chemin :
sudo auditctl -a always,exit -F arch=b64 -F dir=/home/deploy/.ssh -F perm=rwa -k guide_sshsudo auditctl -a always,exit -F arch=b64 -S execve,execveat -F euid=0 -k guide_execLa dernière règle peut produire beaucoup d'événements et enregistrer des arguments : gardez-la pour le pilote ou une fenêtre d'investigation. Dupliquez les règles avec arch=b32 seulement si les exécutables 32 bits sont pris en charge et utilisés. Ne journalisez pas tous les syscalls du serveur.
Après validation, exportez uniquement ces règles dans un fichier de persistance nouveau :
sudo auditctl -l | grep 'guide_' | sudo tee /etc/audit/rules.d/70-guide.rules >/dev/nullsudo augenrules --checkLe fichier sert aux prochains chargements ; les règles temporaires sont déjà actives. Sauvegardez tout fichier préexistant avant de le remplacer.
Ajoutez à /etc/falco/falco_rules.local.yaml, sans écraser les règles existantes, cette détection pédagogique :
- rule: Guide sensitive read desc: Sensitive file opened for reading condition: > evt.type in (open, openat, openat2) and evt.is_open_read=true and evt.rawres>=0 and (fd.name=/etc/shadow or fd.name startswith /home/deploy/.ssh/) output: > Sensitive read user=%user.name process=%proc.name file=%fd.name parent=%proc.pname priority: WARNING- rule: Guide web server shell desc: Shell started directly by a web worker condition: > evt.type in (execve, execveat) and evt.rawres=0 and proc.name in (sh, bash, dash) and proc.pname in (nginx, apache2, httpd, php-fpm) output: > Web shell process=%proc.name parent=%proc.pname user=%user.name priority: WARNINGValidez avec sudo falco --validate /etc/falco/falco_rules.local.yaml, puis rechargez selon votre service. Cette règle ne détecte pas toute exécution suspecte : corrélez aussi chemins inhabituels, nouveaux binaires et processus hors créneau. Construisez des exceptions documentées après observation, jamais une exclusion générale de root.
3. Tester puis enquêter sans nettoyage immédiat
En préproduction, déclenchez une lecture sans afficher le contenu :
sudo head -c 0 /etc/shadowsudo ausearch -k guide_read -ts recent -isudo journalctl -u falco --since '-10 minutes'sudo auditctl -sL'ouverture doit apparaître dans les deux systèmes ; adaptez le nom du service Falco à votre installation. Testez les changements de comptes uniquement avec un compte jetable en laboratoire.
Lors d'une alerte réelle, notez l'heure, le PID, son parent, les connexions et les identifiants d'événement. Exportez les logs vers un stockage d'incident restreint, calculez leurs empreintes et documentez l'opérateur. Une collecte sur machine active modifie son état : faites préserver mémoire et disque par l'équipe compétente si nécessaire. Isolez au niveau réseau tout en gardant le canal de collecte autorisé ; ne supprimez pas immédiatement comptes, fichiers ou conteneurs.
Surveillez événements perdus, files d'attente, CPU, espace disque et nombre d'alertes par règle. Les exclusions trop larges et la lecture systématique de passwd créent respectivement des angles morts et du bruit.
Pour revenir en arrière, retirez les règles ajoutées une à une avec auditctl -d et les mêmes filtres, puis retirez leurs lignes du fichier persistant. N'utilisez pas auditctl -D, qui efface toutes les règles. Restaurez le fichier local Falco précédent, validez et rechargez. Préservez les logs et maintenez les autres détections pendant ce repli.
Sources : Linux Audit, auditctl, Falco, champs des règles.
Retrouvez-le dans nos publications
Les étapes clés de cet article, en carrousel. Suivez-nous pour découvrir les prochaines. Nos publications sont rédigées en anglais.