Forum:Aktuelle Welle von Bot-Anmeldungen

Forum > Aktuelle Welle von Bot-Anmeldungen

Keine Anmeldungen übers Pfingstwochenende

Damit wir hier nicht Bereitschaftsdienst über die Feiertage halten müssen, habe ich die Registrierungsfunktion vorübergehend deaktiviert. --Wüstenspitz (Diskussion) 17:39, 22. Mai 2026 (NNZ)

Es reicht!

Nachdem das geänderte Captcha nichts bewirkt hat, bin ich für die Installation von Extension:ConfirmAccount (Archive-Version aus 2013). Das gibt es auch schon für unsere bärtige Version von MediaWiki. Dann gibts nur noch neue Accounts, die von einem unserer Admins bestätigt werden. Eure Meinung?

BTW: Ich hatte das "Glück", auf dem Server eingeloggt zu sein, als er gerade in Guru-Laune kam. Daher konnte ich für einen Moment schauen, was da passiert: mysqld belegt einen Großteil der CPU, macht eine Menge Prozesse auf und reißt dabei das Limit von ulimit -u (welches im übrigen absurd hoch eingestellt ist). Die Varnish-XID bringt nicht so viel, da finde ich im Log nur meine eigene Browsersession. Weil die bash deshalb keine neuen Prozesse mehr aufmachen konnte, war es nicht möglich in die mysql-Konsole zu schauen was da gerade genau passiert. Der mysqld ist in dem Moment mit Dingen beschäftigt wie "Copying to tmp table on disk", "Copying to tmp table" und "converting HEAP to MyISAM". Ausgehend von Mediawiki auf Localhost für Remote Connections aus dem Tor-Netz.

das absurde Limit also limitieren? Ist das mal eben machbar? Wird die Tor-Adressen-Liste für jeden Tor-Block einmal temporär in die Datenbank geladen? ConfirmAccount: Großartige Idee. Saharasani (Diskussion) 08:45, 23. Mai 2026 (NNZ)

Mir fehlen Infos um überhaupt einschätzen zu können, welche Limits auf dem Server Sinn machen. Unser Leitkamel meldet sich nicht, habe ich schon vor Tagen versucht. Aber ja, die Limits ändern ist möglich. Die Tor-Liste umfasst aktuell etwas über 10.000 Einträge. Das über Mediawiki zu blocken ist wohl nicht der beste Weg. Auch Apache scheint damit nicht glücklich zu sein, so eine lange Deny-Liste ignoriert er. Im Augenblick denke ich mehr an iptables und/oder fail2ban. Ich möchte aber nicht solche Experimente mit dem Server machen. Falls ich einen kleinen Fehler mache, schieße ich mich selbst raus. --Wüstenspitz (Diskussion) 10:30, 23. Mai 2026 (NNZ)

@Wüstenspitz, vielen Dank für deine E-Mail. Ich würde jetzt gern den neuen Server einmal plattmachen und Debian 13 drauf installieren. Was muss ich vorher backupen? Sicher alles in /var/www, aber was ist z.B. mit der Datenbank? Brauchen wir die noch, oder sind das eh alles Test-Daten? -- Sloyment (Diskussion) 04:26, 24. Mai 2026 (NNZ)

@Sloyment: Hallo! Das ist nicht so einfach. Soweit ich das überblicken kann, gibt es keine schnelle Möglichkeit, von der alten direkt auf die neueste Version von Mediawiki zu kommen. Man muss Zwischenschritte einlegen und das zieht sich wegen Abhängigkeiten von Mediawiki uber PHP und Apache bis zum Linux Kernel. Ich würde den neuen Server so lassen wie er ist, da hatten wir schon ein paar Anpassungen an der damals aktuellen Version von Mediawiki gemacht. Dann auf beiden Servern ein DB-Backup machen, auf dem neuen Server die DB mit dem Backup vom alten Server überspielen und dann die Struktur wieder upgraden. Dann Mediawiki Stück für Stück auf die neueste Version bringen, wieder ein DB-Backup + /var/www ziehen, den Server plattmachen, neues Linux drauf, Webservergedöns in der neuesten Version, dann Mediawiki und DB zurückspielen. Es ist ein großer Aufwand mittlerweile. Und währenddessen muss die Kamelo hier readonly werden, sonst haben wir nie den neuesten DB-Stand drüben. Ich kann das alles aber nicht machen, mir fehlt die Zeit. --Wüstenspitz (Diskussion) 06:00, 24. Mai 2026 (NNZ)

