Защита админки wordpress с помощью fail2ban

Для организации простенькой защиты от ботов, которые постоянно проверяют на прочность вашу wordpress админку, быстрее всего настроить fail2ban. Это многофункциональное и эффективное средство для защиты сервисов от постороннего доступа. Рассмотрим его применительно к wordpress.

Введение

В интернете постоянно пасутся стада ботов, проверяющие доступ к тем или иным сервисам. Чаще всего это боты очень простые, они просто подбирают по словарю доступ к ресурсам. Иногда они используют известные уязвимости.

Так как wordpress самый популярный движок для сайта, пробовать его на прочность будут регулярно. Если у вас постоянно обновляется версия и уникальный пароль, которого нет в словарях, то вам скорее всего беспокоиться не о чем.

Fail2ban какой-то уникальной защиты не предоставляет.

Лично я предпочитаю обезопасить себя на всякий случай и закрыть доступ к админке wordpress от слишком назойливых глаз. Будем анализировать лог web сервера и банить всех тех, кто более 3-х раз ввел неверный пароль на доступ к внутренностям сайта.

Я буду показывать настройку fail2ban на примере CentOS 7, но версия ОС тут не имеет принципиального значения. Все настройки самого сервиса подойдут и для других систем.

Установка fail2ban в CentOS 7

Первым делом установим fail2ban в систему с помощью yum. Тут ничего сложного, все как обычно.

# yum -y install fail2ban

Если у вас Debian/Ubuntu, воспользуйтесь командой apt-get install fail2ban.

Настройка fail2ban

Теперь необходимо отредактировать файл настроек, добавив туда информацию о нашем сайте wordpress. Открываем /etc/fail2ban/jail.conf и добавляем в самый конец:

# mcedit /etc/fail2ban/jail.conf [wp-login] enabled = true port = http,https action = iptables[name=WP, port=http, protocol=tcp] # включаем отправку оповещения на почту, если вам это необходимо sendmail[name=wp-login, [email protected], [email protected]] filter = wp-login logpath = /web/sites/serveradmin.ru/log/access.log maxretry = 3

enabled	включаем секцию
port	порты, которые будут забанены
action	действие, которое будет выполняться, в данном случае включается блокировка iptables и отправляется оповещение, но может быть указано что-то одно
filter	название фильтра, по которому будет проходить проверка
logpath	путь до лог файла, которые будет анализироваться
maxretry	количество срабатываний фильтра, после которого хост будет забанен

Дальше нужно создать фильтр, который мы указали ранее. Создаем новый фильтр:

# mcedit /etc/fail2ban/filter.d/wp-login.conf [Definition] failregex = ^ .* “POST /wp-login.php

Сохраняем его и проверяем работу фильтра:

# fail2ban-regex /web/sites/serveradmin.ru/log/access.log /etc/fail2ban/filter.d/wp-login.conf

У меня получилось 240 срабатываний фильтра на этом лог файле. Если вы хотите увидеть строки, которые пометил фильтр, то можете запустить эту же команду с ключом:

–print-all-matched

Запускаем сервис и добавляем в автозагрузку:

# systemctl start fail2ban # systemctl enable fail2ban

На этом все, защита админки wordpress с помощью fail2ban настроена.

Проверка работы

На всякий случай проверьте в /etc/fail2ban/fail2ban.conf куда будут складываться логи сервиса. За них отвечает параметр:

logtarget = /var/log/fail2ban.log

Убедитесь, что у вас настроена ротация этого файла. В CentOS 7 для этого нужно проверить, что в папке /etc/logrotate.d есть файл fail2ban примерно следующего содержания:

/var/log/fail2ban.log { rotate 7 missingok compress postrotate /usr/bin/fail2ban-client flushlogs 1>/dev/null || true endscript }

Во время работы автобана в лог файле будут появляться примерно такие строки:

2015-12-15 16:57:27,878 fail2ban.filter [12814]: INFO [wp-login] Found 188.138.220.43 2015-12-15 17:00:29,738 fail2ban.filter [12814]: INFO [wp-login] Found 188.138.220.43 2015-12-15 17:03:03,292 fail2ban.filter [12814]: INFO [wp-login] Found 185.93.187.31 2015-12-15 17:03:29,419 fail2ban.filter [12814]: INFO [wp-login] Found 188.138.220.43 2015-12-15 17:03:30,184 fail2ban.actions [12814]: NOTICE [wp-login] Ban 188.138.220.43 2015-12-15 17:13:31,082 fail2ban.actions [12814]: NOTICE [wp-login] Unban 188.138.220.43

Проверить, забанены ли реально эти адреса можно посмотрев текущие правила iptables:

# iptables -L -v -n

Либо можно проверить статус командой:

# fail2ban-client status wp-login

Если вам нужно будет вручную кого-нибудь забанить, то можно воспользоваться командой:

# fail2ban-client set [name-of-jail] banip [ip-address]

Это в общем случае, в нашем случае команда будет выглядеть вот так:

# fail2ban-client set wp-login banip 188.138.220.43

Чтобы разбанить какой-нибудь адрес, поступаем следующим образом:

# fail2ban-client set wp-login unbanip 188.138.220.43

Заключение

Такая нехитрая и эффективная в некоторых случаях защита у нас получилась. Я в течении дня собираю около тысячи попыток залогиниться через wp-admin. Не все боты долбятся 3 раза подряд и попадают в бан. Я бы даже сказал, большая часть этого не делает.

Но они и не представляют опасности. Подобная этой настройка защитит в первую очередь от массового нашествия, которое способно серьезно замедлить работу сайта и хостинга в целом.

Закрытие доступа на уровне iptables очень эффективный способ сохранить ресурсы сервера.

Помогла статья? Есть возможность отблагодарить автора

Рекомендую полезные материалы по схожей тематике:

Источник: https://serveradmin.ru/nastroyka-fail2ban-dlya-zashhityi-wordpress/

Настройка fail2ban для защиты WordPress

Мы уже рассматривали плагин Limit Login Attempts, который защищает WordPress от перебора паролей. В этой статье мы рассмотрим альтернативный подход на системном уровне с помощью популярной программы fail2ban.

