Datenschutz­freundliche Konfi­guration eines Mastodon-­Servers

Das folgende Kapitel beschreibt eine Konfiguration eines Mastodon-Servers mit besonderem Schwerpunkt auf einer datenschutzfreundlichen Konfiguration.

Sehr viele Privatpersonen, Vereine oder kleine Firmen haben sich auf den Weg gemacht, um das Fediverse durch den Betrieb eines Mastodon-Servers zu unterstützen. Hierbei greifen sie im Rahmen ihrer Möglichkeiten auf bestimmte Ressourcen zurück. Das heißt, einige nutzen die Dienste eines Rechenzentrums. Die Server stehen dort zusammen mit anderen in klimatisierten Räumen, in denen Zugänge zu einzelnen Maschinen genau geregelt sind. Andere betreiben den Server in Wohn-, Vereins- oder auch in Firmenräumen. Dort sind die allgemeinen Umstände viel weniger geregelt. Die Spannweite reicht von allgemein zugänglichen Räumen bis zu einem eigenen kleinen Serverraum.

Daher versucht der Leitfaden auf verschiedene Bedürfnisse einzugehen und hierfür Rat anzubieten. Dies geht an einigen Stellen zu Lasten der Konkretheit. Es wurde jeweils versucht, die allgemeine Vorgehensweise zu beschreiben und dann möglichst konkrete Hinweise zu geben.

1. Einleitung

Für das vorliegende Kapitel wird angenommen, dass alle Software auf einem Linux-basierten System installiert und betrieben wird. Die Tests der vorgestellten Einstellungen erfolgten auf Basis der Distribution Debian GNU/Linux. Sofern konkrete Pfade zu Dateien oder Verzeichnissen genannt werden, kann es bei anderen Distributionen teils Abweichungen geben.

2. Software für den Betrieb von Mastodon

Neben dem Betriebssystem benötigt Mastodon weitere Software, um korrekt betrieben werden zu können. Dazu gehören:

• Mailserver

• Webserver (nginx)

• Datenbank-Management-System (PostgreSQL)

• weitere Software (Ruby, Node.js etc.)

2.1 Mailserver

Ein korrekt eingerichteter Mailserver mit allen Komponenten wird für dieses Kapitel vorausgesetzt. Dabei sei auf die Anleitung von Thomas Leister verwiesen. Diese beschreibt alle notwendigen Schritte für den sicheren Betrieb eines Mailservers.

2.2 Webserver

Die Entwicklerinnen von Mastodon gehen davon aus, dass nginx als Webserver verwendet wird und liefern bereits eine Konfigurationsdatei mit aus. Daher wird im folgenden nur nginx als Software für den Webserver betrachtet. Auf andere Webserver soll nicht eingegangen werden.

2.3 Datenbank-Management-System

Die Mastodon-Software nutzt ein Datenbank-Management-System (DBMS), um Daten dort abzulegen oder abzurufen. Die Entwicklerinnen haben sich für das DBMS PostgreSQL entschieden. Mögliche sinnvolle Einstellungen werden in Abschnitt „Einstellungen für den Datenbank-Server“ beschrieben.

3. Allgemeine Betrachtungen zur Sicherheit des Mastodon-Servers

Bevor genauere Einstellungen des Servers diskutiert werden, sollen zunächst einige allgemeine Überlegungen hinsichtlich der IT- bzw. Informationssicherheit des Servers angestellt werden. Sowohl die Grundsätze der DSGVO wie auch der Artikel 32 der Grundverordnung fordern angemessene Sicherheitsmaßnahmen bei der Verarbeitung personenbezogener Daten. Einige Überlegungen hinsichtlich der Informationssicherheit sollen unten diskutiert werden.

3.1 Zugang zum Server

Angriffe, die nicht in die Nähe eines IT-Systems kommen, können natürlich auch keinen Schaden anrichten. Maßnahmen zur Zugangskontrolle versuchen genau dies sicherzustellen.

Im Allgemeinen ist es empfehlenswert, den Server bei einem Provider mit entsprechenden Garantien zu betreiben. Viele professionelle Provider sind zertifiziert nach ISO/IEC 27001 bzw. ähnlichen Standards und sichern über Auftragsverarbeitungsverträge zu, wer Zugang zum Server hat und wie die Maßnahmen zur Zugangskontrolle gestaltet sind. Damit haben die Betreiberinnen des Mastodon-Servers einfache und klare Informationen, wer Zugang zu deren Servern hat.

Falls der Server außerhalb eines solchen Rechenzentrums betrieben werden sollte, ist viel mehr Augenmerk auf den Zugang zum Server zu legen. Die Spannbreite kann hier von einem Rechner liegen, der innerhalb eines Vereins, einer gemeinsamen Wohnung oder Ähnlichem betrieben wird, bis hin zu einem Server, der innerhalb eines Serverraums mit klaren Regeln steht. Dies macht es schwer, einen allgemeinen Rat zu geben.

