Не работает fail2ban после обновления

logo

article fail2ban перестал работать, ловить события и блокировать ИП, после обновления до 0.8.11. fail2ban успешно запускается, создаёт изоляторы, но не работает должным образом.

Мы не можем себе позволить чтобы fail2ban не работал имхо на сервер постоянно лезут разные боты, хакеры и взломщики разных национальностей и вероисповеданий, а значит просто обязаны понять и решить проблему...

Автоматическое обновление, как и почти всё автоматическое, а особенно для рабочего сервера, это ЗЛО - по предназначению чем-то схоже с кнопкой "Сделать всё хорошо" http://button.dekel.ru/

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

На сервере использовались:


  • CentOS 6.x (kernel 2.6.32-431.1.2.0.1.el6.x86_64)
  • Fail2Ban 0.8.11
  • gamin-python-0.1.10-9.el6.x86_64
  • gamin-0.1.10-9.el6.x86_64

Несмотря на то, что fail2ban успешно запускался, создавал изоляторы, но он всё же не работал и никак не реагировал на происходящие вокруг него события. Правила проверены "fail2ban-regex /tmp/test_log <REGEX>" и являются рабочими.

Предположив, что это возможно результат какой-то "нъю феартуреса" пошел читать Fail2Ban ChangeLog:

ver. 0.8.11 (2013/11/13) - loves-unittests-and-tight-DoS-free-filter-regexes
...
- Fixes:
* Backends changes detection and parsing. Close gh-223 and gh-103:
     - Polling backend: detect changes in the files not only based on
       mtime, but also on the size and inode.  It should allow for
       better detection of changes and log rotations on busy servers,
       older python 2.4, and file systems with precision of mtime only
       up to a second (e.g. ext3).

Вот оно, кажись, откуда ноги ростут - результат фикса "Backends changes detection and parsing":Polling backend: detect changes in the files not only based on mtime, but also on the size and inode. Т.е. - Опрос бакэнда: определение изменений в файлах не только на основе mtime, но и на основе размера, а также inode.

Изменив "loglevel = 3", в файле /etc/fail2ban/fail2ban.local, на "loglevel = 4" и перезапустив Fail2Ban я обнаружил, что Fail2Ban начал работать и успешно блокировать IP адреса по нужным событиям, но после возврата в "loglevel = 3" Fail2Ban снова перестал работать.

Как проверялась работоспособность? Проверял по событиям ModSecurity, например "Request Missing an Accept Header", которое можно вызвать обратившись к своему серверу/сайту через сканер уязвимости, например http://hackertarget.com/joomla-security-scan/ (можно использовать независимо от CMS), который при обращении к сайту не посылает HTTP заголовок Header, после чего проверяем tail -f /var/log/fail2ban.log и "iptables -L -n" цепочку (Chain) "Chain fail2ban-MODSEC".

Предположив, что проблема связана с упомянутым ранее фиксом (Polling backend), а именно определением изменения лог. файлов, я начал ковырять /etc/fail2ban/jail.local, чтобы попробовать изменить способ определения изменения лог. файлов, которые анализирует Fail2Ban.

Доступны такие методы определения модификации лог. файлов, как "pyinotify", "gamin", "polling" and "auto" - по умолчанию установлено значение "backend = auto", которое я изменил на "backend = gamin", разумеется gamin уже установлен в системе:

# "backend" specifies the backend used to get files modification.
# Available options are "pyinotify", "gamin", "polling" and "auto".
# This option can be overridden in each jail as well.
#
# pyinotify: requires pyinotify (a file alteration monitor) to be installed.
#              If pyinotify is not installed, Fail2ban will use auto.
# gamin:     requires Gamin (a file alteration monitor) to be installed.
#              If Gamin is not installed, Fail2ban will use auto.
# polling:   uses a polling algorithm which does not require external libraries.
# auto:      will try to use the following backends, in order:
#              pyinotify, gamin, polling.
#backend = auto
backend = gamin

И о чудо..., заработало! Значит проблема была с автоматическим определением метода.

Это ещё раз доказывает, что автоматическое определение и автоматическое обновление не всегда одинаково полезны!

Установите пакеты "yum install python-inotify gamin", если они ещё не установлены, проверяем "python -m pyinotify -v /tmp". Если Fail2Ban использует gamin, то "ps aux|grep gam" он должен висеть в процессах /usr/libexec/gam_server.

Рекомендуемый контент

Об авторе
АдМинь БагоИскатель
АдМинь БагоИскатель ярый борец за безглючную работу любых механизмов и организмов во всей вселенной и потому пребывает в вечном поиске всяческих багов, а тот кто ищет как известно всегда находит. Когда что-то или кого-то вылечить не в состоянии, то со словами "Я в аду, а вы все черти" уходит в запой выйдя из которого снова берётся лечить неизлечимое.
Ещё статьи автора

Комментарии   

Олег Головский
0 #2 Олег Головский 05.02.2014 12:17
gamin не рекомендуют использовать: https://bugzilla.redhat.com/show_bug.cgi?id=483510

вместо "gamin" лучше либо "polling" либо "pyinotify", но "pyinotify" чёт не хочет работать

ещё хорошо бы в статью домазать инфу про различие методов pyinotify, gamin и polling
Цитировать
Иван Шаман
0 #1 Иван Шаман 23.12.2013 19:46
Есть такая тема: https://github.com/fail2ban/fail2ban/issues/509

Как я вижу она довольно старая и наболевшая, вероятно связана с автоматическим выбором inotify, когда "backend = auto" например, и использованием множественных изоляторов на одном лог. файле...
Цитировать

Добавить комментарий

АХТУНГ! Все комменты модерасятся модерастом. Мессаги исключительно рекламного или оскорбительного содержания не публикуются, а поэтому злостным спамерам, пранкерам и прочей сетевой нечисти рекомендуем напрасно не тратить своего времени и удовлетворять свои больные фантазии на специализированных Интернет ресурсах! Разумная же критика, замечания, дополнения и хвалебные оды приветствуются, также допускается легкий флуд или троллинг :)


Защитный код
Обновить

Новое на форуме