Différences

Ci-dessous, les différences entre deux révisions de la page.

--- pratique:informatique:parefeu:reaction [11/06/2025 16:01] – une belle maj Zatalyz
+++ pratique:informatique:parefeu:reaction [14/07/2025 16:57] (Version actuelle) – [Démarrage automatique] Zatalyz
@@ Ligne 51: / Ligne 51: @@
   * ''-v'', ''--verbose'' : affiche plus d'infos en sortie.
+==== Les plus fréquement utilisées ====
+Voir qui est banni :
+  reaction show
+Débannir quelqu'un :
+  reaction flush IP
+Tester le dossier de configuration :
+  reaction test-config -c /etc/reaction
+Démarrer (sans systemd) :
+  reaction start -c /etc/reaction/
+==== Base de donnée ====
 Par défaut les bases de données sont dans ''/var/lib/reaction/'' (''reaction-matches.db'' et ''reaction-flushes.db''). Les effacer remet tout à zéro.
@@ Ligne 79: / Ligne 96: @@
 </WRAP>
+<WRAP center round info 100%>
+Avec la version 2 il y a un à présent un service systemd déjà fourni. Il se trouve sur /lib/systemd/system/reaction@.service.
+Je laisse La vieille doc "pour mémoire" mais ce n'est plus forcément utile.
+</WRAP>
+Après installation et vérification, pour utiliser systemd :
+<code>sudo systemctl daemon-reload
+sudo systemctl enable --now reaction@reaction
+</code>
+Ce qui suit après le @ est le chemin vers la configuration dans /etc/ ; comme je lui fais lire le dossier, c'est donc juste "reaction" pour "/etc/reaction".
+<WRAP center round alert 100%>
 Je vais créer deux services : un pour Reaction proprement dit, un pour avertir en cas de plantage. Vu que j'ai eu des plantages muets, je lui dis de se relancer si ça lui arrive((Je précise que ça date des premières versions du logiciel, qui a bien évolué depuis.)) et sinon, j'ai une alerte.
@@ Ligne 142: / Ligne 174: @@
 <code>sudo systemctl enable reaction.service
 sudo service reaction start</code>
+</WRAP>
 ==== Envoyer un mail en cas de plantage ====
@@ Ligne 153: / Ligne 187: @@
   * Rapport (journalier ?) sur les ip bannies (histoire de pouvoir suivre ce qui se passe et la charge) ?
+Point côté syntaxe : dans les noms, on peut utiliser le tiret bas, mais pas de tiret classique, ça va faire des erreurs car jsonnet l'interprète... Donc "mon_filtre" est ok, pas "mon-filtre".
 ==== Découpage des fichiers ====
 Il s'agit de me simplifier un peu la lecture et la maintenance. Sur l'exemple ici, j'ai 3 types de fichiers
@@ Ligne 231: / Ligne 266: @@
 };
+// retry et retryperiod sont quand il y a plusieurs tentatives autorisées
+// juste mettre le banFor sinon...
+// Filtre (et options) par défaut : ni trop doux, ni trop cruel.
 local filter_default = {
   retry: 3,
   retryperiod: '3h',
-  actions: banFor('24h'),
+  actions: banFor('48h'),
+};
+// Filtre doux : c'est peut-être légitime. Et peut-être pas.
+local filter_soft = {
+  retry: 6,
+  retryperiod: '3h',
+  actions: banFor('10s'),
+};
+// Filtre violent : un seul essai, banni un mois.
+local filter_hard = {
+  actions: banFor('720h'),
+};
+local stream_name(name) ={
+  reason: {
+    cmd: ['logger', 'REACTION BLOCK <ip> because: ', name],
+  },
 };
+// Exposer les définitions précédentes pour qu'elles soient accessibles depuis un autre fichier Jsonnet
 {
   banFor: banFor,
   filter_default: filter_default,
+  filter_soft: filter_soft,
+  filter_hard: filter_hard,
+  stream_name: stream_name,
 }
@@ Ligne 276: / Ligne 337: @@
   * ''lib.filter_default'' et ''lib.banFor'' : on utilise les actions ''banFor'' et ''filter_default'' mais comme elles sont dans le fichier ''_lib.jsonnet'', on appelle la variable définie avant (''lib''). Sinon, ben... ça marche pas.
+Concernant l'appel des diverses fonctions, il y a plein de petites subtilités. Par exemple, si on veut appliquer les actions par défaut (même durée de ban, même valeurs pour retry, retryperiod) mais déclarer une action complémentaire comme "stream_name", alors on fait ceci :
+<code>
+[...]
+        apache_auth: lib.filter_default + {
+          regex: [
+            @'^.*client <ip>.* regex',
+          ],
+          actions: lib.filter_default.actions + lib.stream_name('apache_auth'),
+        },
+[...]
+</code>
+Ici ''lib.filter_default.actions'' précise qu'il faut appliquer les actions par défaut de "filter_default". ''+ lib.stream_name('apache_auth')'' permet d'ajouter l'action stream_name (qui permet de loguer pour "quoi" on a banni), en précisant une raison personnalisée donc. Il faut quand même déclarer ''lib.filter_default'' au niveau du stream (après "apache_auth" dans l'exemple), afin que les paramètres "retry" et "retryperiod" s'appliquent sur le stream.
 ==== Réaliser des actions plus compliqués ====
 Lorsqu'il y a bannissement via Reaction, j'aimerais pouvoir réaliser certaines actions, comme être avertie par mail.