crowdsec security for vps

CrowdSec: Nowoczesny zamiennik Fail2Ban

przez

W dobie zautomatyzowanych ataków typu brute-force i skanerów podatności, klasyczne rozwiązania typu Fail2Ban często przestają wystarczać. Odpowiedzią na te wyzwania jest CrowdSec – nowoczesne narzędzie typu Open Source, udostępniane na lekkiej i liberalnej licencji MIT.

Projekt narodził się we Francji z inicjatywy Philippe’a Humeau i Thibaulta Koechlina, którzy bazując na wieloletnim doświadczeniu w branży cyberbezpieczeństwa, postanowili stworzyć „cyfrowy monitoring sąsiedzki”. Za rozwojem narzędzia stoi firma o tej samej nazwie, która na co dzień zajmuje się budowaniem globalnej sieci wymiany informacji o zagrożeniach (Cyber Threat Intelligence).

Sercem CrowdSeca jest unikalne połączenie zaawansowanej analizy zachowań z potęgą społeczności. W praktyce oznacza to, że gdy jeden użytkownik wykryje i zablokuje agresywne IP, informacja ta trafia do wspólnej bazy, błyskawicznie chroniąc całą resztę sieci. Dzięki napisaniu silnika w języku Go, rozwiązanie jest znacznie szybsze i bardziej efektywne od swoich poprzedników, a przy tym w minimalnym stopniu obciąża zasoby serwera.

Instalacja CrowdSec na serwerze Linux

Najpierw dodajemy repozytorium i instalujemy silnik (LAPI):

curl -s https://install.crowdsec.net | sudo bash
sudo apt-get install crowdsec

Po instalacji CrowdSec automatycznie wykryje Twoje usługi (np. Nginx, Apache, SSH).

Konfiguracja pod serwer WWW

Aby CrowdSec mógł realnie blokować ataki, potrzebujesz tzw. Bouncera (odbijacza). Dla serwera WWW najskuteczniejszy jest bouncer na poziomie firewalla (NFTables/IPTables):

sudo apt-get install crowdsec-firewall-bouncer-iptables

Scenariusze poprawiające bezpieczeństwo stron:

Warto doinstalować konkretne kolekcje reguł (hub), które chronią przed typowymi atakami webowymi:

  • HTTP Crawl Non-Static: Wykrywa agresywne skanowanie plików php/html.
  • Nginx-Proxy-Manager / Apache2: Specyficzne logi dla Twojego serwera.
  • **Bot-Conf: ** Ochrona przed niechcianymi botami.

Instalacja dodatkowych kolekcji i scenariuszy:

sudo cscli collections install crowdsecurity/sshd crowdsecurity/apache2 crowdsecurity/postfix crowdsecurity/dovecot crowdsecurity/smb crowdsecurity/appsec-virtual-patching crowdsecurity/iptables

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

sudo systemctl reload crowdsec
sudo systemctl reload crowdsec

Własna biała lista (White-list)

CrowdSec pozwala na definiowanie adresów, które nigdy nie powinny zostać zablokowane (nasze ip, klasy ip Baselinkera, itp.). Stwórzmy dedykowany plik, który pozwoli nam dodać te adresy na tzw. białą listę.

Krok 1: Tworzenie pliku moje-adresy.yaml

touch /etc/crowdsec/parsers/s02-enrich/moje-adresy.yaml

Krok 2: Zawartość pliku

name: uzytkownik/moje-adresy
description: "Moja wlasna biala lista adresow IP"
whitelist:
  reason: "Zaufane IP administratora i biura"
  ip:
    - "1.2.3.4" # Twoje stałe IP
  cidr:
    - "192.168.1.0/24" # Twoja sieć lokalna

Krok 3: Ochrona pliku przed nadpisaniem

CrowdSec podczas aktualizacji może nadpisać pliki wewnątrz swoich katalogów. Aby mieć pewność, że plik przetrwa, użyjemy flagi „immutable”:

# Blokowanie pliku (tylko do odczytu, nawet dla roota)
sudo chattr +i /etc/crowdsec/parsers/s02-enrich/moje-adresy.yaml

# Zdejmowanie flagi przed edycją
sudo chattr -i /etc/crowdsec/parsers/s02-enrich/moje-adresy.yaml

Po edycji przeładuj usługę: sudo systemctl reload crowdsec.

„Zamykanie Crowdsec w klatce”: Systemd Sandboxing

CrowdSec działa z prawami roota. Aby ograniczyć skutki potencjalnego przejęcia procesu, wykorzystamy mechanizmy izolacji wbudowane w systemd.

Edytuj jednostkę serwisową:

sudo systemctl edit crowdsec