Ältere Diskussion

Hat jemand eine Idee, wie kamel der aktuellen Welle von Bot-Account-Erstellungen Herr werden könnte? Momentan sperre ich einfach alles, was nach einem typischen Bot-Accountnamen klingt. Auf die Gefahr hin dass ich jemanden falsch-positiv rauskicke. Keine Ahnung ob es hier mit Filtern möglich wäre, Anmeldeversuche per GeoIP zu lokalisieren und alles was aus Drübenien kommt, zu blocken?

Im FreeMusicWiki unterstelle ich Neu-Accounts erstmal gute Absicht. Wenn jemand aber rumspammt, wird er natürlich gesperrt. Nach einer Weile fasse ich die reinen Spam-Accounts Zero-Edit-Accounts mittels der Extension UserMerge zu einem einzelnen Müll-Account namens ████████ zusammen. Das hält die User-Liste übersichtlich. Die Wellen, in denen lauter neue Accounts erstellt werden, dauern erfahrungsgemäß nur ein paar Tage. -- Sloyment (Diskussion) 17:47, 9. Mai 2026 (NNZ)

Auch eine Möglichkeit. Wobei wir wahrscheinlich einmal mehr über die Steinzeit-Version von MediaWiki stolpern könnten. Ich frage mich, für was diese Schläfer-Accounts eigentlich angelegt werden. Sie sind einfach nur da und tun nichts. Meiner Erfahrung nach geschehen derlei Dinge niemals ohne Grund im Internet, man erkennt ihn nur möglicherweise nicht. --Wüstenspitz (Diskussion) 19:56, 9. Mai 2026 (NNZ)

Manchmal fangen diese Accounts nach Monaten plötzlich an, gemeinsam zu spammen. -- Sloyment (Diskussion) 22:03, 9. Mai 2026 (NNZ)

Richtigen Spam haben wir hier gemessen an der Anzahl der Botaccounts eigentlich überraschend wenig. Vielleicht tun sie ja auch andere Dinge, nutzen irgendwelche Bugs aus für die es einen Account braucht, aber keine Spuren unter Letzte Änderungen hinterlassen? Wenn ich in unsere Accountliste schaue, dann sind da bergeweise teils uralte 0-Edit-Accounts. Dazu müsste man aber aufwendig die Accesslogs durchwühlen, so der alte Server überhaupt welche schreibt. Dazu fehlt mir aber neben der Zeit auch inzwischen die notwendige Zugangsberechtigung. Solange es nicht mehr als eine Handvoll pro Tag sind, macht Sperren mehr Sinn. --Wüstenspitz (Diskussion) 07:29, 10. Mai 2026 (NNZ)

UserMerge für die Kamelo! Kamelurmel (Diskussion) 13:20, 10. Mai 2026 (NNZ)

P.S. HTTPS bitte erstmal für die FreeMusicWiki, da ist das bestimmt einfacher, aber auch norwendig, um die Wahrnehmbarkeit der freien Musikwerke von Null auf Hundert zu bringen.

So sehr ich Wünsche nach neuen Features auch verstehen kann, es macht keinen Sinn. Wir fahren hier mit einer uralten Mediawiki-Version und noch dazu mit einer Alpha und keinem offiziellen Release. Obendrein auch noch proprietär gepatched und diese Änderungen haben Leute gemacht, die nicht mehr hier aktiv sind bzw. schon gar nicht mehr leben. Ich sags ja nicht gern, aber ohne Hilfe von einem oder mehreren Mediawiki-Experten werden wir über die ca. 80%, die wir beim Upgrade-Testlauf erreicht hatten, nicht hinaus kommen. Ohne Upgrade von Hard- und Software fahren wir hier auf Verschleiß, wie man z.B. an den immer wiederkehrenden Varnish-Cache-Gurus sieht. *Schnüff* --Wüstenspitz (Diskussion) 08:04, 11. Mai 2026 (NNZ)

Ich denke, es wäre möglich einen Bot zu schreiben, der sich sämtliche 0-Edit-Accounts zusammensucht und sperrt. Ggf. nur solche, die älter sind als irgendein Stichtag. Ein Nachteil wäre, dass so eine Aktion ein höllisch langes LÄ produzieren würde. Der Vorteil wäre, dass dafür keine Extension in unserem Steinzeit-MediaWiki installiert werden bräuchte. Ich bezweifle nur, dass unser multimorbider Server einer solchen Aktion gewachsen wäre. --Wüstenspitz (Diskussion) 22:38, 11. Mai 2026 (NNZ)

