WordPress/Joomla/404 + Fail2Ban = Ochrona przed brute force attacks

O samym fail2ban już pisałem przy okazji postfix-a. Teraz czas przyszedł na WordPress i Joomle oraz inne dziwne wynalazki :)

Oczywiście fail2ban musi być zainstalowany :)

apt-get install fail2ban

To na początek. W przypadku obu skryptów musimy dodać odpowiednie dodatki które nam do logów wyplują info o nie udanej próbie logowania. Tak więc:

Joomla: http://extensions.joomla.org/extension/fail2ban
oraz
WordPress: https://pl.wordpress.org/plugins/wp-fail2ban/

Ważna informacja. Domyślnie plugin WordPress-a info leci do /var/log/auth.log natomiast plugin Joomli error.log danego virtualnego serwera, najmniej w moim przypadku tak było.

1. Joomla

edytujemy plik /etc/fail2ban/jail.conf

vi /etc/fail2ban/jail.conf

Dodajemy wpis:

[joomla-error]
enabled = true
port = http,https
filter = joomla-error
logpath = /web/*/log/error.log
maxretry = 1

Musimy dopasować logpath, w moim przypadku ma czytać z * czyli każdego podkatalogu plik error.log znajdujący się w podkatalogu log. Parametr maxretry to już mówi sam za siebie :) – dopasować też trzeba pod siebie

Teraz musimy utworzyć filtr:

vi /etc/fail2ban/filter.d/joomla-error.conf

wrzucamy:

[Definition]
failregex = [[]client []] .* user .* authentication failure.*

ignoreregex =

wsio :)

2. WordPess

Ponownie idziemy do edycji konfiguracji jail-a.

vi /etc/fail2ban/jail.conf

dodajemy:

[wordpress]
enabled = true
filter = wordpress
logpath = /var/log/auth.log
maxretry = 3
port = http,https

Następnie dorzucamy filtry:

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

jak poniżej:

# Fail2Ban configuration file
#
# Author: Charles Lecklider
#

[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# common.local
before = common.conf


[Definition]

_daemon = wordpress

# Option:  failregex
# Notes.:  regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P[\w\-.^_]+)
# Values:  TEXT
#
failregex = ^%(__prefix_line)sAuthentication failure for .* from $

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

Opis tego też znajduje się w plugin-ie.

3. Coś extra

Zdarza się, co miałem ostatnio, iż boty latały po stronie i szukały admina lub phpmyadmina w root strony lub w w kombinacji z url co dawało 404. Na takie zachowanie też jest prosta metoda, co znalazłem jakiś czas temu na gicie i lekko coś dodałem od siebie.

Więc idziemy do edycji konfiguracji i dorzucamy:

[apache-nokiddies]
enabled  = true
port     = http,https
filter   = nokiddies
logpath  = /web/*/log/access.log
maxretry = 1

Tutaj widać, że badany jest access.log witryny.

Tworzymy filtr:

vi /etc/fail2ban/filter.d/nokiddies.conf

i dodajemy:

[Definition]
failregex = ^ .*"GET .*w00tw00t
# try to access to admin directory
            ^ .*"GET .*admin.* 403
            ^ .*"GET .*admin.* 404
            ^ .*"GET .*administrator.* 404
            ^ .*"GET .*administrator.* 200
# try to access to install directory
            ^ .*"GET .*install.* 404
# try to access to phpmyadmin
            ^ .*"GET .*dbadmin.* 404
            ^ .*"GET .*myadmin.* 404
            ^ .*"GET .*MyAdmin.* 404
            ^ .*"GET .*mysql.* 404
            ^ .*"GET .*websql.* 404
            ^ .*"GET \/pma\/.* 404
# try to access to wordpress (we use another CMS)
            ^ .*"GET .*wp-content.* 404
            ^ .*"GET .*wp-login.* 404
# try to access to typo3 (we use another CMS)
            ^ .*"GET .*typo3.* 404
# try to access to tomcat (we do not use it)
            ^ .*"HEAD .*manager.* 404
# try to access various strange scripts and malwares
            ^ .*"HEAD .*blackcat.* 404
            ^ .*"HEAD .*sprawdza.php.* 404

ignoreregex =

I wrzucam link do oryginału :) co by nie było: https://github.com/miniwark/miniwark-howtos/wiki/Fail2Ban-setup-for-Apache.

Wszystko :)