Cloudron Forum

@chymian-0 Did you whitelist the ports or did you use iptables/ufw directly? We only support https://docs.cloudron.io/networking/#whitelist-ports

@robi Wow Robi, this is a great feature request!!! Just yesterday one of my Cloudron instances got a lot of traffic to email for a bruteforce attack. @girish I think this feature have to put on the top of the list to improve safety but also to reduce workload of instances and network traffic... [image: 1610527791540-schermata-2021-01-13-alle-09.49.21-resized.png] This is a statping how network performances was impacted before and later bruteforce. Also, need a robust alert system - email or other - to let us know that something is happens.

Thanks for the heads up. We don't really use any of these tools but something to keep in mind. We do use ipset for the firewall block list, but it seems to work fine with Ubuntu 20 though.

@shai said in Format for IP Blocking: If you are curious, blocking China and Russia came to 19,000 rows. Cloudron didn't stutter. The firewall does. It will take progressively longer to make fw changes as you keep adding IP blocks. Not an issue for one time things, but something to keep in mind.

@mehdi my thoughts / use case exactly. Doing so with ipchains is a pain (thanks Docker's intervention to firewall); and ufw just doesn't handle all of the use cases (thanks Docker again).

@necrevistonnezr I was looking in the forum Thank you!

@girish said in Firewall IP blocking: IPv6 not possible: I guess this post was before we had IPv6 support. IPv6 is supported in the firewall by now. Indeed

I was looking if someone, somehow Cloudron implemented Filtron and apparently not it would be nice to have this, even as a sidekick instance. Otherwise for now; I limit the query via Cloudflare with their ZeroTrust service [image: 1720177308337-screen-shot-2024-07-05-at-07.01.28-resized.png]

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