fail2ban – block wp-login.php brute force attacks

Lately I had a lot of brute force attacks on my WordPress blog. I used basic auth to /wp-admin part in nginx configuration to block this and as a better solution I wan't to block source IPs at all on firewall.

To do this, place this filter code in /etc/fail2ban/filter.d/wp-login.conf:

# WordPress brute force wp-login.php filter:
#
# Block IPs trying to authenticate in WordPress blog
#
# Matches e.g.
# 178.218.54.109 - - [31/Dec/2015:10:39:34 +0100] "POST /wp-login.php HTTP/1.1" 401 188 "-" "Mozilla/5.0 (Windows NT 6.0; rv:34.0) Gecko/20100101 Firefox/34.0"
#
[Definition]
failregex = ^<HOST> .* "POST /wp-login.php
ignoreregex =

Then edit your /etc/fail2ban/jail.local and add:

[wp-login]
enabled   = true
port      = http,https
filter    = wp-login
logpath   = /var/log/nginx/access.log
maxretry  = 3

Now restart fail2ban:

service fail2ban restart

All done 馃檪

fail2ban – regu艂ki dla dovecot’a

Domy艣lna konfiguracja fail2ban’a (na Debianie) nie zawiera regu艂 pozwalaj膮cych na blokowanie pr贸b w艂ama艅 na skrzynki POP/IMAP dla dovecota (no chyba 偶e korzystamy z saslauthd). Mo偶na szybko utworzy膰 w艂asny zestaw filtr贸w co przedstawi臋 poni偶ej.

Tworzymy plik:聽/etc/fail2ban/filter.d/dovecot.conf

