Interstellar setting off Fail2Ban on kbin.melroy.org

[Endymion-M]

Describe the bug

Hi, I had a problem with logging into Mbin, and thankfully was able to get to another network and communicate with Melroy directly. I'm going to assume that the Interstellar and core Mbin teams are in regular contact, so hopefully you can put your technical minds together on this.

Here are a few reports that he showed me:
GET
404
/api/users/name/baris
142 B
Dart/3.9 (dart:io)
28 ms
GET
404
/api/users/name/freamon
142 B
Dart/3.9 (dart:io)
26 ms
GET
404
/api/magazine/name/1@lemmy.world
142 B
Dart/3.9 (dart:io)
26 ms
GET
404
/api/magazine/name/1@lemmy.world
142 B
Dart/3.9 (dart:io)
27 ms
GET
404
/api/magazine/name/1@lemmy.world
142 B
Dart/3.9 (dart:io)
24 ms

This activity ends up making his abuse tracker light up, and bans the IP. That can really hurt the adoption of fediverse communities.

Steps to Reproduce

Use Interstellar on Android and connect to kbin.melroy.org.

Version

0.10.1 (F-Droid)

What client platform(s) are you seeing the problem on?

Android

What server platform(s) are you seeing the problem on?

Mbin

Additional context

No response

[jwr1]

Yes, we are in regular contact, I am in fact also on the Mbin team :). My first guess is that it has to do with user and magazine mentions, as those do generate a decent number of network requests. Perhaps @melroy89 would like to add a quick comment here?

[melroy89]

I have indeed very strict 4xx checks in my Fail2ban. For some reason Interstellar performed multiple calls to a very weird magazine name 1@lemmy.world as well as non-existing users:

# All 200s here..
IP - - [02/Dec/2025:15:21:32 +0100]  "PUT /api/comments/10219016/favourite HTTP/1.1" 200 873 "-" "Dart/3.9 (dart:io)" "kbin.melroy.org" 0.059
IP - - [02/Dec/2025:15:21:38 +0100]  "PUT /api/comments/10218513/favourite HTTP/1.1" 200 754 "-" "Dart/3.9 (dart:io)" "kbin.melroy.org" 0.053
IP - - [02/Dec/2025:15:21:43 +0100]  "PUT /api/comments/10217699/favourite HTTP/1.1" 200 844 "-" "Dart/3.9 (dart:io)" "kbin.melroy.org" 0.051

# And then bam, 404:
IP - - [02/Dec/2025:15:21:45 +0100]  "GET /api/magazine/name/1@lemmy.world HTTP/1.1" 404 142 "-" "Dart/3.9 (dart:io)" "kbin.melroy.org" 0.024
# And then again!?
IP - - [02/Dec/2025:15:22:17 +0100]  "GET /api/magazine/name/1@lemmy.world HTTP/1.1" 404 142 "-" "Dart/3.9 (dart:io)" "kbin.melroy.org" 0.027

A little bit later, your app is executing API calls on a local user that never existed? I believe this is a bug for sure.

# first 200 calls.. all fine:
IP - - [02/Dec/2025:15:33:30 +0100]  "GET /api/users/name/@georgetakei@universeodon.com HTTP/1.1" 200 690 "-" "Dart/3.9 (dart:io)" "kbin.melroy.org" 0.203
IP - - [02/Dec/2025:15:33:31 +0100]  "GET /api/users/701702/comments?sort=newest&usePreferredLangs=true HTTP/1.1" 200 10152 "-" "Dart/3.9 (dart:io)" "kbin.melroy.org" 0.362

# And bam 404 suddenly again?
IP - - [02/Dec/2025:15:34:40 +0100]  "GET /api/users/name/freamon HTTP/1.1" 404 142 "-" "Dart/3.9 (dart:io)" "kbin.melroy.org" 0.026

# 200 OK.. first:
IP- - [02/Dec/2025:15:34:18 +0100]  "GET /api/users/name/@nuxttux@mastodon.social HTTP/1.1" 200 680 "-" "Dart/3.9 (dart:io)" "kbin.melroy.org" 0.080
IP - - [02/Dec/2025:15:34:28 +0100]  "GET /api/users/name/@Nonilex@masto.ai HTTP/1.1" 200 1003 "-" "Dart/3.9 (dart:io)" "kbin.melroy.org" 0.062

# BAM, 404 again:
IP - - [02/Dec/2025:15:34:39 +0100]  "GET /api/users/name/baris HTTP/1.1" 404 142 "-" "Dart/3.9 (dart:io)" "kbin.melroy.org" 0.028

(I removed his IP for privacy reasons)

---

Problem is; there is no baris local user and also no freamon local user. In fact, there never been such a user at all on my server. So I think maybe something goes wrong with parsing.. Well something goes wrong for sure.. Causing to looking invalid users.

Not sure what happened with the magazine either, a magazine called 1 is impossible. As far as I know, this name is too short to be even allowed. I also suspect a parsing error or again something weird for sure. I also asked Root from lemmy.world, and he confirmed that such a magazine name of 1 number could ever exists in the first place.

