serious Cloudflare goof
-
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.
-
@benborges you can also consider moving the mail server to a separate Cloudron instance. There's no reason for all of it to be on a single server.
-
@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).
