Comment configurer une installation CrowdSec multiserveur

Posté par  (site web personnel) . Édité par Ysabeau 🧶, Benoît Sibaud, NeoX, Julien Jorge, palm123, Pierre Jarillon et claudex. Modéré par Ysabeau 🧶. Licence CC By‑SA.
Étiquettes :
17
24
mai
2021
Sécurité

Pour rappel, CrowdSec est un outil open source de cybersécurité collaborative conçu pour protéger les serveurs, services, conteneurs ou machines virtuelles exposés sur Internet. Un article plus exhaustif peut être consulté ici.

Il y a quelques mois, nous avons ajouté quelques fonctionnalités intéressantes à la solution lors de la sortie de la version 1.0.x. L’une d’entre elles est la capacité de l’agent CrowdSec à agir comme une API HTTP REST pour collecter les signaux d’autres agents CrowdSec. Ainsi, il est de la responsabilité de cet agent spécial de stocker et de partager les signaux collectés. Nous appellerons cet agent spécial le serveur LAPI à partir de maintenant.

Une autre caractéristique intéressante est que la remédiation des attaques n’a plus lieu sur le même serveur que la détection, mais est réalisée à l’aide de bouncers. Ces derniers s’appuient sur l’API HTTP REST servie par le serveur LAPI.

Sommaire

Objectifs

Dans cet article, nous allons décrire comment déployer CrowdSec dans une configuration multiserveur avec un serveur partageant le signal.

Le serveur-2 et le serveur-3 sont destinés à héberger des services. Vous pouvez jeter un coup d’œil sur le Hub de CrowdSec pour savoir quels services CrowdSec peut vous aider à sécuriser. Enfin, le serveur-1 est destiné à héberger les services locaux suivants :

  • l’API locale nécessaire aux bouncers ;
  • la base de données alimentée par les trois agents CrowdSec locaux et le service de liste de blocage en ligne de CrowdSec. Comme le serveur-1 sert l’API locale, nous l’appellerons le serveur LAPI.

Nous avons choisi d’utiliser un backend PostgreSQL pour la base de données CrowdSec afin de permettre une haute disponibilité. Ce sujet sera abordé dans de futurs articles. Si vous êtes d’accord avec l’absence de haute disponibilité, vous pouvez sauter l’étape 2.

En outre, ce post couvrira la remédiation des attaques pour les services hébergés sur le serveur-2 et le serveur-3 en utilisant les bouncers CrowdSec.

Ce qu’il vous faut avant de commencer

  • Deux serveurs Ubuntu 20.04 préinstallés, connectés à Internet et hébergeant des services. À partir de maintenant, nous désignerons ces serveurs par serveur-2 et serveur-3
  • Un serveur Ubuntu 20.04 préinstallé non connecté à Internet. À partir de maintenant, nous désignerons ce serveur par server-1. Supposons que l’adresse IP du serveur-1 soit 10.0.0.1. (l’absence de connexion Internet sur ce serveur n’est pas une exigence stricte).
  • Un réseau local reliant les trois serveurs

Étape 1 : installation de CrowdSec

Installons CrowdSec sur chaque serveur, en suivant le guide d’installation.

wget -qO - https://s3-eu-west-1.amazonaws.com/crowdsec.debian.pragmatic/crowdsec.asc |sudo apt-key add - && echo "deb https://s3-eu-west-1.amazonaws.com/crowdsec.debian.pragmatic/$(lsb_release -cs) $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/crowdsec.list > /dev/null
sudo apt update
sudo apt install crowdsec

Nous avons maintenant trois installations CrowdSec standard en cours d’exécution.

NdM : histoire de sécuriser un peu la chaîne d’approvisionnement (parce que là, on va valider les signatures des paquets en utilisant la même source que les paquets), on peut vérifier que l’adresse pointée est bien celle de la documentation, aussi présente dans le code source de la documentation (crowdsec/docs/v1.X/docs/getting_started/installation.md) sur GitHub. Debian ou FreeBSD se basent sur les sources GitHub et ne semblent pas référencer cette clé du coup, donc pas de possibilité de vérifier via leurs sites). À tout hasard, la clé au moment de la modération de la dépêche :

pub   rsa3072/0xF275830D0D012898 2021-02-04 [SC] [expire : 2023-02-04]
      76BB08A3995DD598484A0CE6F275830D0D012898
uid                  [ inconnue] Crowdsec Debian Archive <support@crowdsec.net>
sub   rsa3072/0xF611332974D75C7B 2021-02-04 [E] [expire : 2023-02-04]

Étape 2 (facultative) : Changez le backend de la base de données pour postgresql sur le serveur-1.

sudo apt install postgresql

Tout d’abord, nous devons nous connecter à la base de données en tant qu’utilisateur postgres.

