Marvin Pascale

[B.Log]

06 Gennaio 2022

Crowdsec centralizzato

Il precedente articolo ha suscitato interesse e viste le molte domande ho deciso di fare degli approfondimenti e mostrarvi anche come gestire il tutto da un’istanza centralizzata con backend PostgreSQL.

Come funziona Crowdsec

Crowdsec fullstack

Il runtime di CrowdSec ruota attorno ad alcuni semplici concetti:

  • vengono letti i log (file system, journald, docker, ecc);
  • i log vengono analizzati tramite parser;
  • i log normalizzati vengono confrontati con gli scenari;
  • quando uno scenario viene “attivato”, CrowdSec genera un avviso ed eventualmente una o più decisioni:
    • l’avviso viene tracciato e rimarrà anche dopo la scadenza della decisione;
    • la decisione d’altra parte, è di breve durata e indica quale azione dovrebbe essere intrapresa contro l’ip offensivo.

Queste informazioni (il segnale, le decisioni associate) vengono quindi inviate all’API locale di crowdsec e archiviate nel database.

Ogni volta che l’API locale riceve un avviso con decisioni associate, le meta informazioni sull’avviso vengono condivise con l’API centrale:

  • l’ip di origine che ha generato l’alert;
  • lo scenario che è stato attivato;
  • il timestamp dell’attacco;

Questi sono gli unici dati che vengono inviati per poter ridistribuire le liste a tutti gli utenti.

I bouncer (buttafuori) sono software autonomi incaricati di agire. Per fare ciò, i bouncer interrogheranno l’API locale per sapere se ci sono decisioni esistenti contro un dato IP, intervallo, nome utente ecc.

Infrastruttura centralizzata

manager crowdsec Ora che conosciamo a grandi linee il funzionamento di Crowdsec possiamo analizzare uno scenario indicato per un utilizzo in ambienti complessi.

Metteremo in piedi una macchina centrale che avrà il compito di coordinare gli agent e i bouncer installati sulla rete.

Preparazione del master

Per mostrarvi la procedura su una Red Had based useremo come master un server Rocky Linux 8.5.

NB: Diamo per scontato che abbiate già un’installazione funzionante di PostgreSQL con db e utenti pronti.

Scarichiamo ed eseguiamo lo script per l’aggiunta dei repositories e le chiavi GPG, poi installiamo il software necessario

# curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.rpm.sh | bash
# dnf install crowdsec crowdsec-firewall-bouncer-iptables

editiamo il file /etc/crowdsec/config.yaml e nella sezione db_config inseriamo di dati per connetterci a PostgreSQL

....
db_config:
  log_level: info
  type: postgres
  user: crowdsec
  password: [passwordsupersicura]
  db_name: crowdsec
  host: 127.0.0.1
  port: 5432
  sslmode: disable
...

il parametro sslmode: disable è necessario se non avete configurato PostgreSQL per accettare le comunicazioni cifrate. Nel mio caso trattandosi di una istanza in locale ho evitato di attivare l’ssl.

Nella sezione server facciamo in modo di esporre le api e permettere agli altri agenti ci collegarsi.

server:
    log_level: info
    listen_uri: 10.17.60.43:8080
    profiles_path: /etc/crowdsec/profiles.yaml
    online_client: # Central API credentials (to push signals and receive bad IPs)
      credentials_path: /etc/crowdsec/online_api_credentials.yaml

nel file /etc/crowdsec/local_api_credentials.yaml inseriamo l’ip locale della macchina

url: http://10.17.60.43:8080
login: dhfjskdhfeuowifkje98749823
password: hjdsajdkha37842983hjedf982374

aggiungiamo la prima istanza (localhost)

# cscli machines add -a
# systemctl restart crowdsec

Preparazione degli altri server

In questo secondo esempio vedremo l’installazione su una macchina Debian based (Debian 11)

# curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | bash
# apt install crowdsec crowdsec-firewall-bouncer-iptables -y

registriamo l’agent

# cscli lapi register -u http://10.17.60.43:8080

configuriamo il servizio per avviarsi senza api locale

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

editiamo il file appena copiato /etc/systemd/system/crowdsec.service aggiungendo in coda a ExecStart: -no-api

[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=/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
Restart=always
RestartSec=60

[Install]
WantedBy=multi-user.target
# systemctl daemon-reload
# systemctl restart crowdsec

registriamo l’istanza

# cscli lapi register -u http://10.17.60.43:8080

Ora ci spostiamo sul server marster, confermiamo le istanze aggiunte e generiamo il token per ogni bouncer.

# cscli machines list
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
 NAME                                              IP ADDRESS      LAST UPDATE           STATUS  VERSION                                                            
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
 dc6f34b3a4994700a2e333df43728701D0iARTSQ6dxiwyMR  xxx.xxx.xxx.xxx  2021-04-13T12:16:11Z  ✔️       v1.0.9-4-debian-pragmatic-a8b16a66b110ebe03bb330cda2600226a3a862d7
 9f3602d1c9244f02b0d6fd2e92933e75zLVg8zSRkyANxHbC  xxx.xxx.xxx.xxx   2021-04-13T12:24:12Z  🚫
--------------------------------------------------------------------------------------------------------------------------------------------------------------------

per vedere la lista delle istanze e confermiamo con

# cscli machines validate 9f3602d1c9244f02b0d6fd2e92933e75zLVg8zSRkyANxHbC

inserendo l’id univoco dell’istanza

ora generiamo il token per il bouncer

# cscli bouncers add server02
Api key for 'server02':

   02954e85c72cf442a4dee357f0ca5a7c

Please keep this key since you will not be able to retrive it!

Ci spostiamo sul server02 e configuriamo il bouncer editando il file /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml indicando l’ip del server master e la chiave ottenuta in precedenza

api_url: http://10.17.60.43:8080/
api_key: 02954e85c72cf442a4dee357f0ca5a7c

riavviamo il bouncer

# systemctl restart crowdsec-firewall-bouncer.service

Ora siamo pronti per creare un account su app.crowdsec.net e registrare il server master. Cliccando su add instance otterremo un token

# cscli console enroll [ID_UNIVOCO_OTTENUTO]

PS: Tutti i test sono stati eseguiti su Hetzner cloud del quale ho già parlato in questo articolo .


Le opinioni in quanto tali sono opinabili e nulla ti vieta di approfondire l’argomento.

Risorse: