fail2ban – sposób na hakera

Fail2ban od Wireflare to genialne narzędzie, aby zbanować potencjalnych „hakierów” na własnym serwerze.

Sam używam WordPressa (co chyba widać) i nieraz zastanawiałem się jakiej tu wtyczki użyć, żeby tych „baranów” jakoś ukrócić. No ale przecież instalacja dodatkowej wtyczki, blokująca dostęp takiemu atakującemu, to też jest skrypt, który musi być przetworzony przez nasz serwer. Zużyje część zasobów, pamięci, czasu procesora, itd…

Aby skutecznie zabezpieczyć się przed atakami do zaplecza naszego bloga, witryny czy jakkolwiek nazwiemy naszą stronę, wystarczy doinstalować naprawdę banalnie malutką wtyczkę o nazwie „fail2ban” firmy Wireflare.

Teraz UWAGA!
Ten wpis powstał 19 Lutego 2017 roku, więc jak zapewne się domyślasz, mogło się coś już pozmieniać

Odsyłam do aktualnych źródeł, które od dłuższego czasu rozwijają się na GitHub’ie, a dokładnie pod tym linkiem:

https://github.com/fail2ban/fail2ban

Konkretnie napisana instrukcja instalacji oraz konfiguracji kryje się pod tym linkiem:

https://github.com/fail2ban/fail2ban/blob/master/README.md

Wtyczkę znajdziemy w repozytoriach WP, a dla dociekliwych podaję oficjalnego linka do tego zasobu:

https://pl.wordpress.org/plugins/wp-fail2ban/

Fail2ban jest narzędziem działającym kompleksowo, więc zabezpieczy nie tylko samego WordPressa, ale i wiele usług zainstalowanych na naszym serwerze. Jest na tyle popularny, że jego implementacje znajdziemy dla wielu popularnych CMS’ów, jak Joomla, Drupal i innych.

Dobra, ale jedna bardzo ważna sprawa, fail2ban zadziała tylko na samodzielnie stojących serwerach. Jeśli masz wykupiony hosting u szanujących się firm tego typu, to nie musisz się tym przejmować, bo Oni martwią się za Ciebie (a właściwie to o siebie samych).

Opisuję tutaj konfigurację dla serwera Ubuntu / Debian (choć inne distro wiele się chyba nie będą różniły pod kontem konfiguracji), a do napisania go skłoniła mnie przymuszona nieco aktualizacja z Ubuntu 14,04 na 16.04, po której demon fail2ban odmówił mi posłuszeństwa… To jednak zmotywowało mnie do modernizacji sprzętu i konfiguracji.

Ale przejdźmy może jednak do konfiguracji.

Dla tych, co chcą sobie poczytać u źródeł, odeślę was do stron, z których skorzystałem:

• https://www.bjornjohansen.no/using-fail2ban-with-wordpress
• https://wireflare.com/blog/wordpress-login-security-fail2ban/
• https://wireflare.com/blog/permanently-ban-repeat-offenders-with-fail2ban/

Mając swój własny serwer (na czas pisania tego artykułu był to jeszcze „Ubuntu 16.04.1 LTS”, a nowy Debian 8.6 Jessie już czekał na podmianę na nowszych bebechach), trzeba by było zacząć od zainstalowania paczki:

apt-get install fail2ban

Następny krok: konfiguracja.

Na początek proponuję gdzieś na boku zrobić sobie kopię tych standardowych plików konfiguracyjnych. Będzie przynajmniej do czego wrócić, jeśli spierniczymy configi i usługa nie będzie się nam podnosić…

Plik /etc/fail2ban/jail.local odpowiedzialny jest za kilka parametrów. Z ważniejszych są:

• ignoreip – tutaj podajemy adresy IP, których nie będziemy / nie chcemy banować.
• bantime – określamy czas bana w sekundach! (domyślnie jest to 10 minut).
• maxretry – tutaj określamy ilość prób, zanim ban zostanie nałożony na adres IP (domyślne są 3).
• destemail – adres e-mail, gdzie będą przychodzić powiadomienia (dla mnie zbędne, i tak mam dużo takiego „spamu”)
• logpath – ważny parametr każdej monitorowanej usługi, czyli ścieżka do pliku logów !!!musi być prawidłowa!!!

Zatem jeśli chcemy zmienić ustawienia, którejś z monitorowanych usług, to zmieniamy (tu przykład z SSH):