sudo -i -u postgres
psql

Grâce à la documentation Postgresql Crowdsec, nous pouvons maintenant initialiser la base de données.

postgres=# CREATE DATABASE crowdsec;
CREATE DATABASE
postgres=# CREATE USER crowdsec WITH PASSWORD 'CREATE USER crowdsec WITH PASSWORD '<password>';
postgres=# CREATE USER crowdsec WITH PASSWORD '<password>';
CREATE ROLE
postgres=# GRANT ALL PRIVILEGES ON DATABASE crowdsec TO crowdsec;
GRANT

Maintenant, faisons en sorte que CrowdSec connaisse ce nouveau backend de base de données. Pour cela, nous devons mettre à jour la section db_config du fichier /etc/crowdsec/config.yaml.

    db_config:
      log_level: info
      type: postgres
      user: crowdsec
      password: "<password>"
      db_name: crowdsec
      host: 127.0.0.1
      port: 5432

Après avoir réenregistré la machine locale dans la base de données, nous sommes en mesure de redémarrer CrowdSec :

sudo cscli machines add -a
sudo systemctl restart crowdsec

Étape 3 : Faire en sorte que le serveur-2 et le serveur-3 rapportent au serveur LAPI

Tout d’abord, nous devons configurer CrowdSec sur le serveur-1 pour accepter les connexions du serveur-2 et du serveur-3. Assurez-vous que votre pare-feu autorise les connexions du serveur-2 et du serveur-3 sur le port 8080 du serveur-1.

Configurons le serveur API du côté du serveur-1. Pour cela, nous devons modifier les fichiers /etc/crowdsec/config.yaml et /etc/crowdsec/local_api_credentials.yaml.

Pour /etc/crowdsec/config.yaml, c’est maintenant la section API qui doit être modifiée. Il s’agit seulement de mettre à jour l’IP d’écoute de localhost à l’IP locale :

    api:
      client:
        insecure_skip_verify: false
        credentials_path: /etc/crowdsec/local_api_credentials.yaml
      server:
        log_level: info
        listen_uri: 10.0.0.1:8080
        profiles_path: /etc/crowdsec/profiles.yaml
        online_client: # Crowdsec API credentials (to push signals and receive bad IPs)                                                                            
          credentials_path: /etc/crowdsec/online_api_credentials.yaml

Pour /etc/crowdsec/local_api_credentials.yaml nous devons seulement changer l’adresse IP configurée en conséquence :

    url: http://10.0.0.1:8080/
    login: <login>
    password: <password>

Et nous pouvons redémarrer CrowdSec :

sudo systemctl restart crowdsec

Maintenant nous allons configurer les connexions sur le serveur-2 et le serveur-3.
Tout d’abord, nous nous enregistrons auprès du serveur lapi sur le serveur-2 et le serveur-3 :

sudo cscli lapi register -u http://10.0.0.1:8080

Par défaut, le serveur api local est actif sur chaque installation d’agent CrowdSec. Dans cette configuration, nous voulons le désactiver sur le serveur-2 et le serveur-3. Pour ce faire, nous devons modifier le fichier de service systemd de l’agent CrowdSec.

sudo cp /lib/systemd/system/crowdsec.service /etc/systemd/system/crowdsec.service

Maintenant, éditez etc/systemd/system/crowdsec.service et ajoutez le paramètre -no-api à l’invocation de l’agent CrowdSec sur le serveur-2 et le serveur-3.

    [Unit]
    Description=Crowdsec agent
    After=syslog.target network.target remote-fs.target nss-lookup.target

    [Service]
    Type=notify
    Environment=LC_ALL=C LANG=C
    PIDFile=/var/run/crowdsec.pid
    ExecStartPre=/usr/bin/crowdsec -c /etc/crowdsec/config.yaml -t
    ExecStart=/usr/bin/crowdsec -c /etc/crowdsec/config.yaml -no-api
    #ExecStartPost=/bin/sleep 0.1
    ExecReload=/bin/kill -HUP $MAINPID

    [Install]
    WantedBy=multi-user.target

Nous pouvons maintenant constater les changements et redémarrer CrowdSec une fois de plus.

sudo systemctl daemon-reload
sudo systemctl restart crowdsec

La dernière chose à faire est d’autoriser les connexions du serveur-2 et du serveur-3 sur le serveur-1.

