Doc Technique - Cron Noise Analyzer (HTTP + TCP Noise / nft + ss)

Cron / Management Command

Cron Noise Analyzer — Détection “bruit réseau” (HTTP + TCP)

Objectif : détecter rapidement les “pics de bruit” qui saturent ton serveur (bots, scanners, attaques faibles, crawlers agressifs) et te donner un reporting exploitable : Top IP, Top /24, scores, et candidats au blocage.

Nginx access.log (custom) HTTP 4xx / 404 Scores Top IP & /24 Rapports JSON/HTML Verbose / Watch TCP noise (SYN) via ss nft counters (optionnel) TTL blocking (sudo)

Point clé : ce que tu vois dans tcptrack est souvent du TCP (SYN, SYN_SENT/SYN_RECV) qui n’atteint pas forcément HTTP. Donc :

HTTP → visible dans /var/log/nginx/access.log
TCP → visible via ss (et éventuellement via compteurs nft)

Analyse HTTP : parse ton format de log custom (IP, method, URL, status).
Classement : calcule un score (volume + 4xx/404 + signaux annexes).
Focus /24 : repère les sous-réseaux “spray” (multi IP).
Export : JSON + HTML dans /var/lib/ideolab/noise_analyzer/reports/.
Optionnel : blocage TTL (nft/ipset) — uniquement si tu l’actives explicitement.

Étape 1 — Installation (Ubuntu 24.04)

1) Placement du fichier Python

Place la commande dans l’app qui porte tes outils (ex : accounts / toolbox).

your_project/
  accounts/                          # ou toolbox/, tools/...
    management/
      __init__.py
      commands/
        __init__.py
        cron_noise_analyzer.py        # <= le cron

Important : ne pas oublier les __init__.py dans management/ et commands/.

2) (Option) fournir le .py en download via static

# Place une copie ici (si tu veux exposer un download):
# static/toolbox/cron_noise_analyzer.py

3) Vérifier la présence de la commande

python manage.py cron_noise_analyzer --help

4) Prérequis “lecture logs”

Le cron lit /var/log/nginx/access.log. Assure-toi que l’utilisateur qui exécute Django a le droit de lecture (sinon lance via le même user que Nginx ou ajuste les permissions).

Étape 2 — Utilisation au quotidien

A) Diagnostic rapide (HTTP)

python manage.py cron_noise_analyzer

python manage.py cron_noise_analyzer --verbose

B) Rapport & chemins utiles

# En fin d’exécution, le cron imprime :
# [report] json=/var/lib/ideolab/noise_analyzer/reports/noise_report_YYYYMMDD_HHMMSS.json
# [report] html=/var/lib/ideolab/noise_analyzer/reports/noise_report_YYYYMMDD_HHMMSS.html

C) “Dry-run” vs “Apply” (blocage)

Par défaut, le cron peut calculer would_block mais n’applique rien. Pour appliquer un blocage TTL, il faut explicitement --apply et, en général, sudo.

# Applique le blocage TTL (si et seulement si tu l’assumes)
# ATTENTION: requiert sudo si nft/ipset est utilisé
sudo -E /path/to/venv/bin/python manage.py cron_noise_analyzer --apply --ttl 21600

Modes avancés — Verbose / Watch / TCP

1) Mode “Watch” (temps réel)

But : arrêter de lire des logs “années 70” et voir en live ce qui se passe.
Le mode watch boucle toutes les N secondes.

python manage.py cron_noise_analyzer --verbose --watch 2

2) Mode TCP (quand tcptrack explose)

Important : si le bruit est majoritairement SYN / handshake, il se peut que Nginx n’ait rien à logger côté HTTP. Dans ce cas, active l’analyse TCP.

python manage.py cron_noise_analyzer --tcp --verbose

python manage.py cron_noise_analyzer --tcp --verbose --watch 2

3) nft “Operation not permitted”

Si tu vois Operation not permitted (you must be root), c’est normal :

Lecture nft : souvent root (selon policy)
Apply (nft/ipset) : root obligatoire

sudo -E /path/to/venv/bin/python manage.py cron_noise_analyzer --tcp --verbose

FAQ / Dépannage

1) “Le cron détecte rien mais tcptrack montre des tonnes d’IP”

Cause : bruit TCP (SYN) qui ne devient jamais une requête HTTP.
Solution : utiliser --tcp (et éventuellement sudo pour nft).

2) “KeyError: init-firewall”

Django/argparse convertit --init-firewall en init_firewall dans opts. Utilise opts["init_firewall"] (underscore), pas le tiret.

3) “Permission denied sur /var/log/nginx/access.log”

lancer la commande avec un user qui peut lire le log
ou créer un log dédié lisible (vhost access log)
ou ajuster groupe/permissions proprement

4) “Je veux une alerte automatique”

Recommandation : démarrer par une alerte (mail/Discord/Slack) sur status=ALERT, puis seulement après envisager l’auto-blocage TTL.

A) crontab (simple)

# Toutes les 5 minutes (analyse + report)
*/5 * * * * cd /opt/ideo-lab && . venv/bin/activate && python manage.py cron_noise_analyzer --tcp >> /var/log/cron_noise_analyzer.log 2>&1

B) systemd timer (propre)

[Unit]
Description=IDEO-Lab cron_noise_analyzer

[Service]
Type=oneshot
WorkingDirectory=/opt/ideo-lab
ExecStart=/opt/ideo-lab/venv/bin/python /opt/ideo-lab/manage.py cron_noise_analyzer --tcp
User=ubuntu
Group=ubuntu

[Unit]
Description=Run cron_noise_analyzer every 5 minutes

[Timer]
OnBootSec=2min
OnUnitActiveSec=5min
AccuracySec=30s
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now cron-noise-analyzer.timer
systemctl list-timers | grep noise

tcptrack : vision live des connexions TCP (même sans HTTP).
ss : états SYN/ESTAB, utile pour quantifier le flood.
access.log : uniquement quand la requête HTTP a réellement eu lieu.

# Connexions TCP vers 443
ss -tan | grep ':443' | head

# Vue "live" côté cron
python manage.py cron_noise_analyzer --tcp --verbose --watch 2