Decision on slash-root.fr

CrowdSec : Avoid a Duplicate Decision / Notification

Wed, 07 Aug 2024 10:52:44 +0200

Introduction

Prenons le cas de l'utilisation de CrowdSec pour protéger des applications web en analysant les logs du reverse-proxy.

Suivant le scénario qui se déclenchera, CrowdSec prendra une décision concernant l'adresse IP concernée. Par exemple, renvoyer un code HTTP 403. Dans ce cas de figure, si l'acteur malveillant persiste, une décision sera prise à chaque fois. Si des notifications sont envoyées à chaque prise de décision, cela peut vite devenir du spam ! C'est le comportement normal puisque le profil par défaut de CrowdSec prend une décision à chaque déclenchement de scénario.

Nous allons voir comment modifier la prise de décision pour vérifier au préalable si une décision identique n'a pas été prise récemment.

Prérequis

CrowdSec installé (voir ici : Installation de CrowdSec)
Toutes les commandes / manipulations présentées ci-dessous seront à exécuter en tant que root.

Modification de la Remediation

Tout va se passer dans un seul fichier : /etc/crowdsec/profiles.yaml

Voici un fichier classique qui ban pendant 4h l'adresse IP qui déclenche un scénario :

#/etc/crowdsec/profiles.yaml
name: default_ip_remediation
filters:
 - Alert.Remediation == true && Alert.GetScope() == "Ip"
decisions:
 - type: ban
 duration: 4h
#duration_expr: "Sprintf('%dh', (GetDecisionsCount(Alert.GetValue()) + 1) * 4)"
on_success: break

Nous allons modifier le filtre pour vérifier si une décision n'a pas été prise il y a moins de 2h pour l'adresse IP concernée.

Voici le fichier modifié :

#/etc/crowdsec/profiles.yaml
name: default_ip_remediation
filters:
 - Alert.Remediation == true && Alert.GetScope() == "Ip" && GetDecisionsSinceCount(Alert.GetValue(), "2h") < 1
decisions:
 - type: ban
 duration: 4h
#duration_expr: "Sprintf('%dh', (GetDecisionsCount(Alert.GetValue()) + 1) * 4)"
on_success: break

Pour valider la modification, redémarrez le service :

systemctl restart crowdsec

Intérêt

On peut se dire : Mais pourquoi faire ça ?

A chaque fois que CrowdSec prendra une décision, si les notifications sont configurées, cela en déclenchera une systématiquement.

Dans mon cas, cela concernait les scans multi-ports et j'en avais marre de recevoir du spam de notification... (Effet JO 2024 ???).

Voici l'output que cela donnait en moins d'une minute :

Conclusion

Maintenant, CrowdSec prendra une décision concernant l'adresse IP qui déclenchera un scénario et qui n'a pas été ban il y a moins de 2h. Si celle-ci revient au bout de 3h et redéclenche un scénario, ça sera reparti pour 4h, etc.

CrowdSec : Protéger l’authentification Gitlab

Fri, 19 Jul 2024 11:06:58 +0200

Introduction

Ce guide explique comment protéger l'authentification sur Gitlab contre les attaques de Bruteforce à l'aide de CrowdSec. Il est essentiel de sécuriser un portail d'authentification web. Une nouvelle collection crowdsec, comprenant 1 parser et 1 scénario, sera installée.

Ce guide se base sur une installation de Gitlab sur Debian 12. La version Gitlab utilisée est la dernière en date (17.2.0).

Prérequis

Une machine Debian 12 avec un accès root ou sudo. Toutes les commandes présentées ci-dessous seront à exécuter en tant que root.
Une connexion internet active.
Gitlab CE ou EE installé
CrowdSec installé (voir ici : Installation de CrowdSec)

Modification du port de l’API CrowdSec

Très important !

Avec une installation standard de Gitlab, le serveur PUMA (serveur web ruby faisant partie de gitlab) écoute sur le port TCP 8080. Il est donc impératif de modifier le port d'écoute de l'API de CrowdSec pour éviter tout conflit.

Procédure décrite [ici]
Vérifiez bien que vos services crowdsec fonctionnent correctement :
```
journalctl -u crowdsec
journalctl -u crowdsec-firewall-bouncer
```

Installation de la collection pour gitlab

En navigant sur le hub de CrowdSec, une collection pour gitlab est disponible.

Installer la collection :

cscli collections install timokoessler/gitlab

Ceci a pour effet d'installer 1 parser et 1 scénario.

Lister les parsers :

cscli parsers list
# timokoessler/gitlab-logs ✔️ enabled 0.1 /etc/crowdsec/parsers/s01-parse/gitlab-logs.yaml

Lister les sénarios :

cscli scenario list
# timokoessler/gitlab-bf ✔️ enabled 0.2 /etc/crowdsec/scenarios/gitlab-bf.yaml

Création du fichier d’acquisition

Afin que le parser Gitlab puisse être utilisé, il faut définir la méthode d'acquisition.

Créez le fichier /etc/crowdsec/acquis.d/gitlab.yaml avec le contenu suivant :

