fail2ban
fail2ban copied to clipboard
IPv6 support master plan
I think that #39 grew out of the proportions to be any longer efficient. So I have decided to organize a new ticket to discuss the high-level development pieces which could largely be taken in steps. Let's continue discussion here at that level, and whenever we finalize the possible plan, detail specific steps in separate issues. So, logical workflow to move off the dead point could IMHO could be be
- Provide basic support for IPv6 addresses in Fail2Ban, at the beginning assuming very conservative prefix (/128). For that -- review/adopt previous work (https://github.com/grooverdan/fail2ban/tree/ipv6, https://github.com/grooverdan/fail2ban/tree/ipv6_2 etc ), without touching actual action definitions, incorporating prefix within the ban ticket (for possible future treatment in 2.) and possibly adopting/using https://github.com/google/ipaddr-py .
- Investigate more and decide on how to deal with variable across use-cases prefixes. Suggested approaches were to
-
variable bantime (@sebres https://github.com/fail2ban/fail2ban/issues/39#issuecomment-59829288) depending on the number of failed attempts within the subnet
-
automatic shrinking of the prefix (@rotanid https://github.com/fail2ban/fail2ban/issues/39#issuecomment-118543341) given growing number of attacks
-
adhere to some very conservative default while maintaining a custom list of network prefixes for known providers/addresses
Also @neirbowj information in https://github.com/fail2ban/fail2ban/issues/39#issuecomment-118527998 .
-
- Look into establishing definitions for support of both ipv4 and ipv6 within action files. See my summary of considered approaches in https://github.com/fail2ban/fail2ban/issues/39#issuecomment-118543134
Although every next step depends on the previous one, I think they have enough of independence to continue discussion in separate issues. ATM I just want to hear from other @fail2ban/contributors and the community if this sounds reasonable.
I think this reflects the separation of issues that I was previously advocating. Basic, equivalent-to-current-IPv4 support for IPv6. Land it, release it.
Then, and only then, start to look at general wider prefix handling generic enough to be applicable to both IPv4 and IPv6. Land it, release it.
And then go from there.
I am not sure we will land/release 1 alone since, as was stated, it could immediately be exploited by an attacker to cause resources exhaustion/DoS. May be only if treatment of IPv6 addresses would be made optional with a big fat warning on possible ramifications.
Maybe something like gradual banning of larger subnets would help? Eg. if f2b bans 25 IPs from /121 subnet, it will ban entire /120 and remove all previous bans for /121. If it later bans another 50 from /120, it will again remove all bans for /120 and ban entire /119. This could be still exploited in some way, but it wouldn't be so easy/fast. (Also I'm not sure if it's technically correct/possible, it's just a thought).
@yarikoptic I can make a IPv6 version as described in your plan, but:
- I will make it iptables/debian only, need help from another contributers for other systems;
- unfortunately I have no interest to make it, as long as #716 and my feature branch based on it + #1116 are not completed resp. both are not mainline (not master), because I see too many conflicts hereafter;
- I see the subnet support as a necessary part of the IPv6, also because of memory exhaustion, increase factor for failure count or time of ban should be applied for subnet's (single IP would be a subset of it), and many other things, why it is really necessary.
the plan sounds good - and i would prefer the optional "1" with default to off and big warning being released. there are use cases, where this is better than f2b doing nothing for IPv6 at all. @mrc0mmand please read the ticket! as far as i understand it, "automatic shrinking of the prefix" does exactly what you are suggesting.
@rotanid I honestly don't know how I could miss that, but now I see it. So sorry and thanks - it's exactly what I mean.
Also, even with 'automatic prefix shrinking' there would be a huge amount of IP addresses, which would be kind of uncomfortable or even slow if we store them in iptables. Wouldn't be eg. ipset better 'default' solution for that? I know even ipset has its limits, but it would be much faster (and probably convenient) than storing that load of IPv6 addresses in iptables.
Could it be possible to implement at first only a block for the specific IPv6 IP? I get tons of logs in my server that fail2ban cannot block the address, because it is an IPv6 address. You can add the /64 or /56 block feature later.
@idefix6 It has already been discussed in #39. Btw, this new topic is to discuss the proper way to implement this, if you need a workaround there are plenty in #39.
Currently we have one table per jail with all banned IPs. We could apply a hierarchical approach, based on ipv6 grouping, to ease the load? Sorry if this has been discussed already.
Currently we have one table per jail with all banned IPs. We could apply a hierarchical approach, based on ipv6 grouping, to ease the load? Sorry if this has been discussed already.
I don't think it was discussed, but I am also not yet familiar with this so can't stay how feasible it will be.
Do you have any new information to support IPv6 banning?
Short - no, we have not. But I work on the solution, unfortunately fewer as secondary priority (there much to do). @fail2ban/developers any thoughts?
:+1: to IPv6 Support :)
+1 .... Did it help? Not really... We know that it is a needed feature, and this issue is not to seek feedback on its desirability, but about the plan. Provide feedback accordingly. Or better -- submit PRs addressing specific parts of the plan for review so feature actually gets implemented. Thanks
edit 1: all non-constructive/0-bit-of-relevant-information comments get removed from this thread
So, as I understand it:
- Get fail2ban to parse IPv6 addresses from logs. I don't think they are logged differently from IPv4.
- At first, have it detect only the /128 prefix for attacks and later have features where it'll see that multiple IPv6 addresses from a similar prefix is attacking and block that prefix. From my research, ISPs normally give a /64 prefix to customers, but would be good to be able to grow the prefix depending on the range of attacks.
- At first, do not modify actions for IPv6, but later maybe have the option to have actionban6 and actionunban6 to specify what to do specifically for IPv6 addresses. As far as I know, UFW will support banning IPv6 in the same way you ban IPv4, so an actionban6 type thing is not needed for it, but I can see where you may need something for say example ip6tables. I think having an actionban6 type variable would be easy to implement.
I believe that getting the basic support can be done rather quickly, but as I have not reviewed the code in full I could be mistaken.
I believe IPv6 support is important as many hosting companies provide IPv6 (such as my own). I would be happy to help implement support for IPv6 once this semester in school is over.
To cut down on spam, I think people should thumb up the post using githubs "Add your reaction" button instead of writing a post saying +1 or something. I for one want IPv6 support, so I have thumbed up the post.
Thank you for your work on this project fail2ban team.
There is a perspective PR https://github.com/fail2ban/fail2ban/pull/1374 so everyone interested is welcome to review/try
We have introduced a new branch with IPv6 support: 0.10, and the new PR #1410 The decision is at least firstly - 0.9 will never get IPv6-support.
Everyone interested to test 0.10 is welcome to review resp. try this new vesion.
Maybe I'm joining a bit late in the discussion, but I would also like to have IPv6 support in fail2ban and I have a potential contribution.
I tried to find a solution for the second item mentioned in the beginning of this issue: "Investigate more and decide on how to deal with variable across use-cases prefixes". I chose to implement "automatic shrinking of the prefix" and I think I have a nice working library:
https://github.com/mjholtkamp/py-iptree
Are people interested in using this library? I do not know if it's a good match, since iptree
uses the ipaddress
package (included in py3.5, separately installed for py2.7), instead of relying on the socket interface that fail2ban currently uses.
iptree
is tested under both python 2.7 and 3.5.
A nice bonus is that the automatic shrinking also works for IPv4 addresses, if you choose to use that.
Thx, I will take a look into your library...
I would also like to have IPv6 support in fail2ban
Well, we have it in 0.10 (even pre-released and yet without subnets, but ... :))
Of course I meant to have IPv6 support with subnet support ;)
Did you get a chance to take a look into the library yet? If you have suggestions on changes, I'm open to it and I wouldn't mind putting some effort into integrating the library in fail2ban (I think there might be some changes internally), but I want to know if it's desired. If you already now that it will never be merged I think it will be a waste of effort :)
When will support for ipv6 be implemented ?
@basd82 It is already implemented in 0.10.x (ca. one and a half years).
@sebres is there debian/ubuntu repo for that version ?
@basd82 both debian testing and ubuntu bionic have it:
$ rmadison -u debian fail2ban
(...)
fail2ban | 0.10.2-1 | testing | source, all
fail2ban | 0.10.2-1 | unstable | source, all
and
$ rmadison -u ubuntu fail2ban
(...)
fail2ban | 0.10.2-1 | bionic/universe | source, all
Also, a github issue isn't the best place to ask these questions.
What parts of IPv6 support are missing? As this issues is open.
As this issues is open.
- [ ] subnet
- [ ] all banning actions must provide IPv6 capability
@basd82 backports of 0.10.2-1 are available from "secret" debian-devel of neurodebian: http://neuro.debian.net/debian-devel/pool/main/f/fail2ban/ I was not yet brave enough to push them into the main repo of neurodebian... but soon I guess ;)
@sebres How can I, as a banning action provider, detect if I should ban a IPv4 or IPv6 without having to run the provided IP through regex? Can I provide two separate ban/unban actions for v4 vs v6 targets?
@f0o this is very easy: we've a conditional section that allows to differentiate between IP families. For example take a look into any action supporting IPv6, e. g. https://github.com/fail2ban/fail2ban/blob/b5dd5adb08f9fd3496f8c63b1d53b0e3c6aabbf1/config/action.d/iptables-common.conf#L79
Short self explaining example:
[Definition]
...
actionban = printf "%%b\n" "ban <_ip_type> <_ip_var>:<port>"
actionunban = printf "%%b\n" "unban <_ip_type> <_ip_var>:<port>"
[Init]
_ip_var = <ip>
_ip_type = IPv4
[Init?family=inet6]
_ip_var = [<ip>]
_ip_type = IPv6
Of course it is not necessary to use some parameters extra (like in the example above), you can simply overwrite actionban
, actionunban
, etc. in section [Init?family=inet6]
.
So yes, you can provide two separate ban/unban actions for v4 vs v6 targets, but IMHO it is better to use parameters, at least saves time (and code) and more dynamical, e. g. if action will be extended then you must not adjust entries in both sections (if the same syntax).
Additionally, you've a new run-time tag <family>
which contains the family of the IP (ban/unban only). So you can use it like this (or similar):
actionban = if [ '<family>' = 'inet4' ]; then ...; fi;
Hi,
I think the ideal solution would be to ban the smallest range whose disappearance would make the rate of bad traffic go down below the acceptable threshold (i.e. what used to be represented by maxretry for a single IPv4 address).
So for example, if we're receiving a brute-force attack from a specific /64 range, but 99,999% of it comes from a specific /128 address within that range, we would only block the /128 one, and not the entire /64 range unless it surpasses the threshold in its own merit. But before considering /64 we would have to check if /127 might be enough to mitigate the problem, then /126, etc. If none of the smaller prefixes are enough, then it means the whole /64 is either evil or incompetent and should be banned entirely.
Obviously, the threshold cannot be the same for all prefixes, otherwise we would ban entire ISPs just because they have some bad apples, or even the whole internet (prefix /0).