Linux-Webserver mit GitHub-Webseiten-Updates und Absicherung über CrowdSec

Dies ist die etwas modifizierte Version eines Skriptes, das ich für eine Workshop-Präsentation genutzt habe. Diese „Anleitung“ beschreibt nur die Basiseinstellungen und ist primär dafür gedacht, jemandem die Thematik zu erklären. Sie sollte nur bedingt für Produktivsysteme eingesetzt werden. In der Demo habe ich alles live in einer VM demonstriert.
Weiterhin ist anzumerken, dass es bei der ACME-Challenge mit Let’s Encrypt und Certbot zu Problemen gekommen ist und ich diese auf Webroot umstellen musste. Hier gibt es bestimmt elegantere Lösungen, aber diese hat bei mir Funktioniert.

Wir installieren unter Debian 13.4. einen nginx Webserver, beziehen die Daten der Webseite automatisiert aus einer GitHub Repository und sichern den Server mit CrowdSec ab. Dabei gehen wir kurz auf cronjobs, Virtuelle Host Konfigurationsdateien, Linux Shell-Expansion und Bash Umleitungen (Pipes) zu /dev/null ein.

Server Installieren

Debian herunterladen: Index of /debian-cd/current/amd64/iso-dvd

Debian installieren, Sprache definieren, Passwörter für Benutzer und root (Admin) definieren. Festplatte partitionieren (komplett).

Bei der Installation die Grafischen-Oberfläche abwählen (Desktop Enviroment / GNOME / etc.). Webserver nicht auswählen, weil der Apache installiert und ich nginx will.

Unterschied Apache und nginx (extrem Vereinfacht)

Apache hat einen höheren Ressourcenverbrauch bei vielen gleichzeitigen Verbindungen. Unterstützt .htaccess‑Dateien.
Nginx benötigt deutlich weniger Ressourcen und skaliert besser bei vielen gleichzeitigen Verbindungen. Unterstützt keine .htaccess‑Dateien! Nginx ignoriert alle .htaccess‑Dateien, weswegen das über die Virtual-Servers-Konfigurationsdateien abgedeckt werden muss.

Was ist eine .htaccess?

Eine .htaccess ist eine Konfigurationsdatei für den Apache‑Webserver, mit der sich verzeichnisbezogene Servereinstellungen festlegen lassen, ohne Zugriff auf die Hauptkonfiguration zu benötigen. Sie wird häufig für Weiterleitungen, Zugriffsbeschränkungen (z. B. Passwortschutz), Fehlerseiten oder Sicherheitsregeln eingesetzt. Änderungen wirken sofort und gelten für das jeweilige Verzeichnis sowie alle Unterverzeichnisse.

Installations CD aus der /etc/apt/sources.list nehmen

Es kommt sonst bei jedem apt update eine Meldung, dass die CD eingelegt werden muss. Original:

deb cdrom:[Debian GNU/Linux 13.4.0 _Trixie_ - Official amd64 DVD Binary-1 with firmware 20260314-11:54]/ trixie contrib main non-free-firmware

deb http://deb.debian.org/debian/ trixie main non-free-firmware
deb-src http://deb.debian.org/debian/ trixie main non-free-firmware

deb http://security.debian.org/debian-security trixie-security main non-free-firmware
deb-src http://security.debian.org/debian-security trixie-security main non-free-firmware

# trixie-updates, to get updates before a point release is made;
# see https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports

deb http://deb.debian.org/debian/ trixie-updates main non-free-firmware
deb-src http://deb.debian.org/debian/ trixie-updates main non-free-firmware

1. Zeile auskommentiert:

#deb cdrom:[Debian GNU/Linux 13.4.0 _Trixie_ - Official amd64 DVD Binary-1 with firmware 20260314-11:54]/ trixie contrib main non-free-firmware

deb http://deb.debian.org/debian/ trixie main non-free-firmware
deb-src http://deb.debian.org/debian/ trixie main non-free-firmware

deb http://security.debian.org/debian-security trixie-security main non-free-firmware
deb-src http://security.debian.org/debian-security trixie-security main non-free-firmware

