Différences

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

--- pratique:informatique:parefeu:reaction [26/06/2025 07:27] – [Configuration] Zatalyz
+++ pratique:informatique:parefeu:reaction [14/07/2025 16:57] (Version actuelle) – [Démarrage automatique] Zatalyz
@@ Ligne 96: / 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 159: / Ligne 174: @@
 <code>sudo systemctl enable reaction.service
 sudo service reaction start</code>
+</WRAP>
 ==== Envoyer un mail en cas de plantage ====
@@ Ligne 249: / 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 294: / 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.