Linux-Server in 15 Minuten mit CrowdSec absichern

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.

Die Instanz-Übersicht in der CrowdSec-Console

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:

CrowdSec Console

* * *

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.

E-Mail

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:

Server in die CrowdSec-Console hinzufügen

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:

Einbindungs-Benachrichtigung in der CrowdSec-Console

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:

Alarme in der CrowdSec-Console
* * *

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

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
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
* * *

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.

* * *
* * *

Änderungshistorie

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

* * *
Christian Süßenguth Christian Süßenguth @sweetgood

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

👾 Magst du Kekse?

Ich würde gerne Cookies setzen

Ist das OK für dich?