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.
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.
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.
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
Noch keine Kommentare.