CrowdSec

Siehe auch

Fail2ban

Begriffe:

Angriffserkennung: Aufgabe des Agents, der sogenannten „Security Engine“. Auf dem CrowdSec HUB finden sich für viele Applikationen vordefinierte Konfigurationsdateien für Attack Scenarios bis hin zu AppSec Rules. Der Agent blockt nichts, das ist Aufgabe des Bouncers.
Scenario: YAML-Dateien, liegen in /etc/crowdsec/scenarios. Abhängig von der Applikation. Für den Apache Webserver unter anderem CVE-Definitionen oder Regelwerke, um exzessives Crawling, „Bad User Agents“ oder „Path Probing“ zu erkennen. Schön: Szenarien werden zwischen ähnlichen Applikationen geteilt, zum Beispiel zwischen Apache httpd und Nginx.
Collection: Enthält Logdatei-Parser und Definitionen für Scenarios. Daraus leitet CrowdSec Entscheidungen ab.
Bouncer: Ist entschieden worden, dass ein Angriff vorliegt, tritt der Bouncer in Aktion und sperrt die IP-Adresse oder schützt eine Webseite mit einem Captcha-Code - je nach Wunsch.
lapi: Bouncer und CrowdSec kommunizieren über das „Local CrowdSec API“.

Links

CrowdSec Hub: https://app.crowdsec.net/hub/
Doku: https://docs.crowdsec.net/index.html

Installation

Die zu schützenden Maschinen müssen mit dem CrowdSec-Agent aus den Hersteller-Repos ausgestattet werden. Die Repos liessen sich zwar auch per curl -s https://install.crowdsec.net | sudo sh installieren, das funktioniert aber beispielsweise nicht unter Rocky 9, da das Installationsskript diese Distribution nicht implementiert hat. Hier würde nur ein curl -s https://install.crowdsec.net | sudo os=rhel dist=9 sh helfen. Mit der manuellen Angabe der Repo-Definitionen hat man aber mehr Kontrolle:

cat > /etc/yum.repos.d/crowdsec.repo << 'EOF'
[crowdsec_crowdsec]
[crowdsec_crowdsec]
name=crowdsec_crowdsec
baseurl=https://packagecloud.io/crowdsec/crowdsec/el/9/$basearch
repo_gpgcheck=1
gpgcheck=1
enabled=1
gpgkey=https://packagecloud.io/crowdsec/crowdsec/gpgkey
       https://packagecloud.io/crowdsec/crowdsec/gpgkey/crowdsec-crowdsec-EDE2C695EC9A5A5C.pub.gpg
       https://packagecloud.io/crowdsec/crowdsec/gpgkey/crowdsec-crowdsec-C822EDD6B39954A1.pub.gpg
       https://packagecloud.io/crowdsec/crowdsec/gpgkey/crowdsec-crowdsec-FED78314A2468CCF.pub.gpg
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300

[crowdsec_crowdsec-source]
name=crowdsec_crowdsec-source
baseurl=https://packagecloud.io/crowdsec/crowdsec/el/9/SRPMS
repo_gpgcheck=1
gpgcheck=1
enabled=1
gpgkey=https://packagecloud.io/crowdsec/crowdsec/gpgkey
       https://packagecloud.io/crowdsec/crowdsec/gpgkey/crowdsec-crowdsec-EDE2C695EC9A5A5C.pub.gpg
       https://packagecloud.io/crowdsec/crowdsec/gpgkey/crowdsec-crowdsec-C822EDD6B39954A1.pub.gpg
       https://packagecloud.io/crowdsec/crowdsec/gpgkey/crowdsec-crowdsec-FED78314A2468CCF.pub.gpg
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300
EOF

sudo dnf -y install crowdsec
mkdir -p /etc/crowdsec/acquis.d

Es braucht noch den passenden Bouncer, um bei einem Angriff die gewünschte Aktion auszuführen:

dnf -y install crowdsec-firewall-bouncer-iptables

cscli bouncer list
iptables --list

Bouncer

Es existieren folgende Bouncer:

crowdsec-aws-waf-bouncer
crowdsec-cloudflare-bouncer
crowdsec-cloudflare-worker-bouncer
crowdsec-custom-bouncer
crowdsec-firewall-bouncer-iptables (arbeitet mit der CROWDSEC_CHAIN)
crowdsec-firewall-bouncer-nftables
crowdsec-openresty-bouncer

Mehr finden sich auf https://github.com/orgs/crowdsecurity/repositories?language=&q=bouncer&sort=&type=all

Konfiguration - lokal

Am Beispiel des Apache Webservers und seiner Welcome-Seite - der Angreifer soll wie bei fail2ban auf Netzwerkebene per iptables ausgesperrt werden. Die Suche nach „apache“ auf dem dem CrowdSec HUB liefert:

cscli collections install crowdsecurity/apache2

cscli collections list
cscli parser list
cscli scenarios list

Als nächstes muss das „Acquisition template“ der Collection konfiguriert werden - in unserem Fall muss es wissen, wo es die Logdateien findet:

/etc/crowdsec/acquis.d/apache2.yaml

