Open mrclschstr opened 4 months ago
I have the same symptoms:
And the same IP blocked... ;)
Been suffering from this for months. At least since May 9 2023; that’s when I noticed it and opened Ticket#1253407.
At least since May 9 2023; that’s when I noticed it and opened Ticket#1253407.
I cannot find your ticket number. Are you sure it's correct?
I cannot find your ticket number. Are you sure it's correct?
I assume, you’re a TINC employee/contractor with access to the servercow.de ticketing system?
Those are my two reports of the issue:
Ticket Number | Priority | Department | Summary |
---|---|---|---|
1253407 | Medium | mailcow Premium | Negative Bann-Zeiten und unsichtbare Buttons |
1910644 | High | mailcow Premium | Wieder negative Bannzeiten |
If you get a lot of login requests with malicious attempt I would use sg. else than that builtin script. It's really not efficient. Do you have any firewall solutions before your server? Or are you familiar with the "real" fail2ban project? https://github.com/fail2ban/fail2ban
Yes, I'm familiar with the real fail2ban project, but I guess having two systems is one too many? Is there a tutorial on how to install an external fail2ban solution? I didn't find anything in the docs...
By the way: Why does mailcow use a self-scripted fail2ban solution at all?
Why does mailcow use a self-scripted fail2ban solution at all?
When I wrote the initial version of this script (it has changed a lot since then) in 2017, the "real" fail2ban did not support IPv6 and couldn't read logs from Docker. I'm pretty sure it supports IPv6 nowadays, but I'm not sure it can handle any of Docker's log drivers other than the (non-default) systemd log.
I have the same issue, although I've changed default fail2ban parameters strongly: Ban time (s): 86400 (24h) Max. ban time (s): 604800 (one week) Ban time is incremented with each ban: true Max. attempts: 5 Retry window (s) for max. attempts: 86400
Example lines (IPs changed): 152.4.204.217/32 (-493h -35m -40s) - [unban] [whitelist] [blacklist (needs restart)] 81.14.65.107/32 (-495h -11m -19s) - [unban] [whitelist] [blacklist (needs restart)] 94.18.180.171/32 (-465h -43m -10s) - [unban] [whitelist] [blacklist (needs restart)]
I've left it running for a few weeks without restarting and eventually it hanged with the last line visible: Error reading log line from pubsub: 'max_attempts'
Running into a similar issue. I've used a third party VPN and tried to force brute for testing and netfilter is not logging in the fail attempts making it harder to create alerts on a SIEM and use SOAR to automate my firewall to have the IP/Subnet blocked.
@kovacs-andras We need to have logging with attempt fails to begin with if we want to be able to use a third-party that can facilitate this service if fail2ban does not work. How are you checking logs and automating today for failed login attempts? Do you recommend a specific log source to ingest login events that we can use to not solely rely on fail2ban/netfilter? Thanks in advance!
I started noticing right after the latest release (2024-6a), so I can't tell when this has been occurring.
The entire machine has been restarted and re-tested with the same issue. Everything else is working as expected.
The only difference in my environment is that IPv6 was completely removed following the official doc.
# docker compose logs -f --tail=200 netfilter-mailcow
netfilter-mailcow-1 | # Warning: table ip nat is managed by iptables-nft, do not touch!
netfilter-mailcow-1 | # Warning: table ip filter is managed by iptables-nft, do not touch!
netfilter-mailcow-1 | # Warning: table ip6 nat is managed by iptables-nft, do not touch!
netfilter-mailcow-1 | # Warning: table ip6 filter is managed by iptables-nft, do not touch!
netfilter-mailcow-1 | Using NFTables backend
netfilter-mailcow-1 | Clearing all bans
netfilter-mailcow-1 | Initializing mailcow netfilter chain
netfilter-mailcow-1 | MAILCOW ip chain created successfully.
netfilter-mailcow-1 | MAILCOW ip6 chain created successfully.
netfilter-mailcow-1 | Setting MAILCOW isolation
netfilter-mailcow-1 | Watching Redis channel F2B_CHANNEL
# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
MAILCOW 0 -- 0.0.0.0/0 0.0.0.0/0 /* mailcow */
DOCKER-USER 0 -- 0.0.0.0/0 0.0.0.0/0
DOCKER-ISOLATION-STAGE-1 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
DOCKER 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
DOCKER 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
DOCKER 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
DOCKER 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
DOCKER 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
DOCKER 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
DOCKER 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
DOCKER 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
DOCKER 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
DOCKER 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
DOCKER 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain DOCKER (11 references)
target prot opt source destination
ACCEPT 6 -- 0.0.0.0/0 172.17.0.2 tcp dpt:8834
ACCEPT 6 -- 0.0.0.0/0 172.18.0.2 tcp dpt:8080
ACCEPT 6 -- 0.0.0.0/0 172.17.0.3 tcp dpt:80
ACCEPT 6 -- 0.0.0.0/0 192.168.32.2 tcp dpt:22
ACCEPT 6 -- 0.0.0.0/0 172.18.0.2 tcp dpt:50000
ACCEPT 6 -- 0.0.0.0/0 192.168.112.3 tcp dpt:80
ACCEPT 6 -- 0.0.0.0/0 172.19.0.2 tcp dpt:4200
ACCEPT 6 -- 0.0.0.0/0 192.168.32.2 tcp dpt:3000
ACCEPT 6 -- 0.0.0.0/0 172.21.0.2 tcp dpt:9443
ACCEPT 6 -- 0.0.0.0/0 172.23.0.2 tcp dpt:5432
ACCEPT 6 -- 0.0.0.0/0 172.20.0.3 tcp dpt:80
ACCEPT 6 -- 0.0.0.0/0 192.168.80.3 tcp dpt:80
ACCEPT 17 -- 0.0.0.0/0 172.17.0.4 udp dpt:1900
ACCEPT 6 -- 0.0.0.0/0 172.23.0.3 tcp dpt:8080
ACCEPT 6 -- 0.0.0.0/0 172.17.0.5 tcp dpt:80
ACCEPT 6 -- 0.0.0.0/0 172.19.0.2 tcp dpt:9000
ACCEPT 6 -- 0.0.0.0/0 172.17.0.6 tcp dpt:3000
ACCEPT 6 -- 0.0.0.0/0 172.19.0.3 tcp dpt:8000
ACCEPT 6 -- 0.0.0.0/0 172.19.0.2 tcp dpt:9420
ACCEPT 6 -- 0.0.0.0/0 172.19.0.3 tcp dpt:8080
ACCEPT 17 -- 0.0.0.0/0 172.17.0.4 udp dpt:7359
ACCEPT 6 -- 0.0.0.0/0 172.19.0.3 tcp dpt:8086
ACCEPT 6 -- 0.0.0.0/0 172.19.0.3 tcp dpt:8089
ACCEPT 6 -- 0.0.0.0/0 172.17.0.4 tcp dpt:8096
ACCEPT 6 -- 0.0.0.0/0 172.19.0.3 tcp dpt:9997
ACCEPT 6 -- 0.0.0.0/0 172.22.1.249 tcp dpt:6379
ACCEPT 6 -- 0.0.0.0/0 172.22.1.5 tcp dpt:8983
ACCEPT 6 -- 0.0.0.0/0 172.22.1.6 tcp dpt:3306
ACCEPT 6 -- 0.0.0.0/0 172.22.1.250 tcp dpt:110
ACCEPT 6 -- 0.0.0.0/0 172.22.1.250 tcp dpt:143
ACCEPT 6 -- 0.0.0.0/0 172.22.1.250 tcp dpt:993
ACCEPT 6 -- 0.0.0.0/0 172.22.1.250 tcp dpt:995
ACCEPT 6 -- 0.0.0.0/0 172.22.1.250 tcp dpt:4190
ACCEPT 6 -- 0.0.0.0/0 172.22.1.8 tcp dpt:80
ACCEPT 6 -- 0.0.0.0/0 172.22.1.250 tcp dpt:12345
ACCEPT 6 -- 0.0.0.0/0 172.22.1.8 tcp dpt:443
ACCEPT 6 -- 0.0.0.0/0 172.22.1.253 tcp dpt:25
ACCEPT 6 -- 0.0.0.0/0 172.22.1.253 tcp dpt:465
ACCEPT 6 -- 0.0.0.0/0 172.22.1.253 tcp dpt:587
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target prot opt source destination
DOCKER-ISOLATION-STAGE-2 0 -- 0.0.0.0/0 0.0.0.0/0
DOCKER-ISOLATION-STAGE-2 0 -- 0.0.0.0/0 0.0.0.0/0
DOCKER-ISOLATION-STAGE-2 0 -- 0.0.0.0/0 0.0.0.0/0
DOCKER-ISOLATION-STAGE-2 0 -- 0.0.0.0/0 0.0.0.0/0
DOCKER-ISOLATION-STAGE-2 0 -- 0.0.0.0/0 0.0.0.0/0
DOCKER-ISOLATION-STAGE-2 0 -- 0.0.0.0/0 0.0.0.0/0
DOCKER-ISOLATION-STAGE-2 0 -- 0.0.0.0/0 0.0.0.0/0
DOCKER-ISOLATION-STAGE-2 0 -- 0.0.0.0/0 0.0.0.0/0
DOCKER-ISOLATION-STAGE-2 0 -- 0.0.0.0/0 0.0.0.0/0
DOCKER-ISOLATION-STAGE-2 0 -- 0.0.0.0/0 0.0.0.0/0
DOCKER-ISOLATION-STAGE-2 0 -- 0.0.0.0/0 0.0.0.0/0
RETURN 0 -- 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-ISOLATION-STAGE-2 (11 references)
target prot opt source destination
DROP 0 -- 0.0.0.0/0 0.0.0.0/0
DROP 0 -- 0.0.0.0/0 0.0.0.0/0
DROP 0 -- 0.0.0.0/0 0.0.0.0/0
DROP 0 -- 0.0.0.0/0 0.0.0.0/0
DROP 0 -- 0.0.0.0/0 0.0.0.0/0
DROP 0 -- 0.0.0.0/0 0.0.0.0/0
DROP 0 -- 0.0.0.0/0 0.0.0.0/0
DROP 0 -- 0.0.0.0/0 0.0.0.0/0
DROP 0 -- 0.0.0.0/0 0.0.0.0/0
DROP 0 -- 0.0.0.0/0 0.0.0.0/0
DROP 0 -- 0.0.0.0/0 0.0.0.0/0
RETURN 0 -- 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN 0 -- 0.0.0.0/0 0.0.0.0/0
Chain MAILCOW (1 references)
target prot opt source destination
DROP 6 -- 0.0.0.0/0 0.0.0.0/0 /* mailcow isolation */
Hi! 5 days ago I migrated my mailcow VM to a new physical host. Migration was done by offline Backup/Restore. The day before I update to 2024-6a. Can't tell what solved it, but since then IP addresses get unbanned as expected.
On the new host several things changed from my previous setup:
Just want to share this. Maybe it help somebody...
Can't tell what solved it, but since then IP addresses get unbanned as expected.
Watch out for whether this occurs only occasionally after a while – like it does for us.
Watch out for whether this occurs only occasionally after a while – like it does for us.
You're right. It was too early to celebrate. The phenomenon still exists for me too...
We have same kind of symptom. When click on unban button, the frontend show unban pending but IP never unban.
I need to execute command like this docker exec netfilter-mailcow-1 iptables -D MAILCOW -s x.x.x.x/32 -j DROP
to solve the problem.
I need to execute command like this […]
Does restarting the netfilter container not work for you? Does your command actually resolve the problem or just get the specified rule off the list?
Contribution guidelines
I've found a bug and checked that ...
Description
Currently I get a lot of login requests to my mailcow instance from a certain subnet, which is why the netfilter container does a lot of bans and unbans. I have noticed that after a certain time (about 3 to 5 days) netfilter no longer unbans the IPs and they remain permanently banned, so to speak. Here is an example for the IP
194.169.175.10
:In the mailcow GUI, the IPs are displayed with a negative ban time:
I have not changed anything in the netfilter settings, so they are default. Restarting the netfilter container usually helps to unblock the IP addresses again.
The following issue describes similar symptoms: https://github.com/mailcow/mailcow-dockerized/issues/5518
Logs:
Steps to reproduce:
Which branch are you using?
master
Which architecture are you using?
x86
Operating System:
Ubuntu 22.04.4 LTS
Server/VM specifications:
4 CPU, 8 GB RAM
Is Apparmor, SELinux or similar active?
No
Virtualization technology:
KVM
Docker version:
26.1.1
docker-compose version or docker compose version:
v2.27.0
mailcow version:
2024-04
Reverse proxy:
No
Logs of git diff:
Logs of iptables -L -vn:
Logs of ip6tables -L -vn:
Logs of iptables -L -vn -t nat:
Logs of ip6tables -L -vn -t nat:
DNS check: