You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello,
I've installed fail2ban with haproxy on a ubuntu 22.04 server.
I found a strange behavior that might be a bug.
I told fail2ban to run a php script as action for ban and unban.
works fine.
My PHP skript runs "fail2ban-client status haproxy" to get a list of blocked ip-adresses to process it further.
works fine.
But when I use fail2ban-client on bash to manual unban an ip it blocks itself.
Run "fail2ban-client set haproxy unbanip 1.2.3.4"
-> tells fail2ban to unban ip (ok in log)
-> calls php script which calls "fail2ban-client status haproxy" (dead for about 20 seconds).
-> dead on bash too even if unban is aborted
Maybe it is not possible to run fail2ban-client two times?
First ist waiting to finish
Second is waiting for the first
deadlock
Thanks
Stefan
The text was updated successfully, but these errors were encountered:
My PHP skript runs "fail2ban-client status haproxy" to get a list of blocked ip-adresses to process it further.
Would probably not solve the issue, but fail2ban-client get <JAIL> banned is probably more appropriate command to get a list of banned IPs.
Maybe it is not possible to run fail2ban-client two times?
Nope. At least not in direct sense, for instance in my IDS based on fail2ban I definitely had nested calls of fail2ban-client in some actions, but... they was affecting different jails.
However it is only based on fail2ban, so some things may deviate, especially parts affecting asynchronous handling in server.
The actual problem is that fail2ban-client works here synchronously, so it waits for an answer from fail2ban-server, which in turn calling actions.removeBannedIP also totally synchronously:
If the action during unban, triggered by server, calls fail2ban-client again, it'd expect that server thread listening on the socket and process the command too, what would not happend because server thread is going to process actions.removeBannedIP in that moment.
Because of #3487, we need to rewrite the server communication anyway, so it'd be theoretically solved after switch to asyncio facilities, but...
Additionally (second problem that may occur) if inside the action something calls fail2ban-client status haproxy which needs also an access to actions object (its banmanager) to get the list of IPs and this may get blocked by some common lock (I don't think it is GIL, rather some lock protecting lists/queues).
In this case it'd be also a deadlock, since the thread of server blocking a mutex for that in turn the actions thread waiting.
The full solution may be to rewrite calling of actions.removeBannedIP asynchronously or to send from server thread an event to actions thread, instead of direct invocation of actions.removeBannedIP there.
sebres
changed the title
[BR]: fail2ban-client blocks itselt
[BR]: nested invocation of fail2ban-client blocks itself
Sep 21, 2023
Hello,
I've installed fail2ban with haproxy on a ubuntu 22.04 server.
I found a strange behavior that might be a bug.
I told fail2ban to run a php script as action for ban and unban.
works fine.
My PHP skript runs "fail2ban-client status haproxy" to get a list of blocked ip-adresses to process it further.
works fine.
But when I use fail2ban-client on bash to manual unban an ip it blocks itself.
Run "fail2ban-client set haproxy unbanip 1.2.3.4"
-> tells fail2ban to unban ip (ok in log)
-> calls php script which calls "fail2ban-client status haproxy" (dead for about 20 seconds).
-> dead on bash too even if unban is aborted
Maybe it is not possible to run fail2ban-client two times?
First ist waiting to finish
Second is waiting for the first
Thanks
Stefan
The text was updated successfully, but these errors were encountered: