Open furian88 opened 5 months ago
Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.
in the console of fail2ban docker i can see these rules:
not of this is however visible on the host (also no chain) -A f2b-HTTP -s 13.40.99.210/32 -j REJECT --reject-with icmp-port-unreachable -A f2b-HTTP -s 176.53.221.188/32 -j REJECT --reject-with icmp-port-unreachable -A f2b-HTTP -s 13.40.73.230/32 -j REJECT --reject-with icmp-port-unreachable -A f2b-HTTP -s 176.53.218.4/32 -j REJECT --reject-with icmp-port-unreachable -A f2b-HTTP -s 13.40.73.139/32 -j REJECT --reject-with icmp-port-unreachable -A f2b-HTTP -s 176.53.217.203/32 -j REJECT --reject-with icmp-port-unreachable -A f2b-HTTP -s 13.40.72.216/32 -j REJECT --reject-with icmp-port-unreachable -A f2b-HTTP -s 174.246.165.63/32 -j REJECT --reject-with icmp-port-unreachable -A f2b-HTTP -s 13.40.48.157/32 -j REJECT --reject-with icmp-port-unreachable -A f2b-HTTP -s 174.218.225.78/32 -j REJECT --reject-with icmp-port-unreachable
+1
I suspect that the rebase to Alpine 3.19 a couple of months ago may have caused this.
According to https://www.alpinelinux.org/posts/Alpine-3.19.0-released.html
iptables-nft is now the default iptables backend.
Whereas unraid uses iptables-legacy
as the default iptables backend. So unraid's docker (host) populates the DOCKER-USER
chain (and others) in the -legacy backend. On the other hand, fail2ban now tries to manipulate the iptables-nft
backend, which does not contain the DOCKER-USER
chain, so the rules/chains are broken in fail2ban.
As a test, I tried installing iptables-legacy
inside the fail2ban container:
docker exec -it fail2ban apk add iptables-legacy
then changed the jail.local
to use it:
banaction = iptables-multiport[iptables=iptables-legacy]
and now things are working again.
Of course this is not a permanent solution (since an update to the docker image would again remove iptables-legacy
), but just a test to confirm my suspicions.
Facing the same issue in Unraid 6.12.4, so I have rolled back to the 1.0.2-r2-ls60 release before the rebase to Alpine 3.19 and this seems to have fixed it. To do this set the repository to ghcr.io/linuxserver/fail2ban:1.0.2-r2-ls60
.
Hopefully it can be addressed in a future release.
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.
Facing the same issue in Unraid 6.12.4, so I have rolled back to the 1.0.2-r2-ls60 release before the rebase to Alpine 3.19 and this seems to have fixed it. To do this set the repository to
ghcr.io/linuxserver/fail2ban:1.0.2-r2-ls60
.Hopefully it can be addressed in a future release.
I seem to still be having this same issue in ghcr.io/linuxserver/fail2ban:1.0.2-r2-ls60
Ban detection works but actual ban action doesn't seem to add any rules to iptables. Any ideas?
fail2ban.log
:2024-06-22 22:40:18,864 14908166CB38 NOTIC [authelia-auth] Ban <redacted IP>
2024-06-22 22:40:18,868 14908166CB38 ERROR 1490818e0990 -- exec: { iptables -w -C f2b-authelia-auth -j RETURN >/dev/null 2>&1; } || { iptables -w -N f2b-authelia-auth || true; iptables -w -A f2b-authelia-auth -j RETURN; }
for proto in $(echo 'tcp' | sed 's/,/ /g'); do
{ iptables -w -C DOCKER-USER -p $proto -m multiport --dports http,https,9091 -j f2b-authelia-auth >/dev/null 2>&1; } || { iptables -w -I DOCKER-USER -p $proto -m multiport --dports http,https,9091 -j f2b-authelia-auth; }
done
2024-06-22 22:40:18,869 14908166CB38 ERROR 1490818e0990 -- stderr: 'iptables: No chain/target/match by that name.'
2024-06-22 22:40:18,869 14908166CB38 ERROR 1490818e0990 -- returned 1
2024-06-22 22:40:18,869 14908166CB38 ERROR Failed to execute ban jail 'authelia-auth' action 'iptables-multiport' info 'ActionInfo({'ip': '<redacted IP>', 'family': 'inet4', 'fid': <function Actions.ActionInfo.<lambda> at 0x14908266f420>, 'raw-ticket': <function Actions.ActionInfo.<lambda> at 0x14908266fba0>})': Error starting action Jail('authelia-auth')/iptables-multiport: 'Script error'
authelia-auth
[authelia-auth]
enabled = false
port = http,https,9091
logpath = %(remote_logs_path)s/authelia/authelia.log
jail.local
[authelia-auth]
enabled = true
chain = DOCKER-USER
action = %(known/action)s
docker run
-d
--name='fail2ban'
--net='customzone'
-e TZ="UTC"
-e HOST_OS="Unraid"
-e HOST_HOSTNAME="<redacted>"
-e HOST_CONTAINERNAME="fail2ban"
-e 'VERBOSITY'='-vv'
-e 'PUID'='99'
-e 'PGID'='100'
-e 'UMASK'='022'
-l net.unraid.docker.managed=dockerman
-l net.unraid.docker.icon='https://raw.githubusercontent.com/linuxserver/docker-templates/master/linuxserver.io/img/fail2ban-logo.png'
-v '/var/log/':'/var/log':'ro'
-v '/mnt/user/appdata/Authelia/logs/':'/remotelogs/authelia':'ro'
-v '/mnt/user/appdata/Nginx-Proxy-Manager-Official/data/logs/':'/remotelogs/nginx':'ro'
-v '/mnt/user/appdata/fail2ban':'/config':'rw'
--cap-add=NET_ADMIN
--cap-add=NET_RAW 'ghcr.io/linuxserver/fail2ban:1.0.2-r2-ls60'
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.
This issue should probably stay open...
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.
This issue is still not resolved, this bot is unhelpful.
Is there an existing issue for this?
Current Behavior
fail2ban has worked for me for quite a long time, so long that i stopped checking the logs for a while.
Now i can see in the logging that IP's are being banned as fail2ban logs says so, but it does not ban the ip really from the host side. I can just keep connecting even though i should be banned.
i can also no longer see the iptables on the unraid host. (expected a chain, but its not there)
Expected Behavior
No response
Steps To Reproduce
jail: [authelia-auth]
enabled = true
port = http,80,https,443,9091
protocol = tcp
logpath = %(remote_logs_path)s/authelia/authelia.log chain = DOCKER-USER action = iptables-multiport[name=HTTP, port="http,https,9091,4443,18443,8181,7818,8080,1880", protocol=tcp]
action = %(known/action)s
ignoreip = 127.0.0.1/8 ::1 172.18.0.0/16 192.168.0.0/24 bantime = -1 findtime = 24h maxretry = 1
[nginx-bad-request]
enabled = true
port = http,80,https,443,18443,1880,7818
logpath = %(nginx_access_log)s chain = DOCKER-USER action = iptables-multiport[name=HTTP, port="http,https,9091,4443,18443,8181,7818,8080,1880", protocol=tcp]
action = %(known/action)s
ignoreip = 127.0.0.1/8 ::1 172.18.0.0/16 192.168.0.0/24 bantime = -1 findtime = 24h maxretry = 1
error from logs: 2024-04-05 08:42:11,949 150AA2544B38 ERROR 150aa31018a0 -- exec: for proto in $(echo 'tcp' | sed 's/,/ /g'); do iptables -w -D INPUT -p $proto -m multiport --dports http,https,9091,4443,18443,8181,7818,8080,1880 -j f2b-HTTP done iptables -w -F f2b-HTTP iptables -w -X f2b-HTTP 2024-04-05 08:42:11,949 150AA2544B38 ERROR 150aa31018a0 -- stderr: "iptables v1.8.10 (nf_tables): Chain 'f2b-HTTP' does not exist" 2024-04-05 08:42:11,949 150AA2544B38 ERROR 150aa31018a0 -- stderr: "Try `iptables -h' or 'iptables --help' for more information." 2024-04-05 08:42:11,950 150AA2544B38 ERROR 150aa31018a0 -- stderr: 'iptables: No chain/target/match by that name.' 2024-04-05 08:42:11,950 150AA2544B38 ERROR 150aa31018a0 -- stderr: 'iptables: No chain/target/match by that name.' 2024-04-05 08:42:11,950 150AA2544B38 ERROR 150aa31018a0 -- returned 1 2024-04-05 08:42:11,950 150AA2544B38 ERROR Failed to stop jail 'nginx-bad-request' action 'iptables-multiport-f2b-HTTP': Error stopping action Jail('nginx-bad-request')/iptables-multiport-f2b-HTTP: 'Script error'
Environment
CPU architecture
x86-64
Docker creation
Container logs