Différences

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

--- pratique:informatique:parefeu:reaction [15/06/2026 08:12] – [Découpage des fichiers] lien vers la forge Zatalyz
+++ pratique:informatique:parefeu:reaction [16/06/2026 12:25] (Version actuelle) – Zatalyz
@@ Ligne 362: / Ligne 362: @@
 </code>
-==  ==
+== Script bash de log, notif, etc ==
 Un script très basique pour "loguer" les adresses bannis, avec la raison, appelé par l'action "banFor". Je compte me servir de ce genre de log pour alimenter par la suite :
   * les ips bloquées en longue durée (celles qui reviennent plusieurs fois via les filtres doux et par défaut : 6 fois c'est peut-être une erreur, 12 c'est de la maladresse, 24 c'est de l'acharnement...),
@@ Ligne 377: / Ligne 377: @@
 === Streams ===
 Je met ici une config très basique pour ssh (voir [[https://port.numenaute.org/zatalyz/zscript-sysadmin/src/branch/main/files/reaction|la forge]] pour plus de filtres), suffisante pour lister les "pièges" dans la syntaxe.
+<WRAP center round tip 100%>
+[[https://www.sshguard.net/|SSHguard]]((Empaqueté sur Debian)) est souvent plus adapté pour la protection de SSH, car il bannit sur des durées de plus en plus longues. Donc attention à ne pas gêner son fonctionnement avec Reaction. Ce qui n'empêche pas d'ajouter quelques pains bien violents à certains attaquants. Personnellement je n'ai aucune pitié avec ceux qui tentent de se connecter en root, et un banissement d'un mois est presque tendre ; je ne vois pas l'intérêt de les laisser essayer deux fois de suite. Aucun sysadmin suivant les bonnes pratiques ne pourrait faire l'erreur de tenter de se connecter en root.
+</WRAP>
 <code json ssh.jsonnet>
@@ Ligne 389: / Ligne 393: @@
             @'User root from <ip> not allowed because not listed in AllowUsers',
           ],
+        // ce filtre est peu pertinent avec sshguard et va le ralentir dans sa lutte contre les méchants.
         failedlogin: {
           regex: [
@@ Ligne 421: / Ligne 426: @@
 [...]
 </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 ====
+<WRAP center round tip 60%>
+Ce qui suit est plus pour retrouver comment faire au besoin, mais la configuration précédente (log, sans mail en plus, intégré à banFor) me semble suffisante en général.
+</WRAP>
 Lorsqu'il y a bannissement via Reaction, j'aimerais pouvoir réaliser certaines actions, comme être avertie par mail.
@@ Ligne 514: / Ligne 524: @@
 </code>
-{{tag>fail2ban sysadmin iptable}}
+===== Transformer les règles de fail2ban =====
+Ça c'est du chantier...
+Quand on a fail2ban installé, retrouver les regex est un sacré bazar. Il n'y a pas de solution "immédiatement fonctionnelle". Mais deux commandes utiles.
+  fail2ban-client -d
+Celle-ci va lister toutes les règles actives, dans un format permettant de voir quel fichier de log est surveillé et divers détails. C'est assez verbeux, mais utile.
+  fail2ban-client get JAIL failregex
+Remplacer "JAIL" par le nom de la jail ; ne liste que les regex dans un format relativement lisible (enfin, ça reste des regex). On remarque cependant que la partie "<HOST>" n'est pas renseigné, c'est ballot hein ? Suivant les jail, cette variable qui capture l'ip de l'attaquant est soit dans un préfixe (à trouver...) soit sous un format décompressé.
+Jails que je tente d'analyser et recopier :
+  * Apache, error.log
+    * ''apache-auth'' : la plupart des règles semblent utiles. Pas forcément un ban trop violent au premier abord.
+    * ''apache-botsearch'' : c'est surtout le scan de pages à attaquer ; déjà mis dans mes filtres Reaction et aucune pitié avec ça, mais on note que là c'est la version pour "error" et non "access" donc pas les mêmes ?
+    * ''apache-modsecurity'' : faut que je creuse plus, ça semble relié à un mod apache que je ne gère pas.
+    * ''apache-nohome'' : alors, là, lui, je ne sais pas ce qu'il vise...
+    * ''apache-noscript'' : peu de règles, lisibles et très importantes car en effet les badbots les cherchent !
+    * ''apache-overflows'' : à analyser plus finement, car sans doute qu'il y a des histoires de "retry" pour que ce soit pertinent.
+    * ''apache-shellshock'' : j'sais pô.
+  * Apache access.log
+    * ''apache-badbots'' : me semble assez douteuse. Ça ban d'après les users agent, mais ce qui est cherché est plein de vieux trucs. Après, ça peut éviter que les bots indexent trop, trop vite, ou de se faire aspirer le site. Mais j'aurais tendance à plutôt mettre des limiteurs de vitesse ?
+      * Notons cependant qu'on a des badbots repérables aux user-agents et que les ban peut réduire le trafic simplement.
+    * ''apache-fakegooglebot'' : celle-ci semble sacrément foireuse ?
+Autres services, où en théorie on va tout reprendre (plus les notres) :
+  * postfix
+  * dovecot
+  * sieve
+  * sshd
+{{tag>fail2ban sysadmin iptable nftables}}
 [[https://creativecommons.org/publicdomain/zero/1.0/deed.fr|{{ https://liev.re/imagesweb/licences/cc-zero.png?100 | Ce texte est placé sous licence CC0}}]]