If you are using one of the *oma instances (Akkoma, Pleroma, etc): you can easily handle this spam wave without playing defederation whack-a-mole by doing the following:
- Enable
RejectNewlyCreatedAccountNotesPolicy
and set the limit to at least one hour. Note that this is not without tradeoffs: users who migrate to new accounts will not be able to reach your instance until their account is old enough, and will often wonder what’s going on. - Enable
HellthreadPolicy
to limit the maximum number of mentions in a post before it stops notifying mentioned users, or before it’s rejected outright. Temporarily decrease the limit during a spam wave if you need to. - Enable
KeywordPolicy
and add strings commonly found in spam posts, such as domain names (followed by a slash, to reduce false positives from real users simply mentioning the domain without linking it), hashtags, and uncommon words. Look up the “Scunthorpe Problem” if you’re unfamiliar.
When the dust settles, depending on available spoons, I might go through the instances that haven’t cleaned up spam after multiple days. Those are likely abandoned and extra-vulnerable to future attacks and block evaders. On *oma, these defederations will not sever connections and are reversible.
Seirdy reshared this.
Seirdy
in reply to Seirdy • • •obligatory “Fedi needs a middleware like a WAF for filtering remote messages”.
cattle-grid looks like a good start, though it does tend to trigger false positives when scanning for auth-fetch block evaders.
Seirdy
in reply to Seirdy • • •Sensitive content
amazing to me that all the most popular instance software requires admins to play domain-name whack-a-mole to address spam that’s really easy to automatically filter on a message-by-message basis.
how many more spam waves do we need before people realize that these would be effortless to defend against if their instance supported basic filtering that has existed for years?