sudo cscli machines list
     NAME                                              IP ADDRESS      LAST UPDATE           STATUS  VERSION                                                            
    --------------------------------------------------------------------------------------------------------------------------------------------------------------------
     dc6f34b3a4994700a2e333df43728701D0iARTSQ6dxiwyMR  10.0.0.1        2021-04-13T12:16:11Z  ✔️       v1.0.9-4-debian-pragmatic-a8b16a66b110ebe03bb330cda2600226a3a862d7 
     9f3602d1c9244f02b0d6fd2e92933e75zLVg8zSRkyANxHbC  10.0.0.3        2021-04-13T12:24:12Z  🚫                                                                         
     ac86209e6f9c4d7d8de43e2ea31fe28ebvde0vWDr46Mpd3L  10.0.0.2        2021-04-13T12:22:28Z  🚫                                                                         
    --------------------------------------------------------------------------------------------------------------------------------------------------------------------

Dans cette sortie, nous pouvons voir deux machines qui ne sont pas encore validées. Validons-les dès maintenant.

sudo cscli machines validate 9f3602d1c9244f02b0d6fd2e92933e75zLVg8zSRkyANxHbC
sudo cscli machines validate ac86209e6f9c4d7d8de43e2ea31fe28ebvde0vWDr46Mpd3L

Le serveur-2 et le serveur-3 sont maintenant autorisés à pousser les données vers l’agent CrowdSec du serveur-1. Il peut être nécessaire de redémarrer CrowdSec sur le serveur-2 et le serveur-3.

sudo systemctl restart crowdsec

Sur le serveur-1, la commande sudo cscli machines list devrait maintenant montrer trois machines validées.

Étape 4 : mettre en place des mesures de remédiation

Nous voulons maintenant installer nos mesures de remédiation sur nos serveurs connectés à Internet. Tout d’abord, nous devons générer deux jetons API pour le serveur-2 et le serveur-3 sur le serveur-1.

sudo cscli bouncers add server-2
Api key for 'server-2':
   02954e85c72cf442a4dee357f0ca5a7c
Please keep this key since you will not be able to retrive it!

sudo cscli bouncers add server-3
Api key for 'server-3':
   3b1030ce0840c343eecd387ac5a3a614
Please keep this key since you will not be able to retrieve it!

Pour le moment, il n’y a pas de paquet disponible pour le bouncer firewall. Ceci est en haut de notre feuille de route. Donc sur le serveur 2 et le serveur 3 :

wget https://github.com/crowdsecurity/cs-firewall-bouncer/releases/download/v0.0.10/cs-firewall-bouncer.tgz
tar zxvf cs-firewall-bouncer.tgz
cd cs-firewall-bouncer-v0.0.10/
sudo ./install.sh

Il est maintenant temps d’utiliser le token généré au début de cette étape.
api_key et api_url doivent être mis à jour dans /etc/crowdsec/cs-firewall-bouncer/cs-firewall-bouncer.yaml :

    mode: iptables
    piddir: /var/run/
    update_frequency: 10s
    daemonize: true
    log_mode: file
    log_dir: /var/log/
    log_level: info
    api_url: http://10.0.0.1:8080/
    api_key: 02954e85c72cf442a4dee357f0ca5a7c
    disable_ipv6: false
    #if present, insert rule in those chains
    iptables_chains:
      - INPUT
    #  - FORWARD
    #  - DOCKER-USER

Nous pouvons maintenant redémarrer le bouncer firewall.

sudo systemctl restart cs-firewall-bouncer

Conclusion et perspectives

Nous avons décrit comment configurer une installation multi-serveurs de CrowdSec. La surcharge en ressources sur les serveurs 2 et 3 est assez limitée, car la plupart des tâches sont déportées sur le serveur 1. Cela permet d’augmenter l’installation de seulement :

  • L’enregistrement et validation de l’agent CrowdSec sur le serveur LAPI
  • L’ajout et validation de nouveaux bouncers. Il est important de noter que les bouncers et agents CrowdSec ne doivent pas être installés sur le même serveur. Par conséquent, l’agent CrowdSec doit être installé là où les journaux sont générés, mais la remédiation peut être déportée là où elle est utile.

Quelques mises en garde :

  • Les communications entre les agents se font par HTTP en clair. Ceci est acceptable sur un réseau local, mais pas possible sur Internet. CrowdSec permet l’utilisation de HTTPS pour ces communications, un prochain billet couvrira ce sujet.
  • La surveillance ou l’alerte n’est pas non plus couverte dans cet article. CrowdSec permet une surveillance très puissante grâce au scraper Prometheus. Un article couvrira également ce sujet.
  • La base de données CrowdSec n’est pas hautement disponible. En outre, l’agent CrowdSec sur le serveur-1 est un point de défaillance unique.

Maintenant vous vous demandez peut-être : comment construire une installation CrowdSec multi-machine hautement disponible ? Restez à l’écoute de notre prochain article.

L’équipe CrowdSec est toujours heureuse de recevoir des commentaires sur la solution et son utilisation. Si vous souhaitez les rencontrer et discuter avec eux, voici quelques liens utiles.

Aller plus loin

Suivre le flux des commentaires

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