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.
- pyinotify : Python Package Index
- Gamin — Википедия
- Polling (computer science) - Wikipedia, the free encyclopedia
- inotify-tools
- Мониторинг системной активности при помощи inotify
