Yup, this is in our plans. This is also the pre-requisite for @nj 's request of having all apps ask for 2FA in the password field.

I think there's a genuine case in the future where if we introduce per-app admins, then app admin can access terminal of one app to see traffic (and sniff ldap/db creds) of another app. I think it's an excellent suggestion to remove it!

@girish The manual check method is good enough for me. If you do the release channel thing thats cool. But for those of us that a hungry, an extra few clicks isn't a bother.

@Hillside502 yes, that was a ui bug!

To add here, SSHd configs are very often VPS provider specific even, not just Ubuntu. So ideally Cloudron should not try to manage too much around that, since then this might interfere with for example SSH recovery strategies from VPS provider. Generally it is always a good idea to use ssh keys instead of password.

@dieter if you add an ssh key whilst buying the Hetzner server then they don't even create a root pw

Firefox Monitor Server -- breach data is powered by haveibeenpwned https://github.com/mozilla/blurts-server https://monitor.firefox.com/

@necrevistonnezr There is no fail2ban on Cloudron. Currently, we just rate limit all authentication routes to minimize risk (and with 2FA and app passwords risks are even lower now). We had a plan to implement firewalling this release (rate limits per IP, block specific IP etc), but already changes were piling up. So, we will have some more advanced firewalling features in a future release.

Thanks @girish!

@girish All these years and it’s still a pain >_< Edit: I’m referring to Linux distros ofc, not Cloudron.

@girish I second this

@necrevistonnezr this was the one https://forum.cloudron.io/topic/1971/urgent-security-issue-in-nginx-php-fpm

@necrevistonnezr Thanks, good to know. Will keep an eye for the ubuntu update. Cloudron is not at risk because we only use it internally (it is not exposed via public port). We also don't use NOTIFY query (this is a zone change notification across dns servers) as we use unbound as a recursive resolver and nothing more.

I guess this should come in as an nginx update via ubuntu at some point. We don't package nginx ourselves.

@will No worries mate cheers!

@ahkg the reason for whitelisting 172.18.0.1 give access to all requests, is that this is the ip of the Cloudron internal gateway into the subnet where all apps are running. Unfortunately for your case the cloudron healtcheck also comes via this gateway. I think your htaccess file needs to check for the X-Forwarded-For header to check against the correct inbound address.

I have updated the ciphers now according to mozilla's config generator. The commit is https://git.cloudron.io/cloudron/box/commit/ddaa52163bf3844b36d6c29fdffb5db3e0b3f5d0 For the CSP settings, this indeed cannot properly be done on a platform level, as apps require differently strict settings there and have to provide this on their own, so this should ideally be fixed in each app upstream.