Kurzer Hinweis an andere Mastodon-Admins: Diese Registrierungs-Spam-Welle ist noch nicht überstanden.

Bei lsbt.me kamen zunächst massenhaft API-Registrierungen mit Python/aiohttp rein. Auffällig waren Nutzernamen nach dem Muster bp plus 16 Hex-Zeichen und als Antragstext immer Automated protocol deliverability probe. Eine enge Sperre auf diesen User-Agent hat die erste Welle gestoppt.

Heute kamen trotzdem fünf neue Registrierungen mit denselben Nutzernamen und demselben Antragstext. Der Bot gab sich diesmal einfach als Chrome 126 aus. Genau deshalb taugt ein User-Agent nur als kurzfristiger Filter. Er ist ein frei wählbarer Header.

Die Requests laufen über POST /api/v1/accounts. Dieser Endpoint erlaubt Client-Apps, einen neuen lokalen Account direkt in der App anzulegen. Für OAuth-Verbindungen bestehender Accounts braucht ihn keine App. Auch #FediSuite nutzt ihn nicht. Sie registriert sich über /api/v1/apps, holt die Zustimmung über /oauth/authorize und arbeitet danach mit einem User-Token. Die normale Registrierung über die Mastodon-Webseite läuft ebenfalls getrennt über POST /auth.

Ich habe die API-Kontoerstellung auf lsbt.me deshalb komplett abgeschaltet. Webregistrierung, OAuth und bestehende Clients laufen unverändert weiter. Wer einen neuen Account möchte, registriert sich einmal ganz normal wie bisher im Web und kann danach jeden Client nutzen.

Falls ihr diesen optionalen Native-Sign-up-Weg ebenfalls nicht anbieten wollt, könnt ihr in eurem Nginx-Serverblock vor dem allgemeinen location /-Block Folgendes ergänzen. Das Beispiel setzt den in vielen Mastodon-Nginx-Configs vorhandenen @proxy voraus:

location = /api/v1/accounts {
  limit_except GET {
    deny all;
  }

  try_files $uri @proxy;
}

Damit erhält nur POST /api/v1/accounts ein 403. Der lesende GET-Endpoint bleibt erreichbar. Danach wie immer nginx -t und erst bei erfolgreichem Test reloaden.

#Mastodon #Fediverse #MastoAdmin #FediAdmin #FediMod #FediBlock #Moderation #Registration #Spam #Nginx #SelfHosting #SysAdmin #ActivityPub