Eine Betreiberin eines Servers sollte sich daher immer die Frage stellen, wem der Zugang zu dem Server möglich ist und wie der Zugang von unbefugten Personen verhindert werden kann. Das heißt, mögliche Maßnahmen wären

• abgeschlossene Räume (Türen, Fenster etc.),

• klare Regelungen und Kontrolle, wer Zugang zu diesen Räumen hat,

• Einsatz von Alarmanlagen.

Daneben lassen sich weitere Maßnahmen denken, die abhängig vom jeweiligen Ort sind. Hinsichtlich der Zugangskontrolle sollten sich diese eignen, Angreiferinnen von den IT-Systemen fern zu halten. Hier wie auch bei anderen Sicherheitsmaßnahmen ist eine gestaffelte Vorgehensweise sinnvoll und wichtig. Das bedeutet, selbst wenn eine Angreiferin es geschafft hat, eine Hürde zu überwinden, gibt es weitere Schutzmaßnahmen, die es zu überwinden gilt.

Beispielsweise könnte jemand auf die Idee kommen, die „sicherste Tür der Welt“ einzubauen und auf deren Sicherheitsgarantien zu vertrauen. Nichtsdestotrotz könnte ein Wachdienst helfen, Angreiferinnen von der Tür fernzuhalten. Weiterhin wäre eine Alarmanlage sinnvoll. Diese könnte für den Fall aktiv werden, dass das Sicherheitsversprechen der Tür versagt.

3.2 Zugriff auf die Daten

Wenn der Zugangsschutz als erste Hürde versagt, wäre ein Angreifer in der Lage, den Server für seine Zwecke zu verwenden bzw. zu missbrauchen. Daher sind Maßnahmen zum Zugriffschutz die nächste Hürde, die hier wirksam wird. Der Zugriff auf die Daten, insbesondere auf die personenbezogenen Daten, soll nur befugten Personen möglich sein. Damit sind Maßnahmen zu planen, die den Zugriff auf diese Daten schützen.

Einerseits kann man sich Angreifer vorstellen, die in die Räumlichkeiten einbrechen bzw. mutwillig Zugangshürden überwinden. Andererseits sind auch Personen vorstellbar, die Zugangsrechte haben und nicht auf die Daten zugreifen sollen. Typischerweise sind Reinigungs-oder Reparaturdienste in einer solchen Position. Aber auch Besucherinnen, Gäste oder Nutzerinnen, die nicht den Mastodon-Server administrieren sollen, gehören dazu.

Diese Maßnahmen umfassen sichere Authentifizierung durch den Server. Das bedeutet, der Server muss in der Lage sein zu verifizieren, dass die richtige Person versucht, auf die Daten zuzugreifen. Sinnvolle Mittel sind

• sichere Passwörter

• Mehrfaktorauthentisierung

• Verwendung von Schlüsseln oder Zertifikaten bei der Administration über SSH oder andere Remote-Administrationswerkzeuge

• Maßnahmen zum Schutz vor Schad-Software

• Systeme zur Einbruchserkennung (IDS/IPS)

• Festplattenverschlüsselung

• Einsatz eines VPNs zur Administration

Dies macht es Angreifern deutlich schwerer, Zugriff auf die Daten des Servers zu erlangen.

Neben dem Zugriff im laufenden Betrieb sollte auch beim Wechsel von Datenträgern darauf geachtet werden, dass die darauf befindlichen Daten sicher gelöscht werden.

Sichere Passwörter

Nutzerinnen werden meist mittels deren Nutzernamen sowie dem zugehörigen Passwort authentifiziert. Dies betrifft sowohl das Betriebssystem wie auch den Zugang zu Mastodon. Gegebenenfalls werden Passwörter zum Boot des Systems, zur Entschlüsselung der Festplatte sowie an weiteren Stellen benötigt.

Die Firma Hive Systems, LLC diskutiert in einem aktuellen Blogbeitrag Komplexitätsanforderungen. Sie geht davon aus, dass ein mindestens zwölfstelliges Passwort, welches Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen enthält, erst nach mehr als 200 Jahren „errechnet“ werden kann. Unter Verwendung der Hardware, die für das Training von ChatGPT verwendet wurde, sinkt der Zeitraum auf unter ein Jahr. In der Konsequenz müsste hier zu einem komplexen Passwort mit mehr als 12 Stellen geraten werden.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) geht hingegen von mindestens 8 Stellen aus, rät allerdings zu längeren, komplexen Passwörtern.

