Zurück zur Startseite

ipset und CrowdSec Server-Schutz vor Scannern

Der Artikel beschreibt ein dreischichtiges Traffic-Filterungssystem basierend auf ipset, Autoblocking und CrowdSec. Blocking auf Kernel-Ebene reduziert Junk-Traffic auf 0,3 % und Last. Code zum Aktualisieren von Sets, Metriken und Einschränkungen werden bereitgestellt.

Drei WAF-Schichten: ipset + CrowdSec für Linux-Server
Advertisement 728x90

Mehrstufige Traffic-Filterung: ipset, Auto-Blockierung und CrowdSec für Server-Sicherheit

Ein ipset-basiertes Filtersystem mit automatischer Blockierung verdächtiger IPs und CrowdSec reduziert unnötigen Traffic von 12 % auf unter 0,3 %. Die Blockierung erfolgt auf Kernel-Ebene (L3/L4) im Linux, bevor nginx und PHP-FPM Requests bearbeiten. Das entlastet Server bei produktiven Bitrix-Seiten, wo Scans nach .env, wp-login.php und config.php früher Ausfälle bis zu 99 % verursachten.

Wichtige Vorteile: Volle Transparenz bei Blockierungen, atomare Updates der IP-Listen und modularer Aufbau für schnelle Anpassungen an Projekte.

Vorteile gegenüber externen WAFs und CDNs

Externe WAFs und CDNs eignen sich super für globale Riesen-Apps, aber bei kleineren lokalen Setups mit geringem Traffic ist eine selbst gehostete Filterung der bessere Weg.

Google AdInline article slot

Top-Gründe für eine eigene Lösung:

  • Vollständige Kontrolle: Genau sehen, welche IPs blockiert werden, nach welcher Regel und für wie lange.
  • Blockierung vor der App: Kein Ressourcenverbrauch von nginx/PHP für Müll-Traffic.
  • Flexibilität: Einfach Regeln für Bitrix-spezifische Muster wie .env oder .git hinzufügen.
  • Einfachheit: Keine zusätzlichen Schichten, die den Stack aufblähen.

Die Analyse läuft über HTTP-Logs (L7), aber Paket-Drops passieren in iptables mit ipset direkt auf Kernel-Ebene.

Dreistufige Abwehrstruktur

Das System filtert schrittweise in Ebenen.

Google AdInline article slot

Ebene 1: Geo-Blocking. Pakete aus irrelevanten Ländern werden sofort verworfen – ohne HTTP-Parsing.

Ebene 2: Auto-Blockierung verdächtiger IPs. Nach Geo-Check scannt es nach Mustern wie wp-login.php, shell.php, .env. Übeltäter werden für 2 Stunden gebannt.

Ebene 3: CrowdSec. Der Bouncer füttert eine globale Blacklist in ipset mit TTL.

Google AdInline article slot

Die Modularität erlaubt, Ebenen unabhängig zu aktivieren und False Positives zu minimieren.

ipset: Die Basis für Skalierbarkeit

Normale iptables mit Tausenden IP-Regeln bedeuten lineare O(n)-Scans, die unter Last die Performance killen.

ipset nutzt hash:ip oder hash:net für O(1)-Lookups:

-m set --match-set blocked_ips src

Listen-Updates sind atomar über Temp-Sets und Swaps, ohne Downtime:

ipset create "${country}_temp" hash:net 2>/dev/null || ipset flush "${country}_temp"
if [[ -s "$temp_file" ]]; then
    while read network; do
        ipset add "${country}_temp" "$network"
    done < "$temp_file"
    ipset swap "${country}_temp" "$country"
fi
ipset destroy "${country}_temp"

So bleibt der Schutz stabil, auch bei Massen-Updates der Listen.

Erkennung von Scannern durch Muster

Das Skript auto-block-suspicious.sh tailt Logs und zoomt auf verdächtige Requests:

  • wp-login.php (auch auf Bitrix).
  • shell.php, shoha.php.
  • .env, .git, .aws/credentials.

IPs werden automatisch für 2 Stunden geblockt. Beispiel: Ein Ansturm von über 200 /wp-login.php-Hits neutralisiert in 20–30 Sekunden, Load sofort normalisiert.

Blockierungs-Stats:

  • China: 8.802 IPs.
  • Verdächtig: 10 IPs (z. B. 4.193.97.168, 195.178.110.109).

CrowdSec-Integration

Der CrowdSec-Bouncer befüllt die ipset-Liste crowdsec_blacklist mit TTL:

  • Automatische Synchronisation globaler Signaturen.
  • Automatisches Ablaufen bei Timeout.

CrowdSec ergänzt eigene Module und bewältigt bekannte Bedrohungen, ohne die Logik umzubauen.

Umsetzungsergebnisse

Vergleich der Metriken (2025 ohne WAF vs. 2026 mit WAF):

| Metrik | Ohne Schutz | Mit WAF |

|-------------------|---------------|--------------|

| Müll-Traffic | ~12 % | <0,3 % |

| Load Average | 1,8–2,5 | 0,9–1,2 |

| Ausfallrate | Bis 40 % | 12–15 % |

Scanning-RPS-Spikes sterben im Kernel; Analysen sind jetzt bot-frei.

Einschränkungen:

  • Kein Schutz vor High-Volume-L4-Attacken.
  • Erfordert CMS-Updates (Bitrix).
  • Schwach gegen Residential-IPs.
  • Nicht für CDN-Skala-Projekte.

Wichtige Erkenntnisse

  • Skalierbarkeit: ipset liefert O(1)-Checks für Millionen IPs.
  • Atomarität: Swaps verhindern Lücken im Filtering.
  • Modularität: Unabhängige Ebenen (Geo, Verdächtig, CrowdSec) für präzise Feinabstimmung.
  • Effizienz: Müll auf 0,3 %, Load Average halbiert.
  • Transparenz: Volle Einblick, keine Blackbox.

— Editorial Team

Advertisement 728x90

Weiterlesen