Cloudron Forum

I wanted to share some information acquired from the school of hard knocks...

Background: I found that VaultWarden uses PBKDF2-SHA-256 as its default encryption with 600,000 iterations. One thing I discovered from security experts after being one of the many unlucky LastPass customers (victims of a hacking incident) was an added vulnerability in that everyone had the same number of KDF iterations based on default installation values. While VW's 600,000 is far greater (and better because it requires more calculation resources) than my LastPass default setting, it is unfortunately the same for everyone - unless you change that:)

Suggestions:

• Set a random value > 600,000 for the # of KDF iterations - Account Settings | Security | Keys. Setting a value too high can make VW a bit unresponsive, so increase sensibly based on VW's suggested increments.

• OWASP publishes a recommendation on the # iterations for PBKDF2 encryption . Check periodically to make sure your value is equal to or greater than their recommendation.

• Note: Each user will need to change this setting for their account.

Benefits: A random KDF means a hacker has many more possible combinations to try. With any luck they will move on to an easier target. Staying at or above OWASP recommended iterations makes sense as well.

Hope this helps.

I agree 100% with @igaudette. I do understand that some of the applications voted up on the App Wish List like Zulip (one of the top apps for quite some time) take a lot of resources. And Cloudron seems to support both business and home users. But before increasing my paid Cloudron instances, I am waiting to see some of my business needs met. It's a simple question of "make" vs. "buy". I would much rather "buy" a solidly hosted solution from Cloudron rather than "make" it myself using my company's development resources. But I can't wait forever and have started to investigate Cloudron's competitors to see if they can provide these business solutions. I believe in this platform, the Cloudron team, and our community, but spending time adding apps because they are "easy" seems like a bridge to nowhere. Let's start building to somewhere.

@timconsidine You are so right. The best day for Team Cloudron is one in which there are no updates. I give @girish @nebulon @joseph an enormous amount of credit for the job they do. As someone who rolls out ~ monthly updates to users, every time that happens I pray that me and my team didn't miss something important. But it happens to all of us, despite good processes and best of intentions. But 8.3 will be replaced shortly with 8.3.1 and then 8.4 and then 9.0. And this difficult day will be replaced in everyone's memory by the great things that are yet to come!

Since Cloudron already manages "allowed ports" internally, I think that adding TURN server ports to this list is a necessary security feature. Here are the details:

Background:

Several Cloudron users have reported that unwanted (hacking?) attempts are being made to connect to their Cloudron's TURN server despite the fact that no installed apps utilize TURN.

Server resources (256MB RAM + application logs) are being wasted when no app needs an operational TURN server.

Managing this external to the Cloudron server via firewall or proxy leaves the potential for a support issue when a user adds an app that needs TURN, but forgets to update their firewall and enable the ports. (Note: Also, this solution just blocks the connection, but still wastes resources).

Proposal:

Have Cloudron handle TURN server management (resources, ports) internally with the following logic:

(1) If an app requires TURN server access (it should be declared in the app manifest). If that occurs, then the TURN server container should be "brought up" if not already enabled, resources (memory) deployed according to the configuration, and TURN ports permitted in the firewall.

(2) If no apps use TURN, then the server should be disabled, ideally, the container disabled, and TURN ports blocked by the internal Cloudron firewall automatically.

Perhaps a "first step" would be during Cloudron boot, to disable TURN ports (firewall) if no app needed TURN, leaving the container operational as is. This would accomplish the needed security and with no connections being possible, the actual utilization of the RAM should be almost 0.

Everyone, please feel free to add/delete/modify as you see fit!

@d19dotca Many thanks for sharing this. I'd like to suggest another addition based on one nasty abuse I've seen: unsubscribe links that use http instead of https, hoping that browser security blocks/warnings will cause users not to follow through and unsubscribe. Anyone not using https for anything these days is not worthy of my time:) This puts them where they belong:

# Rule to detect unsubscribe links that do not use HTTPS
body UNSUB_LINK_HTTP /unsubscribe.*http:\/\//i
describe UNSUB_LINK_HTTP Unsubscribe link does not use HTTPS
score UNSUB_LINK_HTTP 10.0

Cloudron is so reliable I am using Kuma inside Cloudron to check availability on all my other unreliable vendors:) And some of them will have one less customer in the near future.

@girish We contributed some code back to Plausible Analytics some time ago to accomplish some things we wanted on our time line rather than theirs. They publish infrequent "official" updates to the self-hosted Docker code in part to minimize the support impact on their small development team. I believe they publish their code (not self-hosted) updates more frequently, which might give visibility to security updates and new features. Their primary source of revenue is from paid accounts that they host on their own infrastructure, so perhaps another reason is to entice customers to use their hosted Plausible solution.

FWIW, we do both, in part to support their efforts. They are solid and I have nothing but good things to say about them as a company, a platform, and as individuals.

@necrevistonnezr Thank you for providing this information. It is really nice to know that although I am not a German taxpayer they are watching my back as well. Much appreciated. @joseph And as usual, Cloudron team is on the ball patching quickly so any exposure is minimized. Well done!