Die Komplexitätsanforderungen an Passwörter stellen regelmäßig ein Problem dar. Denn diese lassen sich dann nicht oder nur sehr schlecht merken. Andererseits fällt es Menschen auch meist schwer, ein komplexes, schwer zu erratendes Passwort zu erzeugen.¹ Daher ist es ratsam, auf Software zur Hilfe bei all diesen Aufgaben zurückzugreifen. Die so genannten Passwortmanager helfen, Passwörter sicher aufzubewahren, erzeugen selbst sichere Passwörter und leisten generell einen hohen Beitrag zur Stärkung der Informationssicherheit.

Als einfache und unter verschiedenen Betriebssystemen verfügbare Software kann hier KeePassXC genannt werden. Sollen Passwörter innerhalb von Teams geteilt und verwaltet werden, wäre Bitwarden einen Blick wert.

Mehrfaktorauthentisierung

Bei der Verwendung von Passwörtern wird auf das Wissen um ein Geheimnis (Passwort) als einzelner Faktor zurückgegriffen. Viele Systeme ermöglichen es, einen zweiten Faktor (beispielsweise den Besitz eines Gegenstands) mit zu verwenden.

So könnte mit einer solchen speziellen Hardware die Festplatte aufgeschlossen werden, bevor sich Benutzerinnen am Betriebssystem oder bei Mastodon anmelden. Ohne diesen zweiten, zusätzlichen Faktor können sich Angreiferinnen nicht am System anmelden.

Als spezielle Hardware werden sehr häufig Yubikeys, Nitrokeys oder Smartcards verschiedener Hersteller verwendet. Für das Login bei Mastodon funktionieren auch Apps wie der Aegis Authenticator, FreeOTP+ oder andere. Diese können über die App-Stores installiert werden.

3.3 Sichere Weitergabe der Daten

Im laufenden Betrieb kann es manchmal notwendig sein, Daten an einen anderen Speicher- bzw. Verarbeitungsort zu bewegen. Ein Umzug des Dienstes zu einem anderen Server oder nur der Umzug der Datenbank wären mögliche Szenarien. Erfahrungsgemäß ist dies oft fehlerträchtig.

Daher sollte zu Beginn gut überlegt werden, wo die Daten in welcher Form abgelegt und übertragen werden. Sofern diese auf öffentlich verfügbaren Servern liegen (Web-, FTP- oder ähnliche Server), müssen insbesondere personenbezogene Daten wirksam verschlüsselt sein. Weiterhin ist es empfehlenswert, wenn es für diese Daten eine automatische Löschroutine gibt. Damit liegen diese nicht länger als notwendig auf den Speicherorten.

Die Übertragung der Daten muss entweder über verschlüsselte Leitungen oder verschlüsselte Datenträger erfolgen. Damit erhalten Unbefugte keinen Zugriff auf die übertragenen Daten.

3.4 Gewährleistung der Verfügbarkeit

Benutzerinnen spüren am ehesten Schwankungen bei der Verfügbarkeit des Dienstes. Üblicherweise möchten diese gern den Dienst nutzen, um Beiträge zu lesen oder zu verfassen und gehen davon aus, dass dieser immer ansprechbar ist. Daher ist es für die Betreiberinnen wichtig, sich Gedanken darüber zu machen.

Sofern der Server in einem Rechenzentrum betrieben wird, wird der Provider viele der Maßnahmen selbst bereitstellen. Das heißt, die Server in Rechenzentren verfügen über eine unterbrechungsfreie Stromversorgung (USV). Diese springt beim Stromausfall an und sorgt für eine gewisse Zeit für den weiteren Betrieb der Server. Weiterhin werden dort Maßnahmen zum Brandschutz sowie zur Klimatisierung der Räume getroffen.

Das heißt, auch unter diesen Aspekten ist es empfehlenswert, einen Provider zum Betrieb des Servers heranzuziehen. Sollte der Server hingegen in einer privaten Umgebung betrieben werden, so müssen sich die Betreiberinnen Gedanken zu Gegenmaßnahmen bei einem Server-Ausfall selbst machen und diese implementieren.

Eine weitere mögliche Einschränkung der Verfügbarkeit kann aus dem Ausfall von Hardware-Komponenten, insbesondere der Speichermedien, resultieren. Ein Konzept zur regelmäßigen Sicherung (Backup) und Wiederherstellung (Restore) ist daher unbedingt notwendig. Manche Provider bieten hier Lösungen an.

Häufig müssen die administrierenden Personen selbst Hand anlegen. Das bedeutet, es wird BorgBackup, restic, rsync oder ähnliche Software eingesetzt. Diese kann als Cronjob oder Systemd-Timer regelmäßig automatisch die Backup-Aufgaben ausführen und ist in der Lage, auf verschiedene Speichermedien (USB-Sticks, -Festplatten, Cloud-Speicher etc.) zu schreiben. Die Software ist in der Lage, Backups über mehrere Tage oder Wochen mitzuführen, speichert in der Regel nur Änderungen und spart dadurch Speicherplatz. Die Wiederherstellung ist auch einfach durchzuführen. Im Allgemeinen ist es sehr empfehlenswert, regelmäßig die Wiederherstellung zu testen. So bleibt man in Übung für den Notfall, und kann eventuell schneller Schreibfehler oder ähnliche Probleme feststellen.

