Falco est connu comme un outil pour Kubernetes, et presque tous les guides le concernant sont écrits pour des grappes. Or il n’est pas lié aux grappes : il surveille les appels système, et sur un serveur ordinaire hébergeant un site cela fonctionne exactement de la même façon. Simplement, presque personne n’écrit sur ce cas.

Il est utile là où les autres outils se taisent. Un web shell sur un site ne viole aucun droit, ne produit aucune connexion échouée et ne correspond à aucune signature s’il a été écrit à la main. Mais il présente un comportement anormal pour un serveur web : le processus PHP-FPM lance un interpréteur de commandes. C’est cela que voit Falco.

Ce qu’il remarque

Événements typiques sur un serveur ordinaire :

  • un interpréteur engendré par le processus du serveur web ou de PHP — signe pratiquement non équivoque d’un web shell ;
  • un programme lancé depuis /tmp, /dev/shm ou /var/tmp ;
  • des fichiers sensibles (/etc/shadow, clés privées) lus par un processus qui n’a rien à y faire ;
  • la modification de binaires système ;
  • une connexion sortante depuis un processus qui ne devrait pas utiliser le réseau.

Installation

Le choix décisif se fait à l’installation : par quel moyen Falco obtient les appels système. La variante moderne repose sur eBPF et n’exige ni compilation de module noyau ni en-têtes du noyau :

sudo falcoctl driver config --type modern_ebpf
sudo systemctl restart falco

Le module noyau classique demande des en-têtes et se recompile après chaque mise à jour du noyau — sur un serveur où les mises à jour s’installent automatiquement, c’est une source récurrente de service mort. Si le noyau est assez récent (5.8 et au-delà), choisissez eBPF et oubliez le problème.

Pour vérifier que des événements arrivent bien :

sudo systemctl status falco
sudo journalctl -u falco -n 50

Le bruit et son élimination

C’est le vrai travail. Le jeu de règles livré vise les environnements conteneurisés, et sur un serveur ordinaire une part importante en est soit inapplicable, soit constamment déclenchée.

Les règles livrées (/etc/falco/falco_rules.yaml) ne se modifient pas — le fichier est remplacé à la mise à jour. Vos changements vont dans /etc/falco/falco_rules.local.yaml, et c’est là aussi que les règles superflues se désactivent :

- rule: Terminal shell in container
  enabled: false

Ce qu’il faut d’ordinaire ajuster sur un serveur sans conteneurs :

  • toutes les règles relatives aux conteneurs — sans conteneurs, elles ne font qu’occuper de la place dans le rapport ;
  • « Write below etc » — se déclenche à chaque installation de paquet et à chacune de vos modifications de configuration. Il faut une exception pour apt, dpkg et unattended-upgrades, sinon les événements arrivent en flot ;
  • « Read sensitive file untrusted » — se déclenche sur les agents de surveillance, les outils de sauvegarde et les outils d’audit comme Lynis ;
  • les lancements depuis des répertoires temporaires — des exceptions légitimes existent : la compilation d’une application, ou un navigateur automatisé qui décompresse un pilote dans un répertoire temporaire. De tels événements paraissent inquiétants mais s’expliquent, et mieux vaut créer aussitôt une exception pour le chemin précis plutôt que de refaire le raisonnement à chaque fois.

L’ordre raisonnable est le même qu’avec tout autre outil de détection : la première semaine, se contenter d’observer et de créer des exceptions, et seulement ensuite traiter un événement apparu comme un signal. La règle est simple — si le rapport contient régulièrement des événements que vous ne lisez pas, il ne vous sert à rien.

Où envoyer les événements

La sortie se règle dans /etc/falco/falco.yaml : un fichier, le journal système ou la transmission à un programme externe. Pour un serveur unique, un fichier avec rotation suffit — n’oubliez pas la rotation, le fichier d’événements grossit comme n’importe quel journal, et par défaut personne ne le surveille.

Les priorités méritent d’être utilisées pour séparer : les événements critiques là où vous les verrez tout de suite, le reste dans le journal général pour examen ultérieur.

Falco et auditd ne sont pas la même chose

Tous deux surveillent les appels système, mais dans des buts différents. auditd enregistre ce qui se passe afin de pouvoir reconstituer le tableau plus tard : il n’évalue rien et ne signale rien, il tient un journal. Falco applique des règles au moment de l’événement et dit « ceci paraît suspect » — il donne donc un signal plutôt qu’un enregistrement.

Garder les deux est raisonnable : le journal pour la reconstitution, les signaux pour la réaction. S’il faut n’en choisir qu’un, auditd est plus utile sur un serveur où l’essentiel est de reconstituer l’enchaînement des événements après un incident ; Falco là où vous voulez un signal précoce sur un mineur en cours d’exécution ou un web shell.

Vaut-il la place sur un petit serveur

Réponse honnête : pas toujours. Falco traite les appels système et se fait sentir au processeur sur une machine chargée. Si le serveur héberge un site et que vous n’avez encore ni contrôle d’intégrité ni mises à jour automatiques correctes, ce n’est pas par là qu’il faut commencer.

Son heure vient plus tard — quand les bases sont posées et que la question restante est de savoir ce qui se passe sur le serveur que les journaux ne montrent pas. Il couvre une classe d’événements mieux que toutes les autres réunies : un interpréteur lancé par le processus du serveur web. À quoi ressemblent les événements répartis par priorité et par règle, la page de démonstration ci-dessous le montre.