filenames:
  - /var/log/apache2/*.log
  - /var/log/*httpd*.log
  - /var/log/httpd/*log
labels:
  type: apache2  # or "syslog"

# test config and reload
crowdsec -t && systemctl reload crowdsec.service
tail /var/log/crowdsec.log

Angriffe können jetzt erkannt werden. CrowdSec bei der Arbeit zuschauen:

tail -f /var/log/crowdsec.log /var/log/crowdsec-firewall-bouncer.log

Tipp

Webserver stressen? Zum Beispiel so:

dnf -y install httpd-tools
ab -n 5000 http://apache/

Oder so:

for i in {1..500}; do curl --silent http://apache/$RANDOM > /dev/null ; done

Konfiguration - verteilt

Das bereits analog zu Fail2ban funktionierende System soll jetzt Teil eines CrowdSec-Verbundes werden, und seine ermittelten Daten anderen Teilnehmern zur Verfügung stellen (oder selbst welche erhalten). Eine TLS-basierte, verschlüsselte Kommunikation wird ebenfalls unterstützt.

Auf dem ersten Server (192.0.2.10):

MY_IP=192.0.2.10

sed --in-place=.bak "s#listen_uri: 127.0.0.1:8080#listen_uri: $MY_IP:8080#g" /etc/crowdsec/config.yaml
sed --in-place=.bak "s#url: http://127.0.0.1:8080#url: http://$MY_IP:8080#g" /etc/crowdsec/local_api_credentials.yaml

Liste der weiteren CrowdSec-Server angeben:

/etc/crowdsec/config.yaml

api:
  server:
    trusted_ips: # IP ranges, or IPs which can have admin API access
      - 192.0.2.20

systemctl restart crowdsec.service

sed --in-place=.bak "s#api_url: http://127.0.0.1:8080/#api_url: http://$MY_IP:8080/#g" /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml

systemctl restart crowdsec-firewall-bouncer.service

Jeder weitere CrowdSec-Server muss sich beim ersten registrieren. Auf dem zweiten Server 192.0.2.20:

cscli lapi register --url http://192.0.2.10:8080
systemctl reload crowdsec.service

Das muss auf dem ersten Server bestätigt werden:

cscli machines list
cscli machines validate 246e96213e7f4a1dbeba126d7611c74dYVsUUolgvPQoJrgR

Der Bouncer der zusätzlichen CrowdSec-Server soll sich zukünftig mit dem ersten Server verbinden. Dafür benötigen diese Bouncer jeweils einen eigenen API-Key, die man auf dem ersten Server wie folgt erzeugt (der Name ist dabei völlig wurscht):

cscli bouncers add firewall-bouncer-192.0.2.20

Auf dem neuen CrowdSec-Server (192.0.2.20) den Bouncer mit der IP des ersten Servers konfigurieren und den API-Key eintragen:

SERVER_IP=192.0.2.10
API_KEY='pOIt9SsDIMn5qRg3BHjLlR59OM7mvTFyt2NoR5rMalw'

sed --in-place=.bak "s#api_url.*#api_url: http://$SERVER_IP:8080#" /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml
sed --in-place=.bak "s#api_key.*#api_key: $API_KEY#" /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml
systemctl restart crowdsec-firewall-bouncer.service

Whitelisting

Whitelisten bearbeiten, beispielsweise sollen Attacken von 192.168.0.0/16 gesperrt werden dürfen:

Achtung

Private LAN-IP-Adressen sind per default whitelisted.

/etc/crowdsec/parsers/s02-enrich/whitelists.yaml

name: crowdsecurity/z00-linuxfabrik-whitelists
description: "Whitelist events from private ipv4 addresses"
whitelist:
  reason: "private ipv4/ipv6 ip/ranges"
  ip:
    - "127.0.0.1"
    - "::1"
  cidr:
  #   - "192.168.0.0/16"
    - "10.0.0.0/8"
    - "172.16.0.0/12"
  # expression:
  #   - "'foo.com' in evt.Meta.source_ip.reverse"

systemctl reload crowdsec.service

Log-Dateien testen

Wird das Log ausgwertet, und wie?

# which log formats are supported? the name is needed for the `--type` parameter
grep ^filter /etc/crowdsec/parsers/s01-parse/*

tail -n 1 /var/log/secure | cscli explain --file - --type sshd
tail -n 1 /var/log/httpd/access_log | cscli explain --file - --type apache2
tail -n 1 /var/log/mariadb/mariadb.log | cscli explain --file - --type mariadb

Werden IP’s aus dem 192.168er-Bereich geblockt oder nicht? Falls nein, wird „[whitelisted]“ ausgegeben:

grep 192.168 /var/log/httpd/access_log | tail -n 1 | sudo cscli explain --file - --type apache2

Gesperrte IPs ermitteln

Welche IP-Adressen sind auf der Banlist?

ipset list
cscli decisions list

IP-Adresse manuell freigeben

Um die durch CrowdSec geblockte IP-Adresse 10.26.6.74 zu entsperren:

cscli decisions delete --ip 10.26.6.74

# enable again
cscli decisions add --ip 10.26.6.74 --duration 24h --reason "web bruteforce"

Update/Upgrade

# updating index
cscli hub update

# upgrading parsers etc.
cscli hub upgrade

Built on 2024-11-18