Cloudron Forum

Follow up from the customer: "The issue here turned out to be that in Wordpress, WP Rocket caching plugin was used. This plugin automatically starts to preload the cache of each page once something in the site has been updated. The preload itself causes some stress on the CPU and maybe some other processes. Turning off the plugin, the products were sent for less than 2 mins."

They are working with the WP Rocket team to find a workaround.

@girish said in Networking - Whitelist ports does not work as expected:

@robi @BrutalBirdie done! https://git.cloudron.io/cloudron/box/-/commit/4287642308081d27dcc160f845fd5dedb27eb481

That was fast. ♥

@malvim said in Feasibility of running cloudron inside a vpn with package redirection:

What ports do you think I should be concernet about forwarding packages? Is it just 80, 443 and 25? I've taken a look at cloudron_firewall.sh and there's a bit more stuff going on there, isn't there? Heheh

https://docs.cloudron.io/security/#cloud-firewall is the full list. But at the barest minimum port 443 is enough.

Thanks, now I understand

@girish https://www.ipdeny.com/ipblocks/data/countries/all-zones.tar.gz

But I did get that from your blog post for 5.6: https://blog.cloudron.io/cloudron-5-6-released/ so maybe you're looking for better ones?

thank youuuuu 🙂

Deployed at https://cloudron.io/documentation/security/#privacy-control

@girish Thanks a lot for this great support and that you want to take a look at it 👍

It's not a must have, but it come's very handy for monitoring my Cloudron instance and get warnings if something goes weird or reaches high loads.

Netdata is also something i did not think about earlier, so maybe that will workout for me as well.

I must say (apart from this topic), i am really 100% satisfied till so far about Cloudron and the active community that's behind it. Many answers to my questions i did already find here in the forums 😉

Also a big thanks to the Staff of Cloudron, that picks up problems really quick and solve's them as much as they can.

I hope Cloudron will live for a long time in the upcoming future, because it's the solution i was looking for a long time 😉
Really glad i came accros all this and thanks to everybody 👍 👍

@HulaCloud We don't have plans to support netdata out of the box but I think it's a good idea to atleast have some interoperability instructions. Let me give this a try and get back.

This appears to be someone/bot trying out common usernames in one of your apps. Unfortunately this is not too uncommon, but also not an a real issue if you have strong passwords. The requests will be rate-limited as well to prevent proper brute-force attacks.

The internal IP is associated to an app, it may or may not change when an app is restarted. However the ldap logs might indicate there are multiple apps configured to use LDAP. The port is actually dynamic per request, so that is the reason why it does not show in docker ps/inspect

@mehdi Thats kind of scary, thanks for the correction.

@staypath Continuing my conversation with myself 🙂

Posting this here in case anyone else comes across this with the same question: I found that configuring fail2ban to use systemd was the trick:

[sshd] port = ssh #logpath = %(sshd_log)s #backend = %(sshd_backend)s backend = systemd enabled = true maxretry = 1 bantime = 14d

@Trankery Is your comment somehow related to the original subnet question (or did you post in the wrong thread) ?

@oatwalker from those posts, I assume you installed mumble on the side on your Cloudron. While this might work, it could break on future updates as we cannot reliably test such setups. If you are interested, you might want to look into https://cloudron.io/documentation/custom-apps/tutorial/ to see how you could package mumble as a Cloudron app. Also the firewall would have been setup by the platform automatically then.

@988uh is there any update on this from your side?

@necrevistonnezr That is true, however the configuration steps are different than what has been described before when trying to work around this issue.

I'm installing a new Cloudron and got bit by this again.. can't get mosh to work without manually tweaking iptables.

iptables -I INPUT 1 -p udp --dport 60000:60010 -j ACCEPT

@niko was there any error restarting cloudron-firewall service or such? This should still work as expected, so maybe you hit a bug somewhere?

Also could you share your ports.json config here so we can try to reproduce this? If you don't want to expose your port settings here, you can also send them to support@cloudron.io