Für Backups empfiehlt sich, die 3-2-1-Regel zu befolgen. Das bedeutet:

• 3 Kopien der Daten: Es sollte immer mindestens drei Kopien der Datenbestände geben. Dies soll dafür sorgen, dass die Ausfallwahrscheinlichkeit minimiert wird. Denn wenn Daten nur auf einem System gespeichert sind, gibt es eine recht hohe Wahrscheinlichkeit, dass im Falle einer Wiederherstellung auch die gespeicherten Daten nicht verfügbar sind. Wenn diese jedoch auf drei unterschiedlichen und voneinander unabhängigen Systemen gespeichert sind, so ist ein Ausfall nahezu unmöglich.

• 2 verschiedene Speichermedien: Die Kopien sollen auf mindestens zwei verschiedenen Speichermedien aufbewahrt werden. Die Anfälligkeit für Fehler ist bei unterschiedlichen Medien nicht gleich. Im Gegensatz kommt es des öfteren vor, dass beispielsweise Festplatten eines Herstellers aus der gleichen Serie nach etwa gleich langer Benutzungsdauer ausfallen. Die Nutzung verschiedener Hersteller und Speichermedien verlagert dies auf unterschiedliche Zeitpunkte und reduziert so die Anfälligkeit für Fehler.

• 1 Kopie an einem anderen Ort: Mindestens eine Kopie der Daten soll sich an einem anderen Ort als die beiden anderen Kopien befinden. Im Falle eines Brandes oder eines anderen Notfalls ist so sichergestellt, dass eine Kopie immer noch verfügbar ist und benutzt werden kann.

3.5 Vorkehrungen für Sicherheitsvorfälle

Im Bereich der Informationssicherheit gibt es viele Expertinnen, die der Meinung sind, dass in alle Dienste eingebrochen werden wird. Es ist nur eine Frage des Zeitpunkts. Gerade auch vor diesem Hintergedanken ist es sinnvoll, Vorkehrungen für den Sicherheitsvorfall zu treffen.

Dabei kann ein Sicherheitsvorfall das Ausnutzen einer Sicherheitslücke mit anschließendem Einbruch in den Server, eine falsche Konfiguration, durch die Daten veröffentlicht werden, das Speichern einer Kopie der Datenbank im öffentlich verfügbaren Verzeichnis eines Webservers und vieles mehr sein. In der Mehrzahl der Fälle ist ein Sicherheitsvorfall vermutlich auch eine Verletzung des Schutzes personenbezogener Daten im Sinne des Art. 4 Nr. 12 DSGVO. Daher werden diese unten gedanklich gleich behandelt.

Zunächst ist es sinnvoll, sich Gedanken zu möglichen Sicherheitsvorfällen zu machen, und zu überlegen, was bei konkreten Fällen getan werden könnte. Diese Schritte können und sollen dann auch geübt werden. Dies hilft, mögliche Lücken aufzudecken und Übung für das reale Auftreten eines Vorfalls zu haben.

Neben der Beseitigung des durch einen Sicherheitsvorfall angerichteten Schadens sind insbesondere Meldepflichten im Blick zu behalten. Die DSGVO fordert im Artikel 33 eine Meldung an die Aufsichtsbehörden. Diese Meldung muss innerhalb von 72 Stunden nach Entdecken des Vorfalls geschehen. Nur für den Fall, dass der Sicherheitsvorfall zu keinen Risiken für Rechte und Freiheiten der betroffenen Personen führt, ist es zulässig, auf diese Meldung zu verzichten. Weiterhin ist bei einem voraussichtlich hohen Risiko für Rechte und Freiheiten der betroffenen Personen nach dem Art. 34 DSGVO auch eine Meldung direkt an diese Personen zu machen.

Somit müssen Informationen über Sicherheitsvorfälle schnell zu den verantwortlichen Personen gelangen. Der genaue Personenkreis hängt von der Organisationsstruktur ab. In Frage kommen hier die Geschäftsführung, Personen oder Abteilungen, die die Server administrieren oder die Informationssicherheits- bzw. Datenschutzbeauftragte. Diese sind in der Lage, sich über die Schwere des Vorfalls zu informieren und eine Entscheidung für die weitere Verfahrensweise zu treffen.

Eine Meldung muss dabei folgende Informationen enthalten:

• eine Beschreibung des Vorfalls mit Angabe der Kategorien und ungefähren Anzahl der betroffenen Personen

• Name und Kontaktdaten des Datenschutzbeauftragten oder einer anderen Anlaufstelle

