Я использую fail2ban/firewalld ограничить доступ ботов к Nginx сервер. Обычно конфигурация соответствующей клетки выглядит так:
[nginx-botsearch]
#banaction = iptables-multiport
enabled = true
filter = nginx-botsearch
logpath = /var/log/nginx*/*access*.log
maxretry = 3
bantime = 3600
Это работает как ожидалось (по умолчанию для запрета используется firewallcmd-ipset), т.е. iptables -L показывает запись в INPUT_direct цепочка:
REJECT tcp -- anywhere anywhere multiport dports http,https match-set fail2ban-nginx-botsearch src reject-with icmp-port-unreachable
с соответствующими ipset из fail2ban-nginx-botsearch.
Однако я заметил странное поведение, когда bantime увеличена. Все работает как положено для bantime <= 4294967. Когда я установил bantime = 4294968 и перезагрузить fail2ban сервис, запись в iptables вывод отсутствует (ipset не создается) и действительно, тестирование, например, с ab Утилита показывает, что запрет не применяется. Интересно, что используя banaction = iptables-multiport работает даже при «больших» банах. В чем может быть причина такого поведения? Я использую fail2ban v 0.9.7 на CentOS 7.
Это не совсем fail2ban связанная проблема, скорее ошибка в netfilter код вашего ядра. Короче, ваша версия ipset имеет целочисленное переполнение для timeout параметр, поэтому вы видите непредсказуемое поведение, когда оно превышает 32-битное целое число.
Вы не увидите этого с мультипортом, поскольку он не использует этот код и вместо этого полагается на свои собственные устройства для отслеживания тайм-аутов.
Вот ссылка на сайт к исправлению этой проблемы в коде netfilter.