ClassicPress im Fediverse
30. März 2023 um 15:59 Uhr von Atari-Frosch
Es ist nur logisch, ClassicPress (wie auch WordPress) als dezentrale Blogging-Software mit dem dezentralen Fediverse zu verbinden. Also habe ich vor einiger Zeit das Plugin ActivityPub installiert. Nur: Mein Blog konnte und kann im Fediverse überwiegend nicht gefunden werden. Mastodon-Instanzen sehen es nicht. Hubzilla-Instanzen können es sehen, wie mir schon bestätigt wurde, aber das allein genügt ja nicht.
An dem Plugin gibt es zunächst etwas zu kritisieren. Vor vielen Jahren bereits hat sich bei WordPress die Erkenntnis durchgesetzt, daß es eine gute Idee sei, den Login-Namen und den Display-Namen der Blog-Autorenschaft zu trennen, weil damit die erste Hälfte der Login-Daten bereits offengelegt ist. ActivityPub publiziert die Beiträge nun unter @loginname@blog.name, und reißt damit diese Lücke wieder auf. Nun können Bots wieder versuchen, das Paßwort zum bekanntgegebenen Login-Namen zu erraten. Es wäre also angebracht, den Nutzenden die Möglichkeit zu geben, einen anderen als den Login-Namen anzugeben – oder einfach den Display-Namen (oder einen Teil davon, wenn zum Beispiel ein Leerzeichen enthalten ist) zu verwenden.
Ich verwende zwar WPS Hide Login und verstecke damit den Login, trotzdem habe ich zusätzlich direkt mal noch 2FA eingerichtet, damit da keine unerwünschten Dinge passieren.
Aber das ist leider nicht mein einziges Problem bei der Integration von ClassicPress ins Fediverse.
Zunächst war mir bei der Durchsicht der Meldungen von fail2ban aufgefallen, daß Mastodon-Instanzen immer wieder geblockt wurden. Das lag an einem meiner selbst erstellten Filter: Ich filtere unter anderem auf den String „cacti“. Der Client-String von Mastodon-Instanzen kann aber so aussehen:
173.255.242.40 - - [19/Mar/2023:16:17:52 +0100] "GET / HTTP/1.1" 499 0 "-" "http.rb/5.1.1 (Mastodon/4.1.0+bloomingcacti-patch2; +https://m1.thosemartins.net/)"
Mein Filter meinte eigentlich den Request, nicht den Client. Nun denn. Also habe ich erstmal den String „(Mastodon“ beim Client als Ausnahme-Regelung hinzugefügt. Das scheint alleine aber noch nichts zu helfen. Denn auch Wordfence Security ist mit den Zugriffen der Mastodon-Instanzen nicht einverstanden, und blockt sie weiterhin. Wordfence behauptet, diese Instanzen würden nach nicht vorhandenen Dateien crawlen:
Exceeded the maximum number of page not found errors per minute for a crawler.
Also habe ich mir das mal etwas genauer angesehen.
Ich hatte die Quote für „number of page not found errors per minute“ auf 4 eingestellt gehabt. In den Logfiles fand ich zunächst bei einer schnellen Durchsicht keine korrespondierenden Einträge. Zwar habe ich zwischendurch viele Zugriffe von Mastodon-Instanzen aus aller Welt binnen weniger Sekunden (was BTW ziemlich beeindruckend aussieht), aber die schicken größtenteils alle nur ein GET / rein – und geloggt wird ein Status 499. Das heißt eigentlich, daß der Client die Verbindung geschlossen hat, bevor der Request vollständig beantwortet werden konnte. Sinn ergibt das für mich nicht. Es sind nun nicht so viele Zugriffe, daß der nginx ins Schleudern kommen könnte. Eventuell ist der Crawler von Mastodon da ein wenig zu ungeduldig?
Allerdings: Diese Zugriffe lösen nicht die Reaktion von Wordfence aus. Das sind nämlich andere Instanzen. Also habe ich mir mal eine dieser Wordfence-Meldungen rausgepickt und gezielt die dazugehörigen Logfile-Einträge gesucht. Wordfence meldete zum Beispiel:
Date: Fri, 3 Mar 2023 02:32:34 +0000
[…]
Wordfence has blocked IP address 208.87.131.176.
The reason is: "Exceeded the maximum number of page not found errors per minute for a crawler.".
The duration of the block is 10 days.
User IP: 208.87.131.176
User hostname: fediverse.one
Die dazugehörigen Logfile-Einträge sehen so aus:
208.87.131.176 - - [03/Mar/2023:03:32:28 +0100] "GET /.well-known/x-nodeinfo2 HTTP/1.1" 404 153 "-" "Friendica 'Giant Rhubarb' 2023.03-dev-1516; https://fediverse.one"
208.87.131.176 - - [03/Mar/2023:03:32:29 +0100] "GET /.well-known/nodeinfo HTTP/1.1" 404 153 "-" "Friendica 'Giant Rhubarb' 2023.03-dev-1516; https://fediverse.one"
208.87.131.176 - - [03/Mar/2023:03:32:29 +0100] "GET / HTTP/1.1" 200 1585 "-" "Friendica 'Giant Rhubarb' 2023.03-dev-1516; https://fediverse.one"
208.87.131.176 - - [03/Mar/2023:03:32:30 +0100] "GET / HTTP/1.1" 200 53471 "-" "Friendica 'Giant Rhubarb' 2023.03-dev-1516; https://fediverse.one"
208.87.131.176 - - [03/Mar/2023:03:32:30 +0100] "GET /api/v1/instance HTTP/1.1" 404 21004 "-" "Friendica 'Giant Rhubarb' 2023.03-dev-1516; https://fediverse.one"
208.87.131.176 - - [03/Mar/2023:03:32:30 +0100] "GET /.well-known/host-meta HTTP/1.1" 404 153 "-" "Friendica 'Giant Rhubarb' 2023.03-dev-1516; https://fediverse.one"
208.87.131.176 - - [03/Mar/2023:03:32:31 +0100] "GET /status.php HTTP/1.1" 404 27 "-" "Friendica 'Giant Rhubarb' 2023.03-dev-1516; https://fediverse.one"
208.87.131.176 - - [03/Mar/2023:03:32:31 +0100] "GET /statistics.json HTTP/1.1" 404 21004 "-" "Friendica 'Giant Rhubarb' 2023.03-dev-1516; https://fediverse.one"
208.87.131.176 - - [03/Mar/2023:03:32:31 +0100] "GET /api/v1/directory?limit=1 HTTP/1.1" 404 21004 "-" "Friendica 'Giant Rhubarb' 2023.03-dev-1516; https://fediverse.one"
208.87.131.176 - - [03/Mar/2023:03:32:32 +0100] "GET /poco HTTP/1.1" 404 21004 "-" "Friendica 'Giant Rhubarb' 2023.03-dev-1516; https://fediverse.one"
217.113.43.215 - - [03/Mar/2023:03:32:33 +0100] "GET /feed/ HTTP/1.1" 200 86566 "https://www.google.com" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36"
208.87.131.176 - - [03/Mar/2023:03:32:34 +0100] "GET /api/v1/instance/activity HTTP/1.1" 503 19019 "-" "Friendica 'Giant Rhubarb' 2023.03-dev-1516; https://fediverse.one"
208.87.131.176 - - [03/Mar/2023:03:32:34 +0100] "GET / HTTP/1.1" 503 18105 "-" "Friendica 'Giant Rhubarb' 2023.03-dev-1516; https://fediverse.one"
208.87.131.176 - - [03/Mar/2023:03:32:35 +0100] "GET /.well-known/webfinger?resource=acct%3A%40blog.atari-frosch.de HTTP/1.1" 404 153 "-" "Friendica 'Giant Rhubarb' 2023.03-dev-1516; https://fediverse.one"
208.87.131.176 - - [03/Mar/2023:03:32:35 +0100] "GET /.well-known/webfinger?resource=https%3A%2F%2Fblog.atari-frosch.de HTTP/1.1" 404 153 "-" "Friendica 'Giant Rhubarb' 2023.03-dev-1516; https://fediverse.one"
208.87.131.176 - - [03/Mar/2023:03:32:35 +0100] "GET /.well-known/host-meta HTTP/1.1" 404 153 "-" "Friendica 'Giant Rhubarb' 2023.03-dev-1516; https://fediverse.one"
208.87.131.176 - - [03/Mar/2023:03:32:36 +0100] "GET /.well-known/host-meta HTTP/1.1" 301 169 "-" "Friendica 'Giant Rhubarb' 2023.03-dev-1516; https://fediverse.one"
208.87.131.176 - - [03/Mar/2023:03:32:36 +0100] "GET /.well-known/host-meta HTTP/1.1" 404 153 "-" "Friendica 'Giant Rhubarb' 2023.03-dev-1516; https://fediverse.one"
208.87.131.176 - - [03/Mar/2023:03:32:36 +0100] "GET / HTTP/1.1" 503 18105 "-" "Friendica 'Giant Rhubarb' 2023.03-dev-1516; https://fediverse.one"
Okay, was haben wir denn da? Die Zugriffe auf Dateien unter /.well-known bekommen einen … 404. Das heißt, da wird auf Dateien zugegriffen, die es nicht gibt, und Wordfence schlägt zu.
Mein erster Lösungs-Ansatz in der Konfiguration von Wordfence:
- „If a crawler's pages not found (404s) exceed“ steht jetzt auf 10. Das ist immer noch ziemlich strikt, und Wordfence meint, es könne false positives geben. Bevor ich mein Blog ins Fediverse gehängt habe, gab es allerdings keine.
- Bei „Allowlisted 404 URLs“ habe ich zusätzlich das Muster /.well-known/* eingetragen.
Allerdings werden da noch mehr Dateien abgefragt, die nicht vorhanden sind, was immer das soll. Möglicherweise sind diese Dateien in einer Installation von Mastodon, Friendica, Hubzilla und wie sie alle heißen vorhanden, aber eben nicht in einer Blog-Software. Das betrifft hier die Dateien
- /status.php
- /statistics.json
- /api/v1/directory?limit=1
- /poco und
- /api/v1/instance/activity.
Das sind fünf Dateien. Mit dem Rate-Limit für 404er auf 10 und der Ausnahme auf .well-known sollte das jetzt eigentlich funktionieren. Das Ziel ist, das Blog im Fediverse sichtbar zu machen, ohne die Sicherheit einzuschränken oder die Systemlast hochzutreiben.
Schauen wir mal.