[ssh] -> nazwa jaila
enabled = true -> włączony, jeśli wyłączony to disabled = false
port = ssh -> port usługi - przyjmuje wartość numeryczną lub nazwę portu, listę portów znajdziesz w pliku /etc/services
filter  = sshd -> pierwszy człon nazwy filtra logów: /etc/fail2ban/filter.d/sshd.conf
logpath  = /var/log/auth.log -> ścieżka monitorowanych logów - tylko jedna wartość, ale dopuszczalna jest * czyli wszystkie
maxretry = 15 -> maksymalna ilość nieudanych prób autoryzacji

Ale teraz, myślę że dopiero zaczyna się zabawa.

Nie wystarczy tylko to zainstalować i jakoś tam skonfigurować. Fail2ban oferuje duuużo więcej. Zatem czas na tjuning

Od razu jeszcze na samym początku zalecam (wręcz nalegam) aby zmienić domyślnego demona od logów systemowych. W tym celu proponuję instalację „rsyslog„, który zastępuje podstawowy system logowania. W Debianie i opartych na nim dystrybucjach (np. Ubuntu) instalujemy go poleceniem:

apt-get install rsyslog

Żeby zabezpieczyć naszego WordPressa, dorzucamy kilka dodatkowych sekcji. Po pierwsze nie chcemy, żeby wszystkie próby logowania do panelu administracyjnego były wrzucane do ogólnego „syslog” (czy tam auth.log). Szkoda czasu procka i szukania igły w stogu siana. Oczywiście mogliśmy użyć auth.log lub innych wiadomości dziennika, ale analizowanie tych dzienników (jak już napisałem) wymagałoby większego użycia mocy obliczeniowej procesora, a przecież chcemy, aby ten nasz demon nie przeszkadzał, jak to tylko możliwe. Konfigurujemy zatem nasz plik „rsyslog.conf” (zazwyczaj w katalogu /etc), i na jego końcu dopisujemy następujące linie:

# Zachowuje błędne próby logowania do WP do loga dla Fail2Ban
local1.*  /var/log/wp_f2b.log

Mamy teraz stworzoną regułę dla prób logowania, która wyrzuci je nam do osobnego pliku loga.

touch /var/log/wp_f2b.log

Restartujemy syslog:

service rsyslog restart

Na tym etapie warto sprawdzić, czy próby błędnego logowania są logowane do tego pliku. Zatem zaloguj się nieprawdziwym loginem lub hasłem na swojego WordPressa i w tym nowo utworzonym pliku powinno się coś pojawić.

Teraz czas na stworzenie filtra w fail2ban. .

nano /etc/fail2ban/jail.local

dodajemy:

[wordpress]

enabled = true
filter = wordpress
action = %(action_)s
#action = iptables-multiport[name=WordPress, port="http,https"]
logpath = /var/log/wp_f2b.log
maxretry = 5
findtime = 750
bantime = 72000

Dostosuj sobie odpowiednio parametry „maxretry”, „findtime” oraz „bantime”. Drugim artykułem opisałem efekt końcowy wraz z banowaniem „długodystansowym” (dla upierdliwych hostów), ale o tym napisałem w osobnym artykule: Fail2Ban – RepeatOffender

Teraz filtr dla WordPressa:

nano /etc/fail2ban/filter.d/wordpress.conf

z zawartością:

# Fail2Ban configuration file
#
# Author: WireFlare
#
[INCLUDES]
before = common.conf
[Definition]
_daemon = wordpress
failregex = ^%(__prefix_line)sWordpress authentication failure for .* from <HOST>$
ignoreregex =

Przeładowujemy i restartujemy usługę fail2ban:

service fail2ban reload
service fail2ban restart

Tak, tak, wystarczyło by tylko „restart”, ale spotkałem się z pewnymi przeciwnościami, więc użycie obu poleceń nie zaszkodzi. Czy wszystko działa, możemy sprawdzić za pomocą polecenia:

fail2ban-regex /var/log/wp_f2b.log /etc/fail2ban/filter.d/wordpress.conf

Ostatnią rzeczą, nad którą warto się zastanowić, to wielkość logów, które te świństwa nam wygenerują, więc warto ustawić logrotate, co czynimy edytując plik:

nano /etc/logrotate.conf

i na końcu pliku dopisujemy:

/var/log/wp_f2b.log {
    size 30k
    create 0600 root root
    rotate 5
}

Od teraz bezpieczeństwem naszego WordPressa zajmuje się Fail2Ban

Wszelkie komentarze poprawiające moje niedociągnięcia, bądź błędy merytoryczne, naprawdę są mile widziane. Wszystko po to, abym mógł poprawić własne wypociny i jednocześnie abym nie wprowadzał nikogo w błąd.