Entorno multi servidor con Crowdsec
Con este título tan indigesto, vamos a tratar de explicar qué es lo que hace una bestia parda a Crowdsec… como lo habitual será tener el agente de Crowdsec en cada una de nuestras máquinas de la organización, haremos que entre ellas se puedan comunicar para prevenir ataques.
Esto es, que si un equipo con Windows o Linux es atacado, pueda el resto de máquinas de la organización enterarse del ataque y bloquear la dirección IP del atacante antes de que les pueda siquiera tocar a la puerta. Por defecto digamos que Crowdsec funciona de manera local, cada agente de Crowdsec se comunica a su propio servidor Local de APIs, lo que haremos será que todos se comuniquen al mismo servidor LAPI.
Servidor Local API,
Comenzamos, primero, en la máquina que queremos que actue como servidor API para el resto de agentes. Así que lo habilitamos en su fichero de configuración ‘ /etc/crowdsec/config.yaml’, indicamos la IP por la que escuchará y el puerto:
api: ... server: ... listen_uri: 192.168.2.10:8080 ...
En ‘/etc/crowdsec/local_api_credentials.yaml’ únicamente la misma dirección IP:
url: http://192.168.2.10:8080 ...
Reiniciamos para aplicar los cambios:
sudo systemctl restart crowdsec
Agentes de Crowdsec,
Ahora, el resto de máquinas con Crowdsec deberemos registrarlas contra el Local API del servidor, y además deshabilitaremos el LAPI de cada máquina Crowdsec ya que no se usará.
Por ponerlo de offtopic, si no tienes instalado Crowdsec en la máquina destino a proteger, es el momento 😉 Tienes en posts anteriores cómo proteger un Windows, Linux…
Bueno, venga, va, nos registramos contra el LAPI server desde cada agente con:
sudo cscli lapi register -u http://192.168.2.10:8080 INFO[14-11-2022 10:14:08 PM] Successfully registered to Local API (LAPI) INFO[14-11-2022 10:14:08 PM] Local API credentials dumped to '/etc/crowdsec/local_api_credentials.yaml' WARN[14-11-2022 10:14:08 PM] Run 'sudo systemctl reload crowdsec' for the new configuration to be effective.
Paramos nuestro propio servidor API ya que no lo usaremos:
sudo cp /lib/systemd/system/crowdsec.service /etc/systemd/system/crowdsec.service
Y añadimos ‘-no-api’ en el fichero de configuración de Crowdsec ‘/etc/systemd/system/crowdsec.service’
... ExecStart=/usr/bin/crowdsec -c /etc/crowdsec/config.yaml -no-api ...
Finalmente recargamos los servicios para usar esta nueva configuración:
sudo systemctl daemon-reload sudo systemctl restart crowdsec
Ahora ya si nos vamos al servidor LAPI, podremos ver que hay solicitudes de conexiones pendientes con el comando ‘sudo cscli machines list’:
--------------------------------------------------------------------------------------------------------- NAME IP ADDRESS LAST UPDATE STATUS VERSION AUTH TYPE LAST HEARTBEAT --------------------------------------------------------------------------------------------------------- b91d17c64c4e4a2 192.168.x.xxx 2022-11-14T22:18:00Z ✔️ v1.4.1-debian password 19s 9c70ab3970dd4cc 192.168.x.xxx 2022-11-14T22:14:08Z 🚫 password ⚠️ 4m11s ---------------------------------------------------------------------------------------------------------
Validamos las máquinas ejecutando ‘sudo cscli machines validate 9c70ab3970dd4cc’
sudo cscli machines validate 9c70ab3970dd4cc INFO[14-11-2022 10:19:35 PM] machine '9c70ab3970dd4cc' validated successfully
Y volvemos a verificar ‘sudo cscli machines list’:
--------------------------------------------------------------------------------------------------------- NAME IP ADDRESS LAST UPDATE STATUS VERSION AUTH TYPE LAST HEARTBEAT --------------------------------------------------------------------------------------------------------- b91d17c64c4e4a 192.168.x.xxx 2022-11-14T22:19:00Z ✔️ v1.4.1-debian password 40s 9c70ab3970dd4cc 192.168.x.xxx 2022-11-14T22:19:35Z ✔️ password 5s ---------------------------------------------------------------------------------------------------------
Sin olvidarnos recargar Crowdsec en cada agente una vez le hayamos validado, con:
sudo systemctl restart crowdsec
Mitigaciones,
Ahora, para mitigar, para aplicar acciones que nos permitan reducir los riesgos de vulnerabilidad frente a ciertas amenazas, tendremos que usar los bouncers. Primero, desde el servidor de APIs le crearemos los tokens que necesiten los bouncers de los agentes. Lo haremos con cada bouncer que necesitemos en cada agente, ejemplo ‘sudo cscli bouncers add OS-JITSI-05-fw’
Api key for 'OS-JITSI-05-fw': xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Please keep this key since you will not be able to retrieve it!
En cada agente de Crowdsec deberemos instalar el bouncer que necesitemos, en este caso nos basaremos en los bouncer de tipo firewall, para cada OS, hay un bouncer compatible: Windows firewall, iptables, nftables, ipset, pf… Si tenemos iptables:
sudo apt install crowdsec-firewall-bouncer-iptables -y
Y editamos el fichero de configuración del bouncer del firewall ‘ /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml’ indicando la dirección IP de nuestro LAPI server y el token que acabamos de generarle:
... api_url: http://192.168.2.10:8080/ api_key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxx ...
Reiniciamos el servicio del bouncer del firewall:
sudo systemctl restart crowdsec-firewall-bouncer sudo systemctl status crowdsec-firewall-bouncer
Y listo! Esta máquina quedará preparada, podrá agregar en el firewall del SO entradas denegando el acceso a determinadas direcciones IP que le comunique el servidor de APIs.
Podremos desde el servidor LAPI verificar el estado de los bouncers con ‘sudo cscli bouncers list’:
----------------------------------------------------------------------------------------------------------------------- NAME IP ADDRESS VALID LAST API PULL TYPE VERSION AUTH TYPE ----------------------------------------------------------------------------------------------------------------------- OS-JITSI-05-fw 192.168.x.xxx ✔️ 2023-02-02T16:40:16Z crowdsec-firewall-bouncer v0.0.24-debian api-key OS-ELK-03-fw 192.168.x.xxx ✔️ 2023-02-02T16:40:11Z crowdsec-firewall-bouncer v0.0.24-debian api-key OS-GRA-04-fw 192.168.x.xxx ✔️ 2023-02-02T16:40:11Z crowdsec-firewall-bouncer v0.0.24-debian api-key OS-NGINX-01-fw 192.168.x.xxx ✔️ 2023-02-02T16:40:10Z crowdsec-firewall-bouncer v0.0.24-debian api-key OS-NGINX-01-mirror 192.168.x.xxx ✔️ 2023-02-02T16:40:18Z crowdsec-blocklist-mirror v0.0.1-9-g86d6 api-key OS-OTRS-01-fw 192.168.x.xxx ✔️ 2023-02-02T16:40:16Z crowdsec-firewall-bouncer v0.0.24-debian api-key ... ------------------------------------------------------------------------------------------------------------------------
Y listo! Con esto va quedando la malla cerrada! Todos nuestros Crowdsec de la organización se hablarán mediante un único servidor de API, por lo que todos quedarán igualmente protegidos, compartiendo una única lista de direcciones IPs negra, bloqueando en sus respectivos FWs a las IPs de los atacantes…
Abracitos! Que vaya MUY bien 😉
Posts recomendados:
- Gestión de calendarios con Radicale - 23 de mayo de 2024
- Monitorizando las reglas UTM web de nuestro firewall gracias a Centreon - 21 de mayo de 2024
- Backup automatizado de la configuración de Fortigate - 16 de mayo de 2024