Wklej poniższą konfigurację, która ogranicza uprawnienia procesu:

[Service]
# System jako "tylko do odczytu"
ProtectSystem=strict

# Zezwól na zapis tylko w niezbędnych miejscach
ReadWritePaths=/etc/crowdsec /var/lib/crowdsec /var/log/crowdsec /tmp /run

# Ograniczenia dostępu
ProtectHome=true
PrivateTmp=true
NoNewPrivileges=true
DeviceAllow=/dev/null rw
RestrictRealtime=true

Następnie wykonaj:

sudo systemctl daemon-reload
sudo systemctl restart crowdsec

Aktualizacja Scenariuszy i Kolekcji (CrowdSec Hub)

Najlepiej dodać aktualizację reguł do crontaba:

# aktualizacja baz kolekcji itp crowdsec
15 3 * * * (/usr/bin/cscli hub update && /usr/bin/cscli hub upgrade && /usr/bin/crowdsec -t && /usr/bin/systemctl reload crowdsec) 2>> /var/log/crowdsec_update_errors.log

Następnie utwórz odpowiedni plik logów, do którego kierowane będą komunikaty, z procesu aktualizacji i nadaj mu odpowiednie prawa.

touch /var/log/crowdsec_update_errors.log
sudo chown root:root /var/log/crowdsec_update_errors.log
sudo chmod 700 /var/log/crowdsec_update_errors.log

Bonus: Agresywny Honey-Pot (Dla serwerów bez WordPressa)

Jeśli Twój serwer nie obsługuje WordPressa, każda próba dostępu do jego plików jest ewidentnym atakiem.

Krok 1: Stwórz scenariusz wp-honeypot.yaml

touch /etc/crowdsec/scenarios/wp-honeypot.yaml

Krok 2: Wklej zawartość

type: leaky
name: custom/wp-honeypot
description: "Agresywne wykrywanie botów szukajacych WP/plikow wrażliwych"
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-content/.*` ||
    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~.*` ||
    evt.Parsed.request matches `(?i).*/phpmyadmin/.*`
  )
leakspeed: "0s"
capacity: 0
blackhole: 1m

Krok 3: Konfiguracja profilu (Długi ban)

Edytuj /etc/crowdsec/profiles.yaml i dodaj na początku sekcji notifications: (lub nad domyślnym profilem):

name: long_term_ban_wp
filters:
  - Alert.GetScenario() == 'custom/wp-honeypot'
decisions:
  - type: ban
    duration: 720h # 30 dni
on_success: break

Ustaw odpowiednie prawa

sudo chown root:root /etc/crowdsec/scenarios/wp-honeypot.yaml
sudo chmod 644 /etc/crowdsec/scenarios/wp-honeypot.yaml

Szybka weryfikacja

Możesz sprawdzić, czy uprawnienia są spójne z resztą plików w tym katalogu, wpisując:

ls -l /etc/crowdsec/scenarios/

Powinieneś zobaczyć coś w stylu:

-rw-r--r-- 1 root root […] wp-honeypot.yaml

Co tutaj dodaliśmy i dlaczego?

wp-config..*: Wyłapuje próby dostępu do wp-config.php, ale też wp-config.php.bak, wp-config.php.swp (pliki tymczasowe edytorów) czy wp-config.txt.

.env.*: To obecnie „Święty Graal” dla botów. Pliki .env zawierają hasła do baz danych, klucze API do AWS, Stripe czy Mailgun.

.git/config: Boty szukają publicznie dostępnych repozytoriów, żeby pobrać cały kod źródłowy Twojej strony.

.sql.*: Próby pobrania zrzutów bazy danych (np. backup.sql, dump.sql.gz).

.bak / .php~: Często programiści robią kopię pliku przed edycją. Takie pliki nie są interpretowane przez PHP, więc serwer WWW wyświetla je jako zwykły tekst – podając napastnikowi kod źródłowy na tacy.

/phpmyadmin/: Klasyka gatunku. Jeśli nie masz zainstalowanego PMA, każda próba wejścia tam to bot szukający dziurawych wersji narzędzia.

Konfiguracja logów (Acquisition)

Aby CrowdSec widział logi stron w ISPConfig, edytuj /etc/crowdsec/acquis.yaml:

filenames:
  - /var/www/clients/client*/web*/log/error.log
  - /var/www/clients/client*/web*/log/access.log
labels:
  type: apache2 # lub nginx, zależnie od tego co masz w ISPConfig

Instalacja i uruchomienie

Przeładuj CrowdSec, aby wczytał nowy scenariusz:

sudo systemctl reload crowdsec

Upewnij się, że logi HTTP są czytane. CrowdSec musi „widzieć” logi Twojego serwera (Nginx/Apache). Sprawdzisz to komendą:

