Is it possible to limit IP address which can access to Cloudron instance login page?
@eric f you follow the idea of ip tables (imho the only valid thing), think of the openVPN app from the app store. The idea is to allow access to the dashboard only from the (external) ip from the Cloudron instance itself. Therefore you need openVPN
@eric Thank you for the code snippet!
That's the format of suggestion what I'm exactly seeking for.
At the moment, all that I can do is copy-paste, so...
.htaccess method would be useful when I want to limit access to individual apps, like Monica or Roundcube.
I just personally feel uncomfortable/insecure when people can access to the login page just by adding "my." in front of the root domain.
That's why I want to limit the access from random people by allowing an IP addresses from my self-hosted VPNs (Yes, OpenVPN).
My question is; is setting up iptables like this
sudo iptables -A INPUT -s xxx.xxx.x.x -j ACCEPTcan limit the access to the apps on my Cloudron?
I need to achieve these;
- to limit the access to my Cloudron dashboard login page
- while limiting the access to the login page, I want to let some pubic apps (Ghost, Wordpress, Lamp) stay public (without IP limit)
Thank you all for your advices!
@hiyukoim Ah I see!
I'm still looking into the correct command to execute for my case, but still no clue. (Maybe I should consult a specialist...?)
Iptable looks a bit too advanced for beginners. Still, limiting access to my.yourcloudron.com by IP is one of the essential security features, I think.
If Cloudron UI can let us manage IP address whitelist/blacklist, that'd be a great help for me and people like me.
@hiyukoim With the hardening that Cloudron does, and with Two Factor Authentication enabled, limiting access to the login screen doesn't buy you much. Unless you're fairly advanced, I wouldn't do it.
I'm a senior security consultant for a top security company and I don't do it. Think about every web service you use, limiting access to specific IP addresses is an older security model.
I too won't recommend going down the iptables route. Generally, with 2FA you are quite protected. We haven't completely documented iptable commands (and I am afraid to put them here) because people will try it and if something is wrong, it will lock them out.
A workaround if you really want to blacklist/whitelist is to use a 3rd party service like say Cloudflare which can act as a proxy to the Cloudron dashboard and in Cloudflare you can set up firewall rules. Cloudflare can do this at a domain level, so your other sites are intact. But do know that your credentials will now go via Cloudflare.
But do know that your credentials will now go via Cloudflare.
This part is particularly important ^^
This post is deleted!
@will Cloudflare has a few products/features that analyze the contents of the traffic and may even insert scripts into it by parsing the HTML. This is the reason we had the major cloudflare security incident.
Personally, I feel it comes down whether you trust them with decrypted traffic. The answer totally depends on the use case and how you use them, I think.
@girish Ah, so they are not looking inside the TLS tunnel, but getting HTTP traffic that leaked.
Relevant portion for those interested:
"This included HTTP headers, chunks of POST data (perhaps containing passwords), JSON for API calls, URI parameters, cookies and other sensitive information used for authentication (such as API keys and OAuth tokens)."
@will Can you give you source for the information that Cloudflare does not see inside the encryption session? I am a bit skeptical. The TLS tunnel goes to them, not to your own server. The whole point of their service is for them to handle the session so they can do some smart caching. The only more or less similar thing I know of is their Keyless SSL technology ( https://support.cloudflare.com/hc/en-us/articles/360022014111 ) which allows them to still terminate the encrypted session while not having the keys.
@mehdi Yeah I think Im mistaken on that.
We are implimenting an enterprise TSL Break & Inspect (man in the middling everyone's TLS) and it requires the endpoint to have the certificate of the Proxy accepted on box.
Basically, if Cloudflare was breaking and inspecting TLS sessions in order to cache, you'd need their TLS cert on your server.
[You] -------TLS Tunnel ------- [Destination Server]
Break & Inspect TLS
[You] ------ TLA Tunnel to Cloudflare (TLS Session 1) ------ [Cloudflare Proxy] ----- TLS Tunnel to Destination (TLS Session 2) --------- [Destination Server]
So instead of the destination's certificate, you'd be seeing Cloudflare's cert. I'll look into it more, I don't want to give bad advice.
@will When you enable, Cloudflare proxying, you do see their cert (or the cert you have provided them with).
It's basically a break-and-inspect that they do. Except their root certificate is already trusted by most machines by default ^^
@mehdi Thats kind of scary, thanks for the correction.