Hi
If it's feasible, I wonder why we can't find anything about that in the Internet or in fail2ban site. No one has done it yet? On the contrary, we can find ample "complaints" that fail2ban won't work with IPv6.
Hmm, well on cursory inspection I agree there are some hard coded assumptions. Doesn't look dramatically difficult to fix, but not something I was planning to look at myself.
See: /usr/share/fail2ban/server/filter.py for: IP_CRE = re.compile("^(?:\d{1,3}\.){3}\d{1,3}$")
Also note the functions in the same file to check for duplicate IPs and similar.
(I believe that iptables is still unable to be altered dynamically? Each time you *think* you are inserting a rule, actually you are dropping the entire ruleset, then reinserting the entire new ruleset with one extra rule. This creates a window of opportunity each time you innocently insert a new rule. Further it explains the O(n^2) speed of running "iptables -A" or similar)
Actually, iptables can be altered dynamically; For example, the iptables-multiport action does: actionban = iptables -I fail2ban-<name> 1 -s <ip> -j DROP actionunban = iptables -D fail2ban-<name> -s <ip> -j DROP
"iptables -A" runs only when fail2ban starts.
Please re-read my previous email:
My understanding is that "iptables -[IA]" works internally by first downloading and then clearing the entire old kernel rule list. Then some time later it inserts a new complete rule list including the new rule. It's not clear that this swap is atomic and hence there is a small window of opportunity when you have zero firewall rules in place...
If you find this scary then please do your own research and mitigate as you feel appropriate...
...So back to my suggestion of investigating using ipsets rather than changing any iptables rules... This makes rules properly dynamic and there is no reload involved
Kind regards
Ed W