serious Cloudflare goof
-
There is a serious problem with how Cloudron handles Cloudflare.
I purchased a domain, configured Cloudflair for it, proxying the root of the domain itself. I aimed it at the IP address of a VPS where I'm installing Cloudron.
During the install I pick Cloudflare as the DNS provider and give the system the API token.
The Cloudron install proceeds and then it makes the amazingly grim error of point my.domain.com to the public IP of the VPS without proxying it.
I went to the Cloudflare interface and switched it to proxy but the damage is already done. My workstation did a DNS lookup and that information is cached in services like Farsight and RiskIQ. Having Cloudflare running after the fact will keep the skiddies at bay, but any serious bad actor is going to be able to get that public IP.
What will it take for Cloudron to turn the proxy on when creating the my.domain.com DNS record?
-
@NetwarSystem mmm, Cloudron implements DNS integration and nothing more. I think it's up to the user to enable/disable proxying or any other feature as they see fit. Cloudron does not tamper with those settings.
Cloudflare proxying proxies all traffic via Cloudflare and Cloudflare can read everything. So, one can argue the other way around that Cloudron set up things to make Cloudflare read everything ...
-
@girish said in serious Cloudflare goof:
Cloudflare can read everything.
Exactly.
I really don't get why so many people want to use Cloudflare or think it's a good idea to do so.
-
Cloudron mishandles Cloudflare by being unaware of the proxy option. I just discovered that, having manually turned proxy on for the first apps I chose, then adding a new app, Cloudron helpfully sets them both to just DNS.
So worse that being unaware, it doesn't offer a secure option on setup, and it breaks things that were secured.
-
This isn't a complex issue and I'm amazed in 2023 to find anyone that admits they don't understand the problem.
When a client registers a domain, they use the proxy registration service. This protects them from malicious prosecution attempts, frivolous litigation, and the like. I have clients who've faced this sort of thing in the last year.
When establishing hosting for the domain, the system is protected with the Cloudflare CDN. This interdicts not just denial of service, it also thwarts a lot of intrusion attempts. A little more care in the form of static routing for just what needs to be reached raises the bar even higher.
So when Cloudron just haphazardly exposes an actual public IP in connection with a DNS name, simply turning proxy back on doesn't solve the problem, because that information is then available in tools like Farsight or RiskIQ.
The negative outcomes from the exposure of the hosting IP are numerous. An attacker intending DDoS goes directly at the actual IP, and the system quickly wilts under a barrage of packets.
Starting with just that IP, the attacker will look for "fellow travelers" on the same IP address. If the set is small, they've identified a small hosting provider. If that doesn't produce a result, they'll expand the search to the entire /24. Vulnerable systems get cracked and they all catch that barrage of packets from a shell booter. Then person renting the VPS or dedicated system gets expelled from their hosting provider.
Given some public IPs, some domains, and a little bit of poking around, it's easy to profile the site builder, and find a service address for them.
None of that is at all exotic. I get requests every week or so to identify who is operating a given site. I have not yet encountered someone using Cloudron, but given what I've seen of the system, it's a soft target that is completely unfit for any hazardous duty.
If you want a concrete example of how one little DNS goof produces a catastrophe, I'd be happy to share the study I did on Josh Moon and the digital cesspool known as Kiwi Farms. One mistake, one day, a long time ago was enough of an opening for me to find everything that he was doing.
Cloudron's offering of Cloudflare as a DNS provider without a big fat flashing WE CAN'T DO THIS SECURELY disclaimer is a serious hazard. Right now I've got it running for one project, in a low conflict area, on a system that is not quartered with anything else I do. There's no way I would use Cloudron for anything else, the inability to handle Cloudflare setups in a secure fashion is a deal killer for me.
-
I am not a Cloudflare customer, so I don't know the expectations of Cloudflare customers. Your recommendation is clear. Any other cloudflare customers here? Do you always proxy your sites via Cloudflare? Maybe we should add a checkbox to allow "proxied" setup at domain setup time.
-
@girish said in serious Cloudflare goof:
I am not a Cloudflare customer, so I don't know the expectations of Cloudflare customers. Your recommendation is clear. Any other cloudflare customers here? Do you always proxy your sites via Cloudflare? Maybe we should add a checkbox to allow "proxied" setup at domain setup time.
Cloudflare Domain customer here. Not using proxy. I have doubts about GDPR compliancy.
-
@NetwarSystem said in serious Cloudflare goof:
None of that is at all exotic. I get requests every week or so to identify who is operating a given site. I have not yet encountered someone using Cloudron, but given what I've seen of the system, it's a soft target that is completely unfit for any hazardous duty.
If you want a concrete example of how one little DNS goof produces a catastrophe, I'd be happy to share the study I did on Josh Moon and the digital cesspool known as Kiwi Farms. One mistake, one day, a long time ago was enough of an opening for me to find everything that he was doing.
I don’t believe Cloudron‘s main objective is to be „fit for any hazardous duty“ or to cater to customers of the „Kiwi Farms“ type - but rather legitimate businesses who have to and don’t have a problem with being public.
-
Oh well, I added a checkbox to set the proxying flag for new DNS records. I was in two minds but "security" is plastered all over cloudflare's marketing and docs about this feature. So, people will always have whatever opinion that cannot be changed (including mine
).It's disabled by default. From Cloudron's point of view, this is the secure default.
-
G girish marked this topic as a question on
-
G girish has marked this topic as solved on
-
@girish I'm using cloudron + CF for osintukraine.com, these consideration are super important in adversarial environments, (the question here is not about CF ethics etc..I'm fully aware of them, but still had to use CF for a bunch of very valid reasons)
So yes, the proxy at setup of the app itself would definitely help CF users, I can confirm that every installed app in a CF handled domains, requite to login to CF and manually set proxy enabled.
Since cloudron has full access to CF via the API it would be perfect to allow to set the proxy from the get go, including for the my subdomain.
The problem I'm seeing is that my subdomain is also the MX dns entry
so even if all apps get proxied properly from the start, the MX entry in itself almost render the use of CF + Cloudron useless in a very critical environment.OSINTukraine will be moved back to registrar DNS because ultimately, my domain is already burned, the only thing that kinda save me is that I setup a system that redirect any direct targeting of the box IP back to CF, but again, my IP is burned.
1 year after, I can say that the environment does not seem to be that dangerous for the project I'm running, hence considering to move back.
-
-
@girish on another note, I'm noticing serious issues with the cloudron mail server when used in conjunction with CF, emails sent to me bounce back and the contacts have no way to alert me that their email bounced back, it's still unclear to me why they bounce back, but Cloudron + CF + Self-hosted email server is definitely not working as it should : thunderbird or outlook autodiscovery of email setting fails and even they don't (not sure why in some case they fail and some case they don't) it's impossible to use thunderbird with CF + Cloudron, there is just no way to add the mailbox user.
no issue sending emails, no issue with app emails sending emails to emails hosted by the cloudron, no issues sending emails outside.
problem seems to be getting them. Took me months to notice this problem for instance because i wasn't keeping an eye on the Mail log.
-
-
@benborges Setting the default proxying value in Domains view will essentially set up the domain in Cloudflare with/without proxying for new subdomains. The flag was added only because it's considered a "security" issue. I think adding options to add/remove CF settings per subdomain level should be done in CF itself. It will complicate things too much for us to add things in subdomain level (unless there is a good reason for this).
-
@girish Yes that's I'm currently doing, I mean, heading to CF dns dashboard each time I add a new sub domain/app but this means that during a brief period of time, the IP leaks without being proxied.
I understand if Cloudron does not want to head that way but this means that for high-threat level environments, cloudron should not be used behind CF.
-
@benborges said in serious Cloudflare goof:
I understand if Cloudron does not want to head that way but this means that for high-threat level environments, cloudron should not be used behind CF.
I am confused. The default option which we added for next release should allow you to hide the IP of the server from the get go, no? Can you tell me which workflow it doesn't work for?
-
@girish said in serious Cloudflare goof:
Oh well, I added a checkbox to set the proxying flag for new DNS records. I was in two minds but "security" is plastered all over cloudflare's marketing and docs about this feature. So, people will always have whatever opinion that cannot be changed (including mine
).It's disabled by default. From Cloudron's point of view, this is the secure default.
I think this one is great, it will already improve CF + Cloudron for tons of use cases
-
@benborges said in serious Cloudflare goof:
@girish just thinking out loud but if this is implemented, then other areas where an action create a subdomain on the fly should also have this proxying option available, such as
that is, if the domain is handled by CF dns.Maybe I'm confused, but unless this logic isn't build at the app deployment too, then yes for the main deployment it will work, but not for individual app additions ?
Ideally, if the domain is handled by CF, having a check box to directly proxy the sub-domain installations through CF would be great, but I understand that would add to much CF specific things to the app deployment at cloudron level ?
-
@benborges said in serious Cloudflare goof:
Maybe I'm confused, but unless this logic isn't build at the app deployment too, then yes for the main deployment it will work, but not for individual app additions ?
Ah yes, that's what that flag does. I see now that the screeshot is not "complete". That UI is the domains view. If you set the flag, then when Cloudron adds a new domain to Cloudflare, it will set the proxying based on that value. Essentially, it's the default value of the proxying cloudflare bit for new subdomains (so, not just installation time). If you want to turn this off later, you can do so by going to the Cloudflare dashboard. Cloudron won't interfere with the "proxying" flag after the domain has been added (for the lifecycle of the app).