• eine Beschreibung der Folgen des Vorfalls

• eine Beschreibung der getroffenen Maßnahmen zur Behebung

Die DSGVO lässt auch zu, dass die obigen Informationen schrittweise an die Aufsichtsbehörden übermittelt werden.

Am Ende eines Sicherheitsvorfalls ist es sinnvoll, den Vorfall in Ruhe zu analysieren. Dies hilft, mögliche Verbesserungen für die Zukunft zu finden und zu implementieren.

4. Konfiguration für den Betrieb der Software

In den unten stehenden Abschnitten werden verschiedene Software-Bestandteile und deren mögliche Konfiguration diskutiert. Dabei wird insbesondere auf eine datenschutzgerechte Einstellung Wert gelegt. Das heißt, einerseits soll die Software mit möglichst sicheren Einstellungen betrieben werden und andererseits sollen personenbezogene Daten nach Möglichkeit nicht oder nur so lange wie notwendig verarbeitet werden.

4.1 Einstellungen für das Betriebssystem

Das Betriebssystem, welches den Mastodon-Server wie auch die weiteren Komponenten beherbergt, sollte möglichst sicher im Sinne der Informationssicherheit sein. Das heißt, die Ziele Vertraulichkeit, Integrität und Verfügbarkeit sollten möglichst gut umgesetzt sein. Möglichst gut ist dabei im Sinne des Art. 32 Abs. 1 DSGVO zu verstehen. Das heißt, es müssen verschiedene Faktoren, wie Stand der Technik, Kosten der Umsetzung, Eintrittswahrscheinlichkeit sowie weitere, berücksichtigt werden.

Updates für die installierte Software

Software wird in aller Regel mit Fehlern (Bugs) ausgeliefert. In der Regel sind diese zum Zeitpunkt der Auslieferung nicht bekannt, sondern werden erst im Laufe der Zeit bekannt. Viele Herstellerinnen beheben diese Fehler und stellen Updates zur Verfügung. Einige der Fehler haben Auswirkung auf die IT-Sicherheit des zugrunde liegenden Systems. Daher ist es sinnvoll und wichtig, die Updates rechtzeitig einzuspielen. Dies kann manuell über die üblichen Administrationswerkzeuge passieren. Alternativ gibt es Werkzeuge, die den Prozess für die Aktualisierung des Systems automatisieren (Debian: unattended-upgrades). Regelmäßige Updates aller installierter Software bieten Schutz gegen bekannte Sicherheitslücken.

Rechte für das temporäre Verzeichnis

Unter Linux werden temporäre Dateien oft in das Verzeichnis /tmp gespeichert. Dies kann auch ein Einfallstor für Angreiferinnen sein. Sie legen dort ausführbare Dateien ab und starten sie aus diesem Verzeichnis.

Mit dem Gedankengang sollte das Verzeichnis eine separate Partition auf dem System sein. Dies erlaubt es, das Verzeichnis mit der Option noexec einzubinden. Dies kann ebenfalls erreicht werden, wenn das Dateisystem tmpfs verwendet wird. Für den letzteren Fall könnte die Datei /etc/fstab folgende Zeile enthalten:

tmpfs /tmp tmpfs defaults,rw,nosuid,nodev,noexec,relatime,size=1G 0 0

Damit wird ein Verzeichnis mit einer Größe von einem Gigabyte angelegt. Weiterhin sollte auf Systemen, die systemd einsetzen, die Einheit tmp.mount aktiv sein. Dies lässt sich mittels des Befehls

systemctl is-enabled tmp.mount

prüfen und ggf. mittels systemctl unmask tmp.mount aktivieren.

Korrekte Zeit einstellen

Das Betriebssystem sowie die Anwendungen benötigen für verschiedene Aufgaben die korrekte Uhrzeit. Sofern die Systeme keinen Zugang zu anderen Mitteln haben, ist es sowohl für virtualisierte Umgebungen wie auch für physische Server sinnvoll, die Zeit mit einer oder mehreren offiziellen Quellen abzugleichen.

Hierzu eignen sich folgende Programme

• ntp

• chrony

• systemd-timesyncd

Alle gleichen die lokale Zeit mit einem Zeitserver im Internet ab. Damit ist sichergestellt, dass die korrekte Zeit eingestellt ist. Der Server sollte dabei jeweils auf genau eine Software vertrauen. Der Einsatz mehrerer verschiedener Software zur Steuerung der Systemzeit kann zu Problemen führen.

Festplattenverschlüsselung

Neben den obigen Maßnahmen gehört auch eine Verschlüsselung der Festplatte zu den sinnvollen Maßnahmen. Üblicherweise wird die Verschlüsselung durch Eingabe eines Passworts oder durch die Anwesenheit eines Hardware-Bauteils geöffnet. Bei einem Server, der nur von der Ferne administriert wird, sind hier einige Vorkehrungen zu treffen.