Обратите внимание, что данная статья нацелена на пользователей VPS хостинга и владельцев выделенных серверов. Для установки и настройки fail2ban вам потребуется root-доступ к вашему хостинг-аккаунту и базовые навыки системного администрирования.

Fail2ban

Fail2ban — это системная утилита, которая сканирует логи на определенные записи, и имеет возможность выполнять ряд действий при их обнаружении. Самый простой пример это сканирования журнала доступа по SSH к вашему серверу, и при обнаружении 5 неудачных попыток, заблокировать доступ по IP адресу.

Установить fail2ban на большинстве Linux-систем можно с помощью менеджера пакетов aptitude, apt-get, yum и т.д. На нашем тестовом сервере Ubuntu мы сделали это следующим образом:

$ sudo apt-get install fail2ban

После установки утилиты, вы найдете все ее конфигурационные файлы в директории /etc/fail2ban, включая директорию action.d для действий, и директорию filter.d для фильтров.

Фильтр в fail2ban это набор правил, по которым утилита будет искать определенные вхождения в лог-файлах. Примеры фильтров: попытка входа по SSH, попытка авторизации в Apache, попытка входа через FTP.

Действия в fail2ban запускаются тогда, когда фильтр сработал определенное количество раз. Действия тоже могут быть разными, например: блокировка IP адреса с помощью iptables, отправка оповещения на электронную почту администратору.

Основной файл который собирает все правила вместе в fail2ban называется jail.conf (тюрьма). Там прописываются фильтры и действия, максимальное количество попыток, время блокировки и многое другое. К этому файлу мы скоро вернемся.

WordPress и Fail2ban

Для того, чтобы fail2ban мог понять, что произошла неудачная попытка авторизации в WordPress, нам необходимо об этом явно сообщить со стороны самого WordPress. Сделать мы это можем с помощью простого плагина:

/** * Plugin Name: Return 403 on Failed Login */ function my_login_failed_403() { status_header( 403 ); } add_action( 'wp_login_failed', 'my_login_failed_403' );

По умолчанию WordPress использует HTTP код 200, даже при неудачных попытках авторизации, поэтому глядя на журнал доступа веб-сервера Apache или nginx, сложно сказать была ли попытка успешной. С помощью нашего простого плагина, мы используем код 403 для указания неуспешных попыток входа в WordPress.

После активации плагина убедитесь в том, что он действительно работает. Сделать это можно посмотрев на логи доступа вашего веб-сервера, например в /var/log/nginx/access.log для nginx, или /var/log/apache2/access.log для веб-сервера Apache.

Фильтр fail2ban для WordPress

Создайте новый фильтр в fail2ban (в директории filter.d) и назовите его wordpress-auth.conf. Данный фильтр будет выполнять поиск на 403 статус при доступе к файлам wp-login.php и xmlrpc.php в WordPress. Текст фильтра будет выглядеть следующим образом:

[Definition] failregex = .*POST.*(wp-login.php|xmlrpc.php).* 403

Данные регулярное выражение подойдет для лог-файлов Apache и nginx по умолчанию. Если вы изменили формат журнала вашего веб-сервера, вам придется изменить и регулярное выражение.

Настройка jail.conf

Новый фильтр wordpress-auth.conf легко использовать в файле конфигурации jail.conf. Добавьте следующий код в конец файла:

[wordpress] enabled = true port = http,https filter = wordpress-auth logpath = /var/log/nginx/access.log maxretry = 3 bantime = 3600

Здесь мы указываем путь к лог-файлу нашего веб-сервера, максимальное количество количество неудачных попыток авторизации, и время на которые IP адрес будет заблокирован (действие по умолчанию).

После внесения изменений в конфигурацию, перезапустите сервис fail2ban и смотрите его в действии в /var/log/fail2ban.log:

$ sudo service fail2ban restart $ sudo tail -f /var/log/fail2ban.log 2014-01-22 16:10:44,818 fail2ban.actions: WARNING [wordpress] Ban 115.230.126.74 2014-01-22 17:29:16,103 fail2ban.actions: WARNING [wordpress] Ban 185.24.218.83 2014-01-22 18:53:02,819 fail2ban.actions: WARNING [wordpress] Ban 222.186.62.71 …

Если вы решили протестировать fail2ban на себе, не забудьте установить низкое значение параметра bantime, например 60 для блокировки доступа на одну минуту.

Источник: https://wpmag.ru/2014/fail2ban-wordpress/

WP fail2ban

fail2ban is one of the simplest and most effective security measures you can implement to prevent brute-force password-guessing attacks.

WP fail2ban logs all login attempts – including via XML-RPC, whether successful or not, to syslog using LOG_AUTH. For example:

Oct 17 20:59:54 foobar wordpress(www.example.com)[1234]: Authentication failure for admin from 192.168.0.1
Oct 17 21:00:00 foobar wordpress(www.example.com)[2345]: Accepted password for admin from 192.168.0.1

WPf2b comes with two fail2ban filters, wordpress-hard.conf and wordpress-soft.conf, designed to allow a split between immediate banning and the traditional more graceful approach.

Features

CloudFlare and Proxy Servers

WPf2b can be configured to work with CloudFlare and other proxy servers. For an overview see WP_FAIL2BAN_PROXIES.

Comments

WPf2b can log comments. See WP_FAIL2BAN_LOG_COMMENTS.

Pingbacks

WPf2b logs failed pingbacks, and can log all pingbacks. For an overview see WP_FAIL2BAN_LOG_PINGBACKS.

Spam

WPf2b can log comments marked as spam. See WP_FAIL2BAN_LOG_SPAM.

User Enumeration

WPf2b can block user enumeration. See WP_FAIL2BAN_BLOCK_USER_ENUMERATION.

Work-Arounds for Broken syslogd

WPf2b can be configured to work around most syslogd weirdness. For an overview see WP_FAIL2BAN_SYSLOG_SHORT_TAG and WP_FAIL2BAN_HTTP_HOST.

Blocking Users

WPf2b can be configured to short-cut the login process when the username matches a regex. For an overview see WP_FAIL2BAN_BLOCKED_USERS.

mu-plugins Support