[Definition]
failregex = (?: pop3-login|imap-login): .*(?:Authentication failure|Aborted login \(auth failed|Aborted login \(tried to use disabled|Disconnected \(auth failed|Aborted login \(\d+ authentication attempts).*rip=(?P<host>\S*),.*
ignoreregex =

P贸藕niej dopisujemy na ko艅cu pliku:聽/etc/fail2ban/jail.conf

[dovecot]
enabled  = true
filter   = dovecot
port     = pop3,pop3s,imap,imaps
logpath  = /var/log/mail.log
maxretry = 20
# te dwa poni偶ej wedle uznania - ja mam dobrze ustawione default'y
#findtime = 1200
#bantime  = 1200

Zosta艂o zrestartowa膰 fail2ban’a:

invoke-rc.d fail2ban restart

Tip na bazie dokumentacji:聽http://wiki.dovecot.org/HowTo/Fail2Ban

Ochrona us艂ug przed atakami brute force z fail2ban’em

Bardzo cz臋sto konfiguruj膮c us艂ugi dost臋pne publicznie po艣wi臋ca si臋 sporo czasu na maksymalne zwi臋kszenie bezpiecze艅stwa przez “dopieszczanie” konfiguracji (certyfikaty z mocnym szyfrowaniem, ochron臋 pewnych stron has艂em, dost臋p do SSH tylko kluczami, itd.) ale ca艂kowicie pomija si臋 przygotowanie systemu aktywnie monitoruj膮cego b艂臋dne pr贸by autoryzacji. Oczywi艣cie nie mo偶na umniejsza膰 wagi pierwszego z wymienionych etap贸w ale zdecydowanie nie powinno pomija膰 si臋 te偶 tego drugiego. Przecie偶 ka偶dy admin chcia艂by wiedzie膰 gdy kto艣 pr贸buje w艂ama膰 si臋 na jego serwer (FTP, HTTP, SSH, itp.) – tylko ilu z Nas zadaje sobie trud by uruchomi膰 taki system?

Wielu z nas uwa偶a 偶e przygotowanie takiego mechanizmu jest zbyt pracoch艂onne, trudne, nie teraz, nie mam czasu, itd…. Zapominamy przy tym 偶e gotowy system zostanie oddany w r臋ce u偶yszkodnik贸w a Ci na pewno b臋d膮 z niego korzysta膰 wbrew wszelkim zasadom bezpiecze艅stwa 馃槈

Na przyk艂ad taki Roman z loginem romek ustawi has艂o do poczty abc123 – wirusy i boty zamiast pr贸bowa膰 艂ama膰 has艂o jednego usera bardzo cz臋sto pr贸buj膮 wbi膰 si臋 na popularne loginy wykorzystuj膮c proste has艂a – zaskakuj膮ce jak cz臋sto si臋 im to udaje. A p贸藕niej Roman ma pretensje do admina 偶e jego znajomi dostali po 10000 maili z wirusami…

Tymczasem w wielu przypadkach wystarczy fail2ban w praktycznie podstawowej konfiguracji by ochroni膰 typowe us艂ugi przed:

  • atakami brute force jak w powy偶szym przyk艂adnie (SSH, Apache, vsftpd, proftpd, Postfix, SASL Auth, etc),
  • atakiem pocztowego bot netu (blokowanie host贸w generuj膮cych du偶膮 ilo艣膰 b艂臋d贸w),
  • z艂ymi crawler’ami czy narz臋dziami skanuj膮cymi strony WWW,
  • ataki flood na Bind DNS.

Narz臋dzie napisane jest w Perl’u i dzia艂a jako demon zapisuj膮c dane z syslog’a w ma艂ych paczkach i okresowo uruchamiaj膮c testy sprawdzaj膮ce – wp艂ywa to korzystnie na wydajno艣膰 (bo nie musi analizowa膰 ca艂odniowych log贸w jak prymitywniejsze narz臋dzia). Modu艂owa konfiguracja pozwala 艂atwo doda膰 filtry (wykrywaj膮ce niezdefiniowane w standardzie zdarzenia) lub akcje (np. zamiast wycina膰 spam bota przez iptables mo偶na go wrzuci膰 do naszego prywatnego RBL’a). W innym po艣cie poda艂em przyk艂ad dodania regu艂 dla dovecot’a.

Pomimo i偶 narz臋dzie wydaje si臋 zbytnio nie obci膮偶a膰 systemu to raczej nie odwa偶y艂bym si臋 go zainstalowa膰 na mocno obci膮偶onym serwerze, gdzie generuj膮 si臋 miliony linii log贸w dziennie. W takiej sytuacji potrzebne jest inne rozwi膮zanie.

Instalacja

W moim przypadku na Debianie leci to typowo:

apt-get install fail2ban

Aplikacj臋 mo偶na te偶 do艣膰 艂atwo zainstalowa膰 ze 藕r贸de艂 – zalezno艣ci nie ma zbyt du偶o.

Konfiguracja

Gdy ju偶 zainstalujemy fail2ban’a otwieramy g艂贸wny plik konfiguracyjny /etc/fail2ban/jail.conf. Id膮c od pocz膮tku warto zainteresowa膰 si臋 opcjami:

# poni偶ej nale偶y umie艣ci膰 list臋 adres贸w IP, sieci CIDR, z kt贸rych
# chcemy ignorowa膰 zagro偶enia
ignoreip = 127.0.0.1 10.3.4.0/24

# domy艣lny czas BAN'a - mo偶na nadpisa膰 w konfiguracji danej us艂ugi
bantime  = 36000

# domy艣lna ilo艣膰 wykrytych akcji, po kt贸rych zostanie dojdzie
# do BAN'a
maxretry = 3

# adres osoby, kt贸ra ma by膰 informowana o na艂o偶eniu/zdj臋ciu BAN'a
destemail = moj@mail.pl

# domy艣lna akcja, predefiniowane s膮 3 mo偶liwo艣ci:
# action_    - tylko BAN
# action_mw  - BAN i powiadomienie mailem z danymi WHOIS
# action_mwl - jak wy偶ej plus linie z loga
action = %(action_mwl)s

Dalej w konfigu znajduj膮 si臋 przygotowane definicje poszczeg贸lnych us艂ug i ich konfiguracja, np. SSH:

[ssh]
enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 5
bantime = 3600

[ssh-ddos]
enabled = true
port    = ssh
filter  = sshd-ddos
logpath  = /var/log/auth.log
maxretry = 6

Jak wspomina艂em wcze艣niej w danym bloku mo偶na wpisa膰 inne ni偶 domy艣lne warto艣ci dla opcji bantime i maxretry. Opcja filter wskazuje na nazw臋 pliku z definicj膮 filtru, np:聽/etc/fail2ban/filter.d/sshd.conf. W tej lokalizacji mo偶emy dodawa膰 te偶 w艂asne filtry, trzeba tylko zna膰 wyra偶enia regularne. W opcji port mo偶emy zmieni膰 port, na kt贸rym dzia艂a us艂uga (by banowanie dzia艂a艂o), korzystaj膮c przy tym z nazw dost臋pnych w pliku /etc/services lub bezpo艣rednio wpisuj膮c numer portu.

Domy艣lnie nie jest w艂膮czona ochrona 偶adnej z us艂ug. By j膮 w艂膮czy膰 nale偶y zmieni膰 w stosownym bloku:

enabled = false

na:

enabled = true

i prze艂adowa膰 fail2ban’a:

invoke-rc.d fail2ban restart

I na pocz膮tek wystarczy. W kilku banalnych krokach uruchomili艣my system monitoruj膮cy logi i blokuj膮cy pr贸by w艂ama艅.

Oczywi艣cie w艂膮czaj膮c ochron臋 danej us艂ugi dobrze zapozna膰 si臋 z regu艂ami zapisanymi w danym filtrze – by nie by膰 zaskoczonym gdy sypnie mailami 馃槈

Wy艂膮czenie powiadamiania o starcie fail2ban’a

Je偶eli w艂膮czymy powiadamianie mailem o banach jako gratis fail2ban b臋dzie powiadamia膰 nas mailem o w艂aczeniu i wy艂膮czeniu ochrony dla ka偶dej z us艂ug – na wypadek gdyby kto艣 bez naszej wiedzy zechcia艂 go wy艂膮czy膰. Dla wielu mo偶e to by膰 irytuj膮ce zachowanie.

By wy艂膮czy膰 powiadomienia trzeba w聽pliku akcji – u mnie w:聽/etc/fail2ban/action.d/mail-whois-lines.conf聽wyczy艣ci膰 opcje actionstart i actionstop by wygl膮da艂y jak poni偶ej:

actionstop =
actioncheck =