Cloudron Forum

Thanks for the heads up. The new package is out now.

Actually, it seems a better way to confirm this is the apt package version and not the dovecot version. The latest one (i.e one which will be in next release) shows this: root@e4d2eb1cba0b:/app/haraka# apt list --installed 2>/dev/null | grep dovecot-core dovecot-core/bionic-updates,bionic-security,now 1:2.2.33.2-1ubuntu4.7 amd64 [installed] The current cloudron container has 1:2.2.33.2-1ubuntu4.6

@girish thanks again for this!

@girish also, I imagine if MailPile hadn't tried to make PGP easy as part of it the developer might not have burnt out and there might be a decent open source webmail app!

@nicolas There's a feature request to monitor network traffic at the app level. If we had that, we could have narrowed this down more quickly.

@nebulon just for information - livepatch doesn't mean you don't have to reboot - it just lets you postpone that moment as convenient. For sync - a good practice on old good *nix is to issue sync twice before reboot - to make sure the buffers dumped for sure. On the reboot automation using third-party apps - it's doable; everything is, but why, if you can just add it inside of the system?

@murgero Yeah, makes sense.

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

@girish I think all these % numbers are a bit misleading and opinionated - but as you rightly detail it's a case of looking at the appropriateness of each item and reasonability. It's impossible to know or remember everything but still a nice too for a quick review to see if there's any easy wins, and I suppose the scoring mechanism could be handy marketing for some once a certain level is considered reasonably hardened.

@girish Done - https://forum.cloudron.io/topic/3777/support-optional-cloudflare-proxied-record-creation

This is implemented in 5.4

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!

@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

@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/

@girish Thanks for the tip on updating SSH-keys. I wasn't talking about fail2ban reporting, only. I was also referring to the built-in "rate-limiting" of Cloudron (and other security features, e.g. the cloud firewall) where there's currently little or no transparency what's happening. Since Cloudron "takes over the server" I think it would be a good opportunity to add transparent monitoring of the system's security features similar to the "System info" tab...

Thanks @girish!

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