Linux-Server in 15 Minuten mit CrowdSec absichern
- Christian Süßenguth
- 17.04.2023, aktualisiert am
- Blog
Einen (Linux-)Server ohne Schutz vor unbefugten oder schädlichen Zugriffen im Internet zu betreiben, ist grob fahrlässig. Das ist denke ich jeder Person klar., die regelmäßig mit Servern tun hat. Daher gehört es zu einer der ersten Aktionen, auf einem neu eingerichteten Server fail2ban
zu installieren, denn damit reduziert man das Angriffspotential bereits zu einem großen Teil.
Leider blockiert fail2ban nur auf Basis der tatsächlichen Zugriffe und nicht präventiv, etwa wenn die anfragende IP-Adresse bereits (von anderen) als gefährlich eingestuft wurde. Wer möchte, kann zwar auch bei fail2ban kuratierte Blocklisten hinzufügen, CrowdSec ist an dieser Stelle allerdings effektiver und v.a. schneller eingerichtet.
Inhaltsverzeichnis
Was ist CrowdSec?
Voraussetzungen schaffen
Firewall auf dem Server einrichten
Account bei CrowdSec-Console registrieren (optional)
Installation von CrowdSec
Konfiguration von CrowdSec
Benachrichtigungen aktivieren
E-Mail
Telegram
Einbinden in die CrowdSec Console (optional)
Weitere Anpassungen
Whitelisting eigener IPs
fail2ban entfernen
Ich möchte CrowdSec einrichten, habe dabei aber Schwierigkeiten
Weiterführende Links
Was ist CrowdSec?
CrowdSec ist eine kostenfreie OpenSource-Software, die Verhaltenserkennung mit einem globalen IP-Reputations-Netzwerk kombiniert und auf dieser Basis Entscheidungen trifft. Diese Entscheidungen lauten z.B. "Zugriff zulassen", "CAPTCHA-Seite anzeigen" oder "Zugriff blockieren".
Es orientiert sich an der Philosophie von fail2ban (Parsen von Log-Dateien), ist jedoch IPv6-kompatibel und 60x schneller. Dabei teilt sich die Software in zwei Teile auf: Den Erkennungs-Teil (Agent) und den Entscheidungs-Teil (Bouncer). Nach Bedarf können verschiedene Bouncer installiert werden, die je nach Art bestimmte Aktionen ausführen, z.B. Blockieren mittels Firewall, nginx-Fehlerseite anzeigen, CAPTCHA-Seite anzeigen, usw.
Die "aggressiven IPs" können anschließend ans CrowdSec-Netzwerk weitergegeben werden, damit andere Personen schnell vor diesen geschützt sind.
Voraussetzungen schaffen
Das folgende Tutorial bezieht sich auf einen Server mit Debian 11 (Bullseye).
Solltest du Ubuntu Server oder ein anderes System einsetzen, weichen die Befehle zur Installation von Software vmtl. ab.
Firewall auf dem Server einrichten
Hinweis
Alle folgenden Befehle werden als root
-Benutzer ausgeführt.
In der Standardausstattung von Debian sind weder iptables
, noch ufw
installiert. Um Angriffe blockieren zu können, benötigen wir eine Software-Firewall. Mit folgendem Befehl installieren wir diese nach:
apt install iptables iptables-persistent ufw
Hinweis
Sollte der Befehl unter Debian 12 (bookworm) mit einem Abhängigkeitsfehler fehlschlagen, installiere einfach nur ufw
ohne die beiden anderen Pakete:
apt install ufw
Nach der Installation muss die Firewall noch so konfiguriert werden, dass alle Ports freigegeben werden, die aktuell genutzt / benötigt werden. Andernfalls würden wir uns nach Aktivierung der Firewall aussperren. Mit dem folgenden Befehl erhältst du alle aktuell geöffneten Ports, die auf allen IPv4-Adressen hören:
ss -tulpen | grep "0.0.0.0:[0-9]"
Die Ausgabe sieht in etwa wie folgt aus:
tcp LISTEN 0 4096 0.0.0.0:587 0.0.0.0:* users:(("docker-proxy",pid=2017938,fd=4)) ino:107286257 sk:1 cgroup:/system.slice/docker.service <->
tcp LISTEN 0 4096 0.0.0.0:110 0.0.0.0:* users:(("docker-proxy",pid=2018200,fd=4)) ino:107284208 sk:5 cgroup:/system.slice/docker.service <->
tcp LISTEN 0 4096 0.0.0.0:143 0.0.0.0:* users:(("docker-proxy",pid=2018139,fd=4)) ino:107289200 sk:6 cgroup:/system.slice/docker.service <->
tcp LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=2658081,fd=102),("nginx",pid=2658080,fd=102),("nginx",pid=2658079,fd=102),("nginx",pid=2658078,fd=102),("nginx",pid=2658077,fd=102)) ino:114585902 sk:7 cgroup:/system.slice/nginx.service <->
tcp LISTEN 0 4096 0.0.0.0:465 0.0.0.0:* users:(("docker-proxy",pid=2017969,fd=4)) ino:107288542 sk:8 cgroup:/system.slice/docker.service <->
tcp LISTEN 0 128 0.0.0.0:5269 0.0.0.0:* users:(("lua5.2",pid=1192,fd=7)) uid:107 ino:15512 sk:9 cgroup:/system.slice/prosody.service <->
tcp LISTEN 0 4096 0.0.0.0:9080 0.0.0.0:* users:(("docker-proxy",pid=2018253,fd=4)) ino:107284251 sk:b cgroup:/system.slice/docker.service <->
tcp LISTEN 0 4096 0.0.0.0:25 0.0.0.0:* users:(("docker-proxy",pid=2017996,fd=4)) ino:107286307 sk:c cgroup:/system.slice/docker.service <->
tcp LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=2658081,fd=104),("nginx",pid=2658080,fd=104),("nginx",pid=2658079,fd=104),("nginx",pid=2658078,fd=104),("nginx",pid=2658077,fd=104)) ino:114585904 sk:e cgroup:/system.slice/nginx.service <->
tcp LISTEN 0 128 0.0.0.0:12567 0.0.0.0:* users:(("sshd",pid=1107,fd=3)) ino:14567 sk:f cgroup:/system.slice/ssh.service <->
tcp LISTEN 0 4096 0.0.0.0:4190 0.0.0.0:* users:(("docker-proxy",pid=2018059,fd=4)) ino:107286350 sk:11 cgroup:/system.slice/docker.service <->
tcp LISTEN 0 4096 0.0.0.0:993 0.0.0.0:* users:(("docker-proxy",pid=2018112,fd=4)) ino:107286391 sk:12 cgroup:/system.slice/docker.service <->
tcp LISTEN 0 4096 0.0.0.0:9443 0.0.0.0:* users:(("docker-proxy",pid=2018165,fd=4)) ino:107290352 sk:13 cgroup:/system.slice/docker.service <->
tcp LISTEN 0 4096 0.0.0.0:995 0.0.0.0:* users:(("docker-proxy",pid=2018085,fd=4)) ino:107286374 sk:14 cgroup:/system.slice/docker.service <->
tcp LISTEN 0 128 0.0.0.0:5222 0.0.0.0:* users:(("lua5.2",pid=1192,fd=9)) uid:107 ino:15516 sk:16 cgroup:/system.slice/prosody.service <->
Mit dem folgenden Befehl kannst du nochmal gegenprüfen, dass bestimmte Ports nicht direkt auf einer (externen) IP oder auf IPv6 lauschen, denn diese wären in der obigen Ausgabe nicht enthalten:
ss -tulpen
Nun geben wir mit folgenden Befehlen Stück für Stück die Ports in der Firewall frei:
ufw allow "Nginx Full"
ufw allow xmpp
ufw allow smtp
ufw allow smtps
ufw allow imap
ufw allow imaps
ufw allow pop3
ufw allow pop3s
ufw allow 587/tcp
ufw allow 4190/tcp
ufw allow 12567/tcp
Falls du etwas spezifischere Regeln benötigst, findest du hier einen recht übersichtlichen Blogartikel mit allen Variationen.
Hinweis
Wichtig ist, dass v.a. die SSH-Regel hinzugefügt wurde, sonst wird nach Aktivierung der Firewall die Sitzung getrennt und wir können die Firewall nicht mehr konfigurieren. Solltest du den SSH-Port nicht wie im obigen Beispiel geändert haben, ersetze ufw allow 12567/tcp
durch ufw allow SSH
.
Sobald alle Regeln hinzugefügt wurden, schalten wir die Firewall mit folgendem Befehl ein.
ufw enable
Um eine Übersicht der aktuellen Regeln zu erhalten, kannst du folgenden Befehl verwenden:
ufw status verbose
Die Ausgabe sieht dann bspw. wie folgt aus:
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip
To Action From
-- ------ ----
80,443/tcp (Nginx Full) ALLOW IN Anywhere
25/tcp ALLOW IN Anywhere
465/tcp ALLOW IN Anywhere
110/tcp ALLOW IN Anywhere
995/tcp ALLOW IN Anywhere
143/tcp ALLOW IN Anywhere
993/tcp ALLOW IN Anywhere
5222/tcp (XMPP) ALLOW IN Anywhere
5269/tcp (XMPP) ALLOW IN Anywhere
587/tcp ALLOW IN Anywhere
4190/tcp ALLOW IN Anywhere
12567/tcp ALLOW IN Anywhere
80,443/tcp (Nginx Full (v6)) ALLOW IN Anywhere (v6)
25/tcp (v6) ALLOW IN Anywhere (v6)
465/tcp (v6) ALLOW IN Anywhere (v6)
110/tcp (v6) ALLOW IN Anywhere (v6)
995/tcp (v6) ALLOW IN Anywhere (v6)
143/tcp (v6) ALLOW IN Anywhere (v6)
993/tcp (v6) ALLOW IN Anywhere (v6)
5222/tcp (XMPP (v6)) ALLOW IN Anywhere (v6)
5269/tcp (XMPP (v6)) ALLOW IN Anywhere (v6)
587/tcp (v6) ALLOW IN Anywhere (v6)
4190/tcp (v6) ALLOW IN Anywhere (v6)
12567/tcp (v6) ALLOW IN Anywhere (v6)
Willst du eine Regel wieder löschen, ist das ebenfalls recht einfach möglich.
Der erste Befehl zeigt dir alle Regeln mit vorangestellten Nummern an, der Zweite löscht die entsprechende Nummer:
ufw status numbered
ufw delete 5
Zum Schluss aktivieren wir noch das Logging, damit der CrowdSec-Agent die relevanten Informationen aus den Logdateien auslesen kann:
ufw logging on
Account bei CrowdSec-Console registrieren (optional)
Mit der CrowdSec-Console bekommst du eine sehr übersichtliche Oberfläche an die Hand, mit der du den Zustand deiner einzelnen Instanzen überwachen und verwalten kannst.
Für den Betrieb von CrowdSec ist dieser Account nicht zwingend notwendig – allerdings bietet es sich an ihn zu nutzen. Er ist kostenfrei, man bekommt darüber eine ansprechende Visualisierung und man kann eine unbegrenzte Anzahl an Geräten verwalten und mit Tags ordnen. Man kann bis zu zwei automatisiert aktualisierte Blocklisten auf seine Instanzen anwenden und in der Oberfläche IP-Adressen auf ihre Reputation hin überprüfen – das geht auch per API.
Den Account für die CrowdSec Console kannst du dir hier anlegen:
Installation von CrowdSec
Wenn alle Voraussetzungen erfüllt sind, sind wir jetzt bereit für die Installation von CrowdSec. Dazu fügen wir mir folgendem Befehl zuerst die passenden Paketquellen hinzu:
curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash
Und installieren anschließend den ersten Teil der Anwendung (Agent):
sudo apt install crowdsec
Anschließend benötigen wir noch den zweiten Teil der Anwendung (Bouncer). In den meisten Fällen reicht hier der Standard-Bouncer crowdsec-firewall-bouncer-iptables
aus. Alle verfügbaren Bouncer findest du im CrowdSec Hub:
sudo apt install crowdsec-firewall-bouncer-iptables
Damit ist die Installation von CrowdSec bereits abgeschlossen und der Dienst betriebsbereit.
Konfiguration von CrowdSec
Um mit dem CrowdSec-Daemon zu kommunizieren, gibt es das Kommandozeilen-Tool cscli
. Eine Übersicht aller Befehle findest du in der CrowdSec-Tour oder durch Eingabe von cscli --help
. Hier ein kleiner Auszug der wichtigsten Befehle.
Statistiken und Metriken anzeigen:
sudo cscli metrics
Aktuelle Alarme anzeigen lassen:
sudo cscli alerts list
Aktivierte Bouncer anzeigen lassen:
sudo cscli bouncers list
Aktive IP-Sperren anzeigen:
sudo cscli decisions list
IP-Sperre hinzufügen / aufheben:
sudo cscli decisions add -i 1.2.3.4
sudo cscli decisions delete -i 1.2.3.4
Alle aktivierten Konfigurationen anzeigen:
sudo cscli hub list
Anzeigen, welche IP-Sperren an die CrowdSec Console gemeldet werden:
sudo cscli console status
Benachrichtigungen aktivieren
Standardmäßig versendet CrowdSec keine Benachrichtigungen, liefert aber in der Standardkonfiguration bereits die nötigen Plugins mit.
Für Benachrichtigungen per E-Mail ist die Konfiguration in der offiziellen Anleitung ausführlich beschrieben.
Trage in der folgenden Datei alle notwendigen Daten für den E-Mailversand per SMTP ein (Beispieldaten vorher ersetzen):
/etc/crowdsec/notifications/email.yaml
# Don't change this
type: email
name: email_default # this must match with the registered plugin in the profile
log_level: info # Options include: trace, debug, info, warn, error, off
format: | # This template receives list of models.Alert objects
{{range . -}}
{{$alert := . -}}
{{range .Decisions -}}
<a href=https://www.whois.com/whois/{{.Value}}>{{.Value}}</a> will get <b>{{.Type}}</b> for next <b>{{.Duration}}</b> for triggering <b>{{.Scenario}}</b>. <a href=https://www.shodan.io/host/{{.Value}}>Shodan</a>
{{end -}}
{{end -}}
smtp_host: smtp.domain.de
smtp_username: myemail@domain.de
smtp_password: mypassword
smtp_port: 587
sender_email: myemail@domain.de
receiver_emails:
- receiver@domain.de
encryption_type: ssltls # Required
auth_type: login # "plain" also works
email_subject: CrowdSec Benachrichtigung
# group_wait: # duration to wait collecting alerts before sending to this plugin, eg "30s"
# group_threshold: # if alerts exceed this, then the plugin will be sent the message. eg "10"
# max_retry: # number of tries to attempt to send message to plugins in case of error.
timeout: 20s # duration to wait for response from plugin before considering this attempt a failure. eg "10s"
Aktiviere daraufhin in der folgenden Datei das Benachrichtigungsprofil, indem du vor notifications:
und - email_default
jeweils die Raute entfernst:
/etc/crowdsec/profiles.yaml
name: default_ip_remediation
#debug: true
filters:
- Alert.Remediation == true && Alert.GetScope() == "Ip"
decisions:
- type: ban
duration: 4h
#duration_expr: Sprintf('%dh', (GetDecisionsCount(Alert.GetValue()) + 1) * 4)
notifications:
# - slack_default # Set the webhook in /etc/crowdsec/notifications/slack.yaml before enabling this.
# - splunk_default # Set the splunk url and token in /etc/crowdsec/notifications/splunk.yaml before enabling this.
# - http_default # Set the required http parameters in /etc/crowdsec/notifications/http.yaml before enabling this.
- email_default # Set the required email parameters in /etc/crowdsec/notifications/email.yaml before enabling this.
on_success: break
Nach dem Speichern beider Dateien startest du den CrowdSec-Daemon einmal neu und die E-Mail-Benachrichtigungen sollten funktionieren:
sudo systemctl restart crowdsec
Testen kannst du die Benachrichtigungen, indem du mit Tools wie wapiti
oder nikto
einen Vulnerability-Scan auf deinen Server startest. Beachte bitte, dass es passieren kann, dass du selbst auf einer Blocklist landest, verwende also am Besten einen anderen Server für den Test. Auch kann dadurch die Reputation der "angreifenden" IP-Adresse kurzfristig beeinflusst werden.
Telegram
Für Benachrichtigungen per Telegram ist die Konfiguration in der offiziellen Anleitung ausführlich beschrieben.
Wie du einen Telegram-Bot anlegst, habe ich hier erklärt.
Trage anschließend in der folgenden Datei analog zur offiziellen Anleitung dein Bot-API-Token und deine Chat-ID ein. Die Chat-ID bekommst du, indem du in Telegram einen Chat mit einem Bot wie UserIDGetBot startest. Auch solltest du bei deinem neuen Bot mind. einmal auf "Start" geklickt haben, sonst darf er dir an die angegebene ID keine Nachrichten senden.
/etc/crowdsec/notifications/http.yaml
type: http # Don't change
name: http_default # Must match the registered plugin in the profile
# One of "trace", "debug", "info", "warn", "error", "off"
log_level: info
# group_wait: # Time to wait collecting alerts before relaying a message to this plugin, eg "30s"
# group_threshold: # Amount of alerts that triggers a message before <group_wait> has expired, eg "10"
# max_retry: # Number of attempts to relay messages to plugins in case of error
# timeout: # Time to wait for response from the plugin before considering the attempt a failure, eg "10s"
#-------------------------
# plugin-specific options
# The following template receives a list of models.Alert objects
# The output goes in the http request body
# Replace XXXXXXXXX with your Telegram chat ID, in case it is a group don't forget the prefixed -
format: |
{
"chat_id": "XXXXXXXXX",
"text": "
{{range . -}}
{{$alert := . -}}
{{range .Decisions -}}
{{.Value}} will get {{.Type}} for next {{.Duration}} for triggering {{.Scenario}}.
{{end -}}
{{end -}}
",
"reply_markup": {
"inline_keyboard": [
{{ $arrLength := len . -}}
{{ range $i, $value := . -}}
{{ $V := $value.Source.Value -}}
[
{
"text": "See {{ $V }} on shodan.io",
"url": "https://www.shodan.io/host/{{ $V -}}"
},
{
"text": "See {{ $V }} on crowdsec.net",
"url": "https://app.crowdsec.net/cti/{{ $V -}}"
}
]{{if lt $i ( sub $arrLength 1) }},{{end }}
{{end -}}
]
}
# {{.|toJson}}
# The plugin will make requests to this url, eg: https://www.example.com/
#url: <HTTP_url>
url: https://api.telegram.org/bot<TELEGRAM_API_KEY>/sendMessage # Replace <TELEGRAM_API_KEY> with your API key
# Any of the http verbs: "POST", "GET", "PUT"...
method: POST
headers:
# Authorization: token 0x64312313
Content-Type: "application/json"
# skip_tls_verification: # true or false. Default is false
---
# type: http
# name: http_second_notification
# ...
Aktiviere daraufhin in der folgenden Datei das Benachrichtigungsprofil, indem du vor notifications:
und - http_default
jeweils die Raute entfernst:
/etc/crowdsec/profiles.yaml
name: default_ip_remediation
#debug: true
filters:
- Alert.Remediation == true && Alert.GetScope() == "Ip"
decisions:
- type: ban
duration: 4h
#duration_expr: Sprintf('%dh', (GetDecisionsCount(Alert.GetValue()) + 1) * 4)
notifications:
# - slack_default # Set the webhook in /etc/crowdsec/notifications/slack.yaml before enabling this.
# - splunk_default # Set the splunk url and token in /etc/crowdsec/notifications/splunk.yaml before enabling this.
- http_default # Set the required http parameters in /etc/crowdsec/notifications/http.yaml before enabling this.
# - email_default # Set the required email parameters in /etc/crowdsec/notifications/email.yaml before enabling this.
on_success: break
Nach dem Speichern beider Dateien startest du den CrowdSec-Daemon einmal neu und die Telegram-Benachrichtigungen sollten funktionieren:
sudo systemctl restart crowdsec
Testen kannst du die Benachrichtigungen, indem du mit Tools wie wapiti
oder nikto
einen Vulnerability-Scan auf deinen Server startest. Beachte bitte, dass es passieren kann, dass du selbst auf einer Blocklist landest, verwende also am Besten einen anderen Server für den Test. Auch kann dadurch die Reputation der "angreifenden" IP-Adresse kurzfristig beeinflusst werden.
Einbinden in die CrowdSec Console (optional)
Wenn du dir weiter oben einen Account in der CrowdSec-Console erstellt hast, kannst du nach dem Login in dieser oben rechts auf "Add instance" klicken.
Daraufhin bekommst du einen Befehl angezeigt:
Gib diesen nun auf dem Server ein, auf dem du soeben CrowdSec installiert hast.
Daraufhin erscheint in der Weboberfläche folgende Meldung, die du – wenn alles passt – mit "Accept enroll" bestätigst:
Starte CrowdSec nach dem Akzeptieren in der CrowdSec Console auf dem betreffenden Server einmal neu:
sudo systemctl restart crowdsec
Daraufhin ist der Server über die Oberfläche administrierbar. Ich empfehle dir, diesem einen sprechenden Namen zu geben (Klicke auf die drei Punkte in der Server-Kachel, dann auf "Edit name or tags") und die 2-Faktor-Authentifizierung für den Account zu aktivieren.
Wenn du oben unterhalb von "Instances" auf "Alerts" klickst, bekommst du eine schöne Übersicht aller Entscheidungen:
Weitere Anpassungen
Beim Aufrufen von Befehlen wie cscli bouncers list
kommt es vor, dass folgende Warnmeldung erscheint:
WARN[17-04-2023 12:00:00] You are using sqlite without WAL, this can have an impact of performance. If you do not store the database in a network share, set db_config.use_wal to true. Set explicitly to false to disable this warning.
Solltest du die SQLite-Datenbank nicht auf einem Netzlaufwerk speichern (was sehr warscheinlich ist), kannst du das Write-Ahead Logging für SQLite aktivieren. Das erhöht die Zugriffsgeschwindigkeit auf die Datenbank signifikant.
Trage dazu in der folgenden Datei unterhalb von db_config
den Parameter use_wal
ein und setze ihn auf true
:
/etc/crowdsec/config.yaml
[...]
cscli:
output: human
color: auto
db_config:
log_level: info
type: sqlite
db_path: /var/lib/crowdsec/data/crowdsec.db
use_wal: true
#max_open_conns: 100
#user:
#password:
#db_name:
#host:
#port:
flush:
max_items: 5000
max_age: 7d
[...]
Nach einem Neustart von CrowdSec wird der neue Modus genutzt und die Warnmeldung taucht nicht mehr auf:
sudo systemctl restart crowdsec
Whitelisting eigener IPs
Update 20.06.2024:
Wie ich leider in der Praxis erfahren musste, ist/war die Dokumentation unvollständig. Legt man nämlich der Dokumentation folgend eine eigene Whitelist mit dem gleichen Namen an, wird die Standard-Whitelist durch diese ersetzt.
Um dich also nicht selbst "aussperren" zu können, solltest du statt crowdsecurity/whitelists
einen eigenen Namen verwenden wie z.B. crowdsecurity/whitelists-custom
.
Das zugehörige GitHub-Issue mit weiteren Infos findest du hier.
Solltest du über eine eigene IPv4- oder IPv6-Adresse verfügen, möchtest du diese vllt. auf dem Server in einer Whitelist hinterlegen. Das verhindert, dass weder eine potentielle Angreifer:in mit gefälschten Datenpaketen noch du dich selbst auf die Sperrliste setzen kannst.
Die Anweisungen hierfür findest du auch in der offiziellen Anleitung bzw. dieser Konfigurationsbeschreibung.
Lege dazu eine neue Datei im angegebenen Pfad an, ersetze 1.2.3.4
durch deine IP-Adresse (ggf. kannst du auch weitere Adressen hinzufügen oder ein ganzes Netz freigeben) und füge daraufhin den Inhalt ein:
/etc/crowdsec/parsers/s02-enrich/personal-whitelist.yaml
name: crowdsecurity/whitelists-custom
description: "Whitelist events from my personal ips"
whitelist:
reason: "internal traffic from my personal ips"
ip:
- "1.2.3.4"
# cidr:
# - "192.168.0.0/16"
# expression:
# - "'foo.com' in evt.Meta.source_ip.reverse"
Nach einem Neustart von CrowdSec stehen die IP-Adressen bzw. die CIDR-Adressen auf der Whitelist und können nicht mehr auf der Sperrliste landen:
sudo systemctl restart crowdsec
Bitte prüfe nach der Erstellung der neuen Whitelist, dass produktiv neben deiner neuen Liste auch die Standard-Liste /etc/crowdsec/parsers/s02-enrich/whitelists.yaml
genutzt wird. Das geht ganz einfach mit folgendem Befehl:
cscli parsers list
Beispielausgabe:
PARSERS
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Name 📦 Status Version Local Path
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
crowdsecurity/apache2-logs ✔️ enabled 1.4 /etc/crowdsec/parsers/s01-parse/apache2-logs.yaml
crowdsecurity/dateparse-enrich ✔️ enabled 0.2 /etc/crowdsec/parsers/s02-enrich/dateparse-enrich.yaml
crowdsecurity/geoip-enrich ✔️ enabled 0.4 /etc/crowdsec/parsers/s02-enrich/geoip-enrich.yaml
crowdsecurity/http-logs ✔️ enabled 1.2 /etc/crowdsec/parsers/s02-enrich/http-logs.yaml
crowdsecurity/mysql-logs ✔️ enabled 0.4 /etc/crowdsec/parsers/s01-parse/mysql-logs.yaml
crowdsecurity/nginx-logs ✔️ enabled 1.5 /etc/crowdsec/parsers/s01-parse/nginx-logs.yaml
crowdsecurity/sshd-logs ✔️ enabled 2.3 /etc/crowdsec/parsers/s01-parse/sshd-logs.yaml
crowdsecurity/syslog-logs ✔️ enabled 0.8 /etc/crowdsec/parsers/s00-raw/syslog-logs.yaml
crowdsecurity/whitelists ✔️ enabled 0.2 /etc/crowdsec/parsers/s02-enrich/whitelists.yaml
crowdsecurity/whitelists-custom 🏠 enabled,local /etc/crowdsec/parsers/s02-enrich/personal-whitelist.yaml
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
fail2ban entfernen
Denke nach der Installation daran, das Paket fail2ban
zu entfernen, wenn es zuvor installiert war:
sudo apt purge fail2ban
Ich möchte CrowdSec einrichten, habe dabei aber Schwierigkeiten
Ich unterstütze dich gerne bei der Installation und Konfiguration von CrowdSec auf deinem eigenen Server.
Schreib mir hierzu einfach über Kontakt, per Telegram oder unten in die Kommentare eine Nachricht.
Weiterführende Links
- Crowdsec: secure your web server network – installation and configuration
- Install CrowdSec (Linux)
- Notification plugins - Introduction
Änderungshistorie
20.06.2024, 11:40 – Korrigieren eines kritischen Fehlers in der Whitelisting-Konfiguration
18.02.2024, 17:00 – Ergänzen des CIDR-Parameters in der Whitelist
03.12.2023, 19:15 – Lösung für Problem bei Installation der Abhängigkeiten unter Debian 12 (bookworm) ergänzt
14.05.2023, 14:30 – Details zur SSH-Regel bei ufw ergänzt, Typo korrigiert (Danke an Frankietng)
18.04.2023, 19:15 – Kleinere Ergänzungen, Passage Weitere Anpassungen, Whitelisting eigener IPs und fail2ban entfernen ergänzt
17.04.2023, 20:00 – Artikel erstellt
Hi, ich bin Christian und Inhaber der Firma SWEETGOOD. Mit dem andersGOOD Blog möchte ich auch dich für datensichere IT-Lösungen begeistern. So bringst du dein Unternehmen voran, ohne großen Konzernen deine wertvollen Daten zu liefern. Probiers mal anders!
Kommentarbereich
Die Kommentare sind für dich noch deaktiviert, da du dem Setzen von Cookies bisher nicht zugestimmt hast.
Klicke oben rechts auf "Ja, klar!" und lade die Seite neu, um die Kommentare anzuzeigen.
Seite neu laden