utzer@f.utzer.de

@randompenguin it is kind of reproducible, maybe this grid gallery thing itself is the problem.

Again starts on the top right, then one to the left, then down. Counter clockwise.
RE: f.utzer.de/objects/f5430ab4-10…

@randompenguin reply.

1

2

3

@randompenguin well then.

The second screenshot in my post was how the photos are sorted on Pleroma (another AP social network), there the order was as uploaded.

So this means (only) Friendica shuffles the photos. Or at least Pleroma does not.

I am used to it, it happens since some time.

Can you reproduce it when you create a post?

Maybe take a photo with 1 thing in it, one with 2 things in it and a third one with 3 things in it.

@randompenguin here you have the original photos with the original names. If it helps somehow.

files.utzer.de/download/9b5d0c…

@randompenguin yes, randomized but only when opened locally. Did you have a look at my post on your end, can you share a screenshot how the photos are arranged on your end?

So my hypothesis is, that the random order is only stored locally after transmission to remote or even randomized only when looked at locally.

@randompenguin

Sure.

Link to post
f.utzer.de/display/f5430ab4-20…

First screenshot local on Friendica with random order

Second screenshot remote on Pleroma with correct order (correct as uploaded)

@tealk I think now it is nice, your input helped.

git.friendi.ca/assets/contact.…

Linked to on git.friendi.ca

@tom_s Danke für die Hinweise. Ich habe das jetzt in einer kurzen Stichprobe getestet:

• UA-Filter vorübergehend deaktiviert
• Anubis auf DEBUG gestellt
• separates TLS-Light-Logging in Nginx aktiviert

Ergebnis für den angeblichen Android-6-/Chrome-65-Client:

Requests:              13
Unterschiedliche IPs:  13
Challenges ausgestellt: 11
Challenges gelöst:       0

Die 13 Verbindungen ergaben zunächst zwölf verschiedene TLS-Profile. Die Unterschiede bestanden allerdings ausschließlich aus zufälligen GREASE-Werten. Nach deren Normalisierung hatten alle Verbindungen exakt dasselbe TLS-Profil.

Der TLS-Fingerprint allein eignet sich trotzdem nicht für eine sichere Sperre: Dasselbe normalisierte Profil wurde in der Stichprobe auch von aktuellen Chrome-142-, Chrome-148- und Chrome-149-Clients verwendet.

Die Kombination ist jedoch eindeutig verdächtig: Der User-Agent behauptet Android 6 / Chrome 65, verwendet aber einen modernen TLS-1.3-/HTTP/2-Stack und über alle IP-Adressen hinweg dasselbe vollständige HTTP-Headerprofil.

Auch der User-Agent Mozilla/5.0 (compatible; crawler) löste keine seiner zwölf Challenges.

Der aktuelle Flood verbraucht in dieser Stichprobe also hauptsächlich Anubis-Ressourcen und gelangt nicht bis zu Forgejo.

UA-Filter und normales Anubis-Logging sind inzwischen wieder aktiv.

Further update: I have replaced the temporary path-specific rate limit with an exact User-Agent filter.

The ten evenly rotated browser identities responsible for 96.79% of the Anubis challenges, plus the explicit `Mozilla/5.0 (compatible; crawler)` identity, are now rejected by Nginx before reaching Anubis or Forgejo.

The pull-request and issue pages are available normally again, regular web and Git access remain unaffected, and backend load is close to zero.

The crawler has since introduced a new identity:
Android 6 / Nexus 5 / Chrome 65

This identity produced 527 requests from 526 different IPv4 addresses within one hour, confirming the rotating proxy-network pattern. However, the overall volume reaching Anubis has dropped from roughly 35,800 challenges per hour at the peak to about 1,000 per hour, so the exact filtering is currently working very well.

This remains a temporary mitigation because User-Agent strings can be changed at any time.