WPf2b can easily be configured as a must-use plugin – see Configuration.

Install via the Plugin Directory, or upload to your plugins directory.
Activate the plugin through the ‘Plugins’ menu in WordPress.
Edit wp-config.php to suit your needs – see Configuration.

This plugin is perfect, essencial – thank you so much

the best thing about this plugin after it works perfectly,
is that it does not change the directories nor names of the configuration files, something unpleasant that always happens in plugins, you configure everything for the given file, and a certain directory of the plugin and in a new version unnecessarily the plugin changes the things of place. this plugin I have a long time, and I have a command to copy and paste the w2 fail2ban plugin settings to fail2ban, and things continue as usual. Thanks to the developer. Who does not give 5 stars, does not know how to use it.

Great plugin, that worked first time. On Amazon Linux / Centos the location of the log file is /var/log/messages

Great idea if you host your own server and use fail2ban. Thanks!

Works just great with latest version. Keep up the good work.

Источник: https://wordpress.org/plugins/wp-fail2ban/

Защита от брутфорса WordPress, Joomla на шаред хостинге с помощью fail2ban

Понадобилось блокировать особо любопытных, написал пару правил.

Защита от брутфорса для сайтов на базе CMS WordPress:

Создадим файл с регексом для фильтрации попытки логина в админку:

# cat /etc/fail2ban/filter.d/bruteforce_wp.conf

[Definition]
failregex = ^ – – .* “POST /wp-login.php
ignoreregex =
Проверим сразу попадают ли запросы под наше правило:
# fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/bruteforce_wp.conf
Running tests
=============
Use failregex file : /etc/fail2ban/filter.d/bruteforce_wp.conf
Use log file : /var/log/nginx/access.log

Results
=======
Failregex: 122795 total
|- #) [# of hits] regular expression
| 1) [122795] ^ – – .* “POST /wp-login.php
`-
Ignoreregex: 0 total
Date template hits:
|- [# of hits] date format
| [790258] Day/MONTH/Year:Hour:Minute:Second
`-
Lines: 790258 lines, 0 ignored, 122795 matched, 667463 missed
Missed line(s): too many to print. Use –print-all-missed to print all 667463 lines Как видим, 123 тысячи запросов попадают под данное правило, а значит и будем блокировать таким способом.

И добавим секцию для нашего фильтра в jail.local:

# vim /etc/fail2ban/jail.local
[bruteforce_wp]
enabled = true
bantime = 3600
action = iptables-multiport[name=NoAuthFailures, port=”http,https”]
filter = bruteforce_wp
logpath = /var/log/nginx/access.log
maxretry = 5 Т.е. при 5 неправильных логинах залочим IP-адрес на час. Это должно успокоить особо активных.

Защита от брутфорса для сайтов на базе CMS Joomla:

Создадим фильтр:

# cat /etc/fail2ban/filter.d/bruteforce_joomla.conf

[Definition]
failregex = ^ – – .*/administrator/index.php
ignoreregex =

Проверим:
# fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/bruteforce_joomla.conf
Running tests
=============
Use failregex file : /etc/fail2ban/filter.d/bruteforce_joomla.conf
Use log file : /var/log/nginx/access.log

Results
=======
Failregex: 36528 total
|- #) [# of hits] regular expression
| 1) [36528] ^ – – .*/administrator/index.php
`-
Ignoreregex: 0 total
Date template hits:
|- [# of hits] date format
| [792266] Day/MONTH/Year:Hour:Minute:Second
`-
Lines: 792266 lines, 0 ignored, 36528 matched, 755738 missed
Missed line(s): too many to print. Use –print-all-missed to print all 755738 lines Теперь попадет 36 тысяч запросов.

И добавим секцию в jail.local:

# vim /etc/fail2ban/jail.local
[bruteforce_joomla]
enabled = false
bantime = 3600
action = iptables-multiport[name=NoAuthFailures, port=”http,https”]
filter = bruteforce_joomla
logpath = /var/log/nginx/access.log
maxretry = 5

После всех этих изменений перезапустим наш сервер fail2ban:

# /etc/init.d/fail2ban restart Проверим подгрузились ли наши фильтры:

# /etc/init.d/fail2ban status

