ppom a écrit 20 commentaires

La méthode DELETE n'est pas supportée par les formulaires HTML…
Il faut choisir entre "sémantique HTTP pure" ou "pas de javascript" mais aujourd'hui, ce n'est pas possible d'avoir les deux malheureusement !

J'en profite pour informer à la ronde que le wiki est maintenant tout joli et disponible ici : https://reaction.ppom.me 🎉

Et pour éviter de ban un réseau dans lequel tu as une IP que tu veux ignorer, c'est simple aussi :

{
  patterns: {
    // full ip
    ip: {
      regex: '...',
      ignore: ['192.168.1.254'],
    },
    // Only keep "network" part of an IPv4
    ipD: {
      regex: @'[0-9]\.[0-9]\.[0-9]\.',
      ignore: ['192.168.1.'],
    },
  },
}

Pour ce qui est d'une denylist (/blacklist) permanente, je sais pas si c'est pertinent d'implémenter ça directement dans reaction.

Par contre je viens de réfléchir à une configuration qui le permette de manière pas si dégueu !

• À chaque fois que reaction ban une IP, il la stocke également dans un fichier.
• reaction suit ce fichier comme un stream, et n'en garde que les 3 premiers nombres (la partie "réseau")
• au bout de 50 occurences du même réseau en un mois, il ban tout le réseau pour un an.

reaction.jsonnet

local permanentfile = '/var/lib/reaction/permanent';
{
  patterns: {
    // full ip
    ip: {
      regex: '...',
    },
    // Only keep "network" part of an IPv4
    ipD: {
      regex: @'[0-9]\.[0-9]\.[0-9]\.',
    },
  },
  streams: {
    myservice: {
      // ...
      filters: {
        myfilter: {
        // ...
          actions: {
            ban: {
              // ...
            },
            unban: {
              // ...
            },
            // when banning an IP, you also put it in a file
            storeinfile: {
              cmd: ['store.sh', '<ip>', permanentfile]
            },
          },
        },
      },
    },
    myotherservice: {
      // ... same 'storeinfile' action
    },
    permanent: {
      cmd: ['tail', '-fn0', permanentfile],
      filters: {
        oneyearban: {
          regex: [@'^<ipD>.*'],
          // 50 bans of this network in one month
          retry: 50,
          retryperiod: std.toString(31 * 24) + 'h',
          actions: {
            ban: {
              // ...
            },
            unban: {
              // ...
              // unban after 12 months
              after: std.toString(12 * 31 * 24) + 'h',
            },
          },
        },
      },
    },
  },
}

store.sh

#!/usr/bin/env bash
echo "$1" >> "$2"

Notes:

• J'utilise un petit script plutôt que la commande ['sh', '-c', 'echo <ip> >> ' + permanentfile], car faire un sh -c est risqué, de manière inhérente.
• Pour ban un rang d'IP, il faut ajouter le /24: iptables -w -A reaction -s a.b.c.0/24 -j DROP
• Je n'ai pas testé, mais c'est forcément pas loin de fonctionner 😄 S'il y a un vrai intérêt autour de cette méthode, je ferai une page dans le wiki.
• Si quelqu'un trouve une manière élégante de permettre de chainer des streams dans reaction, et ainsi d'ajouter de la réflexivité, ça m'intéresse d'implémenter ça, et d'éviter d'avoir recours à un fichier externe comme dans cet exemple. Mais il faut alors trouver de nouvelles options de conf pour permettre ça de manière élégante. (Les issues sont ouvertes !)
• Si je vous ai perdu avec ce bout de conf, je peux essayer d'expliquer mieux, n'hésitez pas à poser des questions.

Coucou !
Les allowlists (/whitelists) sont déjà implémentées, car on peut faire des exceptions à un pattern :

{
  patterns: {
    ip: {
      regex: '...',
      ignore: [
        '192.168.1.254',
      ],
    },
  },
}

Exemple : dans mon cas, je ne peux pas me permettre de bannir mon routeur, unique accès pour mon serveur à l'Internet mondial™️, ce qui reviendrait à mettre le serveur hors-ligne.

Chouette, merci ! Ça a boosté ma motiv, je suis en train de l'ajouter à NixOS de mon côté : https://github.com/NixOS/nixpkgs/pull/272264