Üblicherweise wird dazu die Software Dropbear installiert. Dies ist ein kleiner SSH-Server. Damit ist eine Verbindung zum Server möglich und die Festplatte kann damit aufgeschlossen werden. Genauere Anleitungen hierzu finden sich im Wiki der Thomas-Krenn AG.

Weitere Maßnahmen

Neben den oben vorgestellten Maßnahmen erscheint die Verwendung von AppArmor sinnvoll. Diese Software regelt die Zugriffsrechte von anderen Programmen über festgelegte Regeln. Einige Betriebssysteme liefern recht umfangreiche Regelsätze mit. Für Mastodon müssen jedoch selbst Regeln angelegt werden.

Weiterhin bietet Systemd eine Art Sandboxing an. Das heißt, der Dienst kann andere Systemdienste in eigenen Umgebungen „einsperren“ und nur bestimmte Zugriffe zulassen. Mittels des Befehls systemd-analyze security servicename werden die aktuellen Einstellungen angezeigt. Davon ausgehend lassen sich diese mittels systemctl edit servicename bearbeiten. Es wäre wünschenswert, wenn seitens der Entwicklerinnen eine gehärtete Systemd-Einheit ausgeliefert wird oder sich künftig ein Projekt findet, was dies entwickelt und pflegt.

Neben den oben vorgestellten Maßnahmen lassen sich noch eine Reihe weiterer Maßnahmen zur Absicherung denken. Das Center for Internet Security bietet mit den CIS Benchmarks eine gute Quelle für weitere Maßnahmen an. Es ist empfehlenswert, diese herunterzuladen und den Hinweisen für das eigene System zu folgen.

Weiterhin bietet auch das BSI mit dem IT-Grundschutz-Kompendium eine Reihe von Bausteinen, die für die Absicherung des Systems verwendet werden können.

4.2 Einstellungen für den Webserver

Als Webserver kommt nginx zum Einsatz. Dieser sollte am besten über die Paketverwaltung des jeweiligen Betriebssystems installiert werden. Dadurch wird sichergestellt, dass Aktualisierungen halb- oder ganz automatisch ankommen. In der Regel wird die Software auch so voreingestellt, dass diese als nicht-privilegierter Systembenutzer ausgeführt wird. Das reduziert die Angriffsmöglichkeiten, da dieser Systembenutzer nicht vollen Zugriff auf alle Systemdateien hat. Für den Fall einer manuellen Installation ist darauf zu achten, dass auch ähnliche Einstellungen getroffen werden.

Die Mastodon-Software bringt bei der Installation bereits eine Konfigurationsdatei für den Webserver mit.² Standardmäßig muss darin nur der Domain-Name ergänzt werden.

Versionsnummer eventuell deaktivieren

Hin und wieder wird empfohlen, die öffentlich sichtbaren Versionsnummern abzuschalten. Dazu muss in den Einstellungen, die sich üblicherweise im Verzeichnis /etc/nginx befinden, die Direktive server_tokens auf Off gestellt werden. Dies bietet meist nur einen geringen Schutz. Denn die von außen abfragbaren Eigenschaften des Webservers lassen sehr oft einen Schluss auf die Versionsnummer oder eine gewisse Spanne an Versionen zu.

TLS aktivieren

In der mitglieferten Konfigurationsdatei sind Einstellungen für den Einsatz von TLS getroffen. Die Hauptaufgabe der Administratorinnen ist es, ein Zertifikat zu beziehen und den Speicherort der Dateien in der Konfiguration zu setzen.

Unten wird auf den Bezug eines Zertifikats mittels Let’s Encrypt eingegangen. Dies ist ein recht einfacher Weg, ein Zertifikat zu beziehen. Allerdings existieren auch andere Certificate Authoritys (CA), die TLS-Zertifikate bereitstellen. Allen ist gemein, dass am Ende des Prozesses eine Zertifikats- und Schlüsseldatei steht. Der Speicherort dieser Dateien muss im Webserver eingetragen werden. Hierzu gibt es in den mitgelieferten Einstellungen für den Webserver (nginx.conf) die Zeilen ssl_certificate und ssl_certificate_key. Dort muss der komplette Pfad zu der entsprechenden Datei eingetragen werden. Es sollte darauf geachtet werden, dass die Schlüsseldatei nur für den root-Benutzer les- und schreibbar ist.

Let’s Encrypt ist eine CA, die den Bezug eines Zertifikats vereinfacht. Die Programme Certbot oder dehydrated.io sorgen dafür, dass der Aktualisierungsstand des Zertifikats geprüft und eventuell automatisch ein neues bezogen wird. Beide sollten automatisiert als Cronjob oder Systemd-Timer gestartet werden.