Too many 4xx calls are not allowed on my server, and the IP will get banned automatically via Fail2Ban for 4 months. Normally this is not a problem, since a web-server or API will not result in 404's calls too often. If it does, that is often an underlying issue or its a crawler trying to find exploits on the web server, etc. Obviously the user didn't do anything wrong, but this was due to invalid calls from Interstellar.

Ps. This was also the reason I asked for a custom user-agent string.

[jwr1]

The reasoning behind these requests is because Interstellar has no way of knowing if users mentioned via @ in a body exist or not. It seems @Endymion-M has encountered a post or comment that contains @freamon and @baris in them. Interstellar parses the body, extracts out those usernames, and makes a request to the API to fetch information on the user. BTW, all of what I said for user mentions applies to magazine mentions as well (with ! mentions).

So I believe a question we should be asking is why those @ mentions appeared in the first place, because isn't Mbin supposed to translate them automatically to valid mentions, or did the original post author not make valid mentions in the first place?

Interstellar does contain session long (lasts as long as the user has the app open and doesn't switch accounts) cache for user and magazine mentions. But I believe the one thing we don't cache is whether a user or magazine exists, so that's definitely a way we could improve.

[melroy89]

The reasoning behind these requests is because Interstellar has no way of knowing if users mentioned via @ in a body exist or not. It seems @Endymion-M has encountered a post or comment that contains @freamon and @baris in them. Interstellar parses the body, extracts out those usernames, and makes a request to the API to fetch information on the user. BTW, all of what I said for user mentions applies to magazine mentions as well (with ! mentions).

I see.. this is interesting.

Its hard to know which thread, comment or post was causing the issue. But I did more digging, and I found for example: https://kbin.melroy.org/m/nodebb-development@community.nodebb.org/p/262487/-/reply/416690

@Endymion-M comment seems to accidentally used @baris@kbin.melroy.org and @freamon@kbin.melroy.org here.

We might found a bug in Mbin maybe? @Endymion-M or could you remember this comment from 8 months ago?

Body content:

@Fitik@fedia.io Second that on Mbin.

@rimu@piefed.social @baris@kbin.melroy.org @freamon@kbin.melroy.org @julian@community.nodebb.org @kspatlas@kbin.earth @psx_crab@lemmy.zip

Rendered:

So I believe a question we should be asking is why those @ mentions appeared in the first place, because isn't Mbin supposed to translate them automatically to valid mentions, or did the original post author not make valid mentions in the first place?

Yesn't.. Maybe this is a bug above? I think we might want to create a upstream bug issue in Mbin then.

Interstellar does contain session long (lasts as long as the user has the app open and doesn't switch accounts) cache for user and magazine mentions. But I believe the one thing we don't cache is whether a user or magazine exists, so that's definitely a way we could improve.

Yea you could try to cache 404's responses on magazines and users that don't exists..?

Also we could think of better API handling here. I'm not sure yet (but maybe not returning 404s?), after all the current design causing 404's could trigger fail2ban on other instances as well I mean.

Or even a better way of communicating users & magazines via API calls, so you no longer need to guess?

[jwr1]

We might found a bug in Mbin maybe?

I think you're right, because I remember replying to that post 8 months ago, and I had a similar issue.

Yea you could try to cache 404's responses on magazines and users that don't exists..?

Yeah, that's what I was suggesting. Just additionally caching if a user/magazine exists or not, so we don't try checking again for the rest of the session.

Also we could think of better API handling here. I'm not sure yet (but maybe not returning 404s?), after all the current design causing 404's could trigger fail2ban on other instances as well I mean.

I honestly think 404 is the correct HTTP status that should be returned. We tried to see if a user existed, the server saw the user did not exist and was not found, so it returned a 404 response code. That seems correct to me. Maybe the fail2ban configuration could be adjusted somehow.

Or even a better way of communicating users & magazines via API calls, so you no longer need to guess?

I agree, it seems like there should be a better way that doesn't require as many API requests.

[melroy89]

I think you're right, because I remember replying to that post 8 months ago, and I had a similar issue.

oei!

That seems correct to me. Maybe the fail2ban configuration could be adjusted somehow.

This is actually the reason behind my request of: #323 😬

I agree, it seems like there should be a better way that doesn't require as many API requests.

Exactly.. I will think about it as well, let me know if you have any ideas how we could improve here as well.

[jwr1]

Exactly.. I will think about it as well, let me know if you have any ideas how we could improve here as well.

I had two ideas so far:

1. Include a list of magazine and user mentions/payloads in the json response of endpoints (such as get/list posts, get/list comments, etc.). This would require changing a lot of endpoints and might not scale very well. Just thought I'd throw it out there.
2. Have a separate endpoint that allows you to send a list of usernames (and magazines) which will return back a list of all the ones that were found. (I think I like this one better)

[Endymion-M]

Eight months is a long time, but looking at in my browser, I'm pretty sure that I was confirming to the NodeBB team that their microblog timestamp was somehow showing that they were posting from the future. I'm entirely in favor of time-travel if you can do it, but I don't think they intended their shared posts to work that way.