# trixie-updates, to get updates before a point release is made;
# see https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports

deb http://deb.debian.org/debian/ trixie-updates main non-free-firmware
deb-src http://deb.debian.org/debian/ trixie-updates main non-free-firmware

Git installieren und SSH‑Schlüssel konfigurieren

apt install -y git

Darauf achten, dass der Benutzer auch Schreibzugriff auf das Document‑Root‑Verzeichnis (Verzeichnis mit den HTML Dateien) hat und vom Webserver (www-data) gelesen werden kann. Der Benutzer www-data hat aus Sicherheitsgründen keine aktive Shell, kann somit keine Befehle ausführen und kann hier nicht verwendet werden.

SSH Deployment Key für den User erstellen:

ssh-keygen -t ed25519 -C "GitHub deployment key example.com" -f ~/.ssh/id_ed25519_GitHub_example.com

Den Deployment-Key der ~/.ssh/config hinzufügen und definieren, dass dieser ausschließlich für GitHub verwendet wird. Standardmäßig probiert SSH jeden verfügbaren Schlüssel bei jedem Host. IdentitiesOnly yes unterbindet das. Wenn man viele Schlüssel hat, kann man sonst Rate-Limit-Fehler (Too many authentication failures) bekommen.

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_GitHub_example.com
  IdentitiesOnly yes

Den öffentlichen Schlüssel in der GitHub Repository unter Settings -> Deploy Key ohne Schreib-Rechte hinzufügen: Managing deploy keys – GitHub Docs

Linux Shell-Expansion

Bei einer Shell Expansion wird der Befehl vor der Ausführung umgewandelt. ~ wird durch die Shell in das Home‑Verzeichnis des aktuell angemeldeten Benutzers aufgelöst. Somit wäre dann ~/.ssh/id_ed25519_GitHub_example.com:

Für root: /root/.ssh/id_ed25519_GitHub_example.com
Für demo: /home/demo/.ssh/id_ed25519_GitHub_example.com

Falls man einen speziellen Benutzer möchte, wäre das ~root für /root/ oder ~demo für /home/demo/.

Webseite automatisiert mit cron und git pull aktualisieren

Git-Repo lokal clonen und testen. In diesem Beispiel benutzte ich mein Demo-Repo auf GitHub:

mkdir -p /var/www/example.com/
cd /var/www/example.com/
git clone git@github.com:Helge-Demo/Demo-Webseite.git .
git pull

In den Crontab wechseln und Standard-Editor definieren, falls das noch nicht passiert ist:

crontab -e

Und diesen Befehl einfügen:

0 */6 * * * cd /var/www/example.com/ && git pull >/dev/null

Hier ein Beispiel, wie das „aufgehübscht formatiert“ ist:

Was ist /dev/null und wie leitet man die Ausgabe um?

/dev/null ist ein spezielles Geräte‑File unter Unix/Linux, das alle hineingeschriebenen Daten sofort verwirft. Es wird genutzt, um Ausgaben von Programmen bewusst zu unterdrücken (z. B. in Skripten oder Cronjobs). Lesen aus /dev/null liefert immer sofort ein leeres Ergebnis.
Mit >/dev/null wird der STDOUT (Standard Output) verworfen und nur STDERR (Standard Error) behalten. Mit >/dev/null 2>&1 wird sowohl der STDOUT (Standard Output) und STDERR (Standard Error) verworfen.

# STDOUT verwerfen

0 */6 * * * cd /var/www/example.com/ && git pull >/dev/null

# STDOUT + STDERR verwerfen

0 */6 * * * cd /var/www/example.com/ && git pull >/dev/null 2>&1

Die Umleitung zu STDOUT wird oft gemacht, um alles bis auf Fehlermeldungen (STDERR) zu unterdrücken, die dann über cronmail (Benachrichtigungen) an den Admin geschickt werden. Weitere Informationen zu Umleitungen und den verschiedenen Kanälen können hier gefunden werden: Umleitungen › Shell › Wiki › ubuntuusers.de

