Структура конфигурационных файлов Fail2Ban
Конфигурационные файлы программы Fail2Ban для Ubuntu расположены в директории /etc/fail2ban/ и имеют внутри этого каталога следующую структуру:
|-- action.d | `-- *.conf | `-- ... |-- fail2ban.d |-- filter.d | |-- ignorecommands | `-- *.conf | `-- ... |-- jail.d | `-- defaults-debian.conf |-- fail2ban.conf |-- jail.conf |-- paths-common.conf |-- paths-debian.conf
Где:
- /etc/fail2ban/action.d/ директория содержит файлы вида *.conf, которые содержат настройки действий программы Fail2Ban при наступлении тех или иных событий.
- /etc/fail2ban/fail2ban.d/ директория по умолчанию пустая, может содержать пользовательские файлы конфигурации для Fail2Ban
- /etc/fail2ban/filter.d/ директория содержит файлы вида *.conf в которых описаны регулярные выражения фильтров для jails. Если вы включили правило и при тестировании его регулярного выражения фильтра вы ведите, что оно не срабатывает, то в этой директории нужно искать соответствующий правилу фильтр и править в нем регулярное выражение.
- /etc/fail2ban/jail.d/ директория содержит файлы вида *.conf которые создаются пользователем и в которых выполняется включение правил/jails и задание для них параметров. По умолчанию в этой директории после установки Fail2Ban находиться только один файл defaults-debian.conf в котором активирован SSH правило/jail. Это значит, что по умолчанию в Ubuntu 16.04 в Fail2Ban сразу включена защита для SSH.
- /etc/fail2ban/fail2ban.conf файл содержит настройки самой программы Fail2Ban (но не настройки правил/jails) и его, как правило, не приходиться корректировать.
- /etc/fail2ban/jail.conf файл, в котором заданы настройки правил/jails по умолчанию. Этот файл содержит все правила и параметры для них по умолчанию. В новой версии Fail2Ban 0.9.x предлагается этот файл не редактировать, а вместо этого использовать кастомные конфиги, которые помещенные в директорию /etc/fail2ban/jail.d/ (подробно см. ниже).
- /etc/fail2ban/paths-common.conf файл с настройками путей для правил/jails, применяется первым.
- /etc/fail2ban/paths-debian.conf еще один файл с настройками путей для правил/jails, применяется вторым и при пересечении переопределяет настройки из paths-common.conf
Примеры правил
В данных примерах блокировка 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
Утилита Linux Fail2Ban
Fail2Ban является удачной утилитой для защиты сервера и его приложений от атак вида подбора/перебора пароля — брутфорса (brute force). Основной принцип работы Fail2ban основан на том, что программа отслеживает превышение количества заданного числа неудачных попыток ввода пароля подряд в течении установленного интервала времени. Такое отслеживание утилита выполняет путем чтения файлов журналов(логов) тех программ, на мониторинг которых она настроена. Fail2Ban просматривает логи и ищет в них строки удовлетворяющие паттерну регулярного выражения из правила фильтра для защищаемой программы. Эти паттерны описывают строки лога, которые отображают неудачные попытки авторизации. Для каждой защищаемой программы формат таких строк свой. При нахождении записей о неудачных попытках авторизации в логах отслеживаемой программы Fail2Ban, в соответствии со своими настройками числа неудачных попыток, выполняет бан IP, с которого выполнялись эти попытки. Технически, для блокирования IP такого клиента Fail2ban использует системный фаервол firewall Linux — Netfilter. Бан выполняется путем задания цепочки правил для Netfilter, направленных на временное блокирование IP клиента.
В Linux существует так же утилита командной строки — iptables, которая является стандартным интерфейсом управления работой межсетевого экрана (брандмауэра) Netfilter. Иногда, в различных описаниях, под словом iptables имеется в виду межсетевой экран Netfilter, хотя в действительности это разные утилиты.
Fail2Ban очень мощная утилита и поставляется сразу с уже настроенными фильтрами для защиты достаточно большого числа программ, список которых постоянно расширяется. Во многих случаях бывает достаточно только включить правило для нужной вам программы и Fail2Ban начнет защищать подключения и авторизации для нее. Однако, иногда может потребоваться более детальная настройка или написание собственных фильтров и правил, а так же тестирование и проверка их работы, что и будет описано ниже. Также, учитывая то, что Fail2Ban выполняет постоянный мониторинг логов отслеживаемых программ, наверное, не следует задействовать излишне много включенных фильтров, что бы не нагружать систему, особенно, когда зашита программы можно сделать и ее собственными средствами. Иными словами не стремитесь включить все фильтры, а делайте это только там где это действительно необходимо и где вы вынуждены предоставлять сервис или службу публично, оставив открытый для нее стандартный порт. Если же вы можете закрыть порт службы для подключений из вне, то это будет лучше чем оставить его открытым, но защищать при этом программой Fail2Ban. Например, если вам не нужны внешние прямые подключения к MySQL т.к. вы работаете с ним при помощи phpmyadmin, то лучше просто закрыть во внешнюю сеть MySQL порт 3306, чем включать правило mysqld в Fail2Ban. Закрытие/открытие портов на выбранных сетевых интерфейсах (сетевых подключениях) удобно выполнять при помощи утилиты arno-iptables-firewall, которая является надстройкой над Linux межсетевым экраном Netfilter, проста в использовании и присутствует в репозиториях Ubuntu.
Использование Fail2Ban не ограничивается только стандартными приложениями, установленными в системе. Вы может применить Fail2Ban и для мониторинга логов своего приложения и настроить правила и фильтры его защиты. Так, например, если ваше WEB приложение подразумевает авторизацию, то вы можете все неудачные попытки авторизации писать в свой лог приложения. Затем, на основе уже имеющихся в Fail2Ban правил и фильтров, сделать их для своего приложения путем изменения лишь регулярного выражения и названий, что будет достаточно просто выполнить и не потребует детального изучения написания цепочек для Netfilter фаервола.
Настройка Fail2ban для SSH
Мы можем настроить Fail2ban, изменив файл /etc/fail2ban/jail.conf. Перед изменением сделайте резервную копию этого файла.
ubuntu@ubuntu:~$ sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Теперь мы настроим Fail2ban, чтобы предотвратить злонамеренные входы в службу sshd. Откройте файл /etc/fail2ban/jail.local в своем любимом редакторе.
ubuntu@ubuntu:~$ sudo nano /etc/fail2ban/jail.local
Перейдите в раздел и введите параметры конфигурации в разделе .
ignoreip = 127.0.0.1/8 192.168.18.10/32 bantime = 300 maxretry = 2 findtime = 600
ignoreip – это список масок cidr, IP-адресов или DNS-хостов, разделенных пробелом. Добавьте свои доверенные IP-адреса в этот список, и эти IP-адреса будут внесены в белый список и не будут заблокированы fail2ban, даже если они выполнят атаку грубой силы на сервере.
bantime – это время, в течение которого IP-адрес будет заблокирован после определенного количества неудачных попыток доступа к серверу.
maxretry – это максимальное количество неудачных попыток, после которых IP-адрес блокируется fail2ban на определенное время.
findtime – это время, в течение которого, если хост делает неудачные попытки maxretry, он будет заблокирован.
После настройки вышеуказанных параметров теперь мы настроим сервис, к которому будут применяться вышеуказанные правила. По умолчанию Fail2ban имеет предварительно определенные фильтры для различных сервисов, поэтому нам не нужно вводить какие-либо конкретные записи для сервисов. Мы только включаем или отключаем различные службы в файле конфигурации. Откройте файл /etc/fail2ban/jail.local в своем любимом редакторе.
ubuntu@ubuntu:~$ sudo nano /etc/fail2ban/jail.local
Найдите в файле раздел и введите в него следующие параметры.
enable = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 3
- enabled определяет, защищена ли эта служба с помощью fail2ban или нет. Если включено – истина, то служба защищена; в противном случае он не защищен.
- port определяет служебный порт.
- filter относится к файлу конфигурации, который будет использовать fail2ban. По умолчанию он будет использовать файл /etc/fail2ban/filter.d/sshd.conf для службы ssh.
- logpath определяет путь к журналам, fail2ban будет следить за защитой сервиса от различных атак. Для службы ssh журналы аутентификации можно найти в /var/log/auth.log, поэтому fail2ban будет отслеживать этот файл журнала и обновлять брандмауэр, обнаруживая неудачные попытки входа в систему.
- maxretry определяет количество неудачных попыток входа в систему, прежде чем они будут заблокированы fail2ban.
После применения вышеуказанной конфигурации для fail2ban перезапустите службу, чтобы сохранить изменения.
ubuntu@ubuntu:~$ sudo systemctl restart fail2ban.service ubuntu@ubuntu:~$ sudo systemctl status fail2ban.service
Клиент Fail2ban
Fail2ban поставляется с инструментом командной строки с именем fail2ban-client, который вы можете использовать для взаимодействия со службой Fail2ban.
Для просмотра всех доступных опций вызовите команду с опцией -h:
fail2ban-client -h
Этот инструмент можно использовать для блокировки/разблокировки IP-адресов, изменения настроек, перезапуска службы и многого другого. Вот несколько примеров:
- Проверьте статус тюрьмы:
sudo fail2ban-client status sshd
- Разбанить IP:
sudo fail2ban-client set sshd unbanip 23.34.45.56
- Запретить IP:
sudo fail2ban-client set sshd banip 23.34.45.56
Сценарии настройки
В реальной жизни настройки могут быть несколько сложнее, чем приведенные здесь или в официальной документации. Рассмотрим несколько примеров, что может понадобиться настроить при балансировке.
1. Backend на https
Предположим, что наши внутренние серверы отвечают по SSL-каналу. Таким образом, нам нужно отправлять запрос по порту 443. Также схема проксирования должна быть https.
Настройка сайта:
server {
…
location / {
proxy_pass https://dmosk_backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
…
}
* обратите внимание на 2 момента:
- Мы в схеме подключения proxy_pass указали https. В противном случае при подключении NGINX будет возвращать ошибку 400.
- Мы задали дополнительные опции proxy_set_header, которых не было в примерах выше.
Настройка upstream:
upstream dmosk_backend {
server 192.168.10.10:443;
server 192.168.10.11:443;
server 192.168.10.12:443;
}
* в данном примере мы указали конкретный порт, по которому должно выполняться соединение с бэкендом. Для упрощения конфига дополнительные опции упущены.
2. Разные бэкенды для разных страниц
Нам может понадобиться разные страницы сайта переводить на разные группы внутренних серверов.
Настройка сайта:
server {
…
location /page1 {
proxy_pass http://backend1;
}
location /page2 {
proxy_pass http://backend2;
}
…
}
* при такой настройке мы будем передавать запросы к странице page1 на группу backend1, а к page2 — backend2.
Настройка upstream:
upstream backend1 {
server 192.168.10.10;
server 192.168.10.11;
}
upstream backend2 {
server 192.168.10.12;
server 192.168.10.13;
}
* в данном примере у нас есть 2 апстрима, каждый со своим набором серверов.
3. На другой хост
Может быть необходимым делать обращение к внутреннему ресурсу по другому hostname, нежели чем будет обращение к внешнему. Для этого в заголовках проксирования мы должны указать опцию Host.
Настройка сайта:
server {
…
location / {
proxy_pass https://dmosk_backend;
proxy_set_header Host internal.domain.com;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
…
}
* в данном примере мы будем проксировать запросы на бэкенды, передавая им имя хоста internal.domain.com.
4. TCP-запрос
Рассмотрим, в качестве исключения, TCP-запрос на порт 5432 — подключение к базе PostgreSQL.
Настройка сайта:
server {
listen 5432;
proxy_pass tcp_postgresql;
}
* в данном примере мы слушаем TCP-порт 5432 и проксируем все запросы на апстрим tcp_postgresql.
Настройка upstream:
upstream tcp_postgresql {
server 192.168.10.14:5432;
server 192.168.10.15:5432;
}
![Fail2ban - установка и настройка [rtzra's hive]](https://myeditor.ru/wp-content/uploads/1/c/2/1c2e59fec6797ac61d66150ef7833b9d.png)
* запросы будут случайным образом передаваться на серверы 192.168.10.14 и 192.168.10.15.
5. UDP-запрос
Рассмотрим также и возможность балансировки UDP-запросов — подключение к DNS по порту 53.
Настройка сайта:
server {
listen 53 udp;
proxy_pass udp_dns;
proxy_responses 1;
}
* в данном примере мы слушаем UDP-порт 53 и проксируем все запросы на апстрим udp_dns. Опция proxy_responses говорит о том, что на один запрос нужно давать один ответ.
Настройка upstream:
upstream udp_dns {
server 192.168.10.16:53;
server 192.168.10.17:53;
}
* запросы будут случайным образом передаваться на серверы 192.168.10.16 и 192.168.10.17.
Настройка fail2ban для запрета запросов в Nginx 403 Forbidden
Обзор установки
- Генерация данных журнала
- Настройка Fail2ban фильтра и jail
Генерация данных журнала для 403 ошибки
Перейдите на URL, который запрещен вашим виртуальным хостом Nginx, чтобы сгенерировать данные журнала
Показажите последние 50 строк вашего файла журнала Nginx
Мы нашли эти записи, которые будут использоваться в качестве основы для фильтра fail2ban для бана пользователей, которые генерируют ошибку 403 forbidden
Теперь, когда у нас есть данные журнала мы можем создать фильтр для fail2ban.
Настройка fail2ban для ошибки в Nginx 403 Forbidden
Нам нужно создать фильтр Fail2ban, который будет соответствовать ошибки из файла журнала. Затем мы создаем jail чтобы использовать этот фильтр и запретить пользователей.
Создание фильтра Fail2ban для запросов forbidden в Nginx
Создать затем фильтр для Nginx
Добавьте это регулярное выражение, которое будет соответствовать ошибке 403 forbidden в журналах Nginx
Ctrl + X, Y + Enter, чтобы сохранить изменения и выйти.
Теперь мы можем проверить фильтр аутентификации Nginx HTTP, сканируя журнал ошибок, указанный в виртуальном хосте Nginx.
Вы увидите этот вывод, который показывает, что нашел неудачные попытки входа, которые мы сгенерировали ранее.
Running tests ============= Use failregex file : /etc/fail2ban/filter.d/nginx-forbidden.conf Use log file : log Results ======= Failregex: 2 total |- #) regular expression | 1) ^ \ \d+#\d+: .* forbidden .*, client: <HOST>, .*$ `- Ignoreregex: 0 total Date template hits: |- date format | Year/Month/Day Hour:Minute:Second `- Lines: 2 lines, 0 ignored, 2 matched, 0 missed
Создание Jail в Fail2ban для запретных запросов в Nginx
Убедитесь, что у вас есть в Fail2ban папка jail
Создайте конфигурационный файл jail Fail2ban в Nginx для HTTP аутентификации
Вставьте эту конфигурацию, которая использует фильтр, который мы создали ранее, который сканирует все файлы журналов Nginx и запрещает пользователям в течение 6000 минут, которые сгененировали ошибку 3 раза в 60-секундный период.
Теперь, когда мы знаем, сделаем jail, проверим синтаксис Fail2ban, чтобы убедиться, что это все работает
Если вы не видите каких-либо ошибок (предупреждения OK), то можно перезапустить fail2ban
Проверка состояния nginx на запрещеное в fail2ban
Клиент Fail2ban может быть использован, чтобы показать статистику своих мест заключения
Во время тестирования на виртуальных машинах, мне удалось получить забаненный шлюз.
Вы также можете перечислить IPTables
Это показывает цепочку Iptables для Nginx запрещенных в jail
Любые боты, которые сканируют и вызывают ошибку 403 forbidden в Nginx, теперь будут автоматически запрещены в Fail2ban.
Запуск fail2ban
Теперь необходимо запустить (или перезапустить) fail2ban и (если это необходимо, например iptables еще не был запущен) iptables.
Для запуска iptables (его нужно запустить первым) выполните следующую команду:
Для перезапуска fail2ban выполните следующую команду:
Для проверки, что fail2ban запущен успешно и правило загружено, выполните следующую команду:
и (если есть второе правило)
Для отображения списка правил iptables выполните следующую команду:
В случае, если Вы только что установили fail2ban / iptables, не забудьте убедиться, что они настроены у Вас стартовать автоматически при загрузке системы!
Конфигурация Fail2ban
На данном этапе Fail2ban уже готов к работе, базовая защита SSH сервера от перебора паролей будет включена по умолчанию. Но лучше всё-же внести некоторые изменения следуя рекомендациям ниже.
У программы два основных файла конфигурации:
- — отвечает за настройки запуска процесса Fail2ban.
- — содержит настройки защиты конкретных сервисов, в том числе sshd.
Файл поделён на секции, так называемые «изоляторы» (jails), каждая секция отвечает за определённый сервис и тип атаки:
ignoreip = 127.0.0.1/8 bantime = 600 maxretry = 3 banaction = iptables-multiport enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 6
Параметры из секции применяются ко всем остальным секциям, если не будут переопределены.
Секция отвечает за защиту SSH от повторяющихся неудачных попыток авторизации на SSH–сервере, проще говоря, «brute–force».
Подробнее по каждому из основных параметров файла jail.conf:
-
ignoreip — IP–адреса, которые не должны быть заблокированы. Можно задать список IP-адресов разделённых пробелами, маску подсети, или имя DNS–сервера.
-
-
bantime — время бана в секундах, по истечении которого IP–адрес удаляется из списка заблокированных.
-
maxretry — количество подозрительных совпадений, после которых применяется правило. В контексте — это число неудавшихся попыток логина, после которых происходит блокировка.
-
enabled — значение указывает что данный jail активен, выключает действие изолятора.
-
port — указывает на каком порту или портах запущен целевой сервис. Стандартный порт SSH–сервера — , или его буквенное наименование — .
-
filter — имя фильтра с регулярными выражениями, по которым идёт поиск «подозрительных совпадений» в журналах сервиса. Фильтру соответствует файл .
-
logpath — путь к файлу журнала, который программа Fail2ban будет обрабатывать с помощью заданного ранее фильтра. Вся история удачных и неудачных входов в систему, в том числе и по SSH, по умолчанию записывается в log–файл .
Управление правилами 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).
Разблокировка 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 с помощью можно выполнить следующую команду
