As Fail2ban is supporting IPV6 right now. Please consider supporting it.
New ticket as the old one about Fail2ban and IPV6 is closed.
https://github.com/fail2ban/fail2ban/releases
Let me preface this by saying I am a huge fan of Fail2ban but is it still relevant in the IPv6 internet?
e.g. When it is routine for home users to be issued with more IPv6 addresses than the entire current IPv4 space how useful can Fail2ban be?
May as well not bother with passwords either!
But more seriously, surely there is still a place for Fail2Ban, while is seems unlikely that bots will scan your entire address space just to find a couple of hosts, Fail2Ban also prevents a determined attacker from brute forcing a known address.
With IPv6 it’s not the problem of someone scanning our whole addres range. It’s more the source address can be an entire /48. Banning that wouldn’t be great I think.
That is my concern. Some context, an IPv6 user with a /48 (common) based on a FAIL2BAN trigger as low as 3 could try a login 3,626,777,458,843,887,524,118,528 times before they exhaust their legitimate address space. For most practical limits this is essentially infinite.
If FAIL2BAN is not subnet aware (and I dont think it is) not only does it become useless? it offers a simple way for a DoS as I am pretty sure a block count anywhere near 1,208,925,819,614,629,174,706,176 addresses would break something.
So IMHO until it can be subnet aware (somehow) I say it is all but pointless and potentially risky.
I want to be wrong.
I wonder if we should discourage the use of IPv6 entirely because of this.
I wonder if we should discourage the use of IPv6 entirely because of this.
After those years of IPv6 evolvement I'm still disappointed by certain things in the IPv6 ecosystem. Though in this case I don't think it would be a good idea to discourage IPv6 as it's really getting too ubiquitous.
@xetorixik @yodax and others, do you follow fail2ban development to know whether they already somehow addressed the "source IPv6 subnet can be huge and thus must not be blocked in it's entirety" issue?
I don’t have an opinion per se on IPv6 and fail2ban. I’m neither against or pro supporting it. That being said, non Ubuntu repos are an effort to support. Wether that is worth it only @JoshData can tell since that burden falls mostly on him.
I turned off IPv6 on my mail server ages ago. If you send mail to hotmail/live/outlook it’s actively discouraged. Their spam detection leans heavily on ip reputation. Which doesn’t really work with IPv6, because of similar reasons as with fail2ban. How much do you block? A /48, might not always be fair. I just got my IP whitelisted by Microsoft because they banned an entire /24.
I run several IPv6-only servers along with some dual stack ones. Across all of the various hosts I use, the "normal" allocation for IPv6 blocks is a /64; whether this is per account (all the servers within my account share a /64) or per host (each server gets its own /64) varies, but it's generally the same size either way. I have one provider that gives my account a /48 and each host a /64 within that, and they really know their stuff when it comes to IPv6 – in fact it might not be a bad idea to ask them. FWIW, nearly all providers I see charge extra for IPv4 addresses now.
Blocking individual IPv6 addresses is pointless, and provides a nice way for attackers to DoS you should you be so silly as to try. Bearing in mind that you could serve every single request you make from a different IP and never run out during your lifetime, blocking /64 subnets makes a lot more sense. That seems to be the general consensus from fail2ban too, though it seems their implementation still isn't there – though others may have built patches that do it.
That was a fascinating read but my overall take is that an upstream ticket that has been discussing the issue for over 5 years means there are many moving parts and it is probably out of scope for here.
I wonder if we should discourage the use of IPv6 entirely because of this.
My current thinking matches @JoshData and maybe goes a bit further to suggest IPv6 is opt in only until such time as we are fully aware of all the issues e.g. hotmail
My current thinking matches @JoshData and maybe goes a bit further to suggest IPv6 is opt in only until such time as we are fully aware of all the issues e.g. hotmail
I'm a bit confused. Are you suggesting MiaB should support only IPv4 and throw away all IPv6 support it has as of now?
I haven't learned anything useful about this in the last few years so I don't have anything new to contribute. But I guess we have two separate problems overall that might have two solutions:
If someone wants to disable IPv6 on an already running MIAB, is it just as simple as deleting the DNS records, or is there something else you would need to do?
If you want to disable it completely it’s easiest to disable IPv6 on the os, then rerun the setup.
Before talking to Microsoft about getting my IP mitigated I read through their documentation. That’s when I saw the IPv6 remark. I can’t find it anymore. (I wanted to link it here) Which is a bit of a problem since now it’s just an anecdotal claim. I’ll try and read through it again today.
Google does allow IPv6 as long as the ptr record is set properly. (And everything else is set like spf, dkim etc)
@yodax any more information and current real experience would be very valuable.
What I see in Microsoft documentation (updated on 09/22/2020) is actually the contrary - namely that IPv6 works without issues under the same conditions as with Google.
So it would seem. I disabled IPv6 5 years ago because it was giving me grief.
I had another look and I couldn’t find it. So my comments only confused the current situation. I’m pretty sure I read something along those lines. Microsoft refers to a lot of external parties when recommending smtp settings. If someone who has IPv6 enabled can report if they can send to Microsoft with just IPv6 that would be awesome.
Is it correct to say this all boils down to cost? i.e. some services that can host MIAB are cheaper without renting IPv4 along with it?
Is it even practical to run an IPv6 only MIAB without losing the ability to talk to deliver some mail?
If the answer to this is "no it is not practical" then at this time there is no cost saving and all IPv6 affords the general user is a transmission path they dont technically need that cant be secured to the level of IPv4.
This logic is why I suggested previously IPv6 be opt in until such time as this risk is mitigated and we better understand the situation in general.
Please correct the flaw in my logic as I suspect I wont be alone in "not really caring about IPv6" in MIAB production for now.
@anoma I don't think there is any flaw in your logic. It's just that there is a long transition phase (years) for which MiaB needs to be backward & forward compatible.
Thus if we want to communicate with IPv6-only mail servers in the future (and there will be more and more of them), we just need IPv6 support in advance (even if it's in a "constrained form" by default with opt-in for a "full form") to make the real switch later (i.e. making the "full form" the new default). It's this easy :wink:.
Thoughts?
So it would seem. I disabled IPv6 5 years ago because it was giving me grief.
I had another look and I couldn’t find it. So my comments only confused the current situation. I’m pretty sure I read something along those lines. Microsoft refers to a lot of external parties when recommending smtp settings. If someone who has IPv6 enabled can report if they can send to Microsoft with just IPv6 that would be awesome.
I use mail-in-a-box with ipv4 and ipv6, but when i send email to office365(Microsoft account) it seems that mail is sent over ipv4, but transferred over ipv6 internally by Microsoft. When sending email via Microsoft Office 365 back to mail-in-a-box it is the same. Microsoft internally sends over ipv6, but when sending to my box it changes to ipv4.
I thought IPV6 had priority over IPV4 so do not quite understand why it does not try IPV6 first.
This info is just from what i read in the mail header. (so maybe I can`t see if it try IPV6)
Is that any help?