17.05.2016 13:50
sebres 19 10300 Источник

Это анонс новой версии fail2ban (пока тестовая альфа-ветка), в которой помимо многих других улучшений и вкусностей, хоть и с опозданием, все же появилась давно запланированная поддержка IPv6.
Время, будь оно не ладно — летит с бешеной скоростью.


Коротко перечень нового, уже вошедшего (и с большой вероятностью вольющегося в скором времени) в fail2ban версии 0.10:


  • конечно же поддержка IPv6 (пока только для iptables, iptables-ipset, firewallcmd, pf)
  • новый синтаксис для псевдо-условных разделов в файлах конфигурации, используется для условного замещения и интерполяции параметров для различных хост-типов, пример [Init?family=inet6] (в настоящее время пока используется только для поддержки IPv6)
  • существенное увеличение производительности fail2ban по сравнению с версией 0.9.x
  • предотвращение регрессии производительности с ростом числа IP адресов (failure и ban)
  • предотвращение ситуации out of memory, при большом количестве failure от многих IPs (maxEntries), а также оптимизация использования памяти в менеджере FailManager
  • (str2seconds) удобная настройки времени в конфигурации, т.е. возможно использование 1h вместо 3600 или 1d вместо 86400, и т.д.
  • (seekToTime) — быстрый старт, предотвращает долгое чтение больших файлов в первый раз после запуска службы
  • умное кэширование всего и вся (dnsToIp, ipToName, пре-интерполяции параметров вызова action и т.д.)
  • [cкоро] слияние с моей incremental версией (ветка ban-time-incr)
  • [cкоро] настраиваемый изменяемый бан-фактор (новая версия ban-time-incr), например гео-зависимость IP-адреса, ниже пример конфигурации, где IP-адрес в десять раз раньше будет считается "плохим", если страна не Россия)
    geo.country = RU:1 default:10
  • [cкоро] автоматическая настраиваемая блокировка под-сетей
  • [cкоро] полностью переписанный client-server (возможность исполнения в режиме foreground, покрытие тестами, новая команда «restart» в дополнение к «reload», изменяемый уровень детализации до heavydebug при старте и другие улучшения)

Существенный рост производительности в fail2ban версии 0.10 можно грубо оценить в следующих цифрах:


Оценка / Версия 0.9.4 0.10
Среднее время реакции (Задержка нахождения failure) 200 мс 15 мс
Среднее время до блокировки (Задержка блокировки) 150 мс 10 мс
Максимальное время реакции (Задержка нахождения failure) 500 мс 30 мс
Максимальное время до блокировки (Задержка блокировки) 1000 мс 20 мс
Средняя скорость блокировки 6 IP/сек 170 IP/сек
Рост задержки блокировки (Регрессия) 100 мс/1000 IPs 5 мс/1000 IPs

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


Для тех кто-читал мою статью "Fail2ban [incremental]: Лучше, быстрее, надежнее" или пользуется этой "инкрементальной" версией — эти ветки пока к сожалению еще не слились (постараюсь закончить в ближайшее время).


Так же планируется автоматическая настраиваемая блокировка под-сетей (т.к. особенно актуально для IPv6-адресов). Просто класть в бан по отдельности 216 (или 65.536) IPv6-адресов при наличии у злоумышленника под-сети X::/112 как-то не комильфо (умолчим уже про под-сети высшего порядка).
Надеюсь до релиза 0.10 этот функционал все-таки допилится.


Я повторюсь, 0.10 — это пока тестовая ветка. Все кто хочет принять участие в тестировании или доработать например поддержку других action — добро пожаловать.


Скачать:
https://github.com/fail2ban/fail2ban/archive/0.10.zip


Гит:
git clone -b 0.10 https://github.com/fail2ban/fail2ban.git

Поделиться с друзьями
-->

