Fail2ban: Избыточная установка в jail.conf для расширенного бана?

Созданный на 7 мар. 2020 · 3Комментарии · Источник: fail2ban/fail2ban

Привет!

Я изучал новую функцию bantime.increment и теперь у меня есть пара вопросов:

jail.conf прежнему содержит часть [recidive] которая использовалась для проверки selflog, чтобы запретить ранее запрещенные IP-адреса, но новый bantime.incement как раз для этого. Разве это не лишнее сейчас?
комментарии bantime.increment не говорят о том, как это связано с findtime и maxretry . Если первый бан закончился, то второй будет сразу же установлен, как только он будет обнаружен, или он должен произойти в findtime для maxretry а затем он будет установлен с увеличенным время?
В комментариях говорится о том, что по умолчанию используется banTime * 1, 2, 4, 8, 16, 32... что для меня означает, что это может продолжаться бесконечно, но #bantime.formula = ban.Time * (1<<(ban.Count if ban.Count<20 else 20)) * banFactor показывает, что он будет максимальным на 2 ^ 20. Какая из них верна?
Может ли bantime.multipliers иметь неопределенное количество множителей или только 20?

how-to

Источник

electrofloat

Самый полезный комментарий

он действительно избыточен, но остался для обратной совместимости (а также для некоторых специальных целей);
# 1460 description содержит таблицу, иллюстрирующую это (я еще должен добавить это в нашу вики);
вкратце - одна и та же экспоненциальная формула будет использоваться для обоих (увеличивает время блокировки и уменьшает максимальное количество попыток);
практически невозможно достичь этого экспоненциально увеличенного времени по умолчанию, потому что по умолчанию время запрета ( 1h ) даже с коэффициентом 1 уже после 13-го бана вырастет до почти 1 года, после 15-го это 4 года, после 18-й - 30 лет, после 19-го - 60 лет, а 20-й бан вызовет 1h * 2<sup i="10">20</sup> , что соответствует примерно 120 годам. С учетом всех запретов, злоумышленника забанили почти на 240 лет!
Такие длительные баны (а также постоянные баны) некрасивы по нескольким причинам, поэтому рекомендуется даже установить bantime.maxtime на несколько недель или 1 месяц. Более длительные запреты просто увеличивают iptables / ipsets, поэтому излишне загружают сетевую подсистему и вообще неосуществимы.
Если (известный как плохой) злоумышленник сделает 1 попытку после бана на 1 месяц, он будет немедленно заблокирован (снова на 1 месяц), так почему же следует использовать более длительный бан? Как бы то ни было, я использую его несколько лет и очень редко наблюдаю некоторые попытки после 2-3 месяцев бана (либо они были «исправлены», меняли IP / провайдера, либо просто удаляли мои защищенные хосты из списка целей атаки).
Это не ограничено, но, как уже было сказано, в этом нет необходимости.

sebres 7 мар. 2020

👍2

Все 3 Комментарий

он действительно избыточен, но остался для обратной совместимости (а также для некоторых специальных целей);
# 1460 description содержит таблицу, иллюстрирующую это (я еще должен добавить это в нашу вики);
вкратце - одна и та же экспоненциальная формула будет использоваться для обоих (увеличивает время блокировки и уменьшает максимальное количество попыток);
практически невозможно достичь этого экспоненциально увеличенного времени по умолчанию, потому что по умолчанию время запрета ( 1h ) даже с коэффициентом 1 уже после 13-го бана вырастет до почти 1 года, после 15-го это 4 года, после 18-й - 30 лет, после 19-го - 60 лет, а 20-й бан вызовет 1h * 2<sup i="10">20</sup> , что соответствует примерно 120 годам. С учетом всех запретов, злоумышленника забанили почти на 240 лет!
Такие длительные баны (а также постоянные баны) некрасивы по нескольким причинам, поэтому рекомендуется даже установить bantime.maxtime на несколько недель или 1 месяц. Более длительные запреты просто увеличивают iptables / ipsets, поэтому излишне загружают сетевую подсистему и вообще неосуществимы.
Если (известный как плохой) злоумышленник сделает 1 попытку после бана на 1 месяц, он будет немедленно заблокирован (снова на 1 месяц), так почему же следует использовать более длительный бан? Как бы то ни было, я использую его несколько лет и очень редко наблюдаю некоторые попытки после 2-3 месяцев бана (либо они были «исправлены», меняли IP / провайдера, либо просто удаляли мои защищенные хосты из списка целей атаки).
Это не ограничено, но, как уже было сказано, в этом нет необходимости.

sebres 7 мар. 2020

👍2

Я изменил sendmail-whois.conf, чтобы он содержал <bantime> и <bancount> следующим образом:
actionban = printf %%b "Subject: [Fail2Ban] <name>: banned <ip> from <fq-hostname> for <bantime> seconds # <bancount> time(s)

и получаю странные результаты:

[Fail2Ban] ssh: banned 192.168.56.1 from localhost.localdomain for 2 seconds # 1 time(s)
[Fail2Ban] ssh: banned 192.168.56.1 from localhost.localdomain for 2 seconds # 2 time(s)
[Fail2Ban] ssh: banned 192.168.56.1 from localhost.localdomain for 8 seconds # 3 time(s)
[Fail2Ban] ssh: banned 192.168.56.1 from localhost.localdomain for 2 seconds # 4 time(s)
[Fail2Ban] ssh: banned 192.168.56.1 from localhost.localdomain for 32 seconds # 5 time(s)
[Fail2Ban] ssh: banned 192.168.56.1 from localhost.localdomain for 2 seconds # 6 time(s)

Могу подтвердить, что время бана увеличивается каждый раз, но в почте не всегда. Я что-то упустил или это ошибка?

electrofloat 7 мар. 2020

но по почте это происходит не всегда.

Поскольку продление выполняется полностью асинхронно (злоумышленник должен быть заблокирован как можно скорее), бан может произойти до того, как время запрета действительно увеличится.
Если это ожидается, для этих целей был добавлен другой параметр действия actionprolong , поэтому используйте его вместо actionban .

sebres 9 мар. 2020

👍1

Была ли эта страница полезной?

0 / 5 - 0 рейтинги