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 nie wystarczają. CrowdSec to rozwiązanie oparte na analizie zachowań i współdzielonej inteligencji (IP wycięte u jednego użytkownika trafia na czarną listę u wszystkich). Jest też szybszy, bardziej efektywny i mniej obciąża serwer.

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:

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

Instalacja dodatkowych scenariuszy:

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

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 lub blok adresów zewnętrznych

Krok 3: Ochrona pliku przed nadpisaniem

CrowdSec podczas aktualizacji, nadpisuje i usuwa wszystkie pliki, które do niego nie należą. Jeśli chcesz mieć 100% pewności, że go nie usunie/zmieni, użyj systemowej flagi „immutable”:

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

Jak odblokować plik do edycji?

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

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

„Zamykanie Crowdsec w klatce”: Systemd Sandboxing

CrowdSec, to program, który działa na serwerze z prawami użytkownika root, więc aby nie mógł „narozrabiać” w przypadku błędu lub przejęcia procesu, wykorzystamy mechanizmy izolacji wbudowane w systemd. Ograniczymy mu dostęp tylko do niezbędnych katalogów.

Edytuj jednostkę serwisową:

sudo systemctl edit crowdsec

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

[Service]
# CrowdSec będzie widział resztę systemu 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
sudo systemctl daemon-reload
sudo systemctl restart crowdsec

Dzięki temu, nawet jeśli w kodzie CrowdSec pojawiłby się krytyczny błąd, proces nie będzie miał technicznej możliwości usunięcia Twoich plików systemowych , czy podglądania folderów domowych użytkowników.

Aktualizacja Scenariuszy i Kolekcji (CrowdSec Hub)

CrowdSec ma wbudowany mechanizm aktualizacji reguł, który nie wymaga restartu całego serwera. Najlepiej zrobić to jednym ciągiem, dodając do crontaba poniższą regułę:

# 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: Serwery, które nie hostują stron opartych na WordPress

Jeśli serwer nie obsługuje WordPressa, to próba otwarcia plików konfiguracyjnych, kopii zapasowych baz danych, czy plików środowiskowych itp., jest ewidentną próbą kradzieży poświadczeń (credentials) lub rekonesans przed atakiem.

Dopisanie ich do scenariusza typu „Honey-Pot” jest dobrym posunięciem, bo żaden normalny użytkownik ani robot Google nigdy nie będzie próbował pobrać pliku .env czy wp-config.php.bak itp.

Pancerna wersja filtra scenariusza wp-honeypot.yaml

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

Wklej poniższą zawartość

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/.*`
  )

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.

Edytuj plik: /etc/crowdsec/profiles.yaml

Znajdź sekcję decisions i dodaj (lub zmodyfikuj) profil na samej górze:

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

Konfiguracja logów (Acquisition)

ISPConfig tworzy logi stron WWW w ścieżkach typu /var/www/clients/clientX/webY/log/. Standardowy CrowdSec ich nie widzi.

Rozwiązanie: Musisz edytować plik /etc/crowdsec/acquis.yaml (lub dodać plik w /etc/crowdsec/acquis.d/), aby wskazać CrowdSecowi logi poszczególnych stron (tzw. wildcards).

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.

Konflikt z Fail2Ban

ISPConfig domyślnie instaluje i konfiguruje Fail2Ban.

Czy można mieć oba? Tak, mogą działać równolegle, ale to „masło maślane”.

Zalecenie: Jeśli decydujesz się na CrowdSec, po poprawnej konfiguracji warto wyłączyć Fail2Ban, aby zaoszczędzić zasoby procesora (Fail2Ban przy dużej ilości logów potrafi mocno obciążyć system).

Podsumowanie

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

Oto zestawienie najważniejszych i najczęściej używanych komend narzędzia cscli (CrowdSec Command Line Interface), które pozwolą Ci sprawnie zarządzać bezpieczeństwem Twojego serwera:

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.