no, only 2-3 ports tcp/udp (wireguard/snmp/ssh)
and it happened inbetween again, without any reboots/upgrades/etc. I got notfied by network mgmgt system, that my cloudron server is down - luckily it was just the firewall…
@cumpal Cloudron expects to be the only one running on the server, so for security reasons it locks it down unless needed by Cloudron or any of the apps on it. If you need to modify it, I think you can just update the firewall rules manually in Ubuntu, though I've not done that part myself as no need for it yet. but hopefully that at least explains why it's locked down. You may want to review the Cloudron docs on security features too.
@jdaviescoates Correct, if you use Gandi API you are using wildcard certs and good.
When a cert is issued, most of the current certificate providers these days "log" the domain name as part of the https://en.wikipedia.org/wiki/Certificate_Transparency project. These reports can then be scanned later. For example, go to https://crt.sh/ and search for say %google.com%. This gives various subdomains of google. When you use wildcard certs, only *.domain.com is logged and thus the subdomain is hidden. So, if you install searx at mysecretsearch.domain.com, there is no way for anyone to know the subdomain mysecretsearch since DNS has no subdomain search.
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.
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
@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 👍 👍
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
@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.