Falco

Exemple de déploiment docker

    falco:
        stdin_open: true
        tty: true
        image: falcosecurity/falco:latest
        container_name: falco
        privileged: true
        restart: always
        environment:
            - TZ=${TIME_ZONE}
        volumes:
            - /sys/kernel/tracing:/sys/kernel/tracing:ro
            - /var/run/docker.sock:/host/var/run/docker.sock
            - /proc:/host/proc:ro
            - /etc:/host/etc:ro
            - $INFRASTRUCTURE_FOLDER_LOCATION/variable-falco_rules.local.yaml:/etc/falco/falco_rules.local.yaml

Création d'exceptions (Macros)

Les macros sont essentielles pour adapter Falco à votre environnement spécifique et éviter les "faux positifs". Voici quelques bonnes pratiques et des explications détaillées pour les macros fournies.

Bonnes pratiques pour les exceptions

Soyez spécifique : Ciblez précisément l'activité légitime. Utilisez toujours au moins deux critères (par exemple, nom du conteneur ET nom du processus) pour éviter de blanchir trop large.
Évitez les champs volatils : Ne vous basez pas sur des ID de conteneurs (container.id) qui changent à chaque redémarrage. Préférez container.name ou container.image.repository.
Utilisez les listes : L'opérateur in est très performant pour lister plusieurs binaires ou fichiers autorisés (ex: proc.name in (bash, sh)).
Modularisez : Créez des macros réutilisables plutôt que de dupliquer des conditions complexes dans chaque règle.
Analysez les logs : Avant de créer une exception, regardez les logs Falco pour extraire les champs exacts (proc.cmdline, user.name, etc.) de l'événement qui a déclenché l'alerte.
Comprendre le pattern "Hook" :
- Pourquoi 2 macros ? Vous remarquerez souvent une paire de macros.
  - La première (ex: transmission_healthcheck) définit QUOI autoriser (votre condition spécifique).
  - La seconde (ex: user_known_stand_streams_redirect_activities) définit OÙ l'autoriser. C'est une macro standard de Falco utilisée dans les règles par défaut. En ajoutant votre condition à cette macro, vous l'injectez automatiquement dans toutes les règles officielles qui l'utilisent, sans avoir à modifier les règles elles-mêmes.

Explication des Macros

Voici le détail des exceptions configurées pour votre environnement :

transmission_healthcheck : Autorise le processus ping uniquement dans le conteneur transmission. C'est souvent utilisé par les healthchecks Docker pour vérifier la connectivité.
postgres_isready : Autorise l'utilitaire pg_isready dans le conteneur postgres-immich. Cela évite les alertes constantes dues aux vérifications de santé de la base de données.
cronjob_safe_bins : Liste blanche de binaires de confiance (curl, rsync, find, etc.) spécifiquement pour le conteneur cronjob. Cela permet à vos tâches planifiées de s'exécuter sans lever d'alerte de sécurité, tout en surveillant si un binaire inconnu (ex: cryptominer) se lance.
mkdocs_shell_activity : Exception très précise qui autorise une commande sh seulement si la ligne de commande contient l'installation du plugin mkdocs spécifiques. Cela permet les builds automatiques sans autoriser tout shell arbitraire.

Configuration YAML

# Macro de base pour le healthcheck transmission
- macro: transmission_healthcheck
  condition: (container.name = "transmission" and proc.name = "ping")

# Application de l'exception aux règles redirigeant les flux standards
- macro: user_known_stand_streams_redirect_activities
  condition: transmission_healthcheck

# Macro pour le healthcheck Postgres
- macro: postgres_isready
  condition: (container.name = "postgres-immich" and proc.name = "pg_isready")

# Autorisation de lecture de fichiers sensibles pour le healthcheck Postgres
- macro: user_known_read_sensitive_files_activities
  condition: postgres_isready

# Définition des binaires sûrs pour les tâches cron
- macro: cronjob_safe_bins
  condition: (container.name = "cronjob" and proc.name in (curl, rsync, xargs, supercronic, supercronic-lin, find, jq, nano))

# Autorisation du "drop and execute" pour les binaires cron définis ci-dessus
- macro: known_drop_and_execute_activities
  condition: cronjob_safe_bins

# Définition des shells autorisés pour cron
- macro: cronjob_shell
  condition: (container.name = "cronjob" and proc.name in (bash, sh))

# Exception spécifique pour l'installation de plugin mkdocs
- macro: mkdocs_shell_activity
  condition: (proc.name = "sh" and proc.cmdline contains "pip install mkdocs-git-authors-plugin")

# Regroupement des exceptions de shell pour les terminaux attendus
- macro: user_expected_terminal_shell_in_container_conditions
  condition: (cronjob_shell or mkdocs_shell_activity)

Exemple de script simple pour recevoir des alertes mail

#!/bin/bash

# Configuration
source /cronjob/.env

while true; do
    # Get logs from the last 60 seconds
    LOGS=$(ssh -i "$SSH_KEY" "$SSH_USER@$SSH_HOST" "docker logs --since 60s falco 2>&1")

    if [ ! -z "$LOGS" ]; then
        echo "Suspicious activity detected!"
        echo "$LOGS"

        # Send email alert
        (
            echo "Subject: Falco Alert"
            echo "From: $POSTFIX_SMTP_USERNAME"
            echo "To: $MAIL_RCPT"
            echo ""
            echo "Suspicious activity detected in Falco logs:"
            echo ""
            echo "$LOGS"
        ) | curl -s --url "$SMTP_URL" --mail-from "$POSTFIX_SMTP_USERNAME" --mail-rcpt "$MAIL_RCPT" --upload-file -
    fi

    # Send heartbeat
    curl -s "https://uptime.albt.org/api/push/Tp9IvnvlCl?status=up&msg=OK&ping=" > /dev/null

    sleep 60
done