PSA: botsin.space, tor, etc
Over the last few weeks, I've dealt with a large amount of DM spam being sent from this server out to other fediverse instances. Most of the spam has been for adult cam sites. managing the reports for this spam has taken up a lot of my time, and allowing the spam to be sent places undue burden on admins of other instances. i determined that a huge amount of this spam was coming from a small subset of IP addresses owned by the hosting company OVH 1/*
PSA: botsin.space, tor, etc
As a professional sysadmin, I've been dealing with OVH almost since their inception and for most of that time it has been a source of a disproportionate amount of spam, server attacks, hacking attempts, and so on. What's more, I've experienced what amounts to criminal neglect when attempting to get them to deal with these sorts of issues.
PSA: botsin.space, tor, etc
This is something I've been dealing with for a long time, and knowing that OVH won't do anything about it, I decided to block their netblocks from the botsin.space server.
I did that last night. This morning I removed those blocks, when I realized that a few mastodon instances are on OVH. I don't want to break federation so I'm going to rewrite the block rules to hopefully allow federation while blocking the spam.
PSA: botsin.space, tor, etc
Meanwhile, I learned that a lot of Tor exit nodes are hosted on OVH. To be frank, your desire to maintain anonymity while viewing bots on the fediverse does not outweigh my needs to be a mentally healthy person. If I can find a way to allow Tor while blocking spam, I will do that, but I am not going to spend a lot of time on it because I don't expect it to be possible. I am truly sorry for any problems that causes. That said...
PSA: botsin.space, tor, etc
I am essentially left with three options:
1) Scan DMs for spam content
2) Block the IP range the content originates from
3) Shut down botsin.space
I will never do #1. I'd rather not do #3. That leaves #2
PSA: botsin.space, tor, etc
just to keep things interesting, while the traffic i'm dealing with comes from OVH, it does not appear to be using Tor
re: PSA: botsin.space, tor, etc
@muffinista Would it be possible to block the IPs from registering accounts but not completely block them?
My forum is hosted on OVH, so it would need access to the public web UI to embed stuff, but that shouldn't mean it needs to *write* anything to your instance.
re: PSA: botsin.space, tor, etc
@ben yeah one option i'm considering is basically just to block the frontend. i think that might work?
re: PSA: botsin.space, tor, etc
@muffinista looks like you can ask TOR for a list of exit nodes that connected to your IP recently: https://check.torproject.org/cgi-bin/TorBulkExitList.py
PSA: botsin.space, tor, etc
@muffinista preventing traffic from https://check.torproject.org/exit-addresses to access the registration is probably sufficient and would allow existing users to login.
PSA: botsin.space, tor, etc
@sascha i'm going to explore something along those lines, thanks
PSA: botsin.space, tor, etc
@muffinista also, OVH, just like Hetzner, provide very very affordable hosting for dedicated boxes, which is great for running an actual scaling instance on the cheap... so I'd really want to prevent their net from getting unfederated
PSA: botsin.space, tor, etc
@muffinista the real issue will be when spammers figure out how to implement a minimal activitypub server... we're gonna have the issues email had 20-30 years ago all over again
PSA: botsin.space, tor, etc
@sascha ugggg yeah
re: PSA: botsin.space, tor, etc
not really, since email from a spam-only domain is easily blocked. and on Mastodon, that can happen retroactively.
the problem occurs when big email servers have some spam and some real accounts.
re: PSA: botsin.space, tor, etc
@ben @muffinista If you've ever run a MTA you know how inventive spammers can get, right now there isn't even a way to ban an entire domain (with subdomains), there's going to be an arms race and I'd rather someone that gets paid to do masto dev takes preemptive and not reactive action.
re: PSA: botsin.space, tor, etc
@sascha @muffinista the solution (that's working extremely well) for WTDWTF is that we require moderator approval for a user's first post and admin approval for any account made from an IP that has logged in in the past.
You also can't edit your public profile until you have at least one post.
Spammers seem to have given up (or at the very least, tried to make profile-only spam and failed because nobody can see it)
re: PSA: botsin.space, tor, etc
@sascha @muffinista (of course, WTDWTF is a forum that doesn't federate with anything, so
it's not a solution that will work identically here, but it felt good to know that a very minimal amount of work can remove any incentive spammers have to try to spam)
re: PSA: botsin.space, tor, etc
@ben @muffinista first contact with an instance approval sounds like it'd work for a while, but doesn't scale. Having a shared whitelist where anyone can OK a new instance seems like a good idea for the long run.
PSA: botsin.space, tor, etc
@sascha yeah, i agree, that was an oversight on my part. i'm sure there's a lot of legit boxes on their network
re: PSA: botsin.space, tor, etc
@muffinista I wonder, could you prevent outbound unsolicited DMs (as in, require previous contact from the recipient)?
Could require too much metadata collection to be a good idea though...
re: PSA: botsin.space, tor, etc
@bhtooefr i've thought about that, or simply preventing you from sending a DM immediately after creating an account, but i'm not sure it would help here. it's a good idea though.
PSA: botsin.space, tor, etc
this whole thing sucks and is a huge weak spot in the fediverse right now