Im Allgemeinen sollte darauf geachtet werden, dass der Webserver nur die TLS-Versionen 1.2 oder neuer mit starken kryptografischen Algorithmen³ verwendet. Derzeit sind alle Algorithmen, die in der Version 1.3 von TLS eingesetzt werden, als sicher anzusehen. Daneben sollten Algorithmen gewählt werden, die Authenticated Encryption (AEAD)⁴ oder Perfect Forward Secrecy (PFS)⁵ einsetzen. Insgesamt verbleiben damit folgende Kombinationen für TLS:⁶

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

• TLS_DHE_RSA_WITH_AES_128_CBC_SHA

• TLS_DHE_RSA_WITH_AES_256_CBC_SHA

• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

Je nach Sicherheitserfordernis kann die obige Auflistung weiter eingegrenzt werden. Keinesfalls sollten folgende Varianten eingestellt werden:

• NULL (keine Verschlüsselung)

• Anonymes Diffie-Hellman (aDH, keine Authentifikation)

• symmetrische Algorithmen mit einer Schlüssellänge von weniger als 128 Bit

• RC4, DES, 3DES sowie andere Algorithmen mit einer Blockgröße von 64 Bit

Diese Einstellungen liefert die Konfigurationsdatei bereits mit aus. Damit müssen keine zusätzlichen Einstellungen in dieser Hinsicht vorgenommen werden.

Weiterhin ist es sinnvoll, den Webserver so einzustellen, dass alle Anfragen zur HTTPS-Version der Seite umgeleitet werden. In der Server-Konfiguration des nginx wird dabei in zwei Teilen gearbeitet. Einer behandelt die Anfragen, die bei Port 80 ankommen und in der Regel HTTP-Anfragen ohne TLS sind. Der zweite Teil behandelt die TLS-Konfiguration. Im ersten Teil wird die folgende Zeile mit eingebaut:

location / { return 301 $host$request_uri; }

Dies leitet alle Anfragen auf die HTTPS-Version der Seite um.

Das Endgerät der Anwenderinnen sollte schließlich eine Information über die Verfügbarkeit von TLS erhalten. Hierzu dient die HTTP Strict Transport Security. Die Standardkonfiguration von Mastodon informiert die Endgeräte darüber, dass sie die folgenden zwei Jahre nach dem letzten Abruf die Seite über TLS erreicht werden kann.

Logging deaktivieren

Webserver führen häufig Log-Dateien über Seiten-Zugriffe und Fehler. In den Dateien können u. a. IP-Adressen und andere personenbezogene Daten gespeichert werden. Daher ist es sinnvoll, dieses Logging entweder komplett zu deaktivieren und nur bei Bedarf (Fehleranalyse) zu aktivieren oder die Log-Dateien schnellstmöglich zu löschen. Eine weitere Möglichkeit wäre, die IP-Adressen in den Log-Dateien ganz oder teilweise durch Nullen zu ersetzen.

Die Deaktivierung des Loggings im nginx erfolgt mittels

access_log off;

error_log /dev/null crit;

in der HTTP-Konfiguration. Bei neueren Versionen von nginx kann auch error_log off; verwendet werden. Alternativ entfernen manche Betreiberinnen die IP-Adresse schon beim Schreiben in die Log-Datei. Die korrekte Konfiguration ist etwas komplexer. Es sei hierzu auf den Beitrag bei der Seite Stackoverflow verwiesen. Dort wird die Konfiguration beschrieben und kann ggf. in die eigenen Einstellungen übernommen werden. Dabei sollte darauf geachtet werden, dass die Log-Datei, die Fehler aufzeichnet (error_log), entsprechend konfiguriert wird.

Sofern Log-Dateien mit personenbezogenen Daten geführt werden, sollten diese Dateien regelmäßig gelöscht werden. Die Software logrotate ist hierzu hilfreich. Sie kann Log- und andere Dateien, die ein bestimmtes Alter oder eine bestimmte Dateigröße überschritten haben, löschen. Das Löschen reicht vom einfachen Entfernen aus dem Dateisystem bis zum Überschreiben mit Nullen oder Zufallswerten.

4.3 Einstellungen für den Datenbankserver

Wie auch der Webserver sollte die Datenbanksoftware über die Paketverwaltung des Betriebssystems installiert werden. Dadurch kommen aktuelle Versionen auf das System, und die Zugriffsrechte sind in der Regel sinnvoll gesetzt.

Die Administration und Pflege von PostgreSQL erfolgt über den Systembenutzer postgres. Alle diejenigen, die Administrationsaufgaben erledigen, sollten das Recht besitzen, als postgres zu agieren. Oft wird dies über das Programm sudo geregelt. Dabei ist es sinnvoll, alle Administratorinnen in einer Gruppe zur Datenbankadministration zu halten. Wenn diese Gruppe beispielsweise dba heißt, kann in der Datei /etc/sudoers.d/postgres folgendes eingestellt werden:

