Skip to content

Threads auf Mastodon für alle blockieren?

Das Fediverse ist ein dezentrales Netzwerk, wo viele Dienste mittels des Protokolls ActivityPub miteinander kommunizieren können. Hierzu gibt es die schöne Grafik mit dem Baum des Fediverse' und seinen vielen Ästen:

The many branches of the Fediverse von Per Axbom

The many branches of the Fediverse von Per Axbom. https://axbom.com/fediverse

Ein neuer Zweig kam kürzlich hinzu: Threads. Das ist ein Ableger des Meta-Konzern, besser bekannt als Facebook. Mit einem Account bei Instagram lässt sich auch Threads nutzen. Threads setzt auf ActivityPub und kann damit prinzipiell auch mit allen anderen Diensten Daten austauschen.

Nun entstanden Diskussionen, inwieweit dies gewollt ist und ob man Threads als Betreiber:in eines Mastodon- oder anderen Fediverse-Servers sperren solle. Mit einer Sperre ist eine Kommunikation mit Threads auf dem Server nicht mehr möglich. Als Argument wird Datenschutz und der “Vernichtungswille” von Großkonzernen angeführt. Da ich unter der Adresse Freie-Re.de auch einen Mastodon-Server betreibe, habe ich mir dazu auch Gedanken gemacht.

ActivityPub funktioniert als Protokoll im wesentlichen so, dass ein Beitrag in einen Postausgangskorb gelegt wird. Andere Server kommen vorbei und holen diese Nachricht ab. Andere Nutzer:innen werfen eine Nachricht in den eigenen Posteingangskorb und ich hole diese irgendwann dort ab. Das Ganze ist unten sowie auf der Wikipedia-Seite zu ActivityPub genauer beschrieben.

Aktivitäten bei ActivityPub.
Aktivitäten bei ActivityPub. Details unter https://de.wikipedia.org/wiki/ActivityPub

Wenn ich nun Beiträge schreibe, holt Threads diese wie alle anderen aus meinem Postausgang ab. Wie alle anderen, sieht der Server die Inhalte und einige andere Eigenschaften des Beitrages. Was dort genau hinterlegt wird, hängt vom konkreten Dienst ab. Mastodon legt keine zusätzlichen personenbezogenen Daten, wie IP-Adresse oder anderes, ab. Damit kann der fremde Server auch nichts mehr sehen.

Anders sieht es natürlich für die Nutzer:innen von Threads aus. Wer sich dort einen Account anlegt und die App nutzt, gibt eine Vielzahl an Daten an den Dienst. Dazu gehören laut App-Store Kontaktdaten, Standortdaten und viel, viel mehr. Das heißt, wer Bedenken hinsichtlich des Datenschutzes hat, sollte sich gut überlegen, ob ein Account bei Threads eine gute Idee ist.

Für Nutzer:innen aus dem Fediverse sehe ich hier jedoch keine größeren Gefahren. Die Daten, die eh öffentlich sind, können auch von Threads gelesen werden. Dadurch entsteht also kein zusätzliches Risiko.

Das zweite geäußerte Bedenken ist der “Vernichtungswille”. Viele große Konzerne und große Firmen verfolgen eine Strategie, die als Embrace, Extend und Extinguish bezeichnet wird. Das heißt, anfangs wird ein freies Protokoll oder eine freie Software gelobt und gern verwendet. Irgendwann gibt es dann Erweiterungen des Protokolls oder der Software, die nur für diejenigen nutzbar sind, die Kund:innen der Firma sind. Später werden dann alle Verbindungen in die “freie Welt” gekappt und das Produkt ist nur noch für Kund:innen nutzbar. Beispiele finden sich bei Google, Facebook und anderen Konzernen.

