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
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: ""
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:
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.
