Is there a way to add a memory-only, realtime-updated ipset to hestia? If not, will you accept a pull request for that feature?

Community Support Firewall
1

I’d like to implement a couple memory-only ipsets that are updated in realtime. However…

  1. 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.

  2. 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.

1 Like
2

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.

3

I already reduced it to 5 instead the old 10…

It depends if you use it to white / blacklist things …

In case it might block you out of a system because an downloaded ipset didn’t work any more …

4

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.

5

If you white list get emptied out you won’t be able to login into the system…

It shouldn’t matter it it looks it only calls on creation of the ipset so it should be possible to bypass if we are able to to load it some how…

If it is less you can just create a rule for it in the firewall directly…

6

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.

7

Yes if you set drop all connections first and then white list the ipset it will work fine…

8

What do you think @eris? Can we add this? I will mod the code and do a pull request.

9

Feel free to create a PR

10

Will you add this feature to hestia? I don’t want to waste my time if it’s a maybe.

11

If it works it will be added…

12

Great!

  1. Will you pick a name for the forth source? It will save us time…

  2. Will you accept movement of IPSET_MIN_SIZE=5 from line 84 of v-add-firewall-ipset to hestia.conf? Or maybe do it in a similar way :

v-add-letsencrypt-user
# LE API
LE_API='https://acme-v02.api.letsencrypt.org'

if [[ "$LE_STAGING" = 'yes' ]]; then
	LE_API='https://acme-staging-v02.api.letsencrypt.org'
fi

i.e. only set IPSET_MIN_SIZE to 0 if something like IPSET_MIN_SIZE_ZERO=yes is present in hestia.conf

13

Did you tried allready:

DROP       all  --  anywhere             anywhere             match-set crowdsec-blacklists src

Is load as expected after reboot…

14

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.

15

Run after

systemctl restart crowdsec-firewall-bouncer

So add:

if [ -x “$HESTIA/data/firewall/post-update.sh” ]; then
bash “$HESTIA/data/firewall/post-update.sh”
fi

And add to bash bash "$HESTIA/data/firewall/post-update.sh"

systemctl restart crowdsec-firewall-bouncer

There is zero create a “memory” version

16

@eris Can you explain what this is referring to?

17

To your issue with Crowdsec… And v-update-firewall deleting the ipset

18

@eris There is not enough detail for me to understand these instructions.

19

For Crowdsec this work fine

1 Like
20

I see.

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.

1 Like