Héhé, j'étais en train de les faire justement !
Mais en cours de route j'ai migré le stockage des binaires et de mon blog, de mon homeserver à mon VPS, pour avoir un uptime nickel.
Toutes les releases sont créées maintenant !

Et waow, je n'avais pas bien lu 😮

Des releases pour Alpine, ce serait super chouette !
Je compte upstream mon package pour NixOS, mais c'est très niche.

Si quelqu'un maintenait un package Debian, ce serait incroyable aussi 🎅

Bon, ça doit pas être très clair sur le repo…
Pour l'instant, il n'y a pas de releases au sens GitLab du terme, mais il y a déjà des tags Git ! (v0.1, v0.2, v0.3, v0.4, v1.0, v1.0.1).
Et des binaires précompilés, aussi linkés dans le README du projet.

Je n'ai pas encore appris à faire des releases "propres" via GitLab/Framagit, mais elles sont d'ores et déjà là.

Merci pour ce chouette retour 😊

Hello 😅
Je vais répondre à tes remarques, même si d'autres l'ont déjà fait

utiliser une commande, c'est old school

Je pense que j'ai deux contre-arguments plus concrets. Une commande, c'est :

• super simple à implémenter
• super versatile

Je n'ai pas envie de recoder des trucs déjà implémentés par journalctl, tail, docker logs, etc… J'estime que ces commandes sont optimisées. Au bout de plusieurs semaines, une commande journalctl a utilisé moins d'une minute de temps de CPU, et je n'ai pas envie de compétiter !

ssh:
  follow: sshd

Il y a des distributions qui appellent ce service ssh, d'autres sshd, d'autres openssh.
Il y a des distributions qui utilisent systemd/journald, d'autres rsyslog, d'autres un plain text…
Je pense qu'hardcoder tous ces noms, tous ces paths, tous ces protocoles, dans reaction, c'est me tirer une balle dans le pied !

Le programme peut maintenant choisir d'utiliser nftables, iptables ou autre, en fonction du système.

Idem, je ne préfère pas que le programme détermine lui-même quel système existe, quel système est en place… Je pense que c'est la porte ouverte à une flopée de bugs plus ou moins sournois.

---

Comme mentionné par quelqu'un d'autre, il est possible d'approcher ta syntaxe avec JSONnet :

local systemd(service) = ['journalctl', '-fu', service + '.service'];
local ban(action) = ['ip46tables', '-w', '-A', 'reaction', '-s', '<ip>', '-j', action];
{
 streams: {
  ssh: {
   cmd: systemd('sshd'),
   filters: {
    failedlogin: {
     ...
     actions: {
      banip: ban('DROP'),
     },
    },
   },
  },
 },
}

Actuellement, le code de reaction fait ~1200 lignes de code, et ça me va bien !
Si je voulais implémenter/hardcoder autant de trucs, ben, déjà, je voudrais pas le faire haha, et ensuite, j'aurais plus de code dédié à des cas spécifiques qu'au coeur de ce que fait reaction : lire la stdout d'un programme, matcher des regexes dessus, et lancer des actions quand il y a un certain nombre de matches.

Et oui, une raison très simple… Je ne connaissais pas du tout 😆

Après un rapide coup d'oeil, je le rangerais dans la même catégorie que salt et consorts : c'est un gros bouzin, avec une architecture 1 manager / N agents… Ça me semble beaucoup pour une petite infrastructure.

Merci pour le lien 🙂

J'ai regardé un peu ferm, qui a l'air d'un très chouette projet, et de gérer des cas plus complexes que ufw.

Par contre j'ai l'impression que ce n'est pas possible de ban une ip temporairement, juste avec un ferm ... <IP>. ip46tables sert juste à ça, ce n'est pas du tout le même scope que ferm 🔀

nftables

cf mes autres réponses à ce sujet !

je ne trouve pas fail2ban complexe à configurer

Je t'en félicite (premier dégré !)
Moi, je m'y perds.

existe-t-il une bdd pour les ban en cours, pour les réappliquer en cas de redémarrage du service ?

Comme a dit Zatalyz, yep, il y en a une ! Pour la petite histoire, elle fonctionne un peu comme celle de Redis : C'est juste un log (dans un format binaire) des matches et des actions exécutées. Il est réécrit périodiquement pour ne pas dépasser les quelques Mo, en ne gardant que les logs encore d'actualité.

