Введение
Рано или поздно ваш сайт будут пробовать на прочность всякие роботы. Если движок сайта свободный, то роботы начинают проверять вас на прочность сразу.
Все бесплатные движки всегда надо обновлять и внимательно относиться ко всем дополнениям что устанавливайте. Обязательно держите резервные копии и тогда даже взлом не страшен.
Меня начали проверять почти сразу. Пользуясь случаем хочу передать привет товарищу Токарчуку Александру Степановичу с IP адреса которого упорно хотели попасть в админку моего сайта. Почему то пытаются войти, в моем случае, как правило с Украины.
Советую сразу смените путь к админке сайта с помощью iThemes Security. По умолчанию путь в WordPress домен/wp-admin и именно сюда все боты и лезут… Поленился я сразу сменить и боты стали ломится каждую минуту и причем в своем большинстве используя Российские ip адреса. Путь сменил, но они всё равно ломятся по стандартному пути…
Настройка
Процесс настройки fail2ban не зависит от дистрибутива Linux.
Основной конфигурационный файл находится в каталоге . Однако, его не рекомендуется менять и для настройки используют подключаемые файлы из каталога .
Существующие фильтры лежат в директории . Можно изменять существующие фильтры или на их основе делать собственные.
Существующие правила реагирования хранятся в директории .
Как правило, все стандартные файлы содержат подробные комментарии.
Действия
Файлы с настройкой действий находятся в каталоге .
Остановимся на описании самых используемых действий:
- iptables — создание простого правила в netfilter с помощью одноименной утилиты;
- iptables-multiport — использование модуля multiports, позволяющий добавлять диапазоны портов для блокировки;
- iptables-ipset — использование ipset для придания более лаконичного вида правилам;
- iptables-allports — блокирует для адреса все порты.
Фильтры
Фильтры, в основном, представляют набор регулярных выражений для поиска ключевых слов в log-файлах. Они находятся в каталоге .
Для создания и настройки своих фильтров, можно использовать имеющиеся файлы в качестве шаблона.
Файлы с фильтрами должны иметь расширение . В дальнейшем использовать указанный фильтр можно, обратившись к нему в правиле по имени файла без расширения.
Например, чтобы использовать фильтр в правиле надо указать:
filter = my
Указание параметров на примере
Для нового правила необходимо создать конфигурационный файл в каталоге /etc/fail2ban/jail.d:
$ vi /etc/fail2ban/jail.d/service.conf
enabled = true port = ssh filter = sshd action = iptables logpath = /var/log/auth.log maxretry = 10 findtime = 600 ignoreip = 127.0.0.1/8
Разберем параметры:
- ssh — название для правила.
- enabled позволяет быстро включать (true) или отключать (false) правило;
- port — порт целевого сервиса. Принимается буквенное или цифирное обозначение.
- filter — фильтр (критерий поиска), который будет использоваться для поиска подозрительных действий. По сути, это имя файла из каталога без на конце.
- action — действие, совершаемое в случае срабатывания правила. В квадратных скобках указаны название для правила, сетевой порт и протокол для блокирования.
- logpath — расположение лог-файла, в котором фильтр будет искать подозрительную активность на основе описанных критериев.
- maxretry — количество действий, которые разрешено совершить до блокировки.
- findtime — время в секундах, в течение которого учитывается maxretry.
- bantime — время, на которое будет блокироваться IP-адрес.
- ignoreip — игнорировать защиту, если запросы приходят с перечисленных адресов.
Если какой-то из параметров не указан в конкретном правиле, для него берется значение по умолчанию, описанное в правиле DEFAULT.
Примечание: Для применения новые правил необходимо перезапустить fail2ban одной из следующих команд:
$ systemctl restart fail2ban
или
$ service fail2ban restart
Делаем свой фильтр (что бы вытащить IP из лога)
- Вопрос — может ли fail2ban работать без файла фильтра?
- Нет, не может. Приложению fail2ban необходимо получить IP-адрес из лога — а это как раз делает фильтр с помощью regex
Пишем свой фильтр. Свой фильтр можно создавать с названием myfilter.conf в папке filter.d/
Общая структура фильтра. В файле фильтра может быть два раздела:
-
[INCLUDES} — необязательно
- before = common.conf
- after = filtername.local
-
- failregex = ….
- ignoreregex = ….
Раздел указывает на файлы фильтров, которые читаются до или после этого файла. Файл common.conf считывается и помещается перед другими строками в этом файле, а файл filtername.local — после . Эти файлы устанавливают некоторые параметры, которые будут использоваться далее в конфигурации.
Раздел указывает на выражения regex, которые нужно применить к файлу лога или исключить из обработки.
Формат выражения failregex:
- должно начинаться с символа ^ — это означает для fail2ban, что будет анализироваться текст после формата даты Y-m-d H:i:s. Есть недокументированная возможность вместо символа ^ использовать свое выражения для формата даты (если в Вашем логе дата формируется по другому), cм. ошибку Debian # 491253
- директива <HOST> — для определения IP-адреса в строке лога (для версии ниже 0.10 работает только для IP v4). Этот тэг <HOST> — внутренняя замена fail2ban регулярного выражения (?:::f{4,6}:)?(?P<host>\S+)
Итого вида failregex = ^ регулярное выражение <HOST> регулярное выражение
Правила, используемые вашей версией fail2ban, зависят от версии питона, используемого в системе.
# python -V Python 2.7.13
У нас фильтр будет относительно простой, т.к. в логе уже собраны адреса IP только «вредителей», не нужно дополнительно искать по условию regex текстовую строку с описанием ошибки. Нам нужно простое регулярное выражение, которое будет «видеть» IP в строках лога.
failregex = ^ <HOST>
Проверим, как работает фильтр (команда + лог + фильтр). Для проверки может быть в качестве фильтра использован или файл с фильтром или сам фильтр (в кавычках)
fail2ban-regex /var/www/user/data/www/_mylog/test.log '^ <HOST>'
удобно тестировать по одной строке.
Результат
- 311 совпадений найдено
- формат даты распознан
Итого наш вариант файла testfilter.conf для папки filter.d
failregex = ^ <HOST> ignoreregex =
Проверяем полностью
fail2ban-regex /var/www/user/data/www/_mylog/test.log /etc/fail2ban/filter.d/testfilter.conf
Вот кстати, полный отчет fail2ban по обнаружению формата даты в логе
Date template hits: |- date format | Day(?P<_sep>)MON(?P=_sep)Year?24hour:Minute:Second(?:.Microseconds)?(?: Zone offset)? | (?:DAY )?MON Day 24hour:Minute:Second(?:.Microseconds)?(?: Year)? | Year(?P<_sep>[-/.])Month(?P=_sep)Day 24hour:Minute:Second(?:,Microseconds)? | Day(?P<_sep>)Month(?P=_sep)(?:Year|Year2) 24hour:Minute:Second | Month/Day/Year:24hour:Minute:Second | Month-Day-Year 24hour:Minute:Second.Microseconds | TAI64N | Epoch | Year-Month-Day24hour:Minute:Second(?:.Microseconds)?(?:Zone offset)? | ^24hour:Minute:Second | ^<Month/Day/Year2@24hour:Minute:Second> | ^Year2MonthDay ?24hour:Minute:Second | MON Day, Year 12hour:Minute:Second AMPM | ^MON-Day-Year2 24hour:Minute:Second
Настройка правил фильтрации
Теперь нам необходимо создать фильтр, который будет извлекать из общего потока сообщений астериска потенциально опасные события (неверный логин/пароль, попытка входа с неразрешенного IP адреса, и т.д. и т.п.). При этом нам необходимо не только обнаруживать такие потенциально опасные события, но и вычленять оттуда IP адрес, с которого было выполнено действие. То есть мы не просто ищем определенные строки в файлах событий астериска, а настраиваем правила фильтрации.
Правила фильтрации можно прописать в файле /etc/fail2ban/filter.d/asterisk.conf. Вот образец содержимого этого файла:
# Fail2Ban configuration file
#
#
# $Revision: 250 $
#
# Read common prefixes. If any customizations available -- read them from
# common.local
#before = common.conf
#_daemon = asterisk
# 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\S+)
# Values: TEXT
#
# Asterisk 1.8 uses Host:Port format which is reflected here
failregex = NOTICE.* .*: Registration from '.*' failed for ':.*' - Wrong password
NOTICE.* .*: Registration from '.*' failed for ':.*' - No matching peer found
NOTICE.* .*: Registration from '.*' failed for ':.*' - Username/auth name mismatch
NOTICE.* .*: Registration from '.*' failed for ':.*' - Device does not match ACL
NOTICE.* .*: Registration from '.*' failed for ':.*' - Not a local domain
NOTICE.* .*: Registration from '.*' failed for ':.*' - Peer is not supposed to register
NOTICE.* .*: Registration from '.*' failed for ':.*' - ACL error (permit/deny)
NOTICE.* .*: Registration from '.*' failed for '' - Wrong password
NOTICE.* .*: Registration from '.*' failed for '' - No matching peer found
NOTICE.* .*: Registration from '.*' failed for '' - Username/auth name mismatch
NOTICE.* .*: Registration from '.*' failed for '' - Device does not match ACL
NOTICE.* .*: Registration from '.*' failed for '' - Not a local domain
NOTICE.* .*: Registration from '.*' failed for '' - Peer is not supposed to register
NOTICE.* .*: Registration from '.*' failed for '' - ACL error (permit/deny)
NOTICE.* .*: Registration from '\".*\".*' failed for ':.*' - No matching peer found
NOTICE.* .*: Registration from '\".*\".*' failed for ':.*' - Wrong password
NOTICE.* .*: No registration for peer '.*' \(from \)
NOTICE.* .*: Host failed MD5 authentication for '.*' (.*)
NOTICE.* .*: Failed to authenticate user .*@.*
NOTICE.* failed to authenticate as '.*'$
NOTICE.* .*: Sending fake auth rejection for device .*\<sip:.*\@\>;tag=.*
NOTICE.* .*: tried to authenticate with nonexistent user '.*'
VERBOSE.*SIP/-.*Received incoming SIP connection from unknown peer
# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =
В asterisk версии 1.4 и более ранних используются строки типа “… failed for ‘<HOST>’ …”, а в asterisk 1.8 и выше – строки “… failed for ‘<HOST>:.*’ …”, поскольку начиная с версии asterisk 1.8 в логах появилась информация о номере порта, которой нет в asterisk 1.4. Приведенный выше вариант учитывает как старые, так и новые версии asterisk, так что Вам нет необходимости в нем что-либо менять.
Для asterisk версии 10 и выше, если Вы включили ведение логов security, не забудьте прописать правила фильтрации для этих логов!
Правила фильтрации можно прописать в файле /etc/fail2ban/filter.d/asterisk-security.conf. Вот образец содержимого этого файла:
# Fail2Ban configuration file
#
#
# $Revision: 250 $
#
# Read common prefixes. If any customizations available -- read them from
# common.local
#before = common.conf
#_daemon = asterisk
# 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\S+)
# Values: TEXT
#
failregex = SECURITY.* SecurityEvent="FailedACL".*RemoteAddress=".+?/.+?//.+?".*
SECURITY.* SecurityEvent="InvalidAccountID".*RemoteAddress=".+?/.+?//.+?".*
SECURITY.* SecurityEvent="ChallengeResponseFailed".*RemoteAddress=".+?/.+?//.+?".*
SECURITY.* SecurityEvent="InvalidPassword".*RemoteAddress=".+?/.+?//.+?".*
# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =
Управление правилами fail2ban
Временное отключение блокировки IP адреса
Для этого Вам необходимо воспользоваться услугой iptables. Сначала мы выведем список правил на консоль, а затем выбрав нужные IP, удалим их из бана.
Для просмотра списка правил введите команду:
Вы увидите сообщение следующего вида:
Нас интересует удалить из бана IP адрес 1.2.3.4, который (как мы видим) находится в цепочке правил (chain) под названием fail2ban-ASTERISK. Набираем команду:
В случае успешного выполнения команды никаких сообщений не появится, и если мы теперь снова запустим команду
то увидим, что IP адрес исчез из блокировки iptables (хотя и остался в блокировке fail2ban!). При этом мы снова можем подключаться к серверу asterisk
Постоянное отключение блокировки IP адреса
Для того, чтобы fail2ban не блокировал определенный IP адрес (или несколько IP адресов) независимо от того, сколько неудачных попыток подбора пароля (и прочих “неправомерных” действий) они совершили, необходимо произвести дополнительную настройку jails в файле /etc/fail2ban/jail.conf
В каждом правиле файла jail.conf может присутствовать параметр ignoreip, который задает список IP адресов, попадающих в “белый список” для этого правила
Поскольку правил у нас может быть два, обратите внимание, что Ваш IP необходимо прописывать в обоих правилах!. Параметр имеет следующий вид:
Параметр имеет следующий вид:
То есть Вы можете прописывать как подсети, так и отдельные IP адреса (в данном случае в “белый список” попадают IP 127.0.0.1-127.0.0.255, 192.168.0.1-192.168.255.255 и 1.2.3.4).
![Fail2ban [айти бубен]](https://fuzeservers.ru/wp-content/uploads/f/8/f/f8f4a153d8f0d95e544c508081eedda7.png)
Разблокировка IP адреса, с которого производилось тестирование
Во время проверки правильности настройки fail2ban Вы неоднократно запускали SIP клиента для тестирования работы по блокировке будущих атак из интернета. И в процессе последующей работы Вам, возможно, также понадобится время от времени производить действия, последствиями которых может быть блокировка со стороны fail2ban / iptables. Хотелось бы не дожидаться, когда fail2ban “соизволит” разблокировать IP сам (а это может быть довольно долго – поскольку параметр bantime можно выставить хоть на час, хоть на день, хоть на год).
Существуют 2 пути решения подобной проблемы:
- Внести IP адрес в правилах fail2ban в список ignoreip. Но иногда это может быть нежелательно (чтобы, например, производить периодическое тестирование работы fail2ban)
- Обычно время findtime (это длительность интервала в секундах, за которое событие должно повториться maxretry раз, после чего бан вступит в силу) намного меньше, чем bantime (это время бана в секундах, по истечении которого IP адрес удаляется из списка заблокированных). Например, findtime выставляется в 10 минут, а bantime – час. Либо findtime – час, а bantime – день или даже больше. И так далее. Поэтому имеет смысл сделать паузу длительностью не менее, чем findtime с момента последнего тестирования (и забанивания Вашего IP адреса), после чего перезагрузить сервис fail2ban. При перезагрузке сервиса fail2ban все блокировки аннулируются. Однако при последующей загрузке fail2ban логи анализируются снова, и если в логах в течение findtime было maxretry неудачных попыток подключения с одного IP, этот IP будет снова забанен сразу после запуска fail2ban.
Тестирование конфигурации fail2ban
Вы можете проверить, как будет применяться фильтр fail2ban к тому или иному логу. Для этого можно запустить команду:
Где /var/log/asterisk/messages – это пример пути к файлу с логами, который будет фильтроваться, а /etc/fail2ban/filter.d/asterisk.conf – сам фильтр, который содержит те фрагменты , которые должны быть в логе .
И напоследок: вместо перезагрузки fail2ban с помощью можно выполнить следующую команду
Делаем свой лог
Например в корневой папке web-server (в папках выше политика безопасности сервера не даст доступа нашему php-скрипту)
<?php
$root_webserver = '/var/www/user/data/www/';
// это корневая папка web server, а не DOCUMENT_ROOT сайта
$my_dir = $root_webserver.'_mylog';
if (! file_exists ($my_dir)){
mkdir ($my_dir, 0777);
}
$file_var = $my_dir.'/test.log';
$size_log = filesize ($file_var); //при отсутствии файла будет false
$bot_info = date("Y-m-d H:i:s").' '.'192.168.1.1 и другая информация'.PHP_EOL; // перевод строки
if ( $size_log === FALSE || $size_log > 300000 ) {
// файла нет или он больше 300 000 байт - делаем новый
file_put_contents($file_var, $bot_info, LOCK_EX);
}else{ // в остальных случаях дописываем в старый
file_put_contents($file_var, $bot_info, FILE_APPEND | LOCK_EX);
}
?>
Дата и время должны записываться в лог в определенном формате, что бы фильтр fail2ban можно было настроить корректно (там потом будет анализ периода заходов бота). Основной стандартный формат ниже (но fail2ban понимает и другие варианты)
год-месяц-день часы:минуты:секунды
поэтому используем php — date(«Y-m-d H:i:s»)
ВАЖНО: внутри WordPress функция date() работает некорректно
Это такая фича, а не баг — читаем статью
В результате этого колдунства у нас получилось:
- в папке /var/www/user/data/www/ (на Вашем сервере может быть другой путь) появилась новая папка «_mylog«
- в этой папке файл «test.log» (общий лог для всех Ваших сайтов на VPS)
- при превышении размера ~300kb — файл создается заново (или можно сделать ротацию логов)
- переменную $bot_info можно собрать как удобнее — главное дата/время и IP
Итого мы имеет лог-файл с адресом вида (в который пишутся строки с IP-адресами ботов)
/var/www/user/data/www/_mylog/test.log
который мы и будет «скармливать» fail2ban
Отладка работы fail2ban
После добавления правил блокировки ip адресов с помощью fail2ban, я некоторое время наблюдаю за сервером, чтобы проверить правильность работы. Для этого делаю вот такое окно в отдельном мониторе и наблюдаю некоторое время.
Здесь открыт лог postfix, dovecot и fail2ban. Если вижу, что правила отрабатываются корректно, завершаю настройку. На этом этапе могут быть заблокированы валидные ip адреса пользователей, у которых одна из учеток указана с неверным паролем. В итоге он банится по ip и у него вообще перестает работать вся почта. Если это локальные пользователи, то можно всю их подсеть добавить в доверенные, но я бы не рекомендовал так делать. В этом случае вы не узнаете, что кто-то вас перебирает из локальной сети. А это случается не редко.
How to unban an IP in Fail2ban?
When a valid user IP is blocked, the server owner may get a Connection timed out message for mail, web, SSH, etc.
For example, a blocked customer will see the below message, when he try to access the server via SSH.
But, we easily identify and unban the IP address from Fail2ban in 4 simple steps.
1) Check if IP address is blocked
Fail2ban uses iptables to block the traffic.
So, our Server Support Engineers first login to the server via SSH, and check for IP block with the following command.
If the IP is blocked by Fail2ban, then it will be listed in the Fail2ban chain like fail2ban-ssh.
2) Check the Fail2ban log
Fail2ban log on the server is at /var/log/fail2ban.log and this logs the details like IP addresses that are banned, the jail, and time they are blocked.
For example, a Fail2ban log looks like this:
Our Support Engineers check these logs to confirm if the IP is blocked by Fail2ban.
3) Get Jail name of blocked IP address
Next step is to confirm the jail name for this IP address is in.
For that, we use the command fail2ban-client status.
Here, the Jail list in the output shows the Jail names set in Fail2ban.
4) Unban the IP address
Once we get the jail name, next step is to unban this IP address.
There is a slight difference in the unban commands depending on the Fail2ban version.
In Fail2ban version(before v0.8.8)
We use the below command to unban the IP address in Fail2ban versions before 0.8.8.
Replace yourjailname with the corresponding jail name and youripaddress with the blocked IP address.
For example, to remove an IP address jailed within ssh, use the below command.
In Fail2ban version v0.8.8 or later
We use the below command to unban the IP address in Fail2ban version 0.8.8 and later.
Replace yourjailname with the corresponding jail name and youripaddress with blocked IP address.
For example, to remove an IP address jailed within ssh, use the below command.
Alternatively, our Server Support Engineers use another method to unban the IP address instead of fail2ban-client.
For that, we first check for the blocked IP address, chain name and its corresponding line number with the following command.
Next, we use the below command to unban that IP address using the line-number and chain name.
In plesk servers, they have integrated the Fail2ban feature aka IP Address Banning with the control panel.
So, server owners can easily unban the IP address in a single click.
Fail2ban in Plesk
Sometimes, we receive requests from server owners to unban multiple IP addresses from their servers.
During such situations, our Support Engineers create custom scripts to unban multiple IP addresses and make it a pain free process.
Запуск fail2ban
Теперь необходимо запустить (или перезапустить) fail2ban и (если это необходимо, например iptables еще не был запущен) iptables.
Для запуска iptables (его нужно запустить первым) выполните следующую команду:
Для перезапуска fail2ban выполните следующую команду:
Для проверки, что fail2ban запущен успешно и правило загружено, выполните следующую команду:
и (если есть второе правило)
Для отображения списка правил iptables выполните следующую команду:
В случае, если Вы только что установили fail2ban / iptables, не забудьте убедиться, что они настроены у Вас стартовать автоматически при загрузке системы!
Настройки
Данная вкладка предназначена для настройки работы Fail2ban.
Флаги «Защитить почтовый сервер», «Защитить веб-почту», «Защитить сервер телефонии», «Защитить VPN-сервер», «SSH», «FTP», «GUI» позволяют Fail2ban анализировать логи авторизации в соответствующих модулях.
В поле «Количество неудачных попыток авторизаций» можно задать количество неудачных попыток авторизации в одном из модулей, отмеченных флагом. После этого IP-адресу будет полностью заблокирован доступ к ИКС. По умолчанию установлено 3 попытки.
![Fail2ban - украл, выпил - в тюрьму! [rtfm.wiki]](https://fuzeservers.ru/wp-content/uploads/2/b/a/2ba42f9980d31ea081d0e44da76be68a.jpeg)
В поле «Интервал неудачных попыток авторизаций» задается время, в течение которого в каждом модуле подсчитывается количество неудачных попыток авторизации (в минутах). По умолчанию установлен интервал 10 минут.
Поле «Блокировать на» предназначено для установки времени, в течение которого будет действовать блокировка IP-адреса (в минутах). По умолчанию установлено значение 10 минут.
Флаг «Увеличивать время бана» позволяет включить дополнительные настройки Fail2ban для увеличения времени бана:
- Прибавить к времени бана случайное время из диапазона от 0 до — параметр выберет случайное значение и прибавит к стандартному времени бана (в минутах);
- «Фактор роста» — дополнительный глобальный коэффициент, на который будут умножаться все множители из списка. Увеличение фактора роста удобно использовать, когда вы хотите значительно увеличить время бана. В таком случае не потребуется переписывать список множителей;
- «Список множителей» — список, по которому будет происходить рост времени бана. Порядковый номер множителя будет соответствовать количеству раз, когда IP-адрес попал в дополнительный бан;
- флаг «Не разделять попытки авторизации по службам».
Пример
- первый бан = (время бана + случайное время) * первый множитель * фактор роста;
- второй бан = (время бана + случайное время) * второй множитель * фактор роста и т. д.;
- по достижении IP-адреса последнего множителя и далее время бана будет считаться по последнему множителю.
Внимание! IP-адреса, попадающие в бан, считаются плохими. На них будет срабатывать увеличение времени бана, пока не пройдет трехкратный промежуток времени последнего бана либо пока они не будут разбанены вручную
Если авторизация на FTP идет через браузер, то количество попыток авторизации, указанное в поле «Количество неудачных попыток авторизаций», будет в два раза меньше, так как браузер пытается первоначально авторизоваться под учетной записью Anonymous.
На данной вкладке также можно сформировать белый список для Fail2ban. Нажмите кнопку «Белый список» и в открывшемся окне задайте соответствие IP-адреса/подсети/диапазона (192.168.1.1, либо 192.168.1.1/28, либо 192.168.1.1-192.168.1.3) и сервиса (всех сервисов), для которых Fail2ban не будет срабатывать. Нажмите «Сохранить».
Внимание! Если Fail2ban заблокирует IP-адрес по одному из сервисов, то доступ с IP-адреса к другим сервисам также будет заблокирован, в том числе к сервисам, добавленным в белый список. Чтобы изменения настроек вступили в силу, нажмите «Сохранить»
Чтобы изменения настроек вступили в силу, нажмите «Сохранить».
Emails from fail2ban not containing whois info help needed.
Hi,
The IP xx.xx.xx.xx has just been banned by Fail2Ban after
4 attempts against ssh.
Here are more information about xx.xx.xx.xx:
Lines containing IP:xx.xx.xx.xx in /var/log/auth.log
Apr 6 11:55:05 user sshd: Invalid user dg from xx.xx.xx.xx
Apr 6 11:55:05 user sshd: Failed none for invalid user dg from xx.xx.xx.xx port 57992 ssh2
Apr 6 11:55:09 user sshd: Failed password for invalid user dg from xx.xx.xx.xx port 57992 ssh2
Apr 6 11:55:13 user sshd: Failed password for invalid user dg from xx.xx.xx.xx port 57992 ssh2
Apr 6 13:42:53 user sshd: Invalid user kjhgfd from xx.xx.xx.xx
Apr 6 13:42:53 user sshd: Failed none for invalid user kjhgfd from xx.xx.xx.xx port 59527 ssh2
Apr 6 13:42:59 user sshd: Failed password for invalid user kjhgfd from xx.xx.xx.xx port 59527 ssh2
Apr 6 13:43:03 user sshd: Failed password for invalid user kjhgfd from xx.xx.xx.xx port 59527 ssh2
Regards,
Fail2Ban
Примеры правил
В данных примерах блокировка IP-адреса будет происходить на 12 минут после 4-х попыток ввода пароля в течение 8 минут. Эти параметры берутся из настроек . Если их нужно переопределить, просто добавляем их при описании правила.
SSH
CentOS
vi /etc/fail2ban/jail.d/ssh.conf
enabled = true
port = ssh
filter = sshd
action = firewallcmd-new
logpath = /var/log/secure
Ubuntu
vi /etc/fail2ban/jail.d/ssh.conf
enabled = true
port = ssh
filter = sshd
action = iptables
logpath = /var/log/auth.log
Asterisk
vi /etc/fail2ban/jail.d/asterisk.conf
enabled = true
filter = asterisk
action = iptables-allports
logpath = /var/log/asterisk/messages
NGINX
vi /etc/fail2ban/jail.d/nginx.conf
enabled = true
port = http,https
filter = nginx-http-auth
action = iptables-multiport
logpath = /var/log/nginx/error.log
NGINX DDoS (req limit)
Данное правило поможет защитить веб-сервер nginx от DDoS-атак. В некоторых сборках, для данного правило может не оказаться готового фильтра, поэтому в данном примере, мы его создадим вручную.
Для начала, необходимо настроить NGINX:
vi /etc/nginx/nginx.conf
В раздел http добавим:
http {
…
limit_req_zone $binary_remote_addr zone=one:10m rate=5r/s;
…
* данная настройка создает зону с интенсивностью запросов в 1 запрос в секунду.
После настраиваем лимит для конкретного виртуального домена в разделе server — location:
server {
…
location / {
…
limit_req zone=one burst=5 nodelay;
…
* данная настройка вместе с предыдущей зоной, созданной в секции http, позволит лимитировать запросы — 1 запрос в секунду при всплеске 5 запросов.
Проверяем конфигурационный файл nginx и перезапускаем сервис:
nginx -t
systemctl reload nginx
В лог-файле (по умолчанию /var/log/nginx/error.log) при превышении лимита подключения мы должны увидеть запись на подобие:
2020/11/16 19:11:08 1330844#1330844: *16640836 limiting requests, excess: 10.520 by zone «one», client: xxx.xxx.xxx.xxx, server: dmosk.ru, request: «GET / HTTP/1.1», host: «dmosk.ru», referrer: «https://dmosk.ru/page1»
* обратите внимание, что в вашем случае путь до лога может быть другой. Он определяется в конфигурационном файле NGINX
Теперь можно приступать к настройке fail2ban. Создаем фильтр:
vi /etc/fail2ban/filter.d/nginx-limit-req.conf
ngx_limit_req_zones = +
failregex = ^\s*\ \d+#\d+: \*\d+ limiting requests, excess: + by zone «(?:%(ngx_limit_req_zones)s)», client: <HOST>
ignoreregex =
* данный файл может быть уже создан и настроен при установке fail2ban. Если это так, то ничего не меняем и идем дальше.
Создаем правило в fail2ban:
vi /etc/fail2ban/jail.d/nginx-ddos.conf
enabled = true
port = http,https
filter = nginx-limit-req
action = iptables-multiport
logpath = /var/log/nginx/error.log
* еще раз обращаю внимание на путь logpath — в вашем случае он может быть другим. После настройки не забываем перезапустить fail2ban:
После настройки не забываем перезапустить fail2ban:
systemctl restart fail2ban
Чем в итоге нам полезен Fail2ban
Хорошо иметь базовую авторизацию в админ интерфейсе под прикрытием Fail2ban и сейчас я расскажу почему…
Кроме массы «добрых» людей по сети ещё бродит оч. много различных ботнетов, которые щупают стандартные каталоги admin|administrator|phpmyadmin etc.., нащупав которые начинают ломать до морковкина заговенья. Кроме попыток «брутфорса» базовой HTTP авторизации они могут предпринимать попытки взлома/спама на другие части сайта, а когда они получают «отлуп» с последующей отправкой в «бан-ю» iptales-a, то на протяжении времени бана остальные части им будут недоступны, а значит мы сэкономим на количестве подключений к сокету, что в общей сложности добавит нашему «серванту» стабильности и безопасности.
Как видим защита от брутфорса базовой HTTP авторизации при помощи Fail2ban может быть довольно эффективной, а в комплексе с другими средствами, такими как ModSecurity, является мощным средством для полномасштабной защиты сервера от различной дряни, которое помогает сэкономить на подключениях, а соответственно и на системных ресурсах (ЦП, РАМ, место на HDD).
Бот подолбил базовую HTTP авторизацию на сервере с «» до «», а потом пропал с концами — видимо боту как-то дошло, что гиблое это дело и здесь он может обломать себе зубы 
Как ранее упоминалось, у медали всегда две стороны — по идее легальные поисковые боты (GOOGLE/Yandex/MSN etc) недолжны обращаться к сайту методом POST и в запросе должны отправлять HTTP заголовок «Accept» и «User-Agent», но на практике бывает всё иначе, а поэтому иногда они могут попадать в бан под Fail2ban или ModSecurity — ИП ботов можно добавить в исключения. В результате возможно временное снижение ПР (ака «Page Rank»), позиций в выдаче и т.д., но, нужно выбирать — либо стабильность и безопасность сервера либо ПР (ака «Page Rank») и позиции в результатах поиска.
Fail2ban можно заточить/допилить почти под любые запросы/сервисы. Все описанные здесь примеры приведены на примере собственного опыта, часть которых успешно используются на данном сервере — поэтому «непидрулите» к нашему сайту без HTTP заголовка «Accept» и «User-Agent», не пытайтесь «брутфорсить» базовую HTTP авторизацию и ведите себя хорошо, а иначе будете добровольно-принудительно, как минимум на пару часов, сосланы в «баню»!;)
Олег Головский
