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.
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 . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Cybersécurité ou marketing ?
Posté par barmic 🦦 . Évalué à 0.
Parce que fail2ban c'est efficace ?
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) . Évalué à 2.
fail2ban réduit par 100 environ les attaques sur SSH…
[^] # Commentaire supprimé
Posté par Anonyme . É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) . É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) . Évalué à 4.
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 . Évalué à 4.
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 . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Cybersécurité ou marketing ?
Posté par claudex . É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 . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Cybersécurité ou marketing ?
Posté par claudex . É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 🦦 . É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 . Évalué à 4. Dernière modification le 25 août 2021 à 22:43.
Mais c'est assez peu répandu pour que ça en vaille la peine sur les attaques généralistes
Beaucoup d'IP différentes. Visiblement, suffisamment pour que je n'en vaille pas la peine.
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).
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 🦦 . Évalué à 2.
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.
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.
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 . Évalué à 8.
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 . Évalué à 2.
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 🦦 . Évalué à 3.
Configure ton syslog
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.
Ç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.
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 . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Cybersécurité ou marketing ?
Posté par barmic 🦦 . Évalué à 2.
On va faire une citation complète, si tu veux bien :
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 . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Cybersécurité ou marketing ?
Posté par Anonyme . É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 . É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) . É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) . É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 🦦 . É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) . É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 . É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 . É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 . Évalué à 3.
Warning: team 1er degré detected !
[^] # Re: Piper un script depuis curl
Posté par Benoît Sibaud (site web personnel) . É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 . É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) . É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) . É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 . É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 . Évalué à 8.
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 deapt-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'optionsigned-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 . É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.