Ich bin heute nach langer Zeit mal wieder per SSH auf den Server gekommen, nachdem er mich zuletzt nicht reinlassen wollte. Habe mir mal die Serverlogs angeschaut. Da läuft aktuell ein wilder Scan aus einem Botnetz auf alle möglichen Resourcen, existierende wie nicht existierende. Pickt man sich mal eine bestimmte Resource heraus, z.B. /var/www/kamelopedia/aizh dann findet man Calls von IP-Adressen aus Vietnam, Brasilien, Frankreich usw. Also eindeutig ein Botnetz. Für eine DoS-Attacke ist es noch etwas wenig aber ich könnte mir vorstellen, wenn die Bots richtig loslegen, legt der Server den Kopf auf die Seite und das sind dann die Varnish Cache Gurus. --Wüstenspitz (Diskussion) 22:28, 13. Mai 2026 (NNZ)

Mir ist aufgefallen, dass die Sicherheitsabfrage auf der Neues-Kamel-registrieren-Seite nur drei mögliche Frage-Antwort-Kombis kennt. Das ist natürlich für Bots eine lächerliche Hürde. Ich habe mal ein paar neue Kombinationen einprogrammiert und die alten Fragen auskommentiert. --Wüstenspitz (Diskussion) 23:18, 13. Mai 2026 (NNZ)

Ich habe noch mal ein bisschen daran gearbeitet. Wie findet ihr das neue Unicode-Symbol-Zähl-und-Kopfrechnen-Captcha? --Wüstenspitz (Diskussion) 11:44, 14. Mai 2026 (NNZ)

Es ist echt frustrierend. Selbst ein vollkommen proprietäres, handgeklöppeltes Captcha wird innerhalb weniger Stunden geknackt. --Wüstenspitz (Diskussion) 21:58, 14. Mai 2026 (NNZ)

Ich habe jetzt noch mal die Logs bzgl. der Account-Registrierungs-Bots untersucht. Mir ist z.B. aufgefallen, dass permanent GET-Requests auf die Spezial:Anmelden-Seite laufen. Solange die alten drei Fragen drin waren, gab es ungefähr ein bis zwei GET-Requests pro Minute. POST-Requests gab es etwa 2 pro Stunde, wobei die Erfolgsrate etwa 0,3 pro Stunde betragen hat.

Nachdem ich die neuen Fragen eingebaut hatte (gestern gegen 22 Uhr) und das neue Unicode-Captcha (heute früh gegen 11 Uhr), hat sich das Muster der Bot-Aktivität sofort verändert. Ab dann gab es 1 bis 2 GET-Requests pro Sekunde auf Spezial:Anmelden und nur noch alle 4 Stunden einen versuchten POST-Request, wovon einer erfolgreich war.

Weiters habe ich mir angeschaut, von wo die Scans kommen. Es ist interessanterweise das Netz vom Fratzenbuch.

Quasi aus Notwehr habe ich mich dann dafür entschieden, für den Bösling die Kosten zu erhöhen. Die Seite Spezial-Anmelden hat jetzt einen 10-Sekunden-Sleep. Also nicht wundern dass die eine Weile braucht bis sie die Registrierungsseite anzeigt. Dadurch hat der Bot es jetzt nicht mehr so leicht, die Sicherheitsabfragen zu analysieren. Dachte ich zumindest. Der Bot hat auch darauf reagiert und operiert nun in einer Art Multithreading und sendet seine Anfragen mit einem verwürfelten IPv6-Prefix.

Jeder GET-Request auf Spezial:Anmelden macht auch eine neue Session auf. Das ist ziemlich viel wenn man bedenkt dass das pro Tag etwa 10.000 Sessions sind, die der Server alle handlen muss (gerechnet mit 1,2 GET-Requests pro Sekunde). Eigentlich bewundernswert, dass er das noch gewuppt bekommt in seinem Alter.

Was würdet ihr davon halten, wenn wir die E-Mail-Adresse zum Pflichtfeld machen würden und man nur noch mit verifizierter Mailadresse editieren dürfte? Ich kenne die alten Diskussionen zu dem Thema, nur wenn sich das so fortsetzt mit dem Spam, dann hätten sich die Rahmenbedingungen geändert.

Ich bin jetzt müde, hab mir den ganzen freien Tag mit diesem Mist um die Ohren geschlagen.

--Wüstenspitz (Diskussion) 00:24, 15. Mai 2026 (NNZ)

