W dobie zautomatyzowanych ataków typu brute-force, skanerów podatności i botnetów, klasyczne rozwiązania takie jak Fail2Ban – oparte na powolnym, liniowym analizowaniu logów za pomocą wyrażeń regularnych (regex) – stają się wąskim gardłem serwerów. Odpowiedzią na te wyzwania jest CrowdSec – nowoczesne narzędzie typu Open Source, udostępniane na liberalnej licencji MIT.
Projekt, zrodzony we Francji, to nie tylko lokalny analizator logów. To potężny „cyfrowy monitoring sąsiedzki”. Za rozwojem narzędzia stoi firma budująca globalną sieć wymiany informacji o zagrożeniach (Cyber Threat Intelligence – CTI).
Sercem CrowdSeca jest silnik napisany w języku Go (Golang). Gwarantuje to potężną wydajność i minimalne zużycie pamięci RAM oraz procesora. Kiedy Twój serwer wykryje i zablokuje agresywne IP, informacja o tym trafia do wspólnej bazy, błyskawicznie chroniąc dziesiątki tysięcy innych serwerów na świecie. I w drugą stronę – Twój serwer otrzymuje listy złośliwych adresów od innych, blokując ataki zanim te w ogóle nastąpią.
Instalacja CrowdSec na serwerze Linux
Instalacja rdzenia systemu sprowadza się do dodania oficjalnego repozytorium i instalacji paczki bazowej (tzw. LAPI):
curl -s https://install.crowdsec.net | sudo bash
sudo apt-get install crowdsecPodczas instalacji CrowdSec automatycznie przeskanuje system, wykryje zainstalowane usługi (np. Nginx, Apache, SSH) i wgra odpowiednie parsery do czytania ich logów.
Remediation Component (Dawniej „Bouncer”)
Sam rdzeń CrowdSeca to tylko analityk – czyta logi i podejmuje decyzje. Aby fizycznie odciąć atakującego od serwera, potrzebujesz „ochroniarza”, czyli tzw. Remediation Component (w starszych poradnikach nazywanego Bouncerem).
W przeszłości trzeba było instalować konkretne pakiety pod dany firewall (np. crowdsec-firewall-bouncer-iptables). Obecnie proces ten zunifikowano. Wystarczy zainstalować jeden zintegrowany komponent, który automatycznie wykryje, czy system używa nftables, iptables czy ipset:
sudo apt-get install crowdsec-firewall-bouncerZbrojenie serwera: Kolekcje i Scenariusze
CrowdSec Hub oferuje gotowe zestawy reguł (kolekcje), które chronią przed specyficznymi atakami. Warto rozszerzyć domyślną ochronę za pomocą narzędzia cscli.
Instalacja głównych kolekcji:
sudo cscli collections install crowdsecurity/sshd crowdsecurity/apache2 crowdsecurity/postfix crowdsecurity/dovecot crowdsecurity/smb crowdsecurity/appsec-virtual-patching crowdsecurity/iptablesInstalacja zaawansowanych scenariuszy dla serwerów WWW:
sudo cscli scenarios install \
crowdsecurity/http-backdoors-attempts \
crowdsecurity/http-bad-user-agent \
crowdsecurity/http-bf-wordpress_bf \
crowdsecurity/http-crawl-non_statics \
crowdsecurity/http-generic-bf \
crowdsecurity/http-path-traversal-probing \
crowdsecurity/http-probing \
crowdsecurity/http-sensitive-files \
crowdsecurity/http-sqli-probing \
crowdsecurity/http-wordpress-scan \
crowdsecurity/http-xss-probing \
crowdsecurity/http-admin-interface-probing \
ltsich/http-w00tw00t
Po wdrożeniu nowych reguł, przeładuj silnik analityczny:
sudo systemctl reload crowdsecWłasna biała lista (Whitelist) – Infrastruktura jako Kod
CrowdSec pozwala na definiowanie adresów IP, które nigdy nie powinny otrzymać bana (np. IP biura, domowe, serwery Baselinker). Użyjemy do tego dedykowanego pliku YAML.
Krok 1: Stwórz plik białej listy:
sudo touch /etc/crowdsec/parsers/s02-enrich/moje-adresy.yamlKrok 2: Otwórz plik edytorem (np. nano) i wklej poniższą strukturę:
name: uzytkownik/moje-adresy
description: "Moja własna biała lista adresów IP"
whitelist:
reason: "Zaufane IP administratora i zewnętrznych API"
ip:
- "1.2.3.4" # Twoje stałe IP domowe
cidr:
- "192.168.1.0/24" # Twoja sieć lokalna/VPNKrok 3 (Pro-Tip):
CrowdSec podczas dużych aktualizacji może modyfikować pliki konfiguracyjne. Aby zabezpieczyć naszą listę przed przypadkowym skasowaniem, nakładamy na plik systemową flagę niezmienności (immutable):
sudo chattr +i /etc/crowdsec/parsers/s02-enrich/moje-adresy.yaml(Gdy w przyszłości zechcesz edytować ten plik, zdejmij flagę komendą: sudo chattr -i …)
Przeładuj usługę: sudo systemctl reload crowdsec.
Hardening: Zamykanie CrowdSeca w klatce (Systemd Sandboxing)
CrowdSec z definicji wymaga uprawnień administratora (roota), aby zarządzać zaporą sieciową. Zgodnie z zasadą ograniczonego zaufania (Zero Trust), możemy ograniczyć uprawnienia tego konkretnego procesu, wykorzystując mechanizmy izolacji wbudowane w demona Systemd.
Edytuj jednostkę usługi:
sudo systemctl edit crowdsecWklej poniższą konfigurację w otwartym oknie:
[Service]
# Montuje cały system jako "tylko do odczytu"
ProtectSystem=strict
# Zezwala na modyfikacje tylko we własnych katalogach roboczych
ReadWritePaths=/etc/crowdsec /var/lib/crowdsec /var/log/crowdsec /tmp /run
# Zaawansowana izolacja
ProtectHome=true
PrivateTmp=true
NoNewPrivileges=true
DeviceAllow=/dev/null rw
RestrictRealtime=trueZastosuj zmiany:
sudo systemctl daemon-reload
sudo systemctl restart crowdsecAutomatyzacja aktualizacji: Systemd Timers (Zamiast Crona)
W starszych poradnikach zalecano dodawanie komend aktualizujących (cscli hub update) do systemowego Crontaba. Dziś to rozwiązanie przestarzałe. CrowdSec dostarcza nowoczesny Timer Systemd, który asynchronicznie dba o aktualizacje bazy wiedzy.
Wystarczy go włączyć i uruchomić:
sudo systemctl enable crowdsec-update.timer
sudo systemctl start crowdsec-update.timerSystemd sam zadba o logowanie przebiegu aktualizacji w głównym dzienniku (journalctl), zwalniając Cię z konieczności tworzenia własnych plików logów.
Ochrona niestandardowych aplikacji (Log Acquisition)
Jeśli używasz paneli hostingowych takich jak ISPConfig, musisz poinstruować CrowdSeca, gdzie leżą pliki logów poszczególnych stron (tzw. Acquisition).
Edytuj plik /etc/crowdsec/acquis.yaml i upewnij się, że zawiera odpowiednie ścieżki:
filenames:
- /var/www/clients/client*/web*/log/error.log
- /var/www/clients/client*/web*/log/access.log
labels:
type: apache2 # (zmień na nginx, jeśli to Twój główny serwer)Po edycji wykonaj sudo systemctl reload crowdsec. Możesz zweryfikować, czy silnik poprawnie widzi i interpretuje logi konkretnej strony, wydając komendę:
sudo cscli explain --type apache2 --file /var/www/twoja-strona.pl/log/access.logBonus: Agresywny „Honey-Pot” (Tylko dla serwerów bez WordPressa)
Jeśli Twój serwer hostuje dedykowane aplikacje, a nie używa WordPressa, to każda próba wywołania pliku wp-login.php jest ewidentnym skanowaniem (atakiem). Możemy stworzyć bardzo agresywny scenariusz, który permanentnie odetnie każdego bota za zaledwie jedno takie zapytanie.
Krok 1: Stwórz plik scenariusza:
sudo nano /etc/crowdsec/scenarios/wp-honeypot.yamlKrok 2: Wklej zawartość łapiącą krytyczne rozszerzenia i wirtualne ścieżki:
type: leaky
name: custom/wp-honeypot
description: "Agresywne wykrywanie botów szukających plików wrażliwych na aplikacjach non-WP"
filter: |
evt.Meta.log_type == 'http_access-log' &&
(
evt.Parsed.request matches `(?i).*wp-login\.php.*` ||
evt.Parsed.request matches `(?i).*wp-admin.*` ||
evt.Parsed.request matches `(?i).*xmlrpc\.php.*` ||
evt.Parsed.request matches `(?i).*wp-config\..*` ||
evt.Parsed.request matches `(?i).*\.env.*` ||
evt.Parsed.request matches `(?i).*\.git/config.*` ||
evt.Parsed.request matches `(?i).*\.sql.*` ||
evt.Parsed.request matches `(?i).*\.bak.*` ||
evt.Parsed.request matches `(?i).*\.php~.*`
)
leakspeed: "0s"
capacity: 0
blackhole: 1mKrok 3:
W pliku /etc/crowdsec/profiles.yaml dodaj na samej górze sekcję wydłużającą czas blokady dla tego konkretnego scenariusza (np. na 30 dni):
name: long_term_ban_wp
filters:
- Alert.GetScenario() == 'custom/wp-honeypot'
decisions:
- type: ban
duration: 720h
on_success: breakPrzeładuj usługę sudo systemctl reload crowdsec.
Dlaczego to działa tak świetnie?
.env.* – Wyłapuje próby wykradzenia kluczy API, haseł do baz i danych chmurowych AWS (to obecnie „Święty Graal” cyberprzestępców).
.git/config – Blokuje boty próbujące sklonować cały kod źródłowy Twojej aplikacji.
.bak / .sql – Zatrzymuje poszukiwaczy zapomnianych backupów baz danych, które programiści często zostawiają w publicznych katalogach.
Niezbędnik Administratora – Komendy (Ściągawka)
Jeśli wdrażasz CrowdSec, możesz z czystym sumieniem wyłączyć i odinstalować Fail2Ban. Poniżej najważniejsze polecenia do zarządzania zaporą:
Zarządzanie blokadami (Decisions):
cscli decisions list – Wyświetla tabelę aktywnych banów (kto, za co i na jak długo).
cscli decisions add –ip 1.2.3.4 –reason „manual ban” – Ręczne zablokowanie adresu.
cscli decisions delete –ip 1.2.3.4 – Ręczne odblokowanie (zdjęcie bana).
Monitorowanie Systemu:
cscli metrics – Pokazuje statystyki w czasie rzeczywistym: ile linii zostało przeczytanych, i które scenariusze są najskuteczniejsze.
cscli alerts list – Historia wykrytych zagrożeń (nawet tych, które nie zaowocowały blokadą).
cscli capi status – Sprawdza status szyfrowanego połączenia z Centralnym API (CTI), skąd pobierane są „bazy wirusów” od innych użytkowników.
Wskazówka: Jeśli używasz narzędzi CI/CD lub własnych skryptów Bash, możesz dodać flagę -o json lub -o raw na końcu większości komend cscli, co wyrzuci wyniki w formacie maszynowym, gotowym do automatycznego parsowania.