Sortie de CrowdSec 1.1.x : quelles sont les nouveautés ?

Posté par CrowdSec (site web personnel) le 24 août 2021 à 06:09. Édité par Ysabeau 🧶 🧦, Benoît Sibaud et palm123. Modéré par Xavier Teyssier. Licence CC By‑SA.

Étiquettes :

août

2021

L’équipe de CrowdSec annonce la sortie de la version 1.1.x, la dernière version de sa solution de cybersécurité gratuite et open-source (MIT) conçue pour protéger les serveurs, services, conteneurs ou machines virtuelles Linux exposés sur Internet. Quoi de nouveau ? Des nouveaux paquets et dépôts, ainsi que des améliorations de l’agent CrowdSec lui-même.

Nouveaux paquets et dépôts

Dans le cadre de cette version, CrowdSec a transféré ses services vers Package Cloud, une distribution de paquets rapide, fiable et sécurisée hébergée dans le cloud. Cette migration a permis à CrowdSec de distribuer davantage de paquets à ses utilisateurs. Outre les paquets existants pour Debian et Ubuntu, notamment Bionic, Bullseye, Buster, Focal, Stretch, Focal pour x86-64 et arm, CrowdSec propose désormais des paquets pour Red Hat Enterprise Linux (RHEL), CentOS et Amazon Linux. L’équipe encourage les utilisateurs et les utilisatrices à mettre à jour les URL des dépôts dès que possible. L’ancien dépôt ne sera plus mis à jour et sera mis hors service sous peu.

CrowdSec a également ajouté la prise en charge des paquets RPM et Debian pour :

son firewall bouncer, qui récupère les nouvelles et les anciennes décisions à partir d’une API CrowdSec et les ajoute à une liste de blocage utilisée par les pare-feux pris en charge
son custom bouncer, qui récupère les nouvelles et les décisions expirées ou supprimées à partir d’une API locale CrowdSec et les transmet comme arguments à un script utilisateur personnalisé.

Diverses améliorations ont également été apportées à l’agent CrowdSec, l’une des plus notables étant une refonte du processus d’acquisition des données pour ajouter la prise en charge des sources CloudWatch. CrowdSec peut maintenant agir comme un serveur syslog, ce qui devrait permettre l’ajout de beaucoup plus de sources de données dans les prochaines versions.

Comment démarrer

Avec la sortie de la version 1.1.x, l’installation et utilisation de CrowdSec est grandement facilitée. Pour installer CrowdSec sur Ubuntu ou Debian, ajoutez les dépôts :

curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash

Puis installez :

sudo apt-get install crowdsec -y

Sur un système CentOS ou Red Hat Enterprise Linux (RHEL), ajoutez-les
dépôts :

curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.rpm.sh | sudo bash

Puis installez :

sudo dnf install crowdsec

Si vous installez de nouveaux services après cela, vous pouvez mettre à jour CrowdSec pour installer les collections requises en utilisant :

/usr/share/crowdsec/wizard.sh -c

Les capacités de détection de CrowdSec fournissent une visibilité sur les menaces ciblant votre système. Cependant, la dissuasion des attaques nécessite une stratégie de sécurité intelligente et proactive, et c’est là que les bouncers entrent en jeu !

Les bouncers fonctionnent en interrogeant l’API de CrowdSec pour savoir quand bloquer une IP. Ils peuvent être téléchargés directement depuis le Hub CrowdSec.

Pour installer le Cs-firewall-bouncer dans un dépôt Ubuntu ou Debian, utilisez :

sudo apt install crowdsec-firewall-bouncer-nftables crowdsec-firewall-bouncer

Si vous utilisez CentOS ou RHEL :

sudo dnf install crowdsec-firewall-bouncer-nftables

Un tutoriel plus exhaustif de cette nouvelle version peut être consulté sur le site web de CrowdSec (en anglais) en cliquant ici.

L’arrivée de la console

Enfin, la toute nouvelle console CrowdSec, qui est maintenant en version bêta privée, fournit une interface web facile à utiliser pour inspecter plusieurs agents CrowdSec répartis sur différents réseaux. Vous pouvez créer un compte et trouver les instructions pour inscrire l’agent CrowdSec ici.

La Console CrowdSec

