Ochrona serwera ipset i CrowdSec przed skanerami

Wielopoziomowa filtracja ruchu: ipset, autoblokada i CrowdSec dla serwerów

System filtracji oparty na ipset, autoblokadzie podejrzanych IP i CrowdSec redukuje śmieciowy ruch z 12% do mniej niż 0,3%. Blokada odbywa się na poziomie jądra Linux (L3/L4), przed przetwarzaniem przez nginx i PHP-FPM. To minimalizuje obciążenie serwera projektu komercyjnego na Bitrix, gdzie skanowanie .env, wp-login.php i config.php powodowało skoki odrzuceń do 99%.

Zalety podejścia: pełna przejrzystość blokad, atomowe aktualizacje list IP, modułowa architektura dla szybkiej konfiguracji projektu.

Zalety przed zewnętrznymi WAF i CDN

Zewnętrzne WAF i CDN nadają się do globalnych projektów, ale dla lokalnych rozwiązań z niskim obciążeniem preferowana jest samowystarczalna filtracja.

Kluczowe powody wyboru własnego systemu:

• Pełna kontrola: widać zablokowane IP, regułę i czas trwania bana.
• Blokada przed aplikacją: zasoby nginx/PHP nie są marnowane na śmieci.
• Elastyczność: szybkie dodawanie reguł pod wzorce Bitrix (.env, .git).
• Prostota: bez zbędnych warstw w architekturze.

Analiza prowadzona jest na podstawie logów HTTP (L7), ale odrzucanie pakietów — w iptables z ipset na poziomie jądra.

Struktura trójwarstwowej obrony

System jest uwarstwiony do sekwencyjnej filtracji.

Warstwa 1: Geoblokada. Pakiety z nieistotnych krajów odcinane są natychmiast, bez parsowania HTTP.

Warstwa 2: Autoblokada podejrzanych IP. Po geoblokadzie sprawdzane są wzorce skanowania: wp-login.php, shell.php, .env. IP banowane na 2 godziny.

Warstwa 3: CrowdSec. Integracja przez bouncer dodaje globalną czarną listę do ipset z TTL.

Modułowość pozwala wyłączać warstwy niezależnie, redukując ryzyko fałszywych alarmów.

Ipset jako podstawa skalowalności

Zwykłe iptables z tysiącami reguł IP prowadzą do liniowego przeszukiwania O(n), degradującego wydajność pod obciążeniem.

Ipset używa hash:ip lub hash:net dla sprawdzeń O(1):

-m set --match-set blocked_ips src

Aktualizacja zestawów atomowo przez temp-zestaw i swap, bez przerw w filtracji:

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"

To zapewnia ciągłą ochronę nawet przy masowych aktualizacjach list.

Detekcja skanerów po wzorcach

Skrypt auto-block-suspicious.sh monitoruje logi tail -n, skupiając się na podejrzanych żądaniach:

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

IP automatycznie banowane na 2 godziny. Przykład: fala żądań do /wp-login.php (200+ prób) zneutralizowana w 20–30 sekund, obciążenie znormalizowane.

Statystyki blokady:

• Chiny: 8802 IP.
• Podejrzane: 10 IP (przykłady: 4.193.97.168, 195.178.110.109).

Integracja CrowdSec

Bouncer CrowdSec uzupełnia ipset crowdsec_blacklist z TTL:

• Autosynchronizacja globalnych sygnatur.
• Autousuwanie po czasie.

CrowdSec uzupełnia niestandardowe moduły, zamykając znane zagrożenia bez zastępowania logiki projektowej.

Wyniki wdrożenia

Porównanie metryk (2025 bez WAF vs 2026 z WAF):

| Wskaźnik | Bez ochrony | Z WAF |

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

| Śmieciowy ruch | ~12% | <0,3% |

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

| Odrzucenia | Do 40% | 12–15% |

Skoki RPS od skanowania przerywane na jądrze, analityka oczyszczona z botów.

Ograniczenia:

• Nie chroni przed atakami L4 dużym ruchem.
• Wymaga aktualizacji CMS (Bitrix).
• Nieefektywne przeciwko residential IP.
• Nie dla globalnych projektów z CDN.

Co jest ważne

• Skalowalność: ipset zapewnia sprawdzenia O(1) dla milionów IP.
• Atomowość: swap zapobiega przerwom w filtracji.
• Modułowość: Niezależne warstwy (kraje, podejrzane, CrowdSec) dla precyzyjnej konfiguracji.
• Efektywność: Redukcja śmieci do 0,3%, LA dwa razy niższe.
• Przejrzystość: Pełna kontrola bez czarnych skrzynek.

— Editorial Team