Der Ansatz ist auch hier zu befürchten. Das heißt, am Anfang gibt es eine Verbindung in das Fediverse und alle jubeln, dass Threads sich für ein freies Protokoll entschieden hat. Ich kann mir vorstellen, dass dann vielleicht Bilder und Videos nur in schlechter Auflösung ins Fediverse gelangen. Wer das Original sehen will, braucht ein Threads-Konto. Oder man kann nur mit den Accounts bei Threads interagieren, wenn man dort ein Konto hat. Hier könnt ihr eure Fantasie benutzen, wie sich das sinnvoll einschränken lässt, um andere zu Threads zu locken. Wenn dann genügend Leute Threads nutzen, kann die Verbindung ins Fediverse gekappt werden. Nutzer:innen sind dahin abgewandert und eventuell fristet das Fediverse dann ein Nischendasein. Das ist natürlich im Moment eine Vermutung und was genau passieren wird, weißt außerhalb von Meta niemand.

Ich halte es aufgrund der Beobachtungen anderer Firmen für eine erwartbare Entwicklung und für eine, auf die sich die Betreiber:innen einstellen sollten. Doch bringt ein Block von Threads hier etwas?

Wenn sich viele und insbesondere die großen Instanzen auf einen Block einlassen, würde das sicher etwas bringen. Dann fehlen Threads die initiale Zahl an aktiven Konten und sie müssen den Dienst irgendwie anders zum Laufen bekommen. Hier gibt es für den Konzern viele Möglichkeiten und ein Block wird sie einfach bewegen, anfangs einen anderen Weg zu nutzen.

Wenn sich jedoch nur ein kleiner Teil des Fediverse' zu einem Block durchringen kann, wird Threads weiter föderieren und vielleicht obigen Weg verfolgen. Sollte der Extinguish-Teil klarer werden, ließe sich vielleicht durch die Drohung, dass geblockt wird, Druck aufbauen.

Im allgemeinen bin ich der Meinung, dass weder ein präventiver Block noch ein späterer Block langfristig in dem Sinne etwas bringt, dass man den Konzern umstimmen kann. Hier wäre es wichtig, dass sich die Gemeinschaft der Betreiber:innen frühzeitig zusammenrauft und eigene Strategien entwickelt, wie mit der potenziellen Strategie von Threads umgegangen wird. Innerhalb dieser Strategie kann dann ein Block ein Baustein sein.

Aufgrund dieser Überlegungen habe ich mich daher entschieden, mit Threads zu föderieren und diese nicht zu blockieren. Derzeit überlasse ich das den Nutzer:innen. Wenn es irgendwelche anderen Gründe für einen Block geben sollte, würde ich die Gründe prüfen und aufgrund der Bewertung einen Block vornehmen, so wie das auch bei anderen mache.

Tor entfernt 1000 Server aus dem Netz

Unter dem Titel Safeguarding the Tor network: our commitment to network health and supporting relay operators veröffentlichte das Tor-Projekt einen Blog-Artikel. Darin wurde gemeldet, dass mehrere Server aus dem Netzwerk entfernt wurden.

Verlauf der Relays über die letzten TageAuf der obigen Grafik ist die Delle deutlich zu sehen. Auch eine Suche nach Relays findet um die 1000 Tor-Server. Was ist passiert?

In den Kommentaren im Tor-Blog und auch an anderen Stellen im Internet wird auf ATOR verwiesen. Dies ist eine Cryptocoin, die darauf basiert, dass andere Tor-Server betreiben. Soweit ich das sehe, muss in der torrc der String ator mit Werten enthalten sein. ATOR scheint dann auszuwerten, wie lange die Server online und auf der Basis Geld auszuschütten. Das ist zumindest das, was ich mir aufgrund divreser Quellen zusammengereimt habe.

Das Tor-Projekt hat nun herausgefunden, dass es diese Server gibt und begonnen, die Relays aus dem Netzwerk zu verbannen. Eine Suche ergibt immer mal einzelne neue, aber weitestgehend sind die aus dem Netzwerk verschwunden.