@alex-a-soto Great idea. I'm interested. Let's see if anyone else has a similar interest. In either case, I will reach out as you suggested.

I would like to wish Team Cloudron a Merry Christmas and Happy New Year! Thank you for all you do to make our lives better. And to all the incredible members of our community that make this the best platform in tech, my appreciation and warm wishes for a terrific 2026:)

As a relatively new member of the Cloudron community (especially compared to @scooke) I can see both points of view. The current collection of apps is very eclectic, spanning both personal and business. And to a certain extent that reflects the wide range of our community - a strength.

I do not envy @girish and team trying to please all of us. It is both thankless and impossible. But one person's "must have" app is another person's "who cares". The danger is losing members if their needs are not met with the applications they need or want.

Perhaps having a simplified installation process would allow more people to customize their Cloudrons as desired. And yes, despite the warnings that you are on your own, I am sure that support questions will arise. And the spirit of the Cloudron team and the community to help will always prevail. As long as these questions are within reasonable limits, perhaps this will allow the platform to grow more valuable without being overwhelmed. I would suggest that custom-installed apps have its own topic area, especially if the results could be hidden from search engines to prevent prospective members getting the wrong impression about Cloudron's reliability per @scooke 's valid concerns.

Finally, I am personally interested in a business-oriented, custom-app platform where Dockerized applications can be hosted in a well-thought out and architected environment like Cloudron. We are exploring several ideas along these lines, including adding some private applications we have created, others we have paid to license, and some that are open source. And these systems would require incremental Cloudrons - helping to grow the revenue stream. In the end, that's the idea, isn't it...

@joseph What I see appears to be "normal" attempts to connect to a TURN server. The problem is that there is no application "publishing" my TURN server to make it usable by potential WebRTC connections. So these are people trying to leverage a misconfigured TURN server or a software vulnerability. In my mind, it's no different than people probing to SSH to a server - hence the reason to use Fail2Ban and other tools to restrict this.

Since Cloudron manages "allowed ports" internally, I think that TURN server ports should be added to that list as follows:

(1) If an app requires TURN server access (it should be declared in the app manifest), then TURN ports should be opened)
(2) If no apps use TURN, then those ports should be closed by CLoudron automatically.

Agreed. Cloudron is A+:)

@marcusquinn I would build a new room with floor to ceiling monitors on one wall. Reclining theatre seating and a kegerator. And a Hirsh keypad to prevent anyone except me from entering:)

@creative567145 Try these (replacing endpoint and region with proper references matching your bucket):

export S3_ACCESS_KEY="your_backblaze_b2_keyID"
export S3_SECRET_KEY="your_backblaze_b2_applicationKey"
export S3_BUCKET="your-bucket-name"
export S3_ENDPOINT="s3.us-west-002.backblazeb2.com"
export S3_REGION="us-west-002"
export S3_SSL="true"

Decided to implement Postiz and after working through the config and options, I realized that the app is of marginal use on Cloudron. Here are the details:

(1) You can enable OIDC which is great. But if you disable registration, you are unable to invite any other users to your "workspace".

(2) If using OIDC, potentially each Cloudron user could have their own workspace, but you would have to enable registration, add the user, and then disable the user.

(3) Assuming you follow the path in #2, there is no admin interface to see the users in your instance, leaving you with the potential that someone unknown has signed up and is using your Postiz instance.

(3) If you use the app's own authentication (not OIDC), you can invite other users, but can only have a single workspace per domain. (see #4)

(4) #3 would not be a problem as you can define a workspace for each Cloudron domain you wish, except that the Docker container is massive (4GB) due to an unoptimized node_modules. So the cost of an instance per domain is 4GB of disk and 1GB of RAM. A lot of resources wasted.

If you are social media team of 1 person and need only one workspace on your server, I can see where Postiz would work. But with Cloudron's strength being a multi-domain architecture, Postiz seems to be lacking in many areas.

Any other opinions?

@infogulch Looks like you are right. I checked one of my VW backups and searching for the unique KDF iterations revealed that it is in fact stored in the database. So the information I read after the LastPass breach was incorrect suggesting that a random value of similar size provided more protection that just using the default value.

As I recall the default value at that time was 100,000 and OWASP was suggesting a much larger number. In fact some long time users had much smaller KDF iterations, making the hacking effort minimal.

So it looks like OWASP recommendation should be the minimum KDF iterations and to @girish question earlier, perhaps increasing the value based on your own hardware devices in sensible increments.

Thank you @infogulch for correcting my misinformation. But since my random # was higher than 600,000, I'm keeping it:)

@girish Thanks for the suggestion. Sounds like I will need to pursue this idea on an app by app basis, rather than signing on as a Cloudron user. If I am successful, I will share the results so that others can benefit as well.

I have been playing with packaging Keila. Still needs some more work, though. I am particularly interested in the ability to set sending limits (tied to Paddle plans).

@nebulon @girish I think that user choice would be best with Cloudron recommendation (3 failures in a row) being the default.