%dba ALL=(postgres) PASSWD: ALL

Gegebenenfalls lassen sich die Einstellungen nach Bedarf weiter verfeinern.

Der Systembenutzer postgres hat weitreichende Berechtigungen und kann Datenbanken wie Benutzerinnen neu anlegen, ändern etc. Im Sinne des Prinzips der geringsten Berechtigungen ist es sinnvoll, für Abfragen einer speziellen Datenbank Nutzer anzulegen, die genau dies können. Daher sollte hierfür ein weiterer Datenbanknutzer angelegt werden. Die Mastodon-Software geht davon aus, dass dieser den Namen mastodon trägt. Dieser hat standardmäßig keine erweiterten Rechte. Es ist sinnvoll, dies zu kontrollieren. Als Systembenutzer postgres kann folgender Befehl verwendet werden:

psql -c "\du mastodon"

In der Ausgabe sollte der Benutzer nur das Attribut Create DB besitzen.

4.4 Einstellungen für Mastodon

Die Einstellungen für Mastodon selbst werden in Form von Umgebungsvariablen in einer Datei gespeichert. Diese Datei liegt in dem Verzeichnis, in dem die Mastodon-Software installiert wurde und heißt standardmäßig .env.production.

Keine IP-Adressen speichern

Mastodon speichert den Zeitpunkt des letzten Logins mit der jeweiligen IP-Adresse in der Datenbank. Dies erscheint zumeist nicht notwendig. Daher ist es sinnvoll, dies zu deaktivieren. In der oben erwähnten Konfigurationsdatei .env.production sollte daher die Variable IP_RETENTION_PERIOD auf 0 gesetzt werden.

Secure Mode aktivieren

Eine Besonderheit bei Mastodon ist der so genannte „Secure Mode“. Server, die in dem Modus betrieben werden, erfordern es, dass alle Anfragen signiert werden. Dadurch lässt sich steuern, inwieweit öffentliche Nachrichten auf blockierten Servern zu sehen sind. Mit aktiviertem Secure Mode werden diese Inhalte dort nicht angezeigt.

Allerdings bleiben die Inhalte weiterhin über die Webseite verfügbar. Über andere Instanzen können diese eventuell ebenfalls abgerufen werden. Insofern ist das nur ein recht schwacher Schutz für öffentliche Inhalte. Nicht-öffentliche Inhalte erfordern hingegen immer eine Authentifizierung.

Bei Mastodon werden HTTP-Anfragen genutzt, um Informationen abzurufen. Das heißt, ein Client nutzt eine definierte Schnittstelle (Application Programming Interface, API) und sendet meist mittels der GET-Methode Anfragen ab. Ohne aktivierten Secure Mode können so Toots, Profilinformationen und anderes abgerufen werden.

Wenn ein Server den Secure Mode aktiviert hat, können diese Informationen nur mit Hilfe einer Signatur abgerufen werden. Diese Signatur wird vom Server nur bei einer eingeloggten Benutzerin erzeugt. Mit der signierten Anfrage kann der andere Server entscheiden, ob die gewünschten Informationen übermittelt werden oder nicht. Letzteres kann der Fall sein, wenn der Account blockiert ist.

Das Erstellen und Prüfen der Signaturen ist in der Regel rechenaufwendig. Daher ist dies nicht standardmäßig aktiv. Wenn dies aktiviert werden soll, muss in der .env.production der Wert von AUTHORIZED_FETCH auf 1 gestellt werden.

Neben der möglichen höheren Rechenleistung kann es auch sein, dass andere Instanzen im Fediverse Probleme mit dem Secure Mode haben. So musste bei der Diskussionsplattform Lemmy bei Versionen vor der 0.19.4 eine Einstellung aktiviert werden. Falls dem nicht so war, konnten diese Instanzen nicht mit Mastodon-Instanzen mit aktiviertem Secure Mode kommunizieren. Ähnliches ist auch bei anderer Fediverse-Software denkbar, wenn auch derzeit nicht öffentlich bekannt.

Andererseits gibt es auch Software, wie beispielsweise GoToSocial, die Secure Mode standardmäßig aktiviert haben.

Bei der Entscheidung für oder gegen den Secure Mode sollte auch der Umgang mit der Plattform Threads in Erwägung gezogen werden. Im Fediverse gibt es viele Menschen, die aus unterschiedlichen Überlegungen die Plattform von Meta blockieren möchten. Sollte sich die Betreiberin hierfür entscheiden, so würde der Secure Mode dies effektiver machen.

Insgesamt sollten Betreiberinnen daher abwägen, ob sie den Secure Mode aktivieren möchten. Es fällt schwer, hier einen allgemein gültigen Rat zu geben.