В прошлой заметке, посвященной fail2ban, я описал пару фильтров, используемых мной для предотвращения «вражеских» происков, направленных против моего apache. Работало все это отлично, и вопросов не возникало. И дальше бы работало, если бы меня не потянуло на разборки с Chillispot. Дело в том, что в описанных мной конфигурациях fail2ban блокирование нежелательного доступа осуществляется при помощи shorewall. А его-то я как раз и поломал, ковыряясь с Chillispot. Точнее, не поломал, а отключил, так как для работы Chillispot требуется загрузка своего собственного скрипта с правилами для iptables, который «множит на ноль» всю работу shorewall…
Чтож, iptables, так iptables. Нам-то какая разница!? Нужно всего-лишь заставить fail2ban тоже использовать iptables при блокировании доступа. Для этого залез я в файл /etc/fail2ban/jail.conf и настройки «тюрем» своих поисправлял следующим образом:
[apache-shorewall]
enabled = true
filter = apache-noscript
action = iptables[name=httpd, port=http, protocol=tcp]
logpath = /var/log/httpd/error_log
maxretry = 2
И второй «тюрьме» тоже:
[apache-overflow]
enabled = true
filter = apache-overflows
action = iptables[name=httpd, port=http, protocol=tcp]
logpath = /var/log/httpd/error_log
maxretry = 1
Изменения по сравнению с предыдущим вариантом, описанным мной ранее, для наглядности я выделил красным цветом. Также, если сравнить с предыдущими вариантами, я не стал писать строку со вторым «действием» (action) — отправку письма администратору (mail-whois или sendmail). Ему (мне) и так писем достаточно… Названия самих «тюрем» (те, что в указанных примерах написаны в квадратных скобках) я менять не стал. Они все равно ни на что не влияют, только лишь в лог пишутся.
После внесения указанных изменений перезапустил fail2ban командой:
fail2ban-client reload
И все! Кстати, есть еще одно отличие у данного варианта блокирования по сравнению с shorewall, описанным ранее: iptables блокирует только порт apache…