Les membres de l’équipe sont preneurs de vos retours. N’hésitez pas à les contacter via leur Discourse ou Gitter. Pour télécharger cette nouvelle version, vous la trouverez sur le dépôt GitHub de CrowdSec.

Aller plus loin

Téléchargement de la dernière version de CrowdSec (27 clics)
Le site de CrowdSec (134 clics)
CrowdSec : la cybersécurité collaborative, open source et gratuite pour Linux (159 clics)

# Commentaire supprimé

Posté par Anonyme le 24 août 2021 à 08:09. Évalué à 10.

Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Re: Cybersécurité ou marketing ?
  
  Posté par barmic 🦦 le 25 août 2021 à 17:18. Évalué à 0.
  
  Par ailleurs, tant que ce bug ne sera pas résolu Crowdsec restera bien moins efficace que fail2ban.
  
  Parce que fail2ban c'est efficace ?
  
  De manière générale il convient de s'interroger sur le modèle de sécurité de ces outils et sur leur réelle utilité. Il n'empêchent pas les attaques mais permettent dans certaines circonstances de réduire leur probabilité de réussite.
  
  C'est précisément ce pourquoi fail2ban ne me semble que rarement pertinent.
  
  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
  - [^] # Re: Cybersécurité ou marketing ?
    
    Posté par Sytoka Modon (site web personnel) le 25 août 2021 à 18:13. Évalué à 2.
    
    fail2ban réduit par 100 environ les attaques sur SSH…
    - [^] # Commentaire supprimé
      
      Posté par Anonyme le 25 août 2021 à 18:48. Évalué à 1.
      
      Ce commentaire a été supprimé par l’équipe de modération.
      - [^] # Re: Cybersécurité ou marketing ?
        
        Posté par Sytoka Modon (site web personnel) le 25 août 2021 à 19:59. Évalué à 4.
        
        Non, car lorsque tu as des serveurs à 10Gb/s sur internet, les attaques n'arrêtent pas. Avec fail2ban, tu es chiant. Les attaquants le savent puisqu'ils t'attaquent bien moins ensuite et vont voir ailleurs.
        
        La sécurité, c'est effectivement aussi de dire qu'on est chiant et d'aller voir ailleurs. De plus, réduire les attaques, c'est un peu réduire le trafic réseau donc le bilan carbone global.
        
        Donc, ce n'est pas parfait, mais je suis loin de dire que cela n'a aucun intérêt.
        
        [^] # Re: Cybersécurité ou marketing ?
        
        Posté par Nicolas Boulay (site web personnel) le 07 septembre 2021 à 16:24. Évalué à 4.
        
        De plus, réduire les attaques, c'est un peu réduire le trafic réseau donc le bilan carbone global.
        
        En fait non, ton infra coute principalement à la construction, de plus la variation de conso électrique avec ou sans usage est minime. Cela revient à vouloir donner un prix d'usage par minute à un canapé.
        
        "La première sécurité est la liberté"
  - [^] # Re: Cybersécurité ou marketing ?
    
    Posté par Anonyme le 25 août 2021 à 18:21. Évalué à 4.
    
    C'est précisément ce pourquoi fail2ban ne me semble que rarement pertinent.
    
    Si c’est possible, je suis preneur d’une explication plus approfondie : dans ma compréhension du fonctionnement de fail2ban, il y a détection d’une ou plusieurs entrées de log suspectes puis déclenchement d'une ou plusieurs actions prédéfinies, incluant généralement un blocage des IP impliquées. Est-ce rarement pertinent de souhaiter se débarrasser des nuisibles quel que soit le modèle de sécurité ?
    - [^] # Commentaire supprimé
      
      Posté par Anonyme le 25 août 2021 à 18:52. Évalué à 5.
      
      Ce commentaire a été supprimé par l’équipe de modération.
      - [^] # Re: Cybersécurité ou marketing ?
        
        Posté par claudex le 25 août 2021 à 18:55. Évalué à 6.
        
        Ou sur un service qui est mal configuré par erreur.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 25 août 2021 à 19:32. Évalué à 2.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: Cybersécurité ou marketing ?
        
        Posté par claudex le 25 août 2021 à 21:36. Évalué à 3.
        
        Ça dépend de l'erreur, mais typiquement, c'est utile si tu laisse un compte avec un accès par mot de passe uniquement alors que tu pensais que ce n'était pas le cas.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Cybersécurité ou marketing ?
        
        Posté par barmic 🦦 le 25 août 2021 à 22:05. Évalué à 3.
        
        C'est des choses qui se règles par des linters de configuration.
        
        Et sincèrement c'est trop simple de bypasser fail2ban pour croire que ça apporte une telle sécurité. Ça rend les choses un peu plus lentes, mais je n'ai jamais vu quelqu'un décrire le monitoring de la pertinence de la configuration de fail2ban (durée de bannissement, nombre de tentatives réellement bloquées,…) alors que c'est une configuration qui se test très bien de l’extérieur. Tu es l'objet d'attaques automatisées ? Qu'est-ce que ça coute à un attaquant de prendre en compte ta configuration de fail2ban ? Ça réduit les risques ? Mais c'est bien moins efficace que simplement une configuration correcte de ton ssh et ça tombe bien ssh est plus simple à configurer que fail2ban (et si tu reste sur les configurations par défaut des 2 c'est aussi sécurisé).
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: Cybersécurité ou marketing ?
        
        Posté par claudex le 25 août 2021 à 22:43. Évalué à 4. Dernière modification le 25 août 2021 à 22:43.
        
        alors que c'est une configuration qui se test très bien de l’extérieur.
        
        Mais c'est assez peu répandu pour que ça en vaille la peine sur les attaques généralistes
        
        Tu es l'objet d'attaques automatisées ? Qu'est-ce que ça coute à un attaquant de prendre en compte ta configuration de fail2ban ?
        
        Beaucoup d'IP différentes. Visiblement, suffisamment pour que je n'en vaille pas la peine.
        
        Mais c'est bien moins efficace que simplement une configuration correcte de ton ssh et ça tombe bien ssh est plus simple à configurer que fail2ban
        
        SSH n'est qu'un des services derrière fail2ban (limite, le honeypot, vu que toutes les attaques généralistes commencent par SSH avant de faire du web ou du mail).
        
        (et si tu reste sur les configurations par défaut des 2 c'est aussi sécurisé).
        
        Si je reste sur la configuration par défaut des deux, les mots de passe sont autorisés pour SSH, avec failb
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Cybersécurité ou marketing ?
        
        Posté par barmic 🦦 le 25 août 2021 à 22:51. Évalué à 2.
        
        Mais c'est assez peu répandu pour que ça en vaille la peine sur les attaques généralistes
        
        Si si je l'ai observé personnellement sur un serveur perso qui ne sert pas à grand chose (il n'y a rien de particulièrement attirant dessus). Des IPs qui reviennent un peu plus tard quand elles se font bannir, qui modules leur fréquence de tentatives,… Ça n'est pas très compliqué à mettre en place en soit et bon j'ai pu l'observer.
        
        SSH n'est qu'un des services derrière fail2ban (limite, le honeypot, vu que toutes les attaques généralistes commencent par SSH avant de faire du web ou du mail).
        
        J'avais pensé à ce genre de choses, mais plus rigolo en ne se basant pas sur les logs ssh, mais netfilter, mais c'était plus pour l'amusement que pour l'intérêt. Un fail2ban ça se bypass.
        
        Si je reste sur la configuration par défaut des deux, les mots de passe sont autorisés pour SSH, avec failb
        
        Et tu n'es pas du tout à l’abri d'une attaque à bas bruit sur ton mot de passe.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: Cybersécurité ou marketing ?
        
        Posté par jyes le 26 août 2021 à 09:49. Évalué à 8.
        
        Ça n'est pas très compliqué à mettre en place en soit et bon j'ai pu l'observer.
        
        Justement, que les attaques s’adaptent c’est une chose, mais en attendant, ça diminue fortement leur chance de succès. La force brute limitée à 10 tests par jour a peu de chance de trouver un mot de passe réellement utilisé, alors qu’en centaines ou milliers de tests par seconde, c’est autre chose.
        
        [^] # Re: Cybersécurité ou marketing ?
        
        Posté par octane le 30 août 2021 à 11:06. Évalué à 2.
        
        La force brute limitée à 10 tests par jour a peu de chance de trouver un mot de passe réellement utilisé, alors qu’en centaines ou milliers de tests par seconde, c’est autre chose.
        
        Mais là, c'est plus un problème de politique de mot de passe et politique ssh, non?
        A priori, si tu durcis raisonnablement ton serveur ssh (genre connexion que par clé et non par mot de passe), alors le bruteforce n'a aucune chance d'aboutir, que ce soit à 10 tentatives par jour ou des millions par seconde.
      - [^] # Re: Cybersécurité ou marketing ?
        
        Posté par barmic 🦦 le 25 août 2021 à 22:18. Évalué à 3.
        
        C'est pertinent pour réduire (un peu) la taille des logs
        
        Configure ton syslog
        
        pour signaler les IP malveillantes à des tiers
        
        C'est pas d'une très grande fiabilité ce genre de trucs et quand je vois comment ça se passe pour les listes d'IP interdites dans le monde des serveurs de mails, je ne suis pas sûre que ce soit très étique de participer à ça.
        
        pour économiser (très peu) de la bande passante
        
        Ça pourrait être de la sécurité, mais c'est en échange d'IO disque et de CPU, de plus la configuration de netfilter est assez lente si tu ne fais pas les choses dans les règles.
        
        Cela peut seulement limiter la probabilité de réussite d'une attaque sur un service où l'on est obligé d'accepter des mots de passe faibles.
        
        C'est rigolo parce qu'à chaque fois que dès qu'on parle de fail2ban, il y a immédiatement un tas de gens qui ont besoin d'accepter des mots de passes faibles. Et bien sûr j'imagine qu'il est possible de connaître à l'avance l'IP de connexion de ces comptes ? C'est dommage ça. Ça en fait des cas très rares… et c'est de la sécurité à la petite semelle.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 26 août 2021 à 09:05. Évalué à 4.
        
        Ce commentaire a été supprimé par l’équipe de modération.
    - [^] # Re: Cybersécurité ou marketing ?
      
      Posté par barmic 🦦 le 25 août 2021 à 22:31. Évalué à 2.
      
      On va faire une citation complète, si tu veux bien :
      
      De manière générale il convient de s'interroger sur le modèle de sécurité de ces outils et sur leur réelle utilité. Il n'empêchent pas les attaques mais permettent dans certaines circonstances de réduire leur probabilité de réussite.
      
      C'est précisément ce pourquoi fail2ban ne me semble que rarement pertinent.
      
      Donc non, on ne parle pas de quelque soit le modèle de sécurité et c'est une très mauvaise idée de faire des choses quelque soit le modèle de sécurité. Parce qu'ajouter des couches pour ajouter des couches peu rendre l'ensemble plus fragile tout en donnant l'impression que l'on fait pleins de choses. L'important ce n'est pas de faire pleins de choses, c'est de faire des choses efficaces.
      
      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
  - [^] # Commentaire supprimé
    
    Posté par Anonyme le 25 août 2021 à 18:47. Évalué à 4.
    
    Ce commentaire a été supprimé par l’équipe de modération.
    - [^] # Re: Cybersécurité ou marketing ?
      
      Posté par Anonyme le 25 août 2021 à 18:59. Évalué à 2. Dernière modification le 25 août 2021 à 19:01.
      
      est-ce qu'une connexion à un service immédiatement rejetée par le pare-feu d'un serveur est plus, moins ou tout aussi gênante pour la disponibilité de ce serveur par comparaison à la connexion transmise à un service, gérée par ce service et finalement rabrouée car ne correspondant pas à quelque chose d'autorisée par le service en question ?
      
      EDIT: pardon, j'ai répondu avant de lire ta réponse ci-dessus
      - [^] # Commentaire supprimé
        
        Posté par Anonyme le 25 août 2021 à 19:37. Évalué à 2.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: Cybersécurité ou marketing ?
        
        Posté par Sytoka Modon (site web personnel) le 26 août 2021 à 11:07. Évalué à 7.
        
        Pour moi, les deux sont à faire travailler ensemble. Par exemple, tu peux très bien interdire le compte root de la configuration ssh et mettre une règle sur fail2ban bloquant l'IP 7 jours pour toute connexion sur le compte root.
        
        Ainsi, en cas de faille bas niveau sur SSH, tu rajoutes une couche et en plus, tu es très chiant donc ralenti les attaques.
        
        Bref, pour moi, configurer les deux ne peut pas faire de mal.
    - [^] # Re: Cybersécurité ou marketing ?
      
      Posté par eric gerbier (site web personnel) le 29 août 2021 à 10:49. Évalué à 4.
      
      Ssh est un mauvais exemple, parce qu'il est facile à sécuriser nativement, en passant le paramètre PasswordAuthentication à no dans le fichier /etc/ssh/sshd_config.
      Par contre dans le cas d'un site web avec authentification, fail2ban me semble beaucoup plus pertinent et efficace.
      - [^] # Re: Cybersécurité ou marketing ?
        
        Posté par barmic 🦦 le 30 août 2021 à 11:29. Évalué à 2.
        
        Ça peut déjà avoir plus de sens, mais du coup je préfère gérer ça avec un reverse proxy perso (où je peux configurer un waf, gérer des limitations de fréquence de requête, etc).
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Piper un script depuis curl

Posté par Doug Le Tough (site web personnel) le 25 août 2021 à 02:43. Évalué à 7. Dernière modification le 25 août 2021 à 02:46.

| curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash

"Piper" un shell directement depuis curl vers sudo ?

Ça ne semble pas une démarche très sécurisante.
C'est même tout à fait effrayant !
- [^] # Re: Piper un script depuis curl
  
  Posté par jyes le 25 août 2021 à 08:37. Évalué à 1. Dernière modification le 25 août 2021 à 08:37.
  
  Non, mais ne t’inquiète pas, sudo demande ton mot de passe donc c’est sécurisé.
  - [^] # Re: Piper un script depuis curl
    
    Posté par Frédéric Blanc le 25 août 2021 à 09:33. Évalué à 2.
    
    Je ne pense pas que Doug s'inquiète de la seule présence du sudo, mais plutôt de la construction «téléchargement direct vers un shell», qui peut être détectée et exploitée par un serveur corrompu : https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/
    - [^] # Re: Piper un script depuis curl
      
      Posté par Anonyme le 25 août 2021 à 09:51. Évalué à 3.
      
      Warning: team 1er degré detected !
      - [^] # Re: Piper un script depuis curl
        
        Posté par Benoît Sibaud (site web personnel) le 25 août 2021 à 10:42. Évalué à 7.
        
        Ma grand-mère m'a dit d'être moderne et d'utiliser plutôt wget | doas zsh (et de mettre du bicarbonate pour éviter les problèmes de sécurité).
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 25 août 2021 à 18:09. Évalué à 3.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: Piper un script depuis curl
        
        Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) le 25 août 2021 à 19:13. Évalué à 3.
        
        Tu n'as peut-être pas eu la même grand-mère, ça explique.
        
        « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
        
        [^] # Re: Piper un script depuis curl
        
        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 25 août 2021 à 19:46. Évalué à 2.
        
        La sienne utilisait du bicarbonate bio…
        
        “It is seldom that liberty of any kind is lost all at once.” ― David Hume
        
        [^] # Re: Piper un script depuis curl
        
        Posté par octane le 30 août 2021 à 11:09. Évalué à 2.
        
        http://www.bouletcorp.com/2017/11/02/recettes-de-grand-mere/
        
        Le bicarbonate c'est plutôt pour TCP/IP :D
# curl | bash et apt-key

Posté par Anonyme le 27 août 2021 à 02:37. Évalué à 8.
Avec la sortie de la version 1.1.x, l’installation et utilisation de CrowdSec est grandement facilitée. Pour installer CrowdSec sur Ubuntu ou Debian, ajoutez les dépôts :
```
curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash
```
Alors déjà curl | bash quand on fait un produit d'infosec c’est moyen, mais en plus il faut noter que ce script fait usage de apt-key (et de mémoire c’est ce que recommandent toutes les documentations de Package Cloud).

La commande apt-key est dépréciée depuis un moment et Debian 11 est la dernière version à la proposer. La bonne méthode est de placer le fichier de keyring dans /usr/share/keyrings/ et d'utiliser l'option signed-by dans l'entrée sources.list.

Voir la section « OpenPGP Key distribution » sur la page Instructions to connect to a third-party repository du wiki Debian.
# CrowdSec.

Posté par stopspam le 28 août 2021 à 10:03. Évalué à 2.

It Really Whips the Llama's Ass

:p

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.