Die Gründe hierfür sind vielfältig. Im Allgemeinen geht das Projekt davon aus, dass die Betreiber:innen die Relays nicht aus eigener intrinsicher Motivation betreiben, sondern des Geldes wegen. Dies eröffnet natürlich Raum für Angriffe und ist in der wissenschaftlichen Welt seit etwa 15 Jahren diskutiert worden. Über die letzten Jahre war nun immer wieder zu sehen, dass verschiedene Gruppen Angriffe versuchen. Daher lässt das Projekt mittlerweile auch viel mehr Vorsicht walten, was es als gute oder bösartige Relays ansieht. In dem Fall war die Wahl dann klar.

"Direkt vor unseren Augen" von Daniel Moßbrucker

Daniel Moßbrucker hat ein Buch geschrieben, was sich einem heiklen und emotional sehr aufgeladenen Thema widmet: sexualisierte Gewalt an Kindern und dessen Dokumentation. In der öffentlichen Diskussion wird oftmals der verharmlosende Begriff Kinderpornographie verwendet.

Moßbrucker versucht mit dem Buch, Fakten zu liefern. Dazu hat er in diversen Foren recherchiert. Dies ist insbesondere schwer, da schon der Versuch der Beschaffung eine Straftat ist. Moßbrucker schildert in dem Buch beeindruckend, dass er mit drastischen Mitteln versuchte, keine solchen Darstellungen angezeigt zu bekommen. So war es ihm möglich, die Foren zu betreten und anhand der Dateinamen und anderer Eigenschaften abzuschätzen, was dort passiert.

Seine Recherchen führten bereits in der Vergangenheit zu überraschenden Erkenntnissen. Denn offensichtlich bleiben die Darstellungen im Netz und niemand kümmert sich um die Entfernung der Inhalte:

Mit dem Buch geht Daniel Moßbrucker analytisch vor. Er beschreibt zunächst das Problem, erklärt, woher die Darstellungen kommen und wie diese dann in den Foren landen. Dabei geht nicht nur um reine Nackt- oder schlimmere Darstellungen, sondern um eine große Bandbreite. So wird von einem Benutzer berichtet, der tausende Bilder von Kindern in Daunenjacken teilte. Im Kontext wird dann klar, dass diese Bilder in einem sexuellen Kontext gelesen werden.

Dieser Teil des Buches macht klar, wie hier vorgegangen wird, welche Art von Darstellungen interessant sind und auch wie diese technisch gehostet werden. Das liefert dann die Grundlage für den nächsten Teil. Dort geht es um mögliche Maßnahmen. Dabei werden sowohl solche besprochen, die seitens der Politik immer wieder diskutiert werden wie auch solche, die eventuell zielführender erscheinen.

Moßbrucker beschreibt die Sachverhalte in einem nüchteren, unaufgeregtem Ton. Aufgrund seiner Erfahrungen wirkt der Text glaubwürdig und er macht sich viele Gedanken, wie sich die Lage wirklich verbessern kann.

Ich würde mir sehr wünschen, wenn das Buch gerade von Fachleuten in dem Bereich gelesen wird und sich diese mit den Erkenntnissen wirklich dem Schutz von Kindern widmen würden.

Aktualisierung von Mastodon auf Version 4.2.0

Mastodon ist ein soziales Netzwerk zum Selberbasteln. :-) So oder ähnlich lautet eine der Versprechungen des Dienstes. Wer mag, kann einen eigenen Server betreiben und sich somit dem Fediverse vernetzen. Daher betreibe ich Anfang 2023 auch einen Server. Der ist unter den Adressen

erreichbar.

Seit kurzem gibt es nun die Version 4.2.0, die recht viele Verbesserungen bietet. Also wollte ich die Software aktualisieren. Bei Mastodon erfolgen Aktualisierungen in der Regel über git. Das heißt, mittels git fetch wird das Repository aktualisiert und dann wird die “richtige” Version ausgecheckt. Eventuell sind noch Pakete zu aktualisieren und das wars im Wesentlichen.

