Как и многие системные администраторы, при настройке fail2ban, я руководствовался «рекомендациями» из интернета.
Чаще всего «рекомендации» были примерно такими: 10 ошибочных попыток за 30 минут и блокировка на 1 час. И особо не задумывался что будет в реальности при таких настройках.
В конце 2024 года решил более внимательно «поковыряться» со всем этим. Но для «ковыряния» нужен «инструмент». Беглый поиск «инструмента» ничего не дал подходящего для меня. Тогда и был написан этот скрипт для «ковыряния».

Защита любого сервиса (ssh, ftp, www, smb…) состоит из двух частей.

1. Аутентификация самим сервисом. Т.е. сам сервис определяет кому/когда/что он может «предоставить». Здесь используются различные методы: ip, пароли, ключи и т.д. Обрабатывается самим сервисом!
2. FireWall. Блокировка доступа к сервису. Т.е. допустить или запретить попадание «запросов» к сервису по тем или иным признакам. FireWall ничего не знает про аутентификацию на сервисе (методы, пароли, ключи и т.д.). Его «задача» определить/найти что сервис отверг запрос и выполнить свои действия.

У некоторых системных администраторов есть, например, мнение, что для ssh не нужен FireWall. Достаточно правильно настроить ssh и только. Считаю подобное - ошибочным мнением. И мой аргумент - FireWall блокирует именно доступ к сервису. Запросы не доходят до сервиса и сервисом НЕ обрабатываются! На тот же ssh в день (24 часа) могут приходить десятки тысяч запросов из интернета с одного ip (атака на ssh по словарю, например). И на все эти запросы ssh будет отвечать отказами (обрабатывать!). Зачем такая нагрузка на ssh, если FireWall способен просто блокировать эти ip? Правильная настройка ssh и FireWall дополняют друг друга.

1. Далее в тексте буду использовать названия параметров из fail2ban:

• findtime = скользящее временное окно поиска «ошибочных» подключений
• maxretry = количество «ошибок» подключений
• bantime = длительность блокировка (ban)

Пример 1:

• findtime = 30m
• maxretry = 30
• bantime = 1h

Т.е. если fail2ban нашел 30 «ошибок» за 30 минут, то хост (ip) блокируется (ban) на 1 час. Это основные настройки fail2ban, но не единственные.

2. Под «ошибкой» подключения подразумеваю любые ошибки любых протоколов, что найдет fail2ban. У fail2ban достаточно большой набор правил поиска таких ошибок для разных протоколов.

3. fail2ban использует две таблицы: «Found» и «Ban». Таблица «Found» обнуляется при перезапуске сервиса fail2ban! Таблица «Ban» всегда сохраняется. Обнуление таблицы «Found» приводит к тому, что fail2ban счетчик «ошибок» обнуляется! Это надо иметь в виду при больших значениях findtime (дни, недели и т.д.)!
Но если был добавлен/изменен фильтр, то нужно перезапустить сервис fail2ban!

Рассмотрим что происходит при настройках из «Пример 1» выше. Допустим хост попал под эти правила и получил ban. Но после окончания bantime этот хост может продолжать свои попытки.

Посчитаем что может получится за 1 день (24 часа) в пределе из «Пример 1» выше.
Для того, чтобы быть «непойманым», атакующему хосту надо делать 30-1=29 попыток за 30 минут. Далее считам. 24 часа / 30 минут = 48 интервалов по 30 минут. 48 интервалов * 29 попыток = 1392 попыток за 24 часа. И это только для одного хоста (ip) за 1 день! Мне это не понравилось.

Плюс надо добавить, что атакующий достаточно легко может получить реальные значения findtime, maxretry и bantime. Это можно сделать в любом скриптовом языке.

int=time_max/(maxretry-1)

time_max=time_max/2

int=time_max/(maxretry-1)

time_min=time_max

time_max=time_max*2

int=time_max/(maxretry-1)

int=((time_min+time_max)/2)/(maxretry-1)

(time_min+time_max)/2

time_min=(time_min+time_max)/2

int=((time_min+time_max)/2)/(maxretry-1)

(time_min+time_max)/2

time_max=(time_min+time_max)/2

int=((time_min+time_max)/2)/(maxretry-1)

time_max-time_min

По сути подобные настройки не годятся для интернета.

В основе этой настройки тоже лежат findtime, maxretry и bantime. Но к ним добавляются параметры bantime.factor, bantime.increment, bantime.formula и еще несколько.
Опишу только идею «Increase Ban».
Если с простыми/жесткими настройками после снятия очередного ban-а fail2ban «работает» с атакующим хостом как с новым, то с настройками «Increase Ban» fail2ban запоминает что атакующий хост уже получал ban и их количество.
Далее все зависит от количества ban-ов, полученных хостом. А именно, геометрическое увеличение времени блокировки и уменьшение попыток подключений за время findtime.
Как пример (работающий, bantime.factor = 1).
Хост получил первый ban. fail2ban запомнил (таблица «Ban»). После снятия ban-а и при попытках хоста опять подключиться, каждая такая попытка будет считаться за 2 попытки. Т.е. хосту дозволено за время findtime сделать не более maxretry/2 попыток. При превышении хост получает очередной ban, но уже на время bantime*2. После снятия этого ban-а (bantime*2) любая попытка этого хоста будет считаться за 3 попытки. Т.е. дозволено за время findtime сделать не более maxretry/3 попыток и за нарушение - ban уже на bantime*4.
Получается, что с каждым последующим ban-ом количество разрешенных попыток за время findtime уменьшается, а время ban-а растет геометрически (1, 2, 4, 8, 16…).
При настройке «Increase Ban» все зависит от фантазии настраивающего. ;))
Только с «Increase Ban» настройками получается успешно блокировать атакующиее хосты интернета у которых интервал попыток 2-3 часа и более. Такие интервалы имеют сеточки хостов при распределенной атаке.

Анализ эффективности настроек fail2ban невозможен без сбора статистик и их анализа. Причем, нужно собирать статистики с разными интервалами.

Собственно описывать скрипт нет смысла - есть «Информация о скрипте» в самом скрипте.
Писал его для себя и он помог и помогает в «разборках» атак и настройках fail2ban, правильных для моих серверов. ;))

Скрипт рабочий, мной активно используется.
Скрипт можно сохранить под именем, например, «Скрипт для fail2ban» (без кавычек).
Файл скрипта Fail2Ban.bash
Файл описания для скрипта Fail2BanInfo.txt