I’d like to implement a couple memory-only ipsets that are updated in realtime. However…
Trying to add the ipset via /usr/local/hestia/data/firewall/custom.sh
iptables -I INPUT 1 -m set --match-set my-realtime-ipset src -j DROP
causes hestia complain that the ipset name doesn’t exist.
And trying to add a source via v-add-firewall-ipset requires a file, url, or script AND requires 5 ips AND swaps out my-realtime-ipset memory version with hestia .iplist.
Looking into the v-add-firewall-ipset code it doesn’t look possible to memory-only, realtime-updated ipset. True? Or is there something I’m not seeing?
If hestia doesn’t support this, would you be open to a pull request adding the ipset source type called realtime or similar to v-add-firewall-ipset. Please let me know the name you prefer. I’m thinking using that source type to bypass .iplist creation + memory ipset swap while still using the /usr/local/hestia/data/firewall/custom.sh functionality to add the ipset to iptables. If that works for you, please let me know other things in v-update-firewall-ipset and/or v-update-firewall to consider when implementing this feature.
I don’t know if this would solve your problem, but I’d like to see the minimum IP requirement removed from the HestiaCP ipset function. The use case for less than 5 entries, or even an empty ipset, is legitimate.
It does not. I look more fully at the code and ipset is always overwritten by hestia even when autoupdate is false.
I definitely agree. It seems arbitrary. @eris why don’t we move IPSET_MIN_SIZE=5 from line 84 of v-add-firewall-ipset to hestia.conf Which will allow users to make their own choice. Will an empty hestia ipset break anything?
Are you talking about being locked out if your client ip is added to the ipset? Or? If the former, one could easily jump on a free vpn to change their ip and get back in.
Are you saying a ACCEPT (whitelist) ipset iptables rule will drop traffic for all IPs except IPs in the set? It’s not the way I assume it works.
Regardless, this is getting a bit off topic. While I could write a script for each hestia ipset that pulls the ipset members from memory before hestia flushes that memory set and sends that pulled list back to hestia which writes to a file and then loads it back into memory, that is long way around the problem.
I’d like a forth ipset source that hestia doesn’t mess with except to write/delete it as an iptables rule. The use case is realtime data. I’m integrating with a custom realtime memory based blacklist ipset based on some defined server events AND crowdsec memory only ipset blacklist which draws from their api.
Is that something you’d be open to including? I thinking allowing for a fourth source type named realtime or unmanaged or other or something would preserve existing hestia functionality but allow for this use case.
Yes. But hestia removes the crowdsec-created iptables rule via v-update-firewall as well as destroys the crowdsec-blacklists ipset in memory. So this feature will add the ipset to ipset.conf but not create or otherwise touch the actual ipset. Then when adding the iptables rule via hestia, the api-memory based crowdec ipset will work upon reboot or otherwise.
Can you give guidance?
If you want me to decide, I will, but I’d like to save us time by moding the code to hestia standards.
So you are saying completely bypass hestia v-add-firewall-ipset and v-add-firewall-rule and add whatever ipset, ipset member population, iptables rules (or in this crowdsec’s case, restart which creates those) to post-update.sh. True?
The main downside to this solution is hestia’s gui will not display these ipsets or rules, which feels like a bit of a hack, which generally I don’t like to do.