même genre de question pour les ban issue du bannissement fait avec recidive sur fail2ban, qui j'imagine serais fait avec un autre stream avec ta solution

Actuellement, il y aurait besoin de faire :
- soit un second filter avec les mêmes regexes sur le même stream (un peu dommage car ça testera plusieurs fois la même regex, ça pourrait être plus opti)
- soit un stream qui lit les logs de reaction pour voir les bans, et qui ferait des bans plus longs quand il voit plusieurs fois une IP se faire ban (ce qui est un peu crado, et qui nécessite d'avoir le loglevel à INFO au minimum).

En fait j'ai pas encore implémenté de feature de ce type parce que je ne vois pas comment écrire ça de manière élégante dans la configuration. Si vous avez des idées de ce côté, ça m'intéresse vraiment.

le fait d'avoir aucun module pour Apache m'avais refroidi

La configuration d'Apache est assez versatile, et ses logs aussi il me semble. Même chose pour NGINX, comme les logs sont très configurables, peuvent changer selon les distros, le module risque d'être inadapté.
C'est aussi à cause de ce genre de problématiques que je n'ai pas envie de maintenir une configuration officielle des services, mais plutôt d'avoir un wiki qui recense des configurations et des bonnes pratiques.

En fait sur reaction il n'y a pas de configuration par défaut. Seulement un wiki qui donne des exemples. Pour l'instant il n'y a qu'un exemple de configuration pour iptables/ip6tables/ip46tables, parce que c'est ce que j'utilise sur mon serveur.

Mais j'adorerais qu'une personne qui connait nftables (et autres) propose des configurations pour d'autres pare-feux !

Encore une fois, il n'y a pas de backend officiel. reaction c'est juste un outil qui lit la stdout d'un programme, matche des regexes dessus, et lance des actions quand il y a un certain nombre de matches.

Je prendrais avec grand plaisir un exemple de configuration qui utilise nativement nftables ! J'ai fait la doc avec iptables parce que c'est ce que je connais, mais il faudra bien que je me mette à nftables un jour 😁

N'hésitez pas à alimenter le wiki si vous utilisez reaction !

Bonne question !
On peut voir dans le readme que j'ai également codé un minuscule programme en C, ip46tables, qui permet d'unifier iptables et ip6tables. Ça fait partie des détails qui sont simplifiés sur le blog, mais détaillés dans la conf exemple et le wiki.

Les streams ne fonctionnent que par analyse de lignes de textes. Si tu as un outil qui permet de "suivre" un flux et de le transformer en ligne de texte, c'est tout bon !

On peut penser à docker logs -f, journalctl -f, tail -f, tail -f | jq, swaymsg -m, inotifywait -m…

Je ne connais pas vraiment kafka ni opentelemetry, mais il doit bien y avoir un utilitaire qui permet ça.

Ça fait partie des choix de design qui sont importants pour moi. J'estime que les commandes de coreutils, systemd, docker et consorts sont censées être optimisées. Et j'ai envie de limiter au maximum d'avoir dans la base de code de reaction des développements spécifiques. Je pourrais dire que c'est pour respecter la tradition UNIX, KISS, etc, mais c'est surtout pour m'éviter de maintenir du code déjà écrit ailleurs 😉

Merci, bien vu !
J'ai ajouté le lien sur les articles de blog, mais je n'ai pas trouvé en 5 min comment éditer la dépêche 😅

Hello, merci pour cette dépêche et tous ces commentaires forts instructifs !

Après avoir essayé des serveurs du genre, je suis tombée sur Funkwhale, qui propose sa propre API ainsi qu'une API compatible Subsonic (pas parfaite, mais qui fonctionne à peu près avec Ultrasonic).

Le gros + de Funkwhale, c'est qu'il utilise ActivityPub, le protocole du Fediverse, et permet de lire les musiques des serveurs Funkwhale de ses copaines en s'abonnant à leurs libs, depuis son compte, sur son serveur. Dans un groupe d'ami·es, on est une petite dizaine sur 5 serveurs différents, et on découvre plein de musique en écoutant les un·es chez les autres, je recommande !

On a fait un script crado pour fédérer les playlists, qui ne le sont pas encore nativement, et un autre encore plus crado pour reconstruire après-coup une arborescence de fichiers selon les métadonnées, pour partager la musique avec des partages réseaux ou avec le réseau P2P Soulseek. Un régal 😋