Fail2Ban IPv6 support - approaches

fail2ban IPv6

Fail2ban needs IPv6 support
===========================

Summary
-------

Fail2ban's IPv6 support in the underneath layers is easy enough but how do we process action files? A large number of user defined action files exist, some support IPv6 and some don't. Netfilter and other mechanism like ipset can sometimes require a totally different set of tools to deal with IPv4 vs IPv6. To complicate this more it may be needed to block IPv6 network addresses rather than individual IPv6 addresss as they are often handed out in block. An attacker could quite easily control a /64  IPv6 addresss pace and the single banning approach of IPv4 may not be as effective.

References
----------

https://github.com/fail2ban/fail2ban/issues/39
https://github.com/fail2ban/fail2ban/pull/88
http://sourceforge.net/mailarchive/message.php?msg_id=27249783
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470417

Requirements
------------

- Compatibily - Existing users have .local files of the action files that may not be IPv6 compatible if we start putting an IPv6 address in <ip>
- Flexible - Fail2ban was written as a flexible architecture. We'd like our users to be able to write any action file in a IPv6 way and not be too impeded if some tools are IPv4 only. We'd like a user upgrade of fail2ban not to break their existing rules.
- Readible - Action files should be readible by a non expert and be able to work out what they do


Approaches
==========

IPtables Wrapper
----------------

Concept
~~~~~~~

ActionBan / ActionUnban execute a wrapper script. This wrapper script identifies if the address(es) are IPv4 or IPv4 and subsequently executes the approprate backend, like ip6tables/ iptables.

Addressing Requirements
~~~~~~~~~~~~~~~~~~~~~~~

Compatible: a boolean jail config option ipv6 will default to false and be enabled by users when they are sure their .local action scripts work.
Flexible: Because of iptables/ip6tables syntax compatiblity the wrapper script should work for all iptables/ip6tables actions. 
Readible: The only change is the name of the first command command in the action files. 

Action Files
~~~~~~~~~~~~
https://github.com/Th4nat0s/fail2ban/tree/master/config/action.d

Implementation
~~~~~~~~~~~~~~

https://github.com/fail2ban/fail2ban/pull/88

Pros
~~~~

The action files are not increased in size. As iptables/ip6tables are pretty identical in syntax there is no change of different approaches in IPv4 and IPv6.

Cons
~~~~

The script accounts well for iptables based rules. IPsets and other IPfw mechanisms would also require their own explicit wrapper scripts.

Its easy to forget check scripts like "actioncheck = fail2ban-iptables -n -L | grep -q fail2ban-<name>" don't work the same as it did with just  iptables. Here it checks that at least one of IPv4 or IPv6 had the rule containing fail2ban-<name> but the check requires both to exist.

The extra script means the number of system forks/executes is doubled. Addition processing is done within the wrapper script to check if its v4 or v6. This has already been done in the fail2ban core. 

Explicit Definations
-------------------

Concept
~~~~~~~

The fail2ban core creates <ip4> and <ip6> tags dependant of which address family the ban is. If it is an IPv4 address <ip6> isn't defined and if it is a IPv6 address <ip4> isn't defined. The core identifies actions that have tags that are undefined and doesn't execute those aspects of the ban /unban.

The <ip> tag remains and is filled with the address family for IPv4/IPv6 independant actions.

Addressing Requirements
~~~~~~~~~~~~~~~~~~~~~~~

Compatible: a boolean jail config option ipv6 will default to false and be enabled by users when they are sure their .local action scripts work.

Flexible: Because the syntax used is explict its exceptionally easy to write IPv4 and IPv6 actions separately to account for all nuance differences between IPv4 and IPv6 regardless of if it is iptables, ipset, ipfw or another mechanism without chaning the fail2ban core.

Readible: The action files contain raw instructions . The concept of missing tags not being executed needs to be understood. What's there in the config file is exactly what happens and the behaviours of wrappers doesn't need to be examined.

Action Files
~~~~~~~~~~~~

https://github.com/grooverdan/fail2ban/tree/ipv6/config/action.d

Implementation
~~~~~~~~~~~~~~

https://github.com/grooverdan/fail2ban/tree/ipv6

Pros
~~~~

The missing tag approach makes a logical sence, if there's no ipv6 address then it makes no sence to run "ip6tables -I INPUT -s <ip6>...".

The approach accounts for IPsets as per https://github.com/grooverdan/fail2ban/blob/ipv6/config/action.d/iptables-ipset-proto6.conf and is flexible for other IP family specific firewall rules.

This approach can also account for perform netmask blocks in IPv6 and keep IPv4 as single addresses.

No extra abstractions layers requiring more understanding to use.

Less proceses are run and the address family is calculated less.

Cons
~~~~

There are a lot of lines similar as iptables/ipsets are pretty close.

Tag looking structures like <STDIN> (config/action.d/complain.conf) may look like tags and needs to be excluded from substition / removal.