Комментарии (19)


  1. questor
    17.05.2016 20:20
    #9613592

    [cкоро] слияние с моей incremental версией (ветка ban-time-incr)

    Хорошие новости, всё жду когда уже дойдёт и до этой фичи. Два года, считай.


    1. sebres
      17.05.2016 20:45
      #9613628

      Можно было все два года юзать (я ветку постоянно держал стабильной, и регулярно сливал с критичными изменениями из master).


  1. pfactum
    17.05.2016 20:58
    #9613654

    Скажите, а nftables уже полноценно поддерживается?


    1. sebres
      17.05.2016 21:03
      #9613662
      +1

      Ну как бы и в 9-й (соответственно в 10-й ветке) уже полгода как, см. https://github.com/fail2ban/fail2ban/pull/1292
      Вопрос только, что вы имеете ввиду под словом "полноценно"? ;)


      1. pfactum
        17.05.2016 21:09
        #9613670

        О, похоже, этот мерж я упустил из виду. Спасибо.


    1. foxmuldercp
      17.05.2016 22:23
      #9613794

      Их уже можно в полноценный продакшен выпускать?
      у меня знакомые сетевики говорят что в серверный продакшен — ещё раано


      1. agic
        18.05.2016 10:22
        #9614274

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


  1. dfm
    18.05.2016 08:34
    #9614170

    Скажите, когда можно ожидать централизованное управление для большого количества серверов? Вроде недавно что-то мелькало про это на хабре.


    1. hamnsk
      18.05.2016 10:21
      #9614272

      а puppet вам чем не угодил?


      1. dfm
        18.05.2016 10:39
        #9614294

        Речь идет, например, о возможности иметь единую базу «плохих» IP без велосипедов и костылей.


    1. sebres
      18.05.2016 13:38
      #9614664

      Сразу так и не скажу, в планах есть. Пока, к сожалению — только костыли...


  1. ITMatika
    18.05.2016 13:36
    #9614660
    -1

    С Debian дружит? А то в прошлой версии был баг, нужно было танцевать с бубном. Я в первый раз вроде справился. Во-второй — не получилось :)


    1. sebres
      18.05.2016 13:55
      #9614708

      в прошлой версии был баг

      Баг-репорт?


      Debian — мажорная система для fail2ban. Начиная с того, что все тест-кейсы на нем бегают и заканчивая тем, что это primary-система более половины разрабов (включая меня).


      Не нужно там было никогда "танцевать с бубном", от слова совсем. Ну а для тех у кого руки не оттуда растут у кого с "готовкой" проблемы (типа умею, но только из коробки в микроволновку если), yarikoptic делает готовые пакеты на neurodebian — http://neuro.debian.net/pkgs/fail2ban.html. Ставьте оттуда на здоровье.


      Десятку он кстати тоже собирался там выложить альфой. Как появится отпишусь здесь.


      1. ITMatika
        18.05.2016 14:08
        #9614732

        Так в комментариях же к той статье было: https://habrahabr.ru/post/238303/#comment_8213663
        На одном сервере установить получилось. На другом — с этим файлом fail2ban.init — нет. Сложно сказать, почему. Признаю проблемы с «готовкой», далёк я от администрирования никсов.
        В любом случае спасибо за ваш труд и за ссылку на neurodebian тоже :)


        1. yarikoptic
          18.05.2016 16:20
          #9615074
          +1

          Только могу добавить что для тех кто хочет получить наиболее гладкую инсталяцию я рекомендую устанавливать стабильную версию которая идёт с вашим дистрибутивом (например стабильным Debian) — может она будет немного старовата, но зато установка и использование должно быть гладким как по маслу. Я заливаю в NeuroDebian только после того как заливаю в Debian, но в Debian пакет проживает стабилизацию пока оказывается в стабильном релизе OS.


  1. foxmuldercp
    18.05.2016 23:20
    #9615918

    Кстати, а меня интересует внутренняя идеология работы ф2б.
    Например — как идет навешивание правил на логи?
    вот, допустим, у меня на один лог опача навешивается с десяток фильтров.
    А если на хосте шаредхостинга тысячи виртуалок и на каждый лог навешивается по десятку фильтров?


    1. sebres
      19.05.2016 01:07
      #9616004

      т.е. то что апач пишет тысячу логов вас не смущает?.. На самом деле, оно не сильно страшно, пока те логи из системного кэша не вымываются или если backend типа systemd и подобных. Конечно качество фильтров и количество "паразитных" (для
      f2b) строк в логе, т.е. тех что не failure, сильно влияет на скорость и нагрузку, поэтому f2b можно и нужно настраивать… например писать failure в отдельный лог, который скармливаем f2b. Да много чего можно сделать...


      1. foxmuldercp
        19.05.2016 15:58
        #9616974

        У меня апач пишет 4 лога — access+error на 80 + ssl раздельно.
        Кстати, как можно настроить логирование ф2бан чтобы было видно из-за какого лога айпишник влетел в банилку?
        grep $ip /var/log/apache/* когда в системе тысячи логов — может затянуться, а понять почему его банит — нужно и быстро.


        1. sebres
          19.05.2016 16:58
          #9617108

          Если вы пользуете fail2ban от 0.9 (с поддержкой sqlite) то могу предложить например такой велосипед — скрипт показывающий все failures с одного IP. Т.е. в этом случае в логи лезть практически не надо.


          ?sudo? sudo python -c "ip='1.2.3.4'; db='/var/lib/fail2ban/fail2ban.sqlite3';  import sys, logging; logging.basicConfig(stream=sys.stdout, level=logging.ERROR); from fail2ban.server.database import Fail2BanDb; db = Fail2BanDb(db); t = db.getBansMerged(ip=ip); print(('%d attempts, matches:\n  %s' % (t.getAttempt(), '\n  '.join(t.getMatches())) ) if t else 'NOT FOUND')"

          Если без велосипедов или нет поддержки db, пока только либо разделив все логи по разным jail (с одним и тем же фильтром), соответственно сразу зная лог, откуда уши растут.


          Либо используя какой-нибудь дополнительный action, например определив action = %(action_mwl)s после бана f2b вам отправит письмо с информацией чего наделал этот IP (см. action_mwl в jail.conf).
          В принципе ничего не мешает создать свою action на примере того же action.d/blocklist_de.conf (искать тэг <matches> который содержит все это добро), что бы например дополнительно писать всю информацию банненых IP в один файл.


          Вообще-то выглядит как новый FR, для чего-нибудь типа fail2ban-client status ..., как дополнительный flavor… Добавте FR-issue, может и реализуется когда (в принципе ничего сложного не вижу).