Inzwischen habe ich die eine oder andere Sicherheitslücke auf dem Server aufgestöbert und behoben. Dadurch greifen jetzt ein paar Sicherheitsmechanismen wieder, die vorher sozusagen "sabotiert" waren. Nun konnte ich den ganz großen Bot-Traffic der aus immer der selben Quelle kam, erstmal rausfiltern und sehe nun wieder etwas Licht im Protokoll. Es sieht fast so aus, als wäre das neue Captcha gar nicht geknackt. Jetzt wo manuelle Tätigkeiten nicht mehr in den Bot-induzierten Logs untergehen, sieht man, dass die Spam-Accounts von Hand angelegt werden. Womöglich Clickworker oder ähnliches. Gegen die kann ich wenig tun außer immer wieder sperren. Ein gutes hat das Ganze aber: Jetzt wo der Webserver sich wieder besser gegen den Bot-Traffic wehren kann, reagiert er deutlich flotter. Details werde ich hier nicht verraten, ich habs Sloyment aber inzwischen mitgeteilt. --Wüstenspitz (Diskussion) 16:19, 15. Mai 2026 (NNZ)

Wenn die neuen Captcha-Fragen noch nicht geknackt wurden, ist das vielleicht (zumindest noch) nicht wichtig, aber ich habe vorhin das hier gefunden: Link. Falls die neuen Fragen nicht eh schon dynamisch generiert werden, könnte man dem Bot-Betreiber die Arbeit damit noch weiter erschweren. Alpenalpaka (Diskussion) 17:28, 15. Mai 2026 (NNZ)

Etwas ganz ähnliches habe ich ja gemacht. Nur werden nicht die Fragen an sich dynamisch generiert sondern die angebotenen Unicode-Tierchen und die daraus sich ergebenden richtigen Antworten. Gegen die Clickworker kommt man damit allerdings nicht an, die machen einfach immer weiter bis sie irgendwann vllt. merken dass das vergeblich ist weil wir die paar Accounts die "durchrutschen" alle wieder sperren. Aktuell gehen drei von vier manuellen Registrierungsversuchen schief. Also schon mal ganz gut. Nur frage ich mich auf der anderen Seite, ob diese Art Captcha nicht vllt. schon zu kompliziert ist für evtl. erwünschte Neukamele. Allerdings sind die, wenn man mal auf verifizierte Email-Adressen in der Datenbank schaut, in den letzten Jahren extrem selten geworden. Bis 2022 waren es um die 20 bis 30 pro Jahr, danach kann man die hintere Null streichen. Vermutlich hängt das mit dem Delisting von Non-HTTPS-Seiten in den Sumas zusammen. --Wüstenspitz (Diskussion) 17:52, 15. Mai 2026 (NNZ)

Ich muss mich auch mal mit fail2ban beschäftigen. Installiert ist es auf dem Server, es wird nur nicht genutzt. In der Theorie könnte man damit viele der Bot-Scans blocken. --Wüstenspitz (Diskussion) 21:47, 15. Mai 2026 (NNZ)

Zur Frage, ob die Captchas zu kompliziert sind: Wird eigentlich bei allen Fragen zwischen Trampeltier und Dromedar unterschieden? Ist also zum Beispiel die Antwort auf "Wie viele Tiere in dieser Herde sind keine Trampeltiere? (Eins, Zwei, Drei...) 🐪 🐚 🐋 🐙 🐫 🐪 🐫 🐪 🐫 🐫" Drei oder Sechs? -- Alpenalpaka (Diskussion) 15:10, 19. Mai 2026 (NNZ)

Nur da wo es mir von der Frage her sinnvoll erschien. Der Hinweis ist richtig, da müsste ich noch mal nachschärfen. Wobei das Captcha ja ganz offensichtlich seine beabsichtigte Wirkung verfehlt hat. Die "bösen" Captchas von Google oder Cloudflare mag ich nicht einbinden und außerdem bezweifle ich, dass die gegen die Clickworker mehr Effekt hätten. Im Moment bin ich eher geneigt, die Registrierfunktion für eine Weile zu deaktivieren bis der Spuk hier vorbei ist. Für bessere Vorschläge wäre ich dankbar!

BTW: Heute war der Server mal wieder in Guru-Stimmung und während er das war, hat er mich auch nicht per SSH rein gelassen (kex_exchange_identification: read: Connection reset by peer). Also was auch immer ihn da plagt, ich konnte es nicht live untersuchen.

--Wüstenspitz (Diskussion) 17:01, 19. Mai 2026 (NNZ)