Come configurare un’installazione multiserver di CrowdSec

CrowdSec è una soluzione di sicurezza collaborativa e open source creata per proteggere servizi, server, container o macchine virtuali di Linux esposti a Internet con un agente lato server. È una versione modernizzata di Fail2ban che è stata una grande fonte di ispirazione per i fondatori del progetto.

CrowdSec è gratuito (con licenza MIT) e il suo codice sorgente è disponibile su GitHub. La soluzione sta sfruttando un motore di analisi del comportamento IP basato su log per rilevare gli attacchi. Quando l’agente CrowdSec rileva un’aggressione, offre diversi tipi di riparazione per gestire l’IP dietro di essa (divieto di accesso, captcha, autenticazione 2FA ecc.). Il report è curato dalla piattaforma e, se legittimo, condiviso attraverso la comunità CrowdSec in modo che gli utenti possano anche proteggere le proprie risorse da questo indirizzo IP.

Alcuni mesi fa, abbiamo aggiunto alcune caratteristiche interessanti a CrowdSec durante il rilascio della v1.0.x. Uno dei più interessanti è la capacità dell’agente CrowdSec di agire come un’API di rest HTTP per raccogliere segnali da altri agenti CrowdSec. Pertanto, è responsabilità di questo agente speciale memorizzare e condividere i segnali raccolti. D’ora in poi chiameremo questo agente speciale il server LAPI.

Un’altra caratteristica degna di nota è che la mitigazione non deve più avvenire sullo stesso server del rilevamento. La mitigazione viene eseguita utilizzando i buttafuori. I buttafuori si basano sull’API REST HTTP servita dal server LAPI.

Obiettivi

In questo articolo descriveremo come distribuire CrowdSec in una configurazione multi-server con un segnale di condivisione del server.

Sia server-2 che server-3 hanno lo scopo di ospitare servizi. Puoi dare un’occhiata al nostro Hub per sapere quali servizi CrowdSec può aiutarti a proteggere. Ultimo ma non meno importante, server-1 è pensato per ospitare i seguenti servizi locali:

• l’API locale necessaria ai buttafuori

• il database alimentato dai tre agenti CrowdSec locali e dal servizio online di blocklist CrowdSec. Poiché server-1 serve l’API locale, lo chiameremo server LAPI.

Abbiamo scelto di utilizzare un backend postgresql per il database CrowdSec al fine di consentire un’elevata disponibilità. Questo argomento sarà trattato in post futuri. Se sei d’accordo con nessuna disponibilità elevata, puoi saltare il passaggio 2.

Inoltre questo post tratterà la mitigazione degli attacchi per i servizi ospitati su server-2 e server-3 utilizzando i bouncer CrowdSec.

Questo articolo è il primo di una serie.

Prerequisiti

• Due server Ubuntu 20.04 preinstallati con connessione Internet che ospitano servizi di hosting. D’ora in poi, faremo riferimento a questi server con server-2 e server-3 .

• Un server Ubuntu 20.04 preinstallato non rivolto a Internet. D’ora in poi faremo riferimento a questo server con server-1 . Supponiamo che l’ip del server-1 sia 10.0.0.1. (nessuna connessione Internet su questo server non è un requisito rigoroso).

• Una rete locale che collega tutti e tre i server

Passaggio 1: installazione di CrowdSec

Installiamo CrowdSec su ogni singolo server, seguendo Guida all’installazione di CrowdSec .

 wget -qO - https://s3-eu-west-1.amazonaws.com/crowdsec.debian.pragmatic/crowdsec.asc | sudo apt-key add - & amp; & amp; 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 & gt; / dev / null sudo apt update sudo apt install crowdsec

Ora abbiamo tre installazioni CrowdSec standard in esecuzione.

Passaggio 2 (facoltativo): cambia il backend del database in postgresql sul server-1

 sudo apt install postgresql

Per prima cosa dobbiamo connetterci al database come utente postgres.

 sudo -i -u postgres psql

Grazie alla documentazione di Postgresql Crowdsec , ora possiamo inizializzare il database .

 postgres = # CREATE DATABASE crowdsec; CREATE DATABASE postgres = # CREATE USER crowdsec WITH PASSWORD 'CREATE USER crowdsec WITH PASSWORD' & lt; password & gt; '; postgres = # CREA UTENTE crowdsec CON PASSWORD '& lt; password & gt;'; CREATE ROLE postgres = # GARANTISCE TUTTI I PRIVILEGI SU DATABASE crowdsec A crowdsec; CONCESSIONE

Ora facciamo sapere a CrowdSec di questo nuovo database backend. Per ottenere ciò, dovremo aggiornare la sezione db_config del file /etc/crowdsec/config.yaml.

 db_config: log_level: info tipo: postgres utente: crowdsec password: "& lt; password & gt;" nome_db: host crowdsec: 127.0.0.1 porta: 5432

Dopo aver registrato nuovamente la macchina locale nel database, siamo in grado di riavviare CrowdSec:

 sudo cscli machines aggiungi -a sudo systemctl riavvia crowdsec

Passaggio 3: crea rapporti server-2 e server-3 al server LAPI

Per prima cosa dobbiamo configurare CrowdSec su server-1 per accettare connessioni da server-2 e server-3 . Assicurati che il tuo firewall consenta le connessioni da server-2 e server-3 sulla porta 8080 di server-1 .