---
filenames:
 - /var/log/gitlab/gitlab-rails/production_json.log
labels:
 type: gitlab

Redémarrage du service

A présent, le service crowdsec peut être rechargé :

systemctl reload crowdsec

Vérification

Nous allons vérifier le fonctionnement du parser et du nouveau scénario dédié à gitlab.

Pour cela, spammez la page de login de Gitlab, puis vérifiez les résultats :

Alertes :

cscli alerts list
# 2 │ Ip:66.66.66.66 │ timokoessler/gitlab-bf │ │ │ ban:1 │ 2024-07-19 07:56:48.649063483 +0000 UTC

Décisions :

cscli decisions list
# 15001 │ crowdsec │ Ip:66.66.66.66 │ timokoessler/gitlab-bf │ ban │ │ │ 6 │ 3h59m43.261827214s │ 2

Conclusion

En suivant ce guide, vous avez sécurisé l'authentification de votre Gitlab contre les attaques de Bruteforce grâce à CrowdSec.

CrowdSec : Protéger l’authentification Proxmox

Thu, 18 Jul 2024 14:50:45 +0200

Introduction

Ce guide explique comment protéger l'authentification sur Proxmox contre les attaques de Bruteforce à l'aide de CrowdSec. Suite aux dernières actualités de VMware, de nombreux utilisateurs ont migré vers Proxmox. Il est donc essentiel de sécuriser le portail d'authentification, exposé par défaut sur le port TCP 8006.

Ce guide se base sur une installation de Proxmox sur Debian 12. Par défaut, rsyslog n'est plus installé sur Debian 12. Nous verrons comment configurer cela avec journald mais également avec rsyslog si besoin.

Prérequis

Une machine Debian 12 avec un accès root ou sudo. Toutes les commandes présentées ci-dessous seront à exécuter en tant que root.
Une connexion internet active.
Proxmox installé
CrowdSec installé (voir ici : Installation de CrowdSec)

Installation de la collection pour proxmox

En navigant sur le hub de CrowdSec, une collection pour proxmox est disponible.

Installer la collection :

cscli collections install fulljackz/proxmox

Ceci a pour effet d'installer 2 parsers et 1 scénario.

Lister les parsers :

cscli parsers list
# crowdsecurity/syslog-logs ✔️ enabled 0.8 /etc/crowdsec/parsers/s00-raw/syslog-logs.yaml
# fulljackz/proxmox-logs ✔️ enabled 0.2 /etc/crowdsec/parsers/s01-parse/proxmox-logs.yaml

Lister les sénarios :

cscli scenario list
# fulljackz/proxmox-bf ✔️ enabled 0.2 /etc/crowdsec/scenarios/proxmox-bf.yaml

Pour que ceux-ci soient pris en compte, le service CrowdSec doit être rechargé. Nous le ferons après quelques modifications.

Modification du parser proxmox

Le parser spécifique à proxmox se situe ici : /etc/crowdsec/parsers/s01-parse/proxmox-logs.yaml

Pour qu'il soit compatible avec la dernière version de Proxmox, nous allons l'éditer et apporter les modifications suivantes :

pattern_syntax:
 PVE_AUTH_FAIL: 'authentication failure; rhost=::ffff:%{IP:client_ip} user=%{USERNAME:source_user}@%{WORD:realm} msg='

Ajout : ::ffff:

Création du fichier d’acquisition

Afin que le parser Proxmox puisse être utilisé, il faut définir la méthode d'acquisition.

Utilisation avec journald

Pour utiliser le parser avec journald :

Créez le fichier /etc/crowdsec/acquis.d/proxmox.yaml avec le contenu suivant :

journalctl_filter:
 - _SYSTEMD_UNIT=pvedaemon.service
labels:
 type: syslog

Utilisation avec rsyslog

Si vous préférez utiliser rsyslog avec le fichier de log /var/log/syslog :

Installez rsyslog si ce n'est pas déjà fait :
```
apt install -y rsyslog
```
Créez le fichier /etc/crowdsec/acquis.d/proxmox.yaml avec le contenu suivant :

---
filenames:
 - /var/log/syslog
labels:
 type: pvedaemon

Redémarrage du service

A présent, le service crowdsec peut être rechargé :

systemctl reload crowdsec

Vérification

Nous allons vérifier le fonctionnement des parsers et du nouveau scénario dédié à proxmox.

Pour cela, spammez la page de login de Proxmox, puis vérifiez les résultats :

Alertes :

cscli alerts list
# | 2 │ Ip:66.66.66.66 │ fulljackz/proxmox-bf │ │ │ ban:1 │ 2024-07-18 12:13:37.498899667 +0000 UTC

Décisions :

cscli decisions list
# 15001 │ crowdsec │ Ip:66.66.66.66 │ fulljackz/proxmox-bf │ ban │ │ │ 7 │ 3h59m51.44622068s │ 2

Conclusion

En suivant ce guide, vous avez sécurisé l'authentification de votre Proxmox contre les attaques de Bruteforce grâce à CrowdSec.