Eine kurze Erklärung der Cron-Syntax

Der Befehl wird jeden Tag, alle 6 Stunden, auf Minute 00 ausgeführt. Weitere Informationen zu Cron (Mail) kann man bei Cron › Wiki › ubuntuusers.de finden.

#m   h      dom   mon   dow   command
0    */6    *     *     *     cd /var/www/example.com/ && git pull >/dev/null
|     |     |     |     |     |
|     |     |     |     |     +----- Befehl der ausgeführt werden soll
|     |     |     |     +----- Wochentag (0 - 7) (Sonntag ist 0 und 7)
|     |     |     +------- Monat (1 - 12)
|     |     +--------- Tag (1 - 31)
|     +----------- Stunde (0 - 23)
+------------- Minute (0 - 59)

nginx Installieren

apt update && apt install -y nginx

nginx Konfigurieren

„Webseiten“ werden über Virtual-Server-Konfigurationsdateien in /etc/nginx/sites-available/ gespeichert. Aktivierte Virtuelle Host Dateien werden über symbolische Links in /etc/nginx/sites-enabled/ aktiviert. Wenn man mehrere Virtual-Server-Konfigurationsdateien hat, empfiehlt es sich, diese nach dem DNS-Eintrag zu benennen. Weitere Informationen kann man aus der nginx-Dokumentationen Beginner’s Guide erfahren.

Beispiel Konfigurationsdateien

Beispiel einer minimalen Konfigurationsdatei /etc/nginx/sites-available/example.com.conf ohne SSL:

server {
    listen       80;  # Lauscht auf HTTP/1.1 (IPv4)
    server_name  example.com www.example.com; # Gültige Hostnamen für diesen Virtual Server

    location / { # Greift für ALLE Requests
        root   /var/www/example.com/; # Definiert das Document‑Root‑Verzeichnis im Dateisystem
        index  index.html index.htm; # Definiert die Standarddateien die ausgeliefert werden
        try_files $uri $uri/ =404; # Bringt einen 404 bei nichtexistenten Dateien ($uri) oder Verzeichnissen ($uri/), nicht nötig aber best pracice für statische
    }

    # Zugriff auf .md-Dateien verbieten
    location ~ \.md$ {
        deny all;
        return 403;
    }

    # Zugriff auf .git-Verzeichnis verbieten
    location ~ /\.git {
        deny all;
        return 403;
    }
}

Beispiel einer Konfigurationsdatei mit SSL:

server {
    listen 443 ssl http2; # Lauscht auf IPv4 Port 443 mit TLS und HTTP/2
    listen [::]:443 ssl http2; # Lauscht auf IPv6 Port 443 mit TLS und HTTP/2

    server_name example.com www.example.com; # Gültige Hostnamen für diesen Virtual Host

    ssl_certificate     /etc/example.com/fullchain.pem; # Öffentliches Zertifikat
    ssl_certificate_key /etc/example.com/privkey.pem; # Privater Schlüssel zum Zertifikat

    # root und index müssen nicht in einem location Block sein. Wenn Sie ausserhalb sind, vererben sich nach unten, solange sie nicht im location Block überschrieben werden
    root  /var/www/example.com/;
    index index.html index.htm;   

    # Bringt einen 404 bei nichtexistenten Dateien ($uri) oder Verzeichnissen ($uri/), nicht nötig aber best pracice für statische Webseite
    location / {
        try_files $uri $uri/ =404;
    }

    # Zugriff auf .md-Dateien verbieten
    location ~ \.md$ {
        deny all;
        return 403;
    }

    # Zugriff auf .git-Verzeichnis verbieten
    location ~ /\.git {
        deny all;
        return 403;
    }
}

server {
    listen 80; # Lauscht auf HTTP (IPv4)
    listen [::]:80; # Lauscht auf HTTP (IPv6)
    
    server_name example.com www.example.com;
    
    # Meldet einen permanenten Redirect für Web Crawler und leitet die Anfrage auf HTTPS um
    return 301 https://$host$request_uri;

}