Configuriamo il server API sul lato server-1 . Affinché ciò avvenga, dovremo modificare sia /etc/crowdsec/config.yaml e /etc/crowdsec/local_api_credentials.yaml .

Per /etc/crowdsec/config.yaml , è ora la sezione API che deve essere modificata. È solo questione di aggiornare l’IP in ascolto da localhost a 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 Credenziali API Crowdsec (per inviare segnali e ricevere IP non validi) credentials_path: /etc/crowdsec/online_api_credentials.yaml

Per /etc/crowdsec/local_api_credentials.yaml dobbiamo solo modificare l’ip configurato di conseguenza:

 url: http://10.0.0.1:8080/ login: & lt; login & gt; password: & lt; password & gt;

E possiamo riavviare CrowdSec:

 sudo systemctl riavvia crowdsec

Adesso configureremo le connessioni su server-2 e server-3 .

Per prima cosa ci registriamo al server lapi sia su server-2 che su server-3 :

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

By default, the local api server is active on every CrowdSec agent installation. In this setup, we want to disable it on server-2 and server-3. To achieve this, we need to tweak the CrowdSec agent systemd service file.

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

Now edit /etc/systemd/system/crowdsec.service and add the -no-api parameter to CrowdSec agent invocation on both server-2 and server-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

We can now acknowledge the changes and restart CrowdSec once again.

sudo systemctl daemon-reload sudo systemctl restart crowdsec

Last thing to do is to allow server-2 and server-3 connections on server-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 🚫 --------------------------------------------------------------------------------------------------------------------------------------------------------------------

In this output, we can see two machines that are not yet validated. Let’s validate them now.

sudo cscli machines validate 9f3602d1c9244f02b0d6fd2e92933e75zLVg8zSRkyANxHbC sudo cscli machines validate ac86209e6f9c4d7d8de43e2ea31fe28ebvde0vWDr46Mpd3L

server-2 and server-3 are now allowed to push data to server-1 CrowdSec agent. It may be needed to restart CrowdSec on server-2 and server-3.

sudo systemctl restart crowdsec

On server-1, the command sudo cscli machines list should now show three validated machines.

Passaggio 4: configurazione della mitigazione

Ora vogliamo installare la mitigazione sui nostri server con connessione a Internet. Per prima cosa dobbiamo generare due token API per server-2 e server-3 su server-1 .

 sudo cscli bouncers aggiungono la chiave API server-2 per "server-2": 02954e85c72cf442a4dee357f0ca5a7c Si prega di conservare questa chiave poiché non sarà possibile recuperarla!

 sudo cscli bouncers aggiungono la chiave API server-3 per "server-3": 3b1030ce0840c343eecd387ac5a3a614 Si prega di conservare questa chiave poiché non sarà possibile recuperarla!

Per ora, non è disponibile alcun pacchetto per il firewall bouncer. Questo è nella nostra lista di cose da fare ad alta priorità.

Quindi sia su server-2 che su server-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

Se iptables e nftables non sono installati, lo script di installazione chiederà il permesso per installarlo. Lo stesso accadrà per l’installazione di ipset .

È giunto il momento di utilizzare il token che abbiamo generato all’inizio di questo passaggio. Sia api_key che api_url devono essere aggiornati in /etc/crowdsec/cs-firewall-bouncer/cs-firewall-bouncer.yaml : < / p>

 modalità: 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 # se presente, inserisci la regola in quelle catene iptables_chains: - INPUT # - FORWARD # - DOCKER-USER

Ora possiamo riavviare il bouncer del firewall.

 sudo systemctl riavvia cs-firewall-bouncer

Conclusione e prospettive

Abbiamo descritto come configurare un’installazione multiserver di CrowdSec. Il sovraccarico delle risorse su server-2 e server-3 è piuttosto limitato poiché la maggior parte delle attività vengono deportate su server-1 . Ciò consente di aumentare la configurazione solo di:

• registra e convalida l’agente CrowdSec sul server LAPI

• aggiungere e convalidare nuovi bouncer Vale la pena notare che i bouncer e gli agenti CrowdSec non devono essere installati sullo stesso server. Pertanto, l’agente CrowdSec deve essere installato dove vengono generati i log, ma la mitigazione può essere rimossa dove è significativa.

Ovviamente, ci sono delle avvertenze in questa configurazione:

• Le comunicazioni tra gli agenti avvengono tramite http chiaro. Questo è accettabile su una rete locale, ma non possibile su Internet. CrowdSec consente l’uso di https per queste comunicazioni, un prossimo post tratterà questo argomento.

• Anche il monitoraggio o gli avvisi non sono trattati in questo articolo. CrowdSec consente un monitoraggio molto potente tramite il raschietto Prometheus. Un post tratterà anche questo argomento.

• Il database CrowdSec non è altamente disponibile. Inoltre, l’agente CrowdSec su server-1 è un singolo punto di errore.

Ora ti starai chiedendo: come creare una configurazione CrowdSec multi-macchina ad alta disponibilità? Restate sintonizzati per il nostro prossimo articolo.

Il team di CrowdSec è sempre felice di ricevere feedback sulla soluzione e sul suo utilizzo. Se desideri incontrarli e fare due chiacchiere, ecco alcuni link utili. Dai loro un grido!