Description

This PR replaces iptables with nftables and adjusts the Fail2Ban configuration accordingly.

Issues as in #2327 would become obsolete. But this PR does not actually focus on #2327 - it focuses on replacing old software (which is not the default since Debian 10!) with new, more performant software which is also easier to use!

Type of change

• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (README.md or the documentation under docs/)
• If necessary I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

nftables lists IPs a bit differently , so the order was adjusted for the
tests to be more flexible.

This PR should be properly tested before merging. It's not just replacing iptables with nftables, because they both are mostly compatible, but not 100%. Otherwise we wouldn't have to introduced the usage of iptables-legacy in the past. What was the reason for that? Is that reason now obsolete?
I ran into issues when I switched from one to the other and ended up reverting it. That was some time ago and I can't remember what exactly the issue was.

I think the reason for switching to legacy was that the support for Fail2Ban was not there at the time. Support was introduced not too long ago. At the time of the change to legacy (i.e. the change to Debian 10 I guess), Fail2Ban was not ready. Moreover, it was just easy to change to legacy instead of adjusting configurations.

Now, Fail2Ban is ready and I tested the mail server locally. Everything seems to be running quite smoothly. F2B can ban IPs, nft makes working with the routing way easier (compared to iptables).

While I agree that we should be careful here to not forget anything, I cannot think of anything right now. We do not have to merge this straight away, maybe you @casperklein can test with an image created from this branch like I did? Other than that though, I think we're quite fine.

maybe you @casperklein can test with an image created from this branch like I did

Yes, but earliest next week.

Another thing that come to my mind: At the moment, my host and DMS uses iptables. I don't know if it could be problematic, if host and container doesn't match?

Interesting to know would be, if there are already working setups at the moment, with nftables on the host and iptables in DMS.

maybe you @casperklein can test with an image created from this branch like I did

Yes, but earliest next week.

👍

Another thing that come to my mind: At the moment, my host and DMS uses iptables. I don't know if it could be problematic, if host and container doesn't match?

My tests took place on such a system, i.e. iptables on the host and nftables on the system.

Interesting to know would be, if there are already working setups at the moment, with nftables on the host and iptables in DMS.

This I cannot test currently.

I'm running this in production now, and it seems to work very well. I had some troubles at first, but this was due to a wrong custom configuration on my side. F2B bans IPs properly:

root@mail:/# fail2ban-client status
Status
|- Number of jail:	5
`- Jail list:	dovecot, postfix, postfix-sasl, postscreen, recidive
root@mail:/# fail2ban-client status postfix
Status for the jail: postfix
|- Filter
|  |- Currently failed:	1
|  |- Total failed:	6
|  `- File list:	/var/log/mail.log
`- Actions
   |- Currently banned:	1
   |- Total banned:	2
   `- Banned IP list:	212.70.149.72
root@mail:/# nft list set inet f2b-table addr-set-postfix
table inet f2b-table {
	set addr-set-postfix {
		type ipv4_addr
		elements = { 212.70.149.72 }
	}
}

I will make an announcement and I will monitor the logs. If all seems well, we can then go ahead and merge this to be in v11 (maybe even as the last PR to go into v11).

I don't care. For me, this PR is fine and can be merged anytime. Or do I miss something?

I don't care. For me, this PR is fine and can be merged anytime. Or do I miss something?

Nothing :) I will go ahead and merge this then, as I too think this is fine.

I noticed these days, that in my setup IPs don't seem to be banned anymore. Banned IP count gets lower every day.

From today, I see this in /var/log/fail2ban.log:

2022-04-20 17:04:06,001 fail2ban.filter         [2394]: INFO    [dovecot] Found 63.134.141.35 - 2022-04-20 17:04:05
2022-04-20 17:04:07,646 fail2ban.filter         [2394]: INFO    [postfix-sasl] Found 63.134.141.35 - 2022-04-20 17:04:07
2022-04-20 17:24:24,724 fail2ban.filter         [2394]: INFO    [dovecot] Found 112.219.231.93 - 2022-04-20 17:24:24
2022-04-20 17:24:26,198 fail2ban.filter         [2394]: INFO    [postfix-sasl] Found 112.219.231.93 - 2022-04-20 17:24:26
2022-04-20 17:24:41,165 fail2ban.filter         [2394]: INFO    [dovecot] Found 207.191.163.60 - 2022-04-20 17:24:40
2022-04-20 17:24:42,623 fail2ban.filter         [2394]: INFO    [postfix-sasl] Found 207.191.163.60 - 2022-04-20 17:24:42
2022-04-20 18:06:46,160 fail2ban.filter         [2394]: INFO    [postfix] Found 182.204.178.57 - 2022-04-20 18:06:45

However, cross-checking with fail2ban-client status postfix, I don't see 182.204.178.57 as banned. Could someone else check if banning still works?

Edit: Found != Banned. My fault.

@georglauterbach

My tests took place on such a system, i.e. iptables on the host and nftables on the system.

There are 2 types of iptables. The current version is meant to be a drop-in replacement for the older (legacy) iptbales, but under the hood it uses nftables.
The other version is iptables-legacy. On Debian based systems you can switch to that version using update-alternatives --set iptables /usr/sbin/iptables-legacy

Some appliance, notably QNAP, still uses the legacy version of iptables, and don't ship with nftables, although they have recent Linux kernels.
For those systems, nftables (and the new iptables) is not available in Docker environment

This PR broke those systems :)

PR #2662 contains a discussion about this issue. Although I fully agree of not carrying legacy stuff around, it's important for docker-mailserver users to know about this issue.

@dguerri now that you say it, yes, I was using the drop-in replacement of iptables which uses nftables under the hood. I will put my other notes under your PR :)