Każda publicznie dostępna instalacja WHMCS jest bombardowana próbami logowania brute-force w ciągu kilku godzin od uruchomienia. Fail2ban monitoruje Twoje logi, wykrywa powtarzające się niepowodzenia i automatycznie blokuje atakujące adresy IP. Ten przewodnik konfiguruje go dla WHMCS (oraz stosu SSH + web wokół niego) na Ubuntu.

Wymagania wstępne

  • Ubuntu 22.04 z dostępem root
  • WHMCS działający za nginx lub Apache
  • Włączone logowanie aktywności WHMCS (jest domyślnie)

Krok 1 — Zainstaluj Fail2ban

apt update
apt install -y fail2ban
systemctl enable fail2ban

Krok 2 — Utwórz lokalną konfigurację celu (jail)

Nigdy nie edytuj bezpośrednio jail.conf (aktualizacje go nadpiszą). Utwórz /etc/fail2ban/jail.local:

[DEFAULT]
# Zablokuj na 1 godzinę po 5 niepowodzeniach w ciągu 10 minut
bantime  = 3600
findtime = 600
maxretry = 5
# Ignoruj własne adresy IP (biuro, dom, monitoring)
ignoreip = 127.0.0.1/8 ::1 YOUR.OFFICE.IP

[sshd]
enabled = true
port    = 2222

Dostosuj port do swojego rzeczywistego portu SSH i dodaj swoje statyczne adresy IP do ignoreip, aby nigdy się nie zablokować.

Krok 3 — Włącz eskalujące blokady dla recydywistów

Cel recidive blokuje adresy IP, które powracają po wygaśnięciu ich pierwszej blokady — na znacznie dłużej:

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
banaction = iptables-allports
bantime  = 604800   ; 1 tydzień
findtime = 86400    ; 1 dzień
maxretry = 3

Krok 4 — Utwórz filtr WHMCS

WHMCS loguje nieudane logowania administratorów do swojej bazy danych, ale także zapisuje je do logu serwera WWW przy powtarzających się próbach. Najczystszym podejściem jest filtr na własnym logu nieudanych logowań WHMCS. Najpierw skieruj WHMCS na plik logu — lub parsowanie logu dostępu do sieci dla punktu końcowego logowania.

Utwórz /etc/fail2ban/filter.d/whmcs.conf:

[Definition]
# Dopasowuje nieudane żądania POST logowania admina/klienta powracające do strony logowania
failregex = ^<HOST> .* "POST /(dologin|admin/login)\.php.* 200
            ^<HOST> .* "POST /index\.php\?rp=/login.* 200
ignoreregex =

To jest wzorzec początkowy — dostosuj failregex do struktury URL i szablonu Twojego WHMCS. Kluczem jest dopasowanie żądania POST logowania z adresu IP klienta.

Krok 5 — Dodaj cel WHMCS

Dodaj do /etc/fail2ban/jail.local:

[whmcs]
enabled  = true
port     = http,https
filter   = whmcs
logpath  = /var/log/nginx/access.log
maxretry = 5
findtime = 600
bantime  = 7200

Skieruj logpath na rzeczywisty log dostępu nginx/Apache dla vhosta WHMCS.

Krok 6 — Uważaj na problem z prawdziwym IP

Jeśli WHMCS znajduje się za CDN lub reverse proxy, Twój log dostępu pokazuje IP CDN, a nie IP odwiedzającego — Fail2ban zablokowałby CDN i wyłączył całą Twoją witrynę.

Napraw to w nginx, przywracając najpierw prawdziwy adres IP. Dla SprintCDN lub Cloudflare, dodaj ich zakresy do konfiguracji prawdziwego IP:

# /etc/nginx/snippets/realip.conf
set_real_ip_from 1.2.3.0/24;   # zakresy Twojego CDN
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Dołącz to do swojego bloku serwera i upewnij się, że format logu używa $remote_addr (który teraz odzwierciedla prawdziwego klienta). Tylko wtedy Fail2ban zablokuje właściwy adres IP.

Krok 7 — Uruchom i zweryfikuj

systemctl restart fail2ban
fail2ban-client status

Powinieneś zobaczyć swoje aktywne cele (jails): sshd, recidive, whmcs. Sprawdź konkretny cel:

fail2ban-client status sshd

To pokazuje aktualnie zablokowane adresy IP i ich całkowitą liczbę.

Krok 8 — Przetestuj działanie

Z jednorazowego adresu IP (telefon z danymi mobilnymi zadziała), celowo nieudanie zaloguj się do SSH lub WHMCS 6 razy. Następnie na serwerze:

fail2ban-client status sshd
# Powinien wyświetlić testowy adres IP w sekcji "Banned IP list"
iptables -L -n | grep <TEST_IP>

Odblokuj go po zakończeniu:

fail2ban-client set sshd unbanip <TEST_IP>

Krok 9 — Otrzymuj powiadomienia o blokadach (opcjonalnie)

Fail2ban może wysyłać Ci e-maile o każdej blokadzie. W jail.local pod [DEFAULT]:

destemail = you@yourdomain.com
sender    = fail2ban@yourdomain.com
action    = %(action_mwl)s

action_mwl = blokada + e-mail z informacjami whois + linie logów, dzięki czemu uzyskujesz kontekst, kto atakuje.

Warstwowa obrona

Fail2ban zajmuje się warstwą aplikacji, ale ataki wolumetryczne (ktoś rzucający 50 Gbit/s na Twoją stronę logowania) wymagają obrony na poziomie sieci. Na Hostfory, ochrona przed DDoS absorbuje warstwę wolumetryczną, zanim dotrze ona do Twojego serwera, a Fail2ban zajmuje się inteligentnymi, niskowolumetrycznymi atakami brute-force, które się przedostaną. Używaj obu.

Rozwiązywanie problemów

Fail2ban nikogo nie blokuje: Twój failregex nie pasuje do linii logów. Przetestuj to: fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/whmcs.conf. Pokazuje, ile linii zostało dopasowanych.

Fail2ban zablokował mój CDN / całą moją bazę użytkowników: problem z prawdziwym IP z Kroku 6. Odczytujesz adres IP proxy. Napraw przywracanie prawdziwego IP przed ponownym włączeniem.

Zablokowałeś się: jeśli masz dostęp do konsoli/IPMI (dostępny na wszystkich serwerach dedykowanych Hostfory), zaloguj się w ten sposób i dodaj swój adres IP do ignoreip. Dlatego IPMI jest ważne.

Co dalej

Połącz to z tunelem zarządzania WireGuard, aby SSH nie było publicznie dostępne, i ogranicz ścieżkę administratora WHMCS do adresu IP Twojego biura na poziomie nginx. Głęboka obrona przewyższa każdą pojedynczą kontrolę.