yeah that’s good, you could imagine to add the IP to whitelist, however you need to run it each 5 minutes I bet
1 Like
testers are welcome
2 Likes
I have seen, that the ability to set an fqdn is in the cockpit gui now. Is there also an “refreshing” cron job in the updatet package to whitelist the new ip for fail2ban? And if yes how is the timegap and how can i change this?
Regards
yummiweb
Why a cronjob on fail2ban, it makes queries to the default dns server with a TTL (time to live) and when it is over it asks again I presume.
Never use FQDN if possible, for dynamic IP the cronvjob must run on the remote client server, not on your fail2ban server.
Maybe @dnutan can help, I was referring to his script
Not to my knowledge.
If the case is, for instance, a NethServer with dynamic IP from ISP pointing to a FQDN updated through ddns, then you could ran a script through a cron job to get the new IP and add it to the whitelist, but things are always more complex than they seem (whitelist new IP but what happens with old IPs now assigned to who knows who, and if FQDN has more than one IP or IPv6, etc., …surely can be done but have to give it some thought)
EDIT: sorry, I didn’t understand it properly.
It will depend on how fail2ban and the firewall act together regarding the FQDN (if fail2ban transmits only the IP or does something different). If fail2ban queries the DNS server to resolve the IP of the FQDN and then passes the IP to the firewall for block/whitelist purposes then the new IP shall be on the firewall on the next event signaled (fail2ban-update, etc.)
It could be as well as Stéphane guessed, and as fail2ban parses logs, hits the fqdn, resolves IP (with a TTL)…
Sorry for the train of though.
Here’s a parameter (use_dns warn) that logs when a dns lookup is done.
here’s a similar question:
2 Likes