User definable refresh time for IP lists


  • Moderator

    Hi,

    I'd propose a more custom approach for IP list update intervals :)
    As I have that problem ATM I'd really like for pfBlockerNGs default Cronjob to run at least every 2 or 5 minutes (I suppose it only checks if it has something to refresh, doesn't it?) and give the user the ability - at least for IP4/6 lists - to refresh them how he likes at a minimum that is defined by the cronjob (so 2 or 5 minutes or - if suitable even every minute).

    Why that? As the example PRI1 list (in the devel tree) is quite a nice job, pfBNG can then actually be used as a black- or whitelist backend/service for self-hosted lists. We do this for example in combination with Fail2Ban and a custom self-written Ban/Unban action and using the DB capability of Fail2Ban. So if an IP gets blocked, it doesn't get blacklisted on the host itself but the host writes it to a central database. That database has a web frontend that can now get called to create an IP list for the whole customer service and then blocks these IPs for all services and hosts of said customer, not only the one that triggered the action. That is a good solution for clustered or loadbalanced services as well.

    BUT to use that to full extend we need to import those lists in a timing that is closer to 5min instead of only every hour because if we detect e.g. an SQL injection and blacklist the IP the firewall should block it (almost) immediatly. As pfSense itself has no way to read lists < 1d in interval, pfBNG could fill that gap quite nicely!

    Thanks
    Jens


  • Moderator

    @jegr

    I have written an api script a few years ago that can add IPs to an IP customlist. I have not released it yet, but should do that at some point. This can add/remove IPs from any IP customlist. This would have to be scripted to fit your network requirements.

    Its can be problematic to run the pfBlockerNG cron task every 5 mins depending on how many IP Blocklists are being used, and if the Reputation IP options are being used (which takes some time to process). So it was that reason they I didn't add more cron options. The problem is also exacerbated when DNSBL is used, and depending on the number of feeds and if the TLD option is enabled.