Hi,
It seems that, the ban action doesn’t work at all…
I have activated “duration_expr” default option to rise the ban time everytime an ip is remediate.
In the image, you will see that the same ip is banned 4 times in 4h.
Is this a normal behavior ?
I expect to have no new notifications for this ip for 8 hours (the first time was two detections ago).
is the ip really ban or not ?
Thanks
Well,
If i check cscli decisions list
We see that the ip seems banned and the expiration time seems OK.
My question is more functionnal :
If the ip is already banned why would i have more notifications ?
For me, it’s like it doesn’t work what ever if you activate the “duration_time” or not, you receive multiple notifications.
Maybe if we could change the message by <IP> try another time to trigger <trigger>, it will get ban for next <hours>h.
Is it possible to have differents messages ?
Thanks
Which bouncers are you using? If it just nginx then the request still gets logged by nginx so it can multple trigger (it just means they get a 401 response code).
If you are using just the firewall bouncer are you using cloudflare? if so this bypasses the firewall bouncer as the firewall can only see cloudflare IP not the layer 7 IP in the header.
Hi @iiAmLoz,
I use Traefik Bouncer.
I check the log file and there is a lot of 404 for this IP (no 401). It stop logging this IP at 9h13 the 31 May.
...
79.124.59.162 - - [31/May/2023:09:12:27 +0000] "GET /web/sendgrid.env HTTP/1.1" 404 19 "-" "-" 3206450 "-" "-" 0ms
79.124.59.162 - - [31/May/2023:09:12:36 +0000] "GET /ADMIN/sendgrid.env HTTP/1.1" 404 19 "-" "-" 3206467 "-" "-" 0ms
79.124.59.162 - - [31/May/2023:09:12:45 +0000] "GET /api/sendgrid.env HTTP/1.1" 404 19 "-" "-" 3206477 "-" "-" 0ms
79.124.59.162 - - [31/May/2023:09:12:54 +0000] "GET /API/sendgrid.env HTTP/1.1" 404 19 "-" "-" 3206485 "-" "-" 0ms
79.124.59.162 - - [31/May/2023:09:13:03 +0000] "GET /apps/api/sendgrid.env HTTP/1.1" 404 19 "-" "-" 3206493 "-" "-" 0ms
First notification / decision the 30 May at 23h45
So it seems that the IP wasn’t block even if the decision has been made.
Really i don’t understand what’s going on !
PS: I found nothing in auth.log or syslog.
Hey,
I would check the plugin is working and communicating to the LAPI. You can ensure this by running cscli bouncers list unfortunately I cant really help with the bouncer since it is third party.
@iiAmLoz, traefik bouncer seems to work and communicate with LAPI.
traefik-bouncer 172.18.0.2 ✔️ 2023-06-01T08:12:40Z Go-http-client 1.1 api-key
The last sync was made today…
Then all I can recommend is to look at the documentation for the bouncer, something doesn’t seem right. I haven’t used it so I dont have any ideas.
Hello, I’m facing the almost exact same problem, but with the normal firewall bouncers. I can confirm that the bouncers do pull the decisions.
I did notice that the crowdsesc ban ipset gets basically cleared habitually, with no logs of the firewall bouncers indicating anything wrong happening.
The IPSet get wiped OR does the rule get flushed from iptables?
We observed this phenomenon: when reloading the bouncer service, it pulls all the decisions and adds all banned IPs to the blocklist, like it should (about, say, 70 decisions). But after some time (can be a few seconds or a few minutes), something suddenly switches and the ipset contains only like 2 IPs.
