@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 I seeeeee! You've thought all this through before! OK, I learned new things from your explanation. Prob one just for the documentations then unless you think a per-App setting would be easy enough? It's only saving going into Cloudflare to delete and re-add the records but then my next research is going to be into https://dnsmadeeasy.com. TBH as I think Cloudflare is more a pied-piper following for their good marketing than for the essentials that are often better handled at the host (like Anti-DDoS, for which I do like Hetzner covering on the network level).

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!

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.

@Miggi I am a big fan, too and are upvoting. Please also see this thread: https://forum.cloudron.io/topic/1355/pi-hole-network-wide-ad-blocking/17?_=1594947401156 Together it makes even more sense.

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