cscli explain --type log --file /var/www/twoja-strona.pl/log/access.log

Dlaczego to jest lepsze od standardowego scenariusza?

Brak opóźnień: Standardowe scenariusze są projektowane tak, by nie zbanować zapominalskiego administratora, który trzy razy wpisze złe hasło. U Ciebie administratora WP nie ma, więc każda próba to „próba ataku”.

Oszczędność zasobów: Agresywny ban na poziomie Firewalla (przez bouncera) sprawia, że bot nawet nie dotknie już Twojego serwera WWW przez następny miesiąc.

Czystość logów: Szybkie wycinanie skanerów sprawi, że Twoje logi access.log będą znacznie mniejsze i czytelniejsze.

Protip: Uważaj na „False Positives”

Ten scenariusz jest bardzo agresywny. Jeśli masz na tym serwerze jakiekolwiek inne aplikacje, upewnij się, że ich legalne ścieżki nie zawierają frazy .bak lub .sql w adresach URL, które odwiedzają zwykli użytkownicy. Ale przy „czystym” serwerze bez WP, ryzyko pomyłki jest bliskie zeru.

Podsumowanie i przydatne komendy

Jeśli decydujesz się na CrowdSec, warto wyłączyć Fail2Ban, aby zaoszczędzić zasoby. Twój serwer jest teraz chroniony przez globalną sieć wymiany informacji.

Twój CrowdSec jest teraz:

  • Zainstalowany i gotowy do walki z botami.
  • Odporny na pomyłkowe zablokowanie Ciebie (biała lista).
  • Bezpieczny (zamknięty w piaskownicy systemowej).
  • Poddany dobowym aktualizacjom

Najważniejsze komendy cscli:

Zarządzanie decyzjami (Blokadami)

  • cscli decisions list – wyświetla listę wszystkich aktualnie aktywnych blokad (kto, za co i na jak długo został zablokowany).
  • cscli decisions add –ip 1.2.3.4 –reason „manual ban” – ręczne zablokowanie konkretnego adresu IP.
  • cscli decisions delete –ip 1.2.3.4 – ręczne odblokowanie (zdjęcie bana) dla podanego adresu IP.
  • cscli decisions delete –all – usuwa absolutnie wszystkie aktywne blokady z systemu.

Zarządzanie komponentami (Scenariusze, Parsery)

  • cscli hub list – wyświetla listę wszystkich zainstalowanych oraz dostępnych scenariuszy, parserów i kolekcji.
  • cscli collections install crowdsecurity/nginx – instaluje gotowy pakiet ochrony (kolekcję) dla konkretnej usługi (w tym przykładzie Nginx).
  • cscli scenarios list – wyświetla listę tylko zainstalowanych scenariuszy detekcji.
  • cscli parsers list – wyświetla listę zainstalowanych parserów (odpowiedzialnych za czytanie logów).
  • cscli hub update – pobiera najnowsze definicje i aktualizacje reguł z oficjalnego repozytorium CrowdSec.
  • cscli hub upgrade – aktualizuje zainstalowane komponenty do ich najnowszych wersji.

Diagnostyka i Logi

  • cscli metrics – wyświetla statystyki w czasie rzeczywistym: ile linii logów zostało przeczytanych, które scenariusze „odpalają” najczęściej i czy bouncery działają.
  • cscli alerts list – wyświetla historię alertów (nawet tych, które nie skończyły się banem).
  • cscli alerts inspect – pokazuje szczegółowe szczegóły konkretnego alertu (po numerze ID z listy powyżej).
  • cscli explain –dsn „file:///var/log/nginx/access.log” –type nginx – (Bardzo przydatne!) Pokazuje jak CrowdSec interpretuje dany plik logów i czy poprawnie go rozumie.

Zarządzanie Bouncerami i API

  • cscli bouncers list – pokazuje listę aktywnych „odbijaczy” (np. firewall bouncer) i sprawdza, kiedy ostatnio komunikowały się z silnikiem.
  • cscli capi status – sprawdza status połączenia z Centralnym API (siecią CrowdSec), skąd pobierane są listy złośliwych IP od innych użytkowników.

Przeładowanie Crowdsec

  • sudo systemctl reload crowdsec – przeładowuje konfigurację po edycji plików Crowdsec (np. po zmianach w białej liście, pliku konfiguracyjnym), bez przerywania pracy usługi.

Wskazówka: Jeśli chcesz sprawdzić, co dokładnie robi dany scenariusz, możesz dodać -o json lub -o raw na końcu niektórych komend, aby uzyskać dane w formacie łatwiejszym do przetworzenia przez skrypty.