this post was submitted on 10 Jul 2023
383 points (100.0% liked)
Beehaw Support
2796 readers
1 users here now
Support and meta community for Beehaw. Ask your questions about the community, technical issues, and other such things here.
A brief FAQ for lurkers and new users can be found here.
Our September 2024 financial update is here.
For a refresher on our philosophy, see also What is Beehaw?, The spirit of the rules, and Beehaw is a Community
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
The shutdown is a good call given the circumstances.
An idea of less-radical preventive action is placing the instance in read-only mode, either as a Lemmy feature, or through reverse proxy settings (eg reply 503 for any POST/PUT/DELETE request). But that'd require some development and/or preparation.
Doing that on the reserve proxy side would block any user-submitted content and more (logins, searches, ...). This would hopefully be efficient at blocking many attack vectors, while still keeping the instance partially online, even if that's a degraded mode.
Note that if this were a Lemmy feature, if we had been infected, an admin could've gotten hacked and as a result, disabled that feature. I'm not really sure what can be done to make Beehaw foolproof. That said, the UI has since been hardened by CSP headers so this type of attack should no longer be possible.
Would read-only mode help with XSS exploits though, like this particular one? Since the "damage was already done" by the time anybody noticed, wouldn't putting the site in read-only mode still have kept serving up the XSS payload? It'd stop "infected" people from making any state mutations on Lemmy, but eg. data exliftration would still happen