Le panneau ne modifie pas la config Falco — il affiche seulement le snippet et les commandes à appliquer sur le serveur en SSH.
# /etc/falco/rules.d/local-tuning.yaml - rule: <NOM EXACT DE LA RÈGLE dans la liste ci-dessus> condition: and not fd.name = /path/to/exclude append: true
sudo nano /etc/falco/rules.d/local-tuning.yaml sudo falco --validate /etc/falco/rules.d/local-tuning.yaml sudo systemctl restart falco 2>/dev/null || sudo systemctl restart falco-modern-bpf
Utilisez le nom exact de la règle. Si la liste affiche le texte du message plutôt que le nom, activez la sortie JSON dans falco.yaml (json_output: true) : le panneau recevra alors les noms exacts des règles.
On présente d’ordinaire Falco comme un outil Kubernetes, et presque tout ce qui s’écrit à son sujet suppose un cluster. Il fonctionne pourtant très bien sur un serveur Linux classique, où il observe les appels système et lève une alerte lorsqu’un processus fait ce qui ne le regarde pas : lancer un shell depuis le serveur web, écrire dans un répertoire de binaires système, lire des fichiers sensibles, ouvrir une connexion sortante inattendue.
Cette page présente les alertes avec leur priorité, la règle déclenchée, ainsi que le processus et la ligne de commande à l’origine. C’est ce dernier détail qui distingue Falco des outils fondés sur les journaux : il rapporte ce qu’un processus a réellement fait, et non ce qu’un service a choisi d’en écrire.
Le jeu de règles par défaut est pensé pour les conteneurs et sera bruyant sur un serveur nu tant qu’il n’est pas ajusté. Gestionnaires de paquets, sauvegardes et scripts cron déclenchent régulièrement des règles destinées à attraper des intrus. Prévoyez une ou deux heures pour faire taire les comportements légitimes avant que la sortie devienne exploitable : un flux d’alertes que personne ne lit équivaut à aucune alerte.