fail2ban-server (pid 688487) выполняется…
Status
|- Number of jail: 3
`- Jail list: bruteforce_joomla, bruteforce_wp, ssh-iptables То, что надо 3 фильтра: ssh (по умолчанию), брутфорс WP и Joomla. Минут через 10 проверим эффективность для наших новых фильтров:

# fail2ban-client status bruteforce_wp

Status for the jail: bruteforce_wp
|- filter
| |- File list: /var/log/nginx/access.log
| |- Currently failed: 8
| `- Total failed: 22
`- action
|- Currently banned: 2
| `- IP list: 109.86.15.97 94.138.171.124
`- Total banned: 2

# fail2ban-client status bruteforce_joomla
Status for the jail: bruteforce_joomla
|- filter
| |- File list: /var/log/nginx/access.log
| |- Currently failed: 5
| `- Total failed: 1658
`- action
|- Currently banned: 4
| `- IP list: 134.249.50.47 79.148.245.79 94.153.8.248 109.86.15.95
`- Total banned: 4

Как видим, фильтры работают и за 10 минут успели заблокировать примерно 1700 запросов к админкам сайтов.

Источник: http://blog.asidorov.name/2014/12/wordpress-joomla-fail2ban.html

Fail2Ban, WordPress, iThemes Security – защита от брутфорса административной части WordPress

Есть масса более-менее успешных, простых или более сложных методик борьбы с брутфорсом паролей для входа в административную часть WordPress, которая обычно находится по адресу http://www.example.com/wp-login.php

Иногда случается так, что на этот скрипт поступает большое количество POST-запросов с перебором логинов и паролей с целью получения доступа в административную часть. Лучше, конечно, если эта часть защищена хотя бы капчей, которая создает уже заметное препятствие для ручного ввода. Однако в случае автоматизированного брутфорса процесс идет гораздо быстрей.

Здесь мы хотим привести одну, надеемся, полезную заготовку-шпаргалку по подавлению активности брутфорса с использованием связки Fail2Ban и модуля iThemes Security, который очень часто используется для обеспечения базовой безопасности сайта на WordPress. В настройках iThemes Security в разделе “Brute Force Protection” при этом надо включить локальную защиту от брутфорса. Если это сделано, то неудачные попытки отражаются в логах в виде 403 HTTP-кода (Forbidden).

При этом в логах веб-сервера можно видеть примерно такую картинку:

85.15.101.24 – – [02/Jun/2015:03:13:59 +0300] “POST /wp-login.php HTTP/1.0” 403 3794 “https://example.com/wp-login.php” “Mozilla/5.0 (Windows NT 6.0; rv:34.0) Gecko/20100101 Firefox/34.0”
89.22.161.64 – – [02/Jun/2015:03:14:01 +0300] “POST /wp-login.php HTTP/1.0” 403 2042 “https://example.com/wp-login.php” “Mozilla/5.0 (Windows NT 6.0; rv:34.0) Gecko/20100101 Firefox/34.0”
185.57.31.16 – – [02/Jun/2015:03:14:10 +0300] “POST /wp-login.php HTTP/1.0” 403 3794 “https://example.com/wp-login.php” “Mozilla/5.0 (Windows NT 6.0; rv:34.0) Gecko/20100101 Firefox/34.0”
195.128.92.242 – – [02/Jun/2015:03:14:11 +0300] “POST /wp-login.php HTTP/1.0” 403 3794 “https://example.com/wp-login.php” “Mozilla/5.0 (Windows NT 6.0; rv:34.0) Gecko/20100101 Firefox/34.0”
95.30.102.245 – – [02/Jun/2015:03:14:43 +0300] “POST /wp-login.php HTTP/1.0” 403 3794 “https://example.com/wp-login.php” “Mozilla/5.0 (Windows NT 6.0; rv:34.0) Gecko/20100101 Firefox/34.0”
176.122.108.243 – – [02/Jun/2015:03:14:43 +0300] “POST /wp-login.php HTTP/1.0” 403 2042 “https://example.com/wp-login.php” “Mozilla/5.0 (Windows NT 6.0; rv:34.0) Gecko/20100101 Firefox/34.0”
179.234.121.168 – – [02/Jun/2015:03:14:53 +0300] “POST /wp-login.php HTTP/1.0” 403 3794 “https://example.com/wp-login.php” “Mozilla/5.0 (Windows NT 6.0; rv:34.0) Gecko/20100101 Firefox/34.0”

Характерным паттерном является наличие 403-го статуса, что является указателем того, что iThemes Security добросовестно сделал свою работу.

Однако этого может быть мало и “долбежка” в административный интрефейс может продолжаться неконтролируемо долго. Это в свою очередь влечет за собой трату лишних серверных ресурсов на бесполезную нагрузку. Поэтому для окончательного устранения и блокирования таких попыток мы можем как раз и использовать Fail2Ban для забанивания ботов.

Для этого мы можем добавить в основной конфиг fail2ban следующую секцию правил с указанием на фильтр (wordpress-auth):

[wordpress-auth]
enabled = true
filter = wordpress-auth
port = http,https
logpath = /var/www/httpd-logs/*.log
maxretry = 2
findtime = 86400
bantime = 604800

В данном случае мы подключаем работу фильтра с названием wordpress-auth, который будет использоваться для мониторинга всех лог-файлов виртуальных хостов сервера на наличие паттерна, который нам необходим. В данном конфиге мониторятся все лог-файлы, так как на разных виртуальных хостах могут работать различные сайты под вордпресс.

Ну а далее, мы создаем, собственно сам фильтр в директории /etc/fail2ban/filter.d/ с названием wordpress-auth.conf:

%
# WordPress brute force auth filter: /etc/fail2ban/filter.d/wordpress-auth.conf:
#
# Block IPs trying to auth wp wordpress
#
# Пример: 403-й HTTP-код как раз и возникает по причине работы плагины WordPress Security
# 12.34.33.22 – [07/Jun/2014:11:15:29] “POST /wp-login.php HTTP/1.0” 403 4523
#
[Definition]
failregex = ^

В нем-то как раз и прописано условие фильтрации failregex = ^ .* “POST /wp-login.php HTTP/1.0” 403

С помощью этого условия, собственно говоря, и фильтруются IP-адреса, которые впоследствии блокируются.

Ну, и напоследок не забываем перезапустить Fail2Ban:

service fail2ban restart

Наконец, если это настроено, нам будут приходить уведомления от Fail2Ban о блокировке IP, который попал под данный фильтр:

Уведомление Fail2Ban о блокировке IP

Ну и напоследок, в логах fail2ban'а видим, что все идет именно так, как мы и ожидали:

2015-06-02 21:00:38,348 fail2ban.actions: WARNING [wordpress-auth] Ban 82.211.147.157
2015-06-02 21:01:03,856 fail2ban.actions: WARNING [wordpress-auth] Ban 85.142.26.224
2015-06-02 21:02:31,280 fail2ban.actions: WARNING [wordpress-auth] Ban 186.193.152.147
2015-06-02 21:04:56,389 fail2ban.actions: WARNING [wordpress-auth] Ban 193.251.10.65
2015-06-02 21:06:40,911 fail2ban.actions: WARNING [wordpress-auth] Ban 177.139.211.104
2015-06-02 21:07:49,938 fail2ban.actions: WARNING [wordpress-auth] Ban 87.117.9.164
2015-06-02 21:08:03,400 fail2ban.actions: WARNING [wordpress-auth] Ban 187.55.133.127

Полезные ссылки:

Источник: https://7u3.ru/blogs/admin/fail2ban-wordpress-ithemes-security-zashchita-ot-brutforsa-administrativnoy-chasti-wordpress.html

Защищаем WordPress от brutforce и других атак средствами fail2ban

WordPress — самая популярная CMS. Следовательно, и самая востребованная в плане осуществления атак. Достаточно появиться очередному сайту на wordpress, как тут же в логах побегут сообщения вроде:

91.200.12.28 – – [27/Sep/2017:00:33:33 +0300] “POST /wp-login.php HTTP/1.1” 200 3824 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0”
91.200.12.28 – – [27/Sep/2017:00:33:33 +0300] “POST /wp-login.php HTTP/1.1” 200 3824 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0”
91.200.12.28 – – [27/Sep/2017:00:33:33 +0300] “POST /wp-login.php HTTP/1.1” 200 3824 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0”
91.200.12.28 – – [27/Sep/2017:00:33:34 +0300] “POST /wp-login.php HTTP/1.1” 200 3824 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0”
91.200.12.28 – – [27/Sep/2017:00:33:36 +0300] “POST /wp-login.php HTTP/1.1” 200 3824 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0”

И даже если поставить хороший пароль на админку и попытки залогиниться бесконечное кол-во раз никак не ограничить, то как минимум сайт начнёт со временем висеть от большого кол-ва ботнетов, пробующих подобрать пароль на сайт.

Под WordPress существует огромное кол-во плагинов для защиты от хакерских атак. Но во-первых, эти средства будут работать с правами от которых работает wordpress. Во-вторых, это загромождает wordpress (а это сказывается на скорости и безопасности). В-третьих, такие плагины вряд ли будут гибко настраиваться.

Но плюсы плагинов в том, что обычно они начинают работать сразу при их активации (минимум мозговых и физических действий), плюс они спасут вас, если на сервере вы не имеете root-доступа.

Поговорим о защите, которая находится на более низком уровне, нежели wordpress.

Использование fail2ban

fail2ban — программа, позволяющая анализировать логи на определённые вхождения и задавать правила относительно того, что делать в случаях, когда лимиты с конкретного IP исчерпываются.

Для fail2ban существует огромное кол-во готовых правил, которые можно активировать через /etc/fail2ban/filter.d, скачать с оф. сайта, либо написать самостоятельно.

Ставим:

sudo apt install fail2ban
sudo systemctl enable fail2ban

Создаём файл /etc/fail2ban/filter.d/wordpress.conf с правилами для поиска вхождений:

[Definition]
failregex = ^ .* “POST .*wp-login.php ^ .* “POST .*xmlrpc.php
ignoreregex =

И файл /etc/fail2ban/jail.d/wordpress.conf:

[wordpress]
enabled = true
port = http,https
filter = wordpress
action = iptables-multiport[name=wordpress, port=”http,https”, protocol=tcp]
logpath = /var/log/httpd/access_log /var/log/apache2/access*log /var/log/nginx/*log
maxretry = 10
findtime = 600

где в logpath прописываем пути к логам веб-сервера (в том числе можно несколько и по маске), а maxretry — кол-во допустимых попыток.

Перезапускаем fail2ban:

sudo systemctl restart fail2ban

Всё, теперь если кто-то попробует брутфорсить админку, или сканить xmlrpc на наличие уязвимостей — попадёт в бан.

В заключение

Точно таким же способом можно проанализировать логи веб-сервера и написать с десяток других правил, направленных на поиск уязвимых мест в wordpress, поставив лимит и блокировку по IP, дабы вас не сканировали и не расходовали ценные ресурсы вашего сервера/wps, предоставив их пользователям ваших сайтов.

Источник: https://cryptopunks.org/article/wordpress_block_brutforce_attack_by_fail2ban/

Как защитить WordPress при помощи fail2ban

Постановка задачи

Как fail2ban сможет определить, что произошла неудачная попытка авторизации именно в WordPress? Для этого со стороны WordPress необходимо сообщить о наступлении этого события. По-умолчанию WordPress пишет в логи HTTP код 200, причём делает это даже при неудачных попытках авторизации.

По этой причине невозможно точно определить была ли авторизация успешной. При этом, неважно какой использовался веб-сервер Apache или nginx. О какой-то нездоровой активности могут поведать только многочисленные попытки авторизации запросы одной и той же страницы авторизации с одного ip.

Поэтому, для записи в логи кода 403 при неудачной попытке авторизации необходимо написать следующий плагин.

Плагин WordPress для fail2ban

* Plugin Name: Return 403 on Failed Loginfunction my_login_failed_403() {add_action( 'wp_login_failed', 'my_login_failed_403' );

Фильтр fail2ban для WordPress

Для того, чтобы fail2ban смог искать ответ веб-сервера 403 при доступе к станицам авторизации — необходимо создать соответствующий фильтр.

В директории /etc/fail2ban/filter.d создаём файл с именем wp-auth.conf, в него записываем текст фильтра:

failregex = .*POST.*(wp-login.php|xmlrpc.php).* 403

Поиск обращений к wp-login.php или к xmlrpc.php (это самые часто атакуемые страницы wordpress).

Настройка jail.conf

Находим файл /etc/fail2ban/jail.conf и добавляем в него следующие строки

logpath = /var/log/nginx/access.log

После внесения изменений следует перезапустить сервис fail2ban.

Проверка работоспособности.

Заходим на страницу авторизации WordPress и несколько раз имитируем неудачную авторизацию. Следующий этап — просмотр логов доступа веб-сервера по адресу /var/log/nginx/access.log для nginx, или /var/log/apache2/access.log для Apache. Там должно быть что-то вроде этого:

95.0.83.xx — – [07/Aug/2016:06:41:33 +0400] «POST /wp-login.php HTTP/1.0» 200 5791 “-” “-“95.0.83.xx — – [07/Aug/2016:06:41:40 +0400] «POST /wp-login.php HTTP/1.0» 200 5791 “-” “-“95.0.83.xx — – [07/Aug/2016:06:41:57 +0400] «POST /wp-login.php HTTP/1.0» 200 5791 “-” “-“

Далее следует проверить логи fail2ban, там можно будет увидеть что-то вроде этого:

tail -f /var/log/fail2ban.log2014-08-07 06:42:02,818 fail2ban.actions: WARNING [wordpress-auth] Ban 95.0.83.xx

Если эти записи появляются в логах, это означает, что защита успешно срабатывает.

Источник: http://www.mywebtoday.ru/kak-zashhitit-wordpress-pri-pomoshhi-fail2ban-117.html

Защита wp-login в WordPress с Nginx HTTP Auth + fail2ban

Защита wp-login.php для WordPress имеет важное значение для защиты от переборов хакеров. Большинство администраторов WordPress будет использовать плагин , как All-in-One Security (рекомендуется) или Wordfence, чтобы блокировать пользователей, которые делают чрезмерные попытки входа в систему.

Проблема с техникой плагина заключается в том, что эти грубые методы защиты силы все еще дороги для вашего веб – сервера. Когда пользователь пытается войти в систему, происходит обработка PHP и делаются запросы MySQL, чтобы проверить, является ли пользователь действительным или нет.

Если вы получаете много неудачных попыток входа в систему, то вы увидите, что использование центрального процессора и оперативной памяти излишне израсходованы.

Использование основного метода аутентификации HTTP с Nginx будет потреблять гораздо меньше ресурсов, чем при использовании плагина.

При авторизации HTTP не будет использоваться ни PHP, ни MySQL, ваш сервер будет использовать значительно меньше ресурсов, для защиты себя от злоумышленников и хакеров. Мы настроим fail2ban для сканирования файлов журнала Nginx и запретим злоумышленникам на автомате.

Для этого урока вам потребуется доступ оболочки (корневой доступ SSH) на веб-сервер под управлением Debian или Ubuntu.

У вас должны быть установлены Nginx, PHP и WordPress, чтобы использовать это руководство.

Настройка Nginx с базовой HTTP Auth для WordPress

Установите утилиты Apache, чтобы получить генератор файла .htpasswd и Fail2ban

sudo apt-get update
sudo apt-get install apache2-utils fail2ban -y

Создайте файл .htpasswd для вызываемого пользователя andreyex

sudo htpasswd -c /etc/nginx/.htpasswd andreyex

Вам будет предложено ввести пароль дважды. Этот пароль хешированный md5 и будет хранится в файле /etc/nginx/.htpasswd

New password:
Re-type new password:
Adding password for user andreyex

Посмотрите, и вы можете увидите файл .htpasswd, который содержит только урезанный вариант вашего пароля

cat /etc/nginx/.htpasswd

Теперь нам нужно включить .htpasswd в другое место для Nginx в wp-login.php, откройте файл виртуального хоста Nginx

nano /etc/nginx/sites-available/wordpress

Убедитесь, что у вас есть журнал ошибок Nginx, указанный в вашем блоке сервера. fail2ban необходимо сканировать журналы ошибок, чтобы найти неудачные попытки входа.

Добавьте раздел wp-login.php, настройте fastcgi_pass, если вы все еще используете PHP 5.

server { listen 80; server_name andreyex.ru; access_log /var/log/nginx/andreyex.ru.access.log; error_log /var/log/nginx/andreyex.ru.error.log; location = /wp-login.php { auth_basic “Restricted”; auth_basic_user_file /etc/nginx/.htpasswd; include fastcgi_params; fastcgi_pass unix:/run/php/php7.0-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; }

Нажмите Ctrl + X, Y и Enter для сохранения и выхода.

Проверьте синтаксис конфигурации Nginx на правильность заполнения.

nginx -t

Перезапустите Nginx, если вы не получили ошибки.

service nginx restart

Теперь мы создаем некоторые данные журнала, журнал Nginx заполняется с ошибками авторизации HTTP. Это позволит нам проверить, если fail2ban обнаружит неудачные попытки входа.

Убедитесь в том, используйте правильное имя пользователя и неправильный пароль. Также используйте неправильный пользователь и пароль, каждая неудача генерирует различные данные журнала.

Посмотрите в ваш файл журнала Nginx

cat /var/log/nginx/andreyex.error.log

Будет примерно следующее:

2017/02/03 08:12:11 [error] 21122#21122: *1 user “wp” was not found in “/etc/nginx/.htpasswd”, client: 192.168.60.1, server: 192.168.55.095, request: “GET /wp-login.php HTTP/1.1”, host: “192.168.55.095”
2017/02/03 08:12:11 [error] 21122#21122: *1 user “andreyex”: password mismatch, client: 192.168.60.1, server: 192.168.55.095, request: “GET /wp-login.php HTTP/1.1”, host: “192.168.55.095”

Теперь пришло время, чтобы создать фильтр для Nginx

Настройка fail2ban для запрета взломов в WordPress

Fail2ban использует фильтры для выявления нарушений, чтобы запретить пользователей, которые нарушают фильтр.

Создание фильтра Fail2ban для Nginx HTTP Auth

Создадим фильтр Nginx, если вы находитесь в Fail2ban и у вас уже есть этот файл, в этом случае вы можете переходить к тестированию с помощью команды fail2ban-regex.

sudo nano /etc/fail2ban/filter.d/nginx-http-auth.conf

Добавьте код ниже, который является регулярным выражением для логов выше, взято из источника

[Definition]
failregex = ^ [error] d+#d+: *d+ user “S+”:? (password mismatch|was not found in “.*”), client: , server: S*, request: “S+ S+ HTTP/d+.d+”, host: “S+”(, referrer: “S+”)?s*$ ignoreregex =

Нажмите Ctrl + X, Y + Enter, чтобы сохранить изменения и выйти.

Теперь мы можем проверить фильтр аутентификации Nginx HTTP, сканируя журнал ошибок, указанный в файле виртуального хоста Nginx.

fail2ban-regex /var/log/nginx/andreyex.error.log /etc/fail2ban/filter.d/nginx-http-auth.conf

Вы увидите этот вывод, показывающий, наши неудачные попытки входа, которые мы сгенерировали ранее.

Running tests
============= Use failregex file : /etc/fail2ban/filter.d/nginx-http-auth.conf
Use log file : /var/log/nginx/andreyex.error.log Results
======= Failregex: 2 total
|- #) [# of hits] regular expression
| 1) [2] ^ [error] d+#d+: *d+ user “S+”:? (password mismatch|was not found in “.*”), client: , server: S+, request: “GET /wp-login.php.*$
`- Ignoreregex: 0 total Date template hits:
|- [# of hits] date format
| [2] Year/Month/Day Hour:Minute:Second
`- Lines: 2 lines, 0 ignored, 2 matched, 0 missed

Создание Fail2ban для Nginx Jail HTTP Auth

Убедитесь, что у вас есть каталог jail в Fail2ban.

sudo mkdir -p /etc/fail2ban/jail.d

Создание конфигурационного файла Fail2ban jail для Nginx HTTP аутентификации

sudo nano /etc/fail2ban/jail.d/nginx-http-auth.conf

Вставьте конфигурацию, использующая фильтр, который мы создали ранее, она будет сканировать все файлы журнала Nginx и банить пользователей в течение 6000 минут, которые зашли с ошибками 3 раза в 60-секундный период.

[nginx-http-auth]
enabled = true
filter = nginx-http-auth
port = http,https
logpath = /var/log/nginx/*.log
findtime = 60
bantime = 6000
maxretry = 3

Теперь, когда мы настроили jail, проверим синтаксис Fail2ban, убедившись, что это все работает

sudo fail2ban-client -d

Если вы не увидели каких-либо ошибок (предупреждения OK), то мы можем перезапустить fail2ban

service fail2ban restart

Проверка статуса Nginx HTTP Auth Fail2ban

Fail2ban клиент может быть использован, чтобы показать статистику.

sudo fail2ban-client status nginx-http-auth

Во время местного теста нам удалось получить заблокированный шлюз IP.

Вы также можете перечислить IPTables

sudo iptables -L -n

Это показывает цепочку IPtables для ограничения Nginx HTTP Auth запросов

Chain f2b-nginx-http-auth (2 references)
target prot opt source destination
REJECT all — 192.168.0.1 0.0.0.0/0 reject-with icmp-port-unreachable
RETURN all — 0.0.0.0/0 0.0.0.0/0
RETURN all — 0.0.0.0/0 0.0.0.0/0

Вы увидите много ботов сканирования и положить пароли по умолчанию. Они будут быстро запрещены. После того как я установил это решение безопасности WordPress мне не нужны никакие тяжелые PHP плагины как WordFence для блокировки пользователей. Мой веб-сервер может тратить больше времени, используя свои ресурсы более разумно, как обслуживания контента для быстрой доставки пользователю.

Источник: https://andreyex.ru/ubuntu/zashhita-wp-login-d-wordpress-s-nginx-http-auth-fail2ban/

IT Pegas Studio создание сайтов

В предыдущей статье, мы рассмотрели методику защиты от подбора пароля, к панели управления сервером ISPmanager. Теперь когда базовая защита аккаунта у нас настроена, перейдем к защите одного из важнейших элементов веб-сервера phpMyAdmin.

Очень часто взлом сайтов, происходит по вине вебмастера, поленившегося поставить длинный и сложный пароль к БД MySQL. Подобрав имя пользователя и пароль, злоумышленник проникает в phpMyAdmin и как правило просто удаляет все БД к которым сумел добраться.

Как правило, большинство phpMyAdmin защищены cookies аутентификаций, но при этом лог попыток авторизаций не ведется.

У многих возникает резонный вопрос, каким-же образом Fail2Ban сможет блокировать перебор паролей, если нет лога? Да вобщем совсем не сложно, даже для начинающего программиста или системного администратора. Все что нам понадобится, это базовые навыки PHP и немного внимательности. Итак начнем!

Логирование неудачных попыток входа в phpMyAdmin

Поскольку мы используем cookies аутентификацию, нам понадобится файл, в котором находятся функции cookies аутентификации, в CentOS он находится тут – /usr/share/phpMyAdmin/libraries/auth/cookie.auth.lib.php Копируем файл (на случай кривизны рук), далее открываем файл в текстовом редакторе и находим данную функцию:

И добавляем в функцию внесколько строк, которые собственно и добавят, в системный лог, сообщения о неудачных попытках авторизации в phpMyAdmin. B результате этих нехитрых манипуляций, мы получим следующий код:

Теперь загружаем файл на сервер и пробуем авторизоваться в phpMyAdmin, указав некорректное имя пользователя или пароль.

Далее если вы все сделали правильно, в системном логе, которые находится (для CentOS) по адресу – /var/log/messages мы получим запись, примерно такого вида (где хxx.xxx.xxx.xxx ваш IP адрес):

Apr 26 13:36:02 p150170 phpMyAdmin[21516]: xxx.xxx.xxx.xxx – ERROR AUTH phpMyAdmin

Теперь в данном логе, у нас будут фиксироваться, все неудачные попытки авторизации в phpMyAdmin. Можно приступать к настройке Fail2Ban, создав фильтр и правило блокировки.

Заходим в директорию – /etc/fail2ban/filter.d/ и создаем там файл – phpmyadmin.

conf
Открываем созданный нами файл для редактирования и вносим в него следующее правило:

[Definition] failregex = – ERROR AUTH phpMyAdmin ignoreregex =

Настраиваем файл конфигурации

Открываем файл конфигурации Fail2Ban – /etc/fail2ban/jail.conf и вносим в него правило блокировки, для защиты phpMyAdmin.

Указываем число неудачных попыток авторизации – 10, время блокировки злоумышленника – 3 часа (10800 секунд).

Время блокировки и количество неудачных авторизаций, стоит подбирать самостоятельно, это строго индивидуально

[phpmyadmin] enabled = true filter = phpmyadmin action = iptables-multiport[name=phpMyAdmin, port=”80,443″, protocol=tcp] logpath = /var/log/messages findtime = 600 maxretry = 10 bantime = 10800

Проверяем корректность настройки

# fail2ban-regex /var/log/messages /etc/fail2ban/filter.d/phpmyadmin.conf

Перезапускаем Fail2Ban

# service fail2ban restart

В результате этих нехитрых манипуляций, все попытки подбора паролей к phpMyAdmin будут заканчиваться баном злоумышленника, а администратор сервера, сможет спокойно спать по ночам 🙂

Источник: https://pegas-studio.net/development/Fail2Ban_phpMyAdmin

Защита WordPress. Защита админки WordPress

Приветствую Вас на блоге inetmi.ru! Тема дня — Защита wordpress. Защита админки WordPress от взлома.

Недавно мой блог пытались взломать, путём подбора логина и пароля, используемый метод называется «Брутфорс атака». Что это такое?

Представьте себе тот момент, когда Вы вызываете панель для входа в свою админку, набираете адрес в браузерной строке – Ваш сайт/wp-admin или вместо wp-admin прописывается /wp-login.php – это не важно. Появляется поле для ввода данных… Любой, кто знает название Вашего блога, легко получает доступ к панели ввода логина и пароля — стандартная защита админки wordpress…

Методом подбора логина и пароля, взламывается блог. Только не нужно недооценивать взломщиков, думая, что никогда не подберут Вашу заветную фразу, уверяю, это лишь вопрос времени. Зайдя на страницу с формой для ввода данных, злоумышленник активирует программу по перебору или подбору логина и пароля. Маленькие «лапки» роботов будут делать своё дело… Читайте далее и всё поймёте!

Сейчас есть плагины, которые блокируют доступ, после нескольких неудачных попыток ввода логина и пароля. До сих пор многие используют плагины типа «Login LockDown» и другие похожие ему .Казалось бы, установи плагин и всё, полная изоляция, защита wordpress на высоте, можно ставить точку, но давайте пока не будем спешить…

Я уже говорил о том, что мой блог атаковали путём подбора логина и пароля. Всё дело в том, что обычные плагины от Брутфорс вторжений уже непригодны! Они блокируют нападающего по IP, после определённого количества попыток. Например, Какой-то хакер Вася три раза ввел неправильно данные, плагин запомнил его IP и на час-два закрыл ему доступ. Вася курит…

Сейчас вся фишка в новых видах атак! Как правило — это статичный IP адресс, то есть с одного места идёт вторжение.

Но представьте себе на минуту, когда на тебя градом сыплются тысячи различных IPшек – и все адреса разные… Идёт около ста подборов в минуту! Защита админки wordpress построенная на стандартном плагине от брутфорс атак просто не реагирует! Даже если изменить настройки плагина, поставить блокировку на первую неудавшуюся попытку входа, всё равно плагин будет стоять в сторонке. Адреса то ведь разные! Смотрите скрин ниже.

Жаль, не смогу показать всего списка, тогда точно сказали бы– дружище это всемирный заговор против тебя!

Перед глазами мелькали десятки флажков различных стран.

Моя «бывшая» защита wordpress блога смотрела вместе со мной на весь этот беспредел — мы злились! Как это объяснить? Очень просто! Все действия происходят за одним компьютером, который управляет тысячами зомби-буков, расположенными Бог знает где. При помощи заданных программ идут целенаправленные попытки «вскрыть» очередную жертву – сегодня выбрали меня, а завтра кого?..

Итак, друзья, предлагаю перейти от теории к практике!

Надёжная защита WordPress. Защита админки WordPress — плагины

Сейчас, дорогие друзья предлагаю Вам рассмотреть несколько вариантов по защите wordpress, какой выбрать – решать Вам. Оба варианта исключают возможность подбора логина и пароля «роботами».

Защита WordPress при помощи — Captcha

Плагин так и называется – Captcha… Скачать его и проверить можно через свою админку, как это сделать написано здесь — Установка плагинов WordPress. Как проверить плагин

После активации, перейдём к настройкам, где всё на русском, но всё же поясню…

В самих настройках нужно поставить метку в чекбоксе «Форма логина». Остальные пункты на Ваш вкус. Интересным, на мой взгляд, является пункт – «Заголовок для капчи в форме», введите здесь фразу или предложение и это будет отображаться на самой форме ввода данных. Скриншот ниже.

Пункты с арифметикой и уровнем сложности – на Ваше усмотрение… После всех отметок не забываем нажать кнопку «Сохранить…»

Роботы не умеют читать картинки (пока ещё), поэтому они не могут заполнить поле с капчей, следовательно, подбор логина и пароля превращается в бессмысленную возню. Взломщик это понимает и отступает, хотя на его место всегда придёт другой…

Защита WordPress с помощью плагина Protected wp-login

Это очень простое и эффективное решение проблемы, связанное с подбором логина и пароля к админке блога.

Особенностью данного плагина является – создание отдельной, секретной страницы для ввода логина и пароля! То есть, та страница, с формой ввода данных, которая есть сейчас, будет для хакеров — она стандартная и видна всем, другая же будет появляться при наборе Вашего секретного кода (!), только для Вас лично.

Сейчас объясню детальней…

Для начала скачайте плагин из админки блога и активируйте его.

В боковой панели, в параметрах выбираем «Защищённый вход»

Здесь в одно единственное поле, нам нужно ввести придуманный Вами ключ, я для примера написал 111. Нажимаем «сохранить…»

На скриншоте видно сформированную ссылку, она служит для вывода секретной страницы, где будем прописывать свой логин и пароль — «Сохраняем».

Внимание! Скопируйте и сохраните ссылку (не мою, а свою), или запишите себе на бумагу – это Ваш ключ, или можно сказать пропуск.

Теперь каждый раз, перед вводом логина и пароля, Вы должны сначала вставить ключ в браузерную строку и нажать «Enter»… Вставили? Нажали? Открывается похожая страница.

Появляется точно такое же аналогичное поле для ввода личных данных – оно Ваше и никто не будет знать об этом!

Что будет, если попробовать ввести свой логин и пароль в поле ввода, без использования ключа? Смотрите скрин ниже…

Ну, вот и всё, вроде разобрались… Хочу сказать следующее – Уделяйте внимание построению защиты Вашего же блога, используйте новые решения безопасности… Тем, кто не знаком ещё, могу предложить свою статью — Защита wordpress от взлома. Там я рассказываю о новом защитном механизме, который блокирует огромное количество угроз!

На этой теме – «Защита wordpress. Защита админки WordPress» мы пока остановимся. На данный момент мною тестируется новый плагин комплексной защиты блога, вскоре будет статья на эту тему, или же книга в эл.

формате – что именно будет ещё не решил. Скоро!..

Если у Вас возникнут какие-то вопросы или пожелания – пишите в комментариях, обговорим… Не забывайте подписываться по e-mail, что бы в дальнейшем не пропустить выхода новых и интересных статей!

На этом всё, до скорого!

Источник: http://inetmi.ru/zashhita-bloga/zashhita-wordpress-zashhita-adminki-wordpress.html