How to set-up Firewall and/or Proxy to protect my Cloudron instance?
-
- I recently purchased a Cloudron license but until now I could't actively use it due to security concerns: I wish to have another VPS instance (in the same VPC) acting as a gateway (to my Cloudron), such that it could provide reverse proxy (NOT ONLY for HTTPS), maybe packet filtering, vpn and whatever else a gateway/router would do.
- Other posts that I found in this forum were not specifically helpful, and, as of now, the documentation about it is somewhat terse (https://docs.cloudron.io/networking/#firewall).
- So I humbly ask the following:
- What EXACTLY (on the linux system and wherever else) does the "Trusted IPs & Ranges" setting do? The GUI description suggests it only applies to HTTP, but why is that? Whats the difference
- What EXACTLY (on the linux system and wherever else) does the "Blocked IPs & Ranges" setting do? Is it just transpiled into Cloudron's instance nftables/iptables?
- What is the maximum number of lines that the "Blocked IPs & Ranges" and "Trusted IPs & Ranges" can take? And how long does it take to be in effect?
- Could Cloudron's staff shine some light about this at the documentation? I found other forum topics asking for clarifications on networking configs like this, so maybe it deserves to get more detailed documentation.
-
Cloudron uses iptables on the system to open required ports. Those ports depend on the apps which are installed.
The full script, which configures iptables can be found at https://git.cloudron.io/platform/box/-/blob/master/setup/start/cloudron-firewall.sh?ref_type=headsFor the blocked IPs, we use
ipset
together with thecloudron_blocklist
https://git.cloudron.io/platform/box/-/blob/master/src/scripts/setblocklist.sh?ref_type=heads -
-
Thanks for your attention and my apologies for not being able do read your source code before posting here. Actually I tried to, but when following the https://git.cloudron.io/cloudron link ( at https://www.cloudron.io/opensource.html ), this gitlab landing page looked like I'd need an account in order to read the code.
Now that I view it again, I see it actually has a link in the footer (labeled as "Explore") that allows anyone to view the code. A little counter-intuitive, as all of the other footer links only regards to the gitlab project itself.
Anyways, I hope this "discovery" makes me (and others) avoid unnecessary or malformed questions in this forum.That said, I think that security and privacy deserves more attention on your documentation (and maybe in some parts of the PaaS product). The used UFW rules are just too permissive (which is OK inside a SOHO network), but could be better tailored with a drop-in file to make user-provided custom firewall chains; writing a blocklist in a little web text field (or posting it via an API without knowing the maximum payload size) seems unreliable; this lack of explicit documentation about reverse proxying, WAF (etc) just annoys part of your potential customers. Also, while being something not simple to safely deploy, Cloudron could have built-in (or a documented tweak for) traefik.io (or any WAF) integration; some encryption/obfuscation mechanism (at least) for end-user data on the docker volumes (protecting the data-at-rest from third parties); and maybe allow to install some monitoring agent inside each app deployment.
What worries me is that, while having great respect for the Cloudron project and product, maybe just deploying Cloudron "as-is" in a VPS would create security breaches that are (unnecessarily) worse than the privacy breaches regarding the Big Tech ecosystem.
-
If you have any concrete suggestions for improvement, we will certainly look to improve the defaults for Cloudron. Adding a WAF or other external proxying is not really in scope for Cloudron itself, but can be added in front of Cloudron already if sysadmins know the side-effects depending on the apps used on Cloudron, which a WAF introduces.
-
If you have any concrete suggestions for improvement, we will certainly look to improve the defaults for Cloudron. Adding a WAF or other external proxying is not really in scope for Cloudron itself, but can be added in front of Cloudron already if sysadmins know the side-effects depending on the apps used on Cloudron, which a WAF introduces.
@nebulon said in How to set-up Firewall and/or Proxy to protect my Cloudron instance?:
if sysadmins know the side-effects depending on the apps used on Cloudron, which a WAF introduces.
Cloudron does SOOOO much for many of it's users already, and meets our needs. This is an important point. It can't necessarily do everything, nor should that be seen as a weakness or deficiency.
@MiddleEndian, what realistic, current, or recently exploited security breaches are you referring to? If you are talking generalities, well, sure, who knows what the next 0-day is going to be. But what likely exploits is Cloudron ripe for?
-
Thanks for your attention and my apologies for not being able do read your source code before posting here. Actually I tried to, but when following the https://git.cloudron.io/cloudron link ( at https://www.cloudron.io/opensource.html ), this gitlab landing page looked like I'd need an account in order to read the code.
Now that I view it again, I see it actually has a link in the footer (labeled as "Explore") that allows anyone to view the code. A little counter-intuitive, as all of the other footer links only regards to the gitlab project itself.
Anyways, I hope this "discovery" makes me (and others) avoid unnecessary or malformed questions in this forum.That said, I think that security and privacy deserves more attention on your documentation (and maybe in some parts of the PaaS product). The used UFW rules are just too permissive (which is OK inside a SOHO network), but could be better tailored with a drop-in file to make user-provided custom firewall chains; writing a blocklist in a little web text field (or posting it via an API without knowing the maximum payload size) seems unreliable; this lack of explicit documentation about reverse proxying, WAF (etc) just annoys part of your potential customers. Also, while being something not simple to safely deploy, Cloudron could have built-in (or a documented tweak for) traefik.io (or any WAF) integration; some encryption/obfuscation mechanism (at least) for end-user data on the docker volumes (protecting the data-at-rest from third parties); and maybe allow to install some monitoring agent inside each app deployment.
What worries me is that, while having great respect for the Cloudron project and product, maybe just deploying Cloudron "as-is" in a VPS would create security breaches that are (unnecessarily) worse than the privacy breaches regarding the Big Tech ecosystem.
@MiddleEndian said in How to set-up Firewall and/or Proxy to protect my Cloudron instance?:
Now that I view it again, I see it actually has a link in the footer (labeled as "Explore") that allows anyone to view the code. A little counter-intuitive, as all of the other footer links only regards to the gitlab project itself.
I found a setting in gitlab to change this. It now goes to Explore view by default.
-
Thanks for your attention and my apologies for not being able do read your source code before posting here. Actually I tried to, but when following the https://git.cloudron.io/cloudron link ( at https://www.cloudron.io/opensource.html ), this gitlab landing page looked like I'd need an account in order to read the code.
Now that I view it again, I see it actually has a link in the footer (labeled as "Explore") that allows anyone to view the code. A little counter-intuitive, as all of the other footer links only regards to the gitlab project itself.
Anyways, I hope this "discovery" makes me (and others) avoid unnecessary or malformed questions in this forum.That said, I think that security and privacy deserves more attention on your documentation (and maybe in some parts of the PaaS product). The used UFW rules are just too permissive (which is OK inside a SOHO network), but could be better tailored with a drop-in file to make user-provided custom firewall chains; writing a blocklist in a little web text field (or posting it via an API without knowing the maximum payload size) seems unreliable; this lack of explicit documentation about reverse proxying, WAF (etc) just annoys part of your potential customers. Also, while being something not simple to safely deploy, Cloudron could have built-in (or a documented tweak for) traefik.io (or any WAF) integration; some encryption/obfuscation mechanism (at least) for end-user data on the docker volumes (protecting the data-at-rest from third parties); and maybe allow to install some monitoring agent inside each app deployment.
What worries me is that, while having great respect for the Cloudron project and product, maybe just deploying Cloudron "as-is" in a VPS would create security breaches that are (unnecessarily) worse than the privacy breaches regarding the Big Tech ecosystem.
@MiddleEndian said in How to set-up Firewall and/or Proxy to protect my Cloudron instance?:
What worries me is that, while having great respect for the Cloudron project and product, maybe just deploying Cloudron "as-is" in a VPS
We have plenty of docs and technical notes around this - https://docs.cloudron.io/security/ . If you have specific concerns, please open separate threads and we can discuss.
-
G girish has marked this topic as solved