Beispiel einer sehr allgemeinen Konfigurationsdatei für einen Reverse Proxy mit SSL:

server {
        listen      443 ssl http2;
        listen      [::]:443 ssl http2r;

        server_name proxy.example.com www.proxy.example.com;

        ssl_certificate "/etc/proxy.example.com/fullchain.pem"; # Öffentliches Zertifikat
        ssl_certificate_key "/etc/proxy.example.com/privkey.pem"; # Privater Schlüssel zum Zertifikat
        ssl_session_timeout  10m; # Dauer, wie lange TLS‑Sessions gecacht werden

        proxy_redirect      off; # Verhindert das automatische Umschreiben von Redirect‑UR
        proxy_set_header    X-Real-IP $remote_addr; # Reale Client‑IP an das Backend weiterreichen
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for; # Weiterleitung der kompletten Proxy‑Kette (Client → Proxy)
        proxy_set_header    Host $http_host; # Originalen Host‑Header an das Backend durchreichen

       # Leitet alle eingehen Anfragen zu der proxy_pass Adresse um. Der "trailing slash" (/) ist wichtig, da sonst die Anfragen nicnt sauber verarbeitet werden.
        location / {
                proxy_pass http://localhost:8080/web/;
        }

server {
    listen 80; # Lauscht auf HTTP (IPv4)
    listen [::]:80; # Lauscht auf HTTP (IPv6)

    server_name example.com www.example.com;

    # Meldet einen permanenten Redirect für Web Crawler und leitet die Anfrage auf HTTPS um
    return 301 https://$host$request_uri;

}

Hier der Befehl, um example.com zu aktivieren, die Konfiguration auf Fehler zu prüfen und neu einzuladen:

ln -s /etc/nginx/sites-available/example.com.conf /etc/nginx/sites-enabled/
nginx -t
systemctl reload nginx

Unterschied zwischen HTTP/1.1 und HTTP/2

HTTP/1.1 arbeitet textbasiert und benötigt meist mehrere parallele TCP‑Verbindungen, wobei Anfragen sich gegenseitig blockieren können.
HTTP/2 nutzt ein binäres Protokoll, überträgt mehrere Requests gleichzeitig über eine Verbindung (Multiplexing), komprimiert Header (HPACK) und reduziert dadurch Latenz und Overhead.

SSL-Zertifikate mit Lets Encrypt und Certbot

Am einfachsten läuft die Verwaltung von SSL‑Zertifikaten für Webserver mit Let’s Encrypt – Freie SSL/TLS Zertifikate, aber ohne registrierten und erreichbaren CNAME ist das wegen der Host-Challenge nur schwer zu demonstrieren (Demo war in einer VM auf meinem Rechner). Weite Informationen zur Host-Challenge: Challenge Types – Let’s Encrypt

Crowdsec

Registrierung: https://app.crowdsec.net/signup
Login: https://app.crowdsec.net/sign-in
Allgemeine Doku: Introduction | CrowdSec
Online Testumgebung (erfordert Account von GitHub / GitLab / Google oder Registrierung per Mail), führt einen durch die Installation und erklärt was welcher Befehl macht. Sehr gut, wenn man sich keine eigene VM erstellen will: Crowdsec Absolute Beginners Workshop | CrowdSec | Killercoda

Was ist CrowdSec?

CrowdSec ist eine Open‑Source‑Security‑Lösung, die Logdaten analysiert, Angriffe verhaltensbasiert erkennt und Angreifer automatisch blockiert. Angriffe werden mit einer Community geteilt, sodass alle Teilnehmer (die ihre Daten mit der Community teilen) von einer globalen Threat‑Intelligence profitieren.

Somit ist CrowdSec ein kombiniertes IDS (Intrusion Detection System) / IPS (Intrusion Prevention System) und bietet WAF‑Funktionen über das integrierte AppSec‑Module, das HTTP‑Requests in Echtzeit analysiert und Webangriffe wie SQL‑Injection oder XSS direkt im Webserver oder Reverse Proxy blockiert.

Das AppSec‑Modul ist nicht Teil dieser Demo. Weitere Informationen zu AppSec kann man hier finden: AppSec Component – CrowdSec WAF | CrowdSec

Warum CrowdSec (und nicht Fail2Ban)?

Ich habe mich für CrowdSec entschieden, da klassische, online kuratierte häufig mit False Positives, veralteten Informationen oder gezielt manipulierten („poisoned“) Einträgen belastet sind. Solche extern gepflegten Sperrlisten werden oft ungeprüft übernommen und führen dazu, dass legitimer Traffic blockiert wird und Sicherheitsentscheidungen auf einer potenziell unzuverlässigen Datengrundlage basieren.

Zusätzlich unterscheidet sich CrowdSec grundlegend von Fail2ban: Während Fail2ban rein lokal und reaktiv auf einzelne Logereignisse reagiert, bewertet CrowdSec Angriffe verhaltens‑ und kontextbasiert anhand von Mustern und zeitlichem Verlauf. Die daraus resultierenden Sperrentscheidungen sind zudem dienstspezifisch – wird ein WordPress‑Bouncer eingesetzt, werden ausschließlich IP‑Adressen blockiert, die tatsächlich WordPress‑typische Angriffe ausführen. Dadurch steigt die Relevanz der Maßnahmen deutlich, während das Risiko von Fehlblockierungen reduziert wird.

Architektur Schaubild aus Introduction | CrowdSec

Definition Begriffe: Security Engine, Remediation Component und Remote Console

Bei CrowdSec ist die (Security) Engine das Gehirn (erkennt Angriffe), die Remediation Component (auch Bouncer genannt) ist der Vollstrecker (setzt Maßnahmen durch) und die Remote Console ist die zentrale Übersicht und Verwaltung einer oder mehrerer Engines (auf der Webseite). Um die Synchronisation mit der Community zu aktiveren muss die Engine mit der Remote Console verknüpft werden. Ansonsten kann man die Engine und Bouncer auch ausschließlich Lokal betreiben.

Es gibt viele verschiedene Remediation Components, hier ausgewählte Beispiele:

Firewall (z.B. iptables, nftables, pf) blocken mit DROP (oder REJECT, aber nicht empfohlen)
Webserver (z.B. nginx, apache2, caddy) blocken mit HTTP 403 Forbidden

In unserem Beispiel Bentzen wir den nginx-bouncer, da wir einen lokalen Webserver installieren.

Eine Engine, viele Bouncer (Remediation Components)

Besonders bei Containerisierung (Kubernetes Cluster, Docker Container, etc.) ist es nicht praktikabel für jeden Container eine eigene Engine zu betreiben. Deswegen reicht eine zentrale Engine und damit mehrere Bouncer (Englisch für Türsteher) zu verwalten. Das muss aber erst in der /etc/crowdsec/config.yaml freigeschaltet werden, da die Engine Standardmäßig nur auf localhost lauscht.

#listen_uri: 127.0.0.1:8080
listen_uri: 0.0.0.0:8080

Installation der Engine und Verknüpfung mit der Remote Console

Hier der Link zur relevanten Doku: https://docs.crowdsec.net/u/getting_started/installation/linux

Mit folgendem Befehlen wird das Installations-Skript der aktuellen Shell übergeben, um die CrowdSec-Repositories einzurichten und zu installieren.

apt update && apt upgrade -y && apt install -y curl gnupg
curl -s https://install.crowdsec.net | sh
apt update && apt install -y crowdsec

Falls man die Engine nicht nur lokal betreiben möchte, muss man einen Account anlegen und einen API‑Key über die Remote Console – CrowdSec Console erstellen. Dieser wird benutzt, um die Engine mit der Remote Console zu verknüpfen.

# cscli = CrowdSec command line interface
cscli console enroll <API-Key>

Die Installation muss auf der Remote Console CrowdSec Security Engine Setup Health-Check | CrowdSec verifiziert und freigegeben werden. Hier können die Engines auch umbenannt und getaggt werden.

Was sind Tags?

Tags sind frei vergebbare Bezeichnungen (Labels) für Engines und dienen ausschließlich der Organisation, Filterung und Gruppierung. Tags lassen sich grob in verschiedene Kategorien zusammenfassen: Umgebung, Standort, Rolle und Plattform.

Beispiele gängiger Tags: Prod, Test, Dev, Windows, Linux, OnPrem, Cloud, Baremetal, Proxmox, VM, Web, API, Mail, DB

Für unser Fallbeispiel wären das: Test, Linux, Web, VM

Bash Completion (Optional)

Um nicht immer die Befehle komplett ausschreiben zu müssen, kann man die Autovervollständigung (Bash Completion) für die cscli. Der Befehl source ~/.bashrc lädt die Shell‑Einstellungen neu ein, ohne eine neue Shell öffnen zu müssen.

cscli completion bash | tee /etc/bash_completion.d/cscli
source ~/.bashrc

Kurzerklärung .bashrc, .profile und .bash_profile

.profile wird beim Anmelden am System gelesen und legt grundlegende Einstellungen fest, die für die gesamte Sitzung gelten, etwa Sprache oder Umgebungsvariablen.
.bash_profile macht im Prinzip dasselbe, gilt aber speziell für die Bash und wird nur einmal beim Anmelden ausgeführt.
.bashrc wird jedes Mal beim Öffnen eines Terminals geladen und enthält persönliche Komfort‑Einstellungen wie Abkürzungen (Alias), Funktionen, Farben oder das Aussehen der Eingabezeile.

Möchte man Änderungen Systemweit für alle Benutzer setzen, muss das in der /etc/bash.bashrc oder /etc/profile.d/*.sh gemacht werden. Änderungen in der /etc/profile sind nicht empfohlen, da die bei Updates oft überschrieben wird.

Installation nginx-bouncer

Wir installieren den Nginx-Bouncer und die nötigen Abhängigkeiten: Nginx | CrowdSec

apt install -y nginx lua5.1 libnginx-mod-http-lua luarocks gettext-base lua-cjson
apt install -y crowdsec-nginx-bouncer

Standardmäßig benutzt CrowdSec eine SQLite-Datenbank zur Verwaltung der Sperrlisten. Wenn man diese benutzt, wird empfohlen, den SQLite Write Ahead Logging (WAL) Modus zu aktivieren, der für eine bessere Performance und Stabilität bei größeren Sperrlisten sorgt. Alternativ kann man auch eine MariaDB, MySQL oder PostgreSQL Datenbank verwenden, diese müssen aber separat installiert und konfiguriert (und ggf. DB Migriert werden) werden.

echo "db_config:
  use_wal: true" > /etc/crowdsec/config.yaml.local
systemctl restart crowdsec.service

Dem Nginx-Bouncer müssen wir noch sagen, was er machen und wie er sich verhalten soll. Dazu benutzten wir das „Nginx – Generic Protection“ Packet, welches das Auslesen (Parsing) der Nginx-Logs umfasst und eine Vielzahl von Angriffsmustern enthält: Collections, WAF Rules & Configurations | CrowdSec Hub

cscli collections install crowdsecurity/nginx
systemctl restart crowdsec
systemctl restart nginx

Installation Firewall und -Bouncer

IPTables oder NFTables?

IPTables ist die „klassische“ Linux Firewall, die sequenziell die Regelwerke abarbeitet. Das kann bei größeren und/oder komplexen Regelwerken zu Performanceeinbußen führen. Für IPv4, IPv6 und anderen Protokollen werden unterschiedliche Werkzeuge mit unterschiedlicher Syntax benutzt, was Konfiguration komplizierter macht.
NFTables (NetFilter tables) ist der moderne Nachfolger mit einem einheitlichen Framework und konsistenter Syntax für alle Protokolle, besserer Performance und deutlich flexiblerem Regelmanagement. Ist der empfohlene Standard von Debian 13.

Installation NFTable Firewall

Weitere Informationen zu NFTable kann man hier finden: nftables

apt update
apt install -y nftables
systemctl enable --now nftables

Die Hauptkonfiguration erfolgt über /etc/nftables.conf und einfache Regeln kann man hier direkt einfügen. Bei komplexeren Regelwerken empfiehlt es sich, ein separates Verzeichnis zu erstellen und alle Konfigurationsdateien darin zu importieren.

Optional: Konfiguration NFTables

Dieser Schritt ist optional, da CrowdSec für uns die Steuerung der Firewall übernimmt. Der Firewall-Bouncer benutzt dabei nicht die Konfigurationsdateien, sondern steuert die Firewall direkt über Kernel-API. Erwähne ich nur der Vollständigkeit halber und werde das nicht in der Demo umsetzen.

Wenn man darüber hinaus selbst Regeln erstellen möchte, empfiehlt sich die Erstellung eines zentralen Konfigurationsverzeichnisses, so dass die Regeln von Software-Updates nicht überschrieben werden. Weiterhin sollte man den CrowdSec-nftables‑Bouncer in den „Set‑only (Integration) mode“ schalten, um Konflikte zu vermeiden.

mkdir -p /etc/nftables.d/

Jetzt müssen wir die /etc/nftables.conf so modifizieren, dass alle Konfigurationen in /etc/nftables.d/ eingelesen werden. Dafür müssen wir, include "/etc/nftables.d/*.nft" wie unten gezeigt, hinzufügen:

#!/usr/sbin/nft -f

flush ruleset

include "/etc/nftables.d/*.nft"

table inet filter {
        chain input {
                type filter hook input priority filter;
        }
        chain forward {
                type filter hook forward priority filter;
        }
        chain output {
                type filter hook output priority filter;
        }
}

Es ist best practice, Konfigurationen als .nft‑Dateien zu speichern, um diese von anderen Dateien abzugrenzen. Weiterhin sollten die Dateien in /etc/nftables.d/ mit einer Zahl beginnen, sodass sie in der richtigen Reihenfolge geladen werden. Zum Beispiel:

10-table-filter.nft
20-input-base.nft
30-services.nft
40-logging.nft

Installation NFTable-Bouncer

Weitere Infos zu den Firewall Bouncern: Firewall | CrowdSec

Die verwendeten „Linux – Generic Protection“ (Collections, WAF Rules & Configurations | CrowdSec Hub) umfassen den Syslog-Parser und den SSHD Schutz. Welche eine breite Masse an ANgriffysxzenarien abdecken.

apt install crowdsec-firewall-bouncer-nftables
cscli collections install crowdsecurity/linux

Übersicht der Bouncer

Man kann sich die installierten Bouncer anzeigen lassen; wichtig hier ist der „Last API pull“. Der zeigt an, wann diese sich das letzte Mal die aktuellen Regeln von der Engine gezogen haben.

cscli bouncers list

Übersicht der Auto-BANs

Nachdem der Webserver und Bouncer eine Weile gelaufen sind, kann man sich in der cscli anzeigen lassen, was er gemacht hat. Das funktioniert auch, wenn man kein CrowdSec-Konto hat.

cscli decisions list

Ein Standard-BAN läuft 4 Stunden. Bevor eine IP gebannt wird, kann auch eine CAPTCHA-Abfrage für diese IP gesendet werden. Dafür müsste aber erst ein Anbieter für CAPTCHA konfiguriert werden, was hier in der Demo auch nicht gezeigt wird.

CrowdSec Alert Retention Quota (Online Console)

Alle kostenlosen Konten (Community Plan) speichern für 2 Monate 500 Alarme pro Monat. Wenn dieses Limit erreicht ist, werden keine neuen Alarme gespeichert. Dies bezieht sich aber nur auf die Speicherung der Alarme in der Online Console, nicht auf den Betrieb der Security Engine oder der Bouncer!

Die oben gezeigten Daten sind anonymisiert, weswegen die Source ASs (Autonomous Systems) umbenannt wurden.

Security Reports (Mail)

Standardmäßig bekommt man wöchentliche Security Reports per Mail, kann man Abbestellen.

Schreibe einen Kommentar