this post was submitted on 20 Jun 2023
202 points (100.0% liked)
Technology
37699 readers
341 users here now
A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.
Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.
Subcommunities on Beehaw:
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I think that's a heck of a loaded assumption there that I'm relying on the Devs here
Cloudflare ✅ Strict Firewall Rules ✅ Hosting on an actual cloud provider rather than my home ✅ CSAM Scanner ✅
However, that's come with other tradeoffs in useability, speed, and fediration experience.
Just today I found that the OWASP managed rules in Cloudflare end up blocking certain functions of the site, sure I'll be adding an exception/rule for that, but it's not a straight forward task. Heck, the removal of websockets will require quite a few changes in my Cloudflare config.
Sure, someone truly concerned with security knows to do this, but that's definitely not going to be everyone, and now with the current spam situation we're turning individual instance problems into "everyone problems".
Like what? If properly configured none of the things listed should negatively impact hosting a Lemmy instance.
It honestly should be to someone who would be hosting any public web application using Cloudflare. Cloudflare makes all of this quite easy, even to those with less experience.
What config are you referring to? In the Cloudflare console? For websockets changing to a REST API implementation there should be nothing at all you need to do.
And it shouldn't have to be everyone, only those who take on the responsibility of hosting a public web application such as a Lemmy instance.
No matter the capabilities inherent in what you choose to host, the onus rests on the owner of the infrastructure to secure it.
Everyone should be free to host anything they want at whatever level of security (even none) if that's what they want to do. But it's not reasonable nor appropriate to expect it to be done for you by way of application code. It's great if security is baked in, that's wonderful. But it doesn't replace other mitigations that according to best practices should rightfully be in place and configured in the surrounding infrastructure.
In the case of the captcha issue we're discussing here, there's more than enough appropriate, free solutions that you can use to cover yourself.
Can you elaborate which functions are blocked by the managed rules? I haven't noticed anything legit being blocked yet, just a bunch of obviously malicious things.
Yeah, I can't seem to upload photos without whitelisting /pictrs/ from the OWASP managed ruleset. It wasn't being "blocked" but it was trying to do a managed challenge and the lemmy-ui's code didn't really understand what to do with it. so it would just throw an error on upload.
I would recommend reconsidering that solution - I've already seen some malicious image uploads which Cloudflare has caught and prevented. For example:
Maybe you can check which specific rule from the ruleset was being triggered? For me, legit uploads are still working with the default ruleset (as you can see by the screenshot I uploaded in this very comment), so maybe you enabled some extra rules?
Interesting, well, I guess I sound vague because the error was pretty vague:
Cloudflare OWASP Core Ruleset
949110: Inbound Anomaly Score Exceeded
So yeah, your example is from the Standard Managed Ruleset, I wouldn't even think of Disabling that, and I think this issue is limited to this OWASP one only. I think I'm still safe here, but I think I can just exclude only this one particular rule as you noted.
EDIT: Nope that's the one you cannot edit. Strange, I'm fairly certain these files are fine and it's probably not that - I may have to exclude the entire ruleset here.
Double Update: Yeah, so this OWASP one is far to sensitive. I've validated my files with AV and other solutions and tried other machines and such. Apparently it's tripping some XSS rules, SQL injection detection rules, and a few other things. Mostly seem like false positives on account of the EXIF and other file header data.
Triple Update: Found the proper way to exclude from specific rules in the managed rulesets. There's like multiple ways that you appear to be able to do it, but only one way that works.