Stator is inadvertently communicating with defederated domains?
futzle opened this issue · comments
As a member of a visible minority, the first thing I did with my instance was to insert the 400 or so instances on the Oliphant Tier0 list into the users.domain model as Blocked. I consider this SOP for any Fedi instance deployment. (Side note: it'd be nice if I could import block lists on the web interface, or even to pre-emptively add blocked domains without messing with Django scripting.)
Yet I think my instance is still announcing itself to those blocked instances when the stator tries to fetch instance information from it.
$ sudo docker logs -t worker 2>&1 | grep genderheretics
2023-07-06T05:32:58.685628856Z Attempting transition on users.domain#genderheretics.xyz from state outdated
2023-07-07T05:33:06.614091697Z Attempting transition on users.domain#genderheretics.xyz from state updated
2023-07-07T05:33:07.195333279Z Attempting transition on users.domain#genderheretics.xyz from state outdated
2023-07-08T05:33:17.637618935Z Attempting transition on users.domain#genderheretics.xyz from state updated
2023-07-08T05:33:19.152528304Z Attempting transition on users.domain#genderheretics.xyz from state outdated
2023-07-09T05:33:27.694674737Z Attempting transition on users.domain#genderheretics.xyz from state updated
2023-07-09T05:33:28.264756791Z Attempting transition on users.domain#genderheretics.xyz from state outdated
2023-07-10T05:33:44.685896184Z Attempting transition on users.domain#genderheretics.xyz from state updated
2023-07-10T05:33:46.373056364Z Attempting transition on users.domain#genderheretics.xyz from state outdated
2023-07-11T05:34:11.901867475Z Attempting transition on users.domain#genderheretics.xyz from state updated
2023-07-11T05:34:12.429001795Z Attempting transition on users.domain#genderheretics.xyz from state outdated
This feels less than ideal: if the admin of that instance trawls through their webserver logs (they do), they're going to find periodic proof that my server exists.
I wonder if there's an argument for not attempting a state transition on users.Domain objects that have blocked = true, or having a dedicated blocked state so that our instance doesn't try to talk to that server.
What does everyone think?
Ah yes, you're totally right, we should not be doing outgoing requests to them at all - I must have overlooked the "is the remote server alive" check when adding the blocking code.
I can fix that and I'll look into it as soon as I can, but we also have the option of entirely blocking even outbound calls to anything under the domain and making it an error - maybe that would be good as a backup. I can't think of anything you'd want to do with a blocked domain that would be stopped by that.
About the blocklist, I was following the discussion this weekend and thought the same. I'll prepare a PR adding the import feature 🙂
Yeah, especially as it seems like there's an effort to have a common block list format, which I'd like to support.
Agree that if I've defederated example.com, this should extend to sub.example.com and sub.sub.example.com and so on automatically, to prevent playing whack-a-mole with bad actors spinning up subdomains, and to prevent fork-bomb DoS attacks like we saw *.misskey-forkbomb.cf do in 2022. This is also how Mastodon does defederation so it should satisfy the principle of least surprise.
I've fixed the immediate bug here which was poking blocked servers periodically as part of the "are they alive" check - I'll go see if I can make blocking function for subdomains too. That's going to be a little harder to do efficiently as "query for right substring" is not something we have an index for, but I suspect I know how to do it.
Alright, recursive blocking of subdomains is also in (for reference, any blocked domain that tries to send Takahē any content will be told it was successful, but it's just thrown away instead).