Agent Analyseur de journaux¶

Pour profiter pleinement des fonctionnalités de NGX Ops et l'exploitation des journaux (logs), il est nécessaire de déployer l'Agent Analyseur de journaux.

Cet agent fonctionne dans un conteneur séparé de NGX Ops. Il surveille les fichiers de journaux Nginx en temps réel, analyse les requêtes et transmet les informations et alertes au tableau de bord.

L'agent permet notamment d'utiliser les fonctionnalités suivantes :

Analyse des journaux : détection de comportements inhabituels ou potentiellement malveillants à partir de différentes règles, comme les tentatives répétées d'authentification, les scans, les floods ou encore certaines activités de scraping.
Analyse volumétrique : détection des variations inhabituelles du volume de trafic par hôte virtuel. L'analyse tient notamment compte de la saisonnalité du trafic afin de limiter les faux positifs.
Analyse du trafic par pays : détection d'une augmentation inhabituelle du trafic provenant d'un pays donné.
Analyse des journaux WAF : lorsque vous utilisez une version de Nginx intégrant le WAF, comme les variantes WAF ou Coraza, l'agent peut également exploiter les journaux générés par celui-ci.
Affichage du trafic en temps réel : les requêtes peuvent être visualisées en temps réel sur la carte du tableau de bord.
Résumés périodiques : les données collectées et analysées permettent de générer des synthèses périodiques de l'activité du reverse proxy.

L'analyse volumétrique nécessite une période d'apprentissage afin de déterminer le comportement habituel du trafic. L'agent utilise notamment une référence par créneau horaire de la semaine et recommande environ trois semaines d'observation avant de considérer les premières alertes volumétriques comme fiables.

L'Agent Analyseur de journaux doit pouvoir accéder en lecture aux fichiers de logs générés par Nginx. Il fonctionne indépendamment du conteneur NGX Ops et communique avec celui-ci via son API.

Déployer et configurer l'Agent Analyseur de journaux¶

Déploiement de l'agent¶

Le déploiement et la configuration de l'Agent Analyseur de journaux se font directement depuis NGX Ops.

Configuration de l'agent¶

Rendez-vous dans : ADMINISTRATION → Configuration → Analyseur de journaux

Dans la zone de saisie, renseignez la configuration de l'agent. Voici un exemple :

enable: true

host_logs_path: /containers/nginx/nginx/logs
host_data_path: /containers/nginx/config/analyzer
host_geoip_path: /containers/nginx/geoip_data

💡 Tip: Les paramètres correspondant à des chemins (paths) doivent contenir les chemins absolus sur l'hôte. Ils sont utilisés pour configurer les bind mounts Docker nécessaires au fonctionnement de l'agent.

Cliquez ensuite sur Enregistrer.

Démarrer l'agent¶

Une fois la configuration enregistrée, rendez-vous dans : INTEGRATIONS → Analyse

Cliquez ensuite sur le bouton Démarrer.

NGX Ops va alors créer et démarrer le conteneur de l'Agent Analyseur de journaux avec la configuration fournie.

Une fois l'agent démarré, il commence à surveiller les journaux Nginx et les données collectées peuvent être exploitées par les différentes fonctionnalités d'analyse de NGX Ops.

Fichier de référence¶

# Analyse des journaux nginx — agent separe
#
# L agent tourne dans son propre conteneur : l analyse d un journal charge est
# un travail CPU continu, et le sortir du dashboard evite qu un pic de trafic
# rende l interface lente.

enable: false

container_image: forge.rdr-it.com/dockerfiles/nginx-analyzer:latest
# Portage Go (v12.52.0, ~40 % de RAM en moins, meme API, meme base SQLite) :
# publier l image construite depuis nginx-analyzer-go/ et pointer ici. Retour
# arriere = remettre l image Node. Voir nginx-analyzer-go/README.md.
container_name: ngx-analyzer
port: 9100

# ── Chemins HOTE (indispensables) ────────────────────────────────────────────
# Docker resout les sources de montage sur l HOTE. Un chemin qui n existe que
# dans le conteneur du dashboard ferait monter un dossier vide, et l agent ne
# verrait aucun journal.
host_logs_path: /containers/nginx-rproxy/logs
host_data_path: /containers/nginx-rproxy/analyzer
host_geoip_path: /containers/nginx-rproxy/geoip_data

# Fix v12.22.x (audit finding ANA-02) : l ancien motif par defaut
# (\.access\.log$) n a jamais correspondu au fichier ecrit par la
# configuration livree avec ce projet — logging.conf ecrit dans
# "vhosts_access.log" (avec un "_", pas un "."), donc une installation par
# defaut ne suivait AUCUN fichier : la page Analyse restait vide, ce qui
# ressemble a "aucun trafic" plutot qu a une panne de configuration. Le
# nouveau motif couvre les deux conventions : un fichier par vhost
# ("site.fr.access.log", precede d un point) ET le fichier partage de ce
# projet ("vhosts_access.log", precede d un underscore ou en debut de nom).
log_pattern: (^|[._])access\.log$

# ── Detection par signature (active des la premiere minute) ──────────────────
# Seuils volontairement hauts : un detecteur qui crie au loup est ignore en
# trois jours, et devient alors pire qu inutile.
bruteforce_min_failures: 15
scan_min_requests: 40
flood_min_requests: 600

# Codes HTTP ignores par TOUTES les regles et la baseline : une requete deja
# refusee par un autre mecanisme (ex. blocklist en "444") ne declenche plus
# d alerte. Elles restent comptees dans les statistiques et les hits de blocklist.
# Liste separee par des virgules, ex. "444" ou "444,403". Vide = aucun.
ignore_status: ""

# ── Detection volumetrique (necessite un apprentissage) ──────────────────────
# Comptez trois semaines avant la premiere alerte fiable : la reference est
# calculee par creneau horaire de la semaine, il faut plusieurs passages sur
# chaque creneau. L agent annonce son etat plutot que d alerter a vide.
learning_days: 21
sigma_threshold: 6

# ── Notifications ────────────────────────────────────────────────────────────
# Severite minimale envoyee par courriel : low | medium | high
# La regle `analyzer_alert` doit exister et avoir des destinataires dans
# notifications.yml pour que le courriel parte.
notify_min_severity: medium

alert_retention_days: 90

# ── Regles — activation par defaut (premier demarrage uniquement) ────────────
# Passe le tout premier demarrage, l agent memorise ses propres reglages
# (bascules faites depuis la modale "Regles" de la page Analyse) et ces
# valeurs sont ignorees. Modifiez-les depuis le dashboard, pas ici, une fois
# l agent deja demarre une premiere fois.
rule_bruteforce_enable: true
rule_scan_enable: true
rule_flood_enable: true
rule_scraping_enable: true
rule_volumetric_enable: true
rule_country_traffic_enable: true

# ── ModSecurity / WAF ─────────────────────────────────────────────────────────
# Journaux d audit ModSecurity, un fichier par vhost. Format attendu :
# SecAuditLogFormat JSON — le format natif (multi-parties) n est pas supporte,
# il n a pas de schema stable d une version a l autre.
#
#   SecAuditEngine RelevantOnly
#   SecAuditLogParts ABIJDEFHZ
#   SecAuditLogType Serial
#   SecAuditLogFormat JSON
#   SecAuditLog /var/log/nginx/<vhost>.waf.log
#
# Vue separee dans le dashboard, sans notification pour l instant.
waf_log_pattern: \.waf\.log$
waf_retention_days: 60