• # Nouveautés

    Posté par (site web personnel) . En réponse à la dépêche Pyruse 1.0 : pour remplacer Fail2ban et autres « scruteurs » de journaux sur un GNU/Linux moderne. Évalué à 4.

    Salut à tous,

    Un grand merci à LinuxFR et aux Éditions ENI pour le livre que m’a apporté cet article.
    Pourquoi ce cadeau ? Parce que vous avez été nombreux à être intéressés par Pyruse (quelqu’un a même créé un ticket pour suggérer le support d’iptables, qui pourrait donc finalement faire son entrée ultérieurement).

    Du coup, vous serez sans doute intéressés de savoir qu’il y a des évolutions :

    • une procédure d’installation (dites-moi si vous rencontrez des problèmes avec) ;
    • le choix du niveau de détail (concernant les dates+heures) associé à chaque message du rapport quotidien ;
    • le filtre d’appartenance à des plages d’IP, ce qui permet de faire des « whitelist » et « blacklist » ;
    • l’action de log dans le journal systemd, qui permet la détection de récidive, avec autant de niveaux que souhaité.

    Et en ce moment, je travaille à l’ajout d’actions de gestion du DNAT (ou autre mécanisme de proxy). Vous avez sans doute déjà rencontré ce problème : vous avez des attaques (SSH, HTTP...) et elles proviennent toutes de « 127.0.0.1 » ou « 10.0.0.1 » (votre proxy)...

    La solution que je vais mettre en place fonctionne en 2 temps :

    1. Une action travaille sur les logs du pare-feu, ou de haproxy, pour associer 3 adresses+port : le client, le proxy, la destination.
    2. Une autre action permet de substituer des valeurs de variables en fonction de la correspondance établie à la première étape.

    Exemple :

    1. Le client 12.34.56.78:23456 se connecte à votre serveur 87.65.43.21:443 (haproxy), qui utilise la socket locale 10.0.0.1:12345 pour relayer l’appel en mode TCP à OpenSSH sur 10.0.0.2:22.
    2. Une chaîne d’exécution va :
      • extraire des logs haproxy les infos 12.34.56.78:23456, 10.0.0.1:12345, 10.0.0.2:22,
      • établir une correspondance en mémoire, d’une durée de vie limitée, entre ces données.
    3. Quelques entrées de log plus tard, une autre chaîne d’exécution va :
      • détecter une attaque SSH depuis 10.0.0.1:12345 vers 10.0.0.2:22,
      • activer le remplacement (si correspondance trouvée) de la source, qui va remplacer 10.0.0.1:12345 par 12.34.56.78:23456
      • agir sur la vraie adresse IP de l’attaquant.