Als ich das bei meinem Server versuchte, stellte ich fest, dass einige Programme veraltet waren. Das Image, was ich zur Installation verwendete, basiert auf Debian bullseye. Mittlerweile ist Debian bookworm aktuell. Vor dem Update von Mastodon stand also ein Update von Debian. In der Regel ist ein Update von der Vor- zur nächsten Debian-Version recht unproblematisch. So auch hier. Das Update war schnell gemacht.

Also gab ich ein git fetch && git checkout v4.2.0 ein und startete so die Aktualisierung von Mastodon. Danach mussten die Befehle

  • bundle install
  • yarn install --frozen-lockfile

durchgeführt werden. Bei letzten Kommando sagte mir mein System, dass dieser Befehl nicht verfügbar sei. Allerdings lag im Unterverzeichnis bin/ eine ausführbare Datei namens yarn. Als ich diese direkt ausführte, war die Ausgabe wieder, dass Yarn nicht verfügbar sei. Yarn wurde mittels corepack installiert. Aber corepack war auch nicht verfügbar. Damit musste ich noch einen Schritt zurückgehen: zur Installation von node.js selbst.

Hier lag dann die Lösung: Beim Update von Debian wurde auch node.js aktualisiert. In dem Update war vermutlich corepack und anderes nicht mit eingeschlossen. Ich deinstallierte also node.js, aktualisierte die sources.list-Datei und installierte node.js wieder. Damit waren corepack und yarn auch wieder verfügbar und der obige Befehl lief problemlos durch.

Die letzte Hürde bestand im Neustart der Mastodon-Dienste. Ich hatte diese mittels systemctl restart mastodon-* neu gestartet. Dies führte zu Connection refused-Meldungen. Der Streaming-Dienst unter Port 4000 war nicht erreichbar. Dies lag daran, dass der Systemd-Service mastodon-streaming erneuert wurde. Also fehlte noch ein systemctl daemon-reload gefolgt vom Neustart.

Das war dann der Punkt, an dem der Server mit Version 4.2.0 anstandslos weiterlief. :-)

Mehr Informationen zum Podcast "Your are fucked"

Beim MDR wurde vor kurzem die Sendung “You are fucked” ausgestrahlt. Über sechs Sendungen stellte Marcel Roth den Sicherheitsvorfall im Landkreis Anhalt-Bitterfeld vor.

Bei dem Sicherheitsvorfall wurden Rechner des Landkreises mit einer Schadsoftware infiziert. Nach der Infektion erkundeten die Kriminellen das Netzwerk und als sie genug Daten bzw. Informationen gesammelt hatten, verschlüsselten sie die Rechner. Dies führte dazu, dass der Landkreis nicht mehr arbeitsfähig war und den Katastrophenfall ausrief.

In den Sendungen geht es um den Vorfall an sich, es wird eine zeitliche Beschreibung der Vorfälle präsentiert, die Auswirkungen werden diskutiert und Roth versucht auch, in einer Sendung auf die Hintermänner einzugehen. Insgesamt kann ich euch die sechs Folgen nur ans Herz legen. Es ist interessant aufbereitet und man erfährt viel über die Hintergründe.

Ein Nachteil des Formats ist, dass nur Audioinhalte zur Verfügung gestellt werden. Weiterführende Informationen, wie etwa die Shownotes bei Podcasts, vermisse ich. Gerade im Teil 5 “We know who you are” werden einige Experten interviewt und auf deren Dokumente verwiesen. Da hätte ich mir die Shownotes sehr gewünscht. So habe ich einige der Links gesammelt und will sie mit euch teilen. Die Links gehen teils zu Wikipedia-Seiten (deutsch, englisch), zum Teil verlinke ich auch Fahndungsaufrufe bei FBI oder BKA oder ich verwende andere Quellen, die mir sinnvoll erscheinen.

Ransomware-Gruppen

In der Sendung ging es viel um die Gruppen, die Schadsoftware in Form von Ransomware verbreiten, und deren Hintermänner. Der Ursprung lag bei Jewgeni Bogatschow. Er entwickelte die Zeus-Schadsoftware. Deren Sinn war es anfangs, Kontodaten abzugreifen und die Bankkonten leerzuräumen. Diese war so “erfolgreich”, dass er andere benötigte, um alles abzuwickeln. Die Gruppe nannte sich dann The Business Club. Später wurde die Zeus-Software so geändert, dass die mehr militärische Geheimnisse ausleitete. Eine wichtige Person beim Business Club war Maksim Jakubez (Fahndungsseite beim FBI).

Dieser arbeitete später u.a. mit Igor Turaschew (Fahndungsseite beim BKA und beim FBI) in der Gruppe Evil Corp (Beiträge bei Brian Krebs) zusammen. Aus dieser Gruppe entstand schließlich PayOrGrief, die den Angriff gegen den Landkreis durchführten.

Gegen einige der Beteiligten gibt es Haftbefehle, Anklagen und ähnliches:

Das sind ein paar Informationen zur Einführung. Die Genese der Gruppen und deren Schadsoftware ist ein eigenes Kapitel. Hier könnt ihr gern weiter suchen. Wenn ihr interessante Links findet, freue ich mich über Kommentare. Solltet ihr einen Einblick in das Leben einiger der Akteure haben wollen, schaut bei YouTube und anderen Seiten. Da findet sich einiges.

Experten in der Sendung

Brett Callow

Zuerst kam Brett Callow zu Wort. Er arbeitet bei Emsisoft und schrieb als einer der Ersten über die Gruppe PayOrGrief:

Jon DiMaggio

Titelseite des Berichts Nationstate Ransomware
Titelseite des Berichts Nationstate Ransomware

Jon DiMaggio arbeitet bei Analyst1 und ist der Autor des Berichts “Nationstate Ransomware”. In der Sendung wird recht häufig aus diesem Bericht zitiert und die Titelseite sehr ausführlich beschrieben. Im Bericht findet ihr sehr detaillierte Angaben zu den obigen Ransomware-Gruppen, wer mit dahintersteckt, welche Software die benutzt haben usw. Der ist sehr lesenswert.

Marco di Felice

Marco di Felice ist ein Forscher im Bereich der IT-Sicherheit und hat auf DataBreaches.net einiges veröffentlicht. Unter dem Titel »Claiming to be the “new generation,” threat actors declare, “No more discounts or long negotiations”« ist das Statement der Gruppe PayOrGrief zu finden, welches auch in der Sendung verlesen wurde:

Who are we? We are the new generation… No more Discounts, time of long-term negotiations with brainwashing and tons of proofs is finished. The game is over for companies who like long negotiations, pay or grief come to you. We have all leaked files… On our website What about GDPR? Everyone just talks about GDPR. Nobody obeys this law. Plenty of hacked companies that leaked files including id, confidential information, scans etc wasn’t sanctioned for leak. We could stay inside the companies for weeks. It is enough for downloading confidential information, mails, id and other We have analyzed many ransomware groups and we are not like they. Companies are spending a lot of money hiring company-negotiatiors. Where is the result? Nothing. They spend money and time while the documents are publishing. Who won? Company-negotiatiors/Insurance companies. Now we define the rules of the game, fuck discounts, fuck negotiations, fuck time wasting… Pay or Grief. This is our statement

Weitere Informationen:

Molfar

Die Firma Molfar bzw. deren CEO Artem Starosiek machen Analysen aufgrund offener Quellen (OSINT). Dabei stießen sie auf einen Hackathon der Gruppe Wagner. Dort tauchte jemand auf, der sehr viele Ähnlichkeiten zu Turaschew hat und vermutlich mit der identisch ist.

Ich hoffe, ihr fandet die Sammlung oben hilfreich. Wenn ihr mehr Hinweise oder Links habt, kommentiert gern.

cronjob