URL: https://linuxfr.org/news/comment-configurer-une-installation-crowdsec-multiserveur Title: Comment configurer une installation CrowdSec multiserveur Authors: CrowdSec Ysabeau, Benoît Sibaud, NeoX, Julien Jorge, palm123, Pierre Jarillon et Xavier Claude Date: 2021-05-17T12:17:03+02:00 License: CC By-SA Tags: linux, open_source, sécurité et crowdsec Score: 5 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](https://linuxfr.org/news/crowdsec-la-cybersecurite-collaborative-open-source-et-gratuite-pour-linux). 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. ---- [Le site de CrowdSec](https://crowdsec.net/) [Dépôt GitHub](https://github.com/CrowdSecurity/crowdsec) [Forum Discourse](https://discourse.crowdsec.net/) [Channel Gitter](https://gitter.im/crowdsec-project/community) [Dépêche : La cybersécurité collaborative, open source et gratuite pour Linux](https://linuxfr.org/news/crowdsec-la-cybersecurite-collaborative-open-source-et-gratuite-pour-linux) [Dépêche : Sortie de CrowdSec 1.0 : tutoriel d’utilisation ](https://linuxfr.org/news/sortie-de-crowdsec-1-0-tutoriel-d-utilisation) ---- # 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](https://hub.crowdsec.net/) 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](https://docs.crowdsec.net/Crowdsec/v1/getting_started/installation/#install-using-crowdsec-repository). ```bash 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 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.# ```bash sudo apt install postgresql ``` Tout d’abord, nous devons nous connecter à la base de données en tant qu’utilisateur postgres. ```bash sudo -i -u postgres psql ``` Grâce à la documentation Postgresql Crowdsec, nous pouvons maintenant initialiser la base de données. ```sql postgres=# CREATE DATABASE crowdsec; CREATE DATABASE postgres=# CREATE USER crowdsec WITH PASSWORD 'CREATE USER crowdsec WITH PASSWORD ''; postgres=# CREATE USER crowdsec WITH 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: "" 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 : ```bash 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: password: ``` Et nous pouvons redémarrer CrowdSec : ```bash 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 : ```bash 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. ```bash 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. ```bash 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. ```bash 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. ```bash 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. ```bash 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. ```bash 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 : ```bash 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 : ```bash 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. ```bash 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. - [le site CrowdSec](https://crowdsec.net/) - [le repo GitHub](https://github.com/CrowdSecurity/crowdsec) - [le forum Discourse](https://discourse.crowdsec.net/) - [le channel Gitter](https://gitter.im/crowdsec-project/community)