Kategorie: Server-Techniken-Software

Schritt 1: Anmeldung am Blog-Dashboard

Logge dich in das Dashboard deines Blogs ein. Die genaue Vorgehensweise kann je nach Blog-Plattform variieren. Normalerweise erfolgt die Anmeldung über eine URL wie „deinblog.de/wp-admin“ oder „deinblog.com/admin“.

Schritt 2: Erstellen der Kategorie

Suchen Sie im Dashboard-Menü nach der Option „Kategorien“ oder „Categories“. Diese Option befindet sich normalerweise im Bereich „Beiträge“ oder „Posts“.

Klicke auf „Kategorien erstellen“ oder eine ähnliche Schaltfläche, um eine neue Kategorie hinzuzufügen.

Gib einen Namen für die Kategorie ein, z.B. „Server und Server-Panels“.

Du kannst auch eine „Elternkategorie“ auswählen, falls deine Kategorien hierarchisch organisiert sind. Wenn dies nicht der Fall ist, lasse dieses Feld einfach leer.

Klicke auf „Kategorie hinzufügen“ oder „Add Category“, um die neue Kategorie zu erstellen.

Schritt 3: Hinzufügen der Kurzbeschreibung

Nachdem du die Kategorie erstellt hast, suche nach einer Option wie „Kategorien verwalten“ oder „Manage Categories“. Klicke darauf, um die Kategorieeinstellungen zu öffnen.

Hier findest du eine Liste der Kategorien, einschließlich der von dir erstellten „Server und Server-Panels“. Klicke auf „Bearbeiten“ oder „Edit“, um die Kategorieeinstellungen zu ändern.

In den Kategorieeinstellungen gibt es normalerweise ein Feld mit dem Namen „Beschreibung“ oder „Description“. Hier kannst du eine kurze Beschreibung für die Kategorie eingeben, z.B. „Tipps und Tutorials zur Verwaltung von Servern und Server-Panels“.

Speichere die Änderungen, nachdem du die Kurzbeschreibung eingegeben hast.

Schritt 4: Anwenden der Kategorie in deinen Beiträgen

Jetzt, da du die Kategorie erstellt und eine Kurzbeschreibung hinzugefügt hast, kannst du diese Kategorie deinen Blogbeiträgen zuordnen. Wähle einfach diese Kategorie aus, wenn du einen neuen Beitrag erstellst oder einen vorhandenen bearbeitest.

Mecklenburg-Vorpommern setzt auf Nextcloud: Digitale Souveränität beginnt nach der Pressemitteilung

Podcastfolge: Nextcloud statt SharePoint – Mecklenburg-Vorpommerns Souveränitätstest

Mecklenburg-Vorpommern macht etwas, das in der deutschen Digitalpolitik noch immer ungewöhnlich genug ist, um Aufmerksamkeit zu verdienen: Das Land ersetzt Microsoft SharePoint durch eine selbst kontrollierte Kollaborationsplattform auf Basis von Nextcloud. Rund 5.000 Beschäftigte nutzen das Filesharing bereits. Mittelfristig sollen Chat, Videokonferenzen und Groupware hinzukommen und mehr als 50.000 Beschäftigte in Landes- und Kommunalverwaltungen erreichen.

Das ist keine bloße Absichtserklärung. Es gibt einen landeseigenen Betreiber, eine laufende Plattform und eine konkrete Migration. Trotzdem wäre es verfrüht, bereits den Sieg der digitalen Souveränität auszurufen. Open Source ist eine notwendige Grundlage. Souverän wird eine Verwaltung aber erst, wenn sie Betrieb, Wissen, Daten, Schlüssel, Wiederherstellung und Wechselpfad tatsächlich beherrscht.

Mehr Substanz als die übliche Sonntagsrede

Nach Angaben des Finanz- und Digitalisierungsministeriums betreibt die landeseigene DVZ M-V GmbH die Plattform. Nextcloud steht unter der GNU AGPLv3. Das Land nennt eigene Test- und Produktivumgebungen, Betriebsschulungen, Sicherheitsprüfungen und eine priorisierte Einbindung von Stabilitätsupdates. Der Umstieg von SharePoint sei schrittweise und ohne Datenverluste abgeschlossen worden.

Diese Punkte sind wichtig. Ein benannter Betreiber ist besser als eine Wolke aus Unterauftragnehmern. Eine getrennte Testumgebung ist besser als Updates direkt im Produktivsystem. Eine laufende Migration ist mehr wert als die hundertste Strategie mit buntem Titelbild.

Auch der politische Kontext stimmt: Mecklenburg-Vorpommern kooperiert seit 2025 mit Schleswig-Holstein. Parallel nennt das Land OpenProject und den auf OpenWebUI beruhenden Verwaltungschatbot LEA. Daraus könnte mehr als eine einzelne Nextcloud-Installation entstehen: ein offener Verwaltungsarbeitsplatz, dessen Bausteine nicht von einem einzigen US-Konzern diktiert werden.

Open Source ist noch keine Souveränität

Der Quellcode einer Software kann offen sein, während der reale Betrieb weiterhin abhängig bleibt. Wer administriert die Systeme? Wer hält die Verschlüsselungsschlüssel? Welche Komponenten stecken vor und hinter Nextcloud? Ist das Office-Paket offen? Läuft die Videokonferenz über eigene Infrastruktur? Sind Identitätsmanagement, Push-Dienste, Monitoring und Support austauschbar?

Eine Verwaltung kann Nextcloud nutzen und trotzdem in einem neuen Lock-in landen: bei einem Integrator, bei proprietären Erweiterungen oder bei einem Sonderstand, den außer dem bisherigen Dienstleister niemand versteht. Deshalb muss das Land nicht nur Dateien exportieren können. Es braucht Dokumentation, Automatisierung, Versionsstände, Konfigurationen und ausreichend eigenes Personal, damit ein anderer Betreiber übernehmen könnte.

Ein Matrix-Raum ist auch nicht souverän, nur weil Synapse Open Source ist. Ohne Signing Keys, Datenbank, Medien, Reverse-Proxy-Konfiguration und korrekte .well-known-Einträge lässt er sich nicht sauber wiederherstellen. Ebenso ist eine Nextcloud-Sicherung unvollständig, wenn nur Nutzdateien kopiert werden, aber Datenbank, Apps, Konfiguration, Secrets und Cronjobs fehlen.

Der Restore ist die Stunde der Wahrheit

Politik spricht gern über Clouds, Plattformen und Innovation. Seltener spricht sie über den langweiligen Teil, an dem sich Kontrolle entscheidet: Backups und Wiederherstellung.

Ein Backup ist keine Erfolgsmeldung. Erst ein getesteter Restore beweist, dass Daten, Abhängigkeiten und Betriebswissen zusammenpassen. Für Mecklenburg-Vorpommern wären deshalb belastbare Antworten nötig: Gibt es getrennte, versionierte Sicherungen? Werden sie regelmäßig in einer isolierten Umgebung zurückgespielt? Wie lange dauert ein Wiederanlauf? Können zentrale Dienste bei einem Ausfall des Rechenzentrums weiterarbeiten? Wer entscheidet im Notfall über Schlüssel und DNS?

Dass das Land in seiner Kooperation mit Schleswig-Holstein auch Resilienz und Desaster Recovery nennt, ist richtig. Entscheidend ist, ob daraus überprüfbare Praxis entsteht. Ein Dokument im Notfallhandbuch startet noch keinen Server.

5.000 Nutzer sind ein Anfang – 50.000 eine andere Liga

Filesharing für 5.000 Beschäftigte und eine vollständige Kollaborationsumgebung für mehr als 50.000 Menschen sind zwei verschiedene Aufgaben. Sobald Chat, Videokonferenzen, Kalender, Kontakte und gemeinsames Office hinzukommen, steigen Last, Supportbedarf und organisatorische Abhängigkeit.

Dann zählen nicht nur CPU und Speicher. Es geht um Identitäten, Rollen, Barrierefreiheit, mobile Geräte, Aufbewahrungsregeln, Datenschutz, Schulung und Hilfe im Arbeitsalltag. Kommunen haben andere Voraussetzungen als Ministerien. Kleine Verwaltungen benötigen möglicherweise mehr Unterstützung, dürfen aber nicht zu bloßen Mandanten ohne Mitspracherecht werden.

Die Zielzahl muss deshalb an aktiven Nutzern, tatsächlicher Funktionsnutzung, Verfügbarkeit und Zufriedenheit gemessen werden. Ein freigeschaltetes Konto ist noch kein gelungener Rollout.

Die ökonomische Frage: Wer bekommt das Geld und wer behält das Wissen?

Digitale Souveränität ist auch Industriepolitik. Öffentliche Milliarden können entweder Lizenzrenten und Abhängigkeiten finanzieren oder offene Infrastruktur, europäische Anbieter und dauerhaftes Wissen in der Verwaltung stärken.

Das bedeutet nicht, dass Open Source kostenlos ist. Im Gegenteil: Betrieb, Integration, Sicherheit, Schulung und Weiterentwicklung müssen anständig bezahlt werden. Der Unterschied liegt darin, was nach der Zahlung übrig bleibt. Bei einem proprietären Vertrag bleiben häufig Nutzungsrechte und Abhängigkeit. Bei einer klugen Open-Source-Beschaffung bleiben zusätzlich Quellcode, Dokumentation, Standards, Wechselmöglichkeiten und idealerweise Verbesserungen für alle.

Darum sollte Mecklenburg-Vorpommern offenlegen, welche Kosten die Migration und der laufende Betrieb verursachen, welche externen Dienstleister beteiligt sind und welche Anpassungen an die jeweiligen Projekte zurückgegeben werden. Öffentliche Mittel sollten keine unsichtbaren Sonderlösungen produzieren, sondern gemeinschaftlich nutzbare Infrastruktur.

Kooperation statt 16 Landesinseln

Die Zusammenarbeit mit Schleswig-Holstein ist möglicherweise der politisch stärkste Teil des Projekts. Deutschland braucht nicht 16 inkompatible Landesclouds und 11.000 kommunale Einzelwege. Es braucht gemeinsame offene Standards, wiederverwendbare Betriebsmodelle und föderale Strukturen, bei denen ein Land nicht vom guten Willen des anderen abhängig wird.

Gemeinsam heißt dabei nicht zentralistisch. Mecklenburg-Vorpommern muss seine Daten und Entscheidungen selbst kontrollieren können. Gleichzeitig sollten Schnittstellen, Automatisierung, Sicherheitswissen und Beschaffungsunterlagen geteilt werden. So entsteht Redundanz: Wenn ein Betreiber ausfällt oder ein Vertrag endet, existiert ein realer Wechselpfad.

Ein guter Anfang, der öffentlich geprüft werden muss

Mecklenburg-Vorpommern verdient Anerkennung dafür, SharePoint nicht nur zu kritisieren, sondern praktisch zu ersetzen. Doch politische Glaubwürdigkeit entsteht nicht durch das Etikett „souverän“. Sie entsteht durch überprüfbare Kontrolle.

In den kommenden Monaten sind deshalb konkrete Nachweise wichtiger als weitere Hochglanzmeldungen:

Wie entwickeln sich aktive Nutzerzahlen und kommunaler Rollout?
Welche Komponenten werden für Talk, Office und Groupware eingesetzt?
Wo liegen Daten, Schlüssel und Backups?
Gibt es dokumentierte und getestete Wiederherstellungen?
Können Betreiber und Dienstleister gewechselt werden?
Welche Kosten entstehen und welche Verbesserungen fließen upstream?
Gibt es unabhängige Sicherheitsprüfungen und veröffentlichbare Ergebnisse?

Wenn diese Fragen sauber beantwortet werden, kann aus dem Projekt ein Vorbild werden. Wenn nicht, bleibt Nextcloud nur ein anderes Logo auf einer weiterhin fremdbestimmten Infrastruktur.

Digitale Souveränität bedeutet nicht, dass der Staat alles selbst programmieren muss. Sie bedeutet, dass er jederzeit verstehen, prüfen, betreiben, wiederherstellen und wechseln kann. Mecklenburg-Vorpommern hat einen ernst zu nehmenden Anfang gemacht. Jetzt beginnt der Teil, an dem sich entscheidet, ob aus Software tatsächlich politische Handlungsfähigkeit wird.

Diskussion: https://treff.darknight-coffee.eu/@carrabelloy Podcast: https://podcast.darknight-coffee.org/pages/startseite Blog: https://carrabelloy.darknight-coffee.org/blog/ Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Quellen

Ministerium für Finanzen und Digitalisierung Mecklenburg-Vorpommern, „Auf dem Weg zur Digitalen Souveränität: Mecklenburg-Vorpommern setzt auf Open Source“, 3. Juli 2026: https://www.regierung-mv.de/Landesregierung/fm/Aktuell/?id=221531
DVZ M-V GmbH, „Mecklenburg-Vorpommern setzt auf Open Source“, 3. Juli 2026: https://www.dvz-mv.de/news/mecklenburg-vorpommern-setzt-auf-open-source
Gemeinsame Kooperation Mecklenburg-Vorpommern/Schleswig-Holstein zur digitalen Souveränität, 21. Oktober 2025: https://www.regierung-mv.de/Aktuell/?id=215184

Die stille Tür im Linux-Server: Was BPFDoor über unsere Telekommunikationsnetze verrät

Ein Linux-Server kann nach außen vollkommen ruhig wirken. Kein ungewöhnlicher Port steht offen, kein verdächtiger Dienst meldet sich regelmäßig bei einem Kontrollserver, und ein gewöhnlicher Portscan findet nichts. Trotzdem kann im System eine Hintertür warten. Nicht auf eine normale Anmeldung, sondern auf ein präpariertes Netzwerkpaket.

Genau dieses Prinzip nutzt BPFDoor. Die Backdoor ist kein theoretisches Laborstück und auch keine neue Windows-Schadsoftware mit Linux-Anstrich. Sie wurde für langfristige Zugriffe auf Linux-Systeme entwickelt und mit Spionagekampagnen gegen Telekommunikations- und Regierungsnetze verbunden. Rapid7 berichtete 2026 nach einer mehrmonatigen Untersuchung über eine fortdauernde, China-nahe Kampagne in Telekommunikationsumgebungen. Fraunhofer FKIE führt die Malwarefamilie in Malpedia, MITRE ordnet ihre Techniken im ATT&CK-Katalog ein.

Der Fall ist technisch interessant. Politisch ist er noch wichtiger. Berlin diskutiert gleichzeitig neue offensive Befugnisse für Nachrichtendienste, einschließlich Eingriffen in fremde IT-Systeme und des Umgangs mit unbekannten Schwachstellen. Brüssel verpflichtet Betreiber und Hersteller mit NIS2 und Cyber Resilience Act zu mehr Sicherheitsmanagement. Die eine politische Hand verlangt also bessere Verteidigung. Die andere will sich offensive Zugriffsmöglichkeiten erhalten.

Die entscheidende Frage lautet deshalb nicht nur, wie BPFDoor funktioniert. Sie lautet: Wie glaubwürdig ist staatliche Cybersicherheit, wenn derselbe Staat ein Interesse daran haben kann, Schwachstellen nicht sofort zu schließen?

BPF ist keine Firewall

Der Name BPFDoor verweist auf den Berkeley Packet Filter. BPF ist keine eigenständige Linux-Firewall. Es ist eine Filter- und Ausführungsmechanik, mit der Netzwerkpakete früh und effizient ausgewählt werden können. Werkzeuge wie tcpdump und Bibliotheken wie libpcap nutzen diese Technik, damit nicht jedes Paket vollständig in den Userspace kopiert und dort ausgewertet werden muss.

BPFDoor missbraucht diese legitime Fähigkeit. Die Malware bindet einen Filter an einen Raw Socket und prüft eintreffende TCP-, UDP- oder ICMP-Pakete auf bestimmte Aktivierungsdaten. Normale Pakete werden ignoriert. Ein passendes „Magic Packet“ löst dagegen die nächste Stufe aus. Je nach Variante startet die Malware eine Bind- oder Reverse-Shell und verschafft dem Angreifer eine Kommandozeile auf dem kompromittierten System.

Das ist der eigentliche Tarnvorteil: Die Backdoor braucht keinen dauerhaft sichtbaren Listening-Port und kein regelmäßiges Beaconing. Sie muss nicht alle paar Minuten nach Hause telefonieren. Sie wartet passiv im vorhandenen Verkehr.

Unsichtbar ist sie deshalb nicht. Sie hinterlässt Prozesse, Speicherzustände, Socket-Aktivität, geladene Filter, veränderte Firewallregeln oder Laufzeitdateien. Bekannte Varianten manipulieren Prozessnamen, löschen die abgelegte Binärdatei nach dem Start, verändern Zeitstempel und leiten Shell-Historien nach /dev/null. MITRE dokumentiert außerdem Varianten, die hohe TCP-Ports verwenden und iptables-Regeln zur Weiterleitung von Paketen einrichten.

Wer nur nach offenen Standardports sucht, kann BPFDoor übersehen. Wer Host, Speicher, Raw Sockets, BPF-Nutzung, Prozessbaum und ausgehenden Verkehr gemeinsam überwacht, ist nicht hilflos.

Ein Magic Packet ist kein universeller Generalschlüssel

In populären Erklärvideos wird gern eine feste Bytefolge gezeigt, die angeblich „die“ Backdoor aktiviert. Das ist anschaulich, aber gefährlich verkürzt. BPFDoor existiert in mehreren Varianten. Protokolle, Magic Values, Passwörter, Shell-Verhalten und Verschleierung können sich unterscheiden. Der 2022 öffentlich gewordene Quellcode erleichterte es weiteren Akteuren, Varianten abzuleiten.

Eine einzelne Signatur kann deshalb einen bekannten Stand erkennen, aber keine ganze Malwarefamilie abschließend ausschließen. Gute Erkennung kombiniert mehrere Ebenen:

bekannte Hashes und YARA-Regeln für Dateien und Speicher;
auffällige Raw Sockets und BPF-Filter;
unerwartete Prozesse mit Namen legitimer Systemdienste;
ungewöhnliche Runtime- oder Lock-Dateien;
neue oder unerklärliche iptables– beziehungsweise nftables-Regeln;
Shell-Verbindungen auf hohen Ports;
ausgehende Verbindungen, die nicht zum Zweck des Servers passen;
Unterschiede zwischen sauberer Referenzinstallation und produktivem Zustand.

Für einen kleinen selbstgehosteten Matrix- oder Nextcloud-Server bedeutet das nicht, jede Nacht eine Geheimdienstoperation zu vermuten. Es bedeutet, Monitoring nicht auf CPU, RAM und „Port 443 antwortet“ zu reduzieren. Ein System kann verfügbar und trotzdem kompromittiert sein.

Warum Telekommunikationsnetze so wertvoll sind

Telekommunikationsnetze verbinden Identität, Standort und Kommunikation. Im Kern liegen Systeme für Teilnehmerverwaltung, Authentifizierung, Roaming, Abrechnung und Signalisierung. Protokolle wie SS7, Diameter und SCTP transportieren Informationen darüber, welcher Teilnehmer sich wo befindet, wie Verbindungen geroutet und wie fremde Netze einbezogen werden.

Wer sich langfristig in einer solchen Umgebung positioniert, erhält nicht automatisch Zugriff auf jedes Gespräch. Er kann aber Kommunikationsmetadaten, Teilnehmerkennungen, Bewegungsereignisse, Authentifizierungsvorgänge und interne Vertrauensbeziehungen ausspähen. Außerdem kann ein kompromittierter Randserver als Sprungbrett in tiefer liegende Netzsegmente dienen.

Rapid7 beschreibt keinen einzelnen spektakulären Einbruch, sondern ein Kampagnenmodell: erste Zugriffe über exponierte VPNs, Firewalls, Router oder Webanwendungen; danach Zugangsdaten sammeln, seitlich weiterbewegen und langfristige Implantate platzieren. Genannt werden unter anderem missbrauchte Konten und Schwachstellen in öffentlich erreichbaren Systemen.

Das ist keine Besonderheit „des unsicheren Linux“. Linux dominiert viele Server- und Infrastruktursegmente gerade wegen seiner Offenheit, Anpassbarkeit und Stabilität. Diese Stärke schützt aber nicht vor schlechten Zugangsdaten, ungepatchten Appliances, mangelhafter Segmentierung oder fehlender Telemetrie. Open Source ermöglicht Prüfung. Sie ersetzt die Prüfung nicht.

China-Zuschreibung: ernst nehmen, aber sauber formulieren

Malpedia verbindet BPFDoor mit dem Akteur Red Menshen. Rapid7 spricht von einem China-nahen Bedrohungsakteur. Das ist eine fachliche Attribution aus Infrastruktur, Werkzeugen, Vorgehensweisen, Zielauswahl und anderen nachrichtendienstlichen Indikatoren.

Eine solche Zuschreibung kann belastbar sein, bleibt aber etwas anderes als ein öffentlich vollständig beweisbares Strafverfahren. Deshalb ist „China hat alle Netze übernommen“ keine seriöse Schlussfolgerung. Belegt sind Kampagnen und technische Indikatoren. Nicht belegt ist, dass praktisch jedes internationale Telekommunikationsnetz infiziert oder grundsätzlich nicht mehr bereinigbar wäre.

Gerade bei staatlicher Spionage ist Präzision kein Weichspüler. Sie verhindert, dass politische Kritik durch Übertreibung angreifbar wird.

Berlin: Der Staat als Verteidiger und Angreifer

Darknight-Coffee hat die geplante Reform des Nachrichtendienstrechts bereits ausführlich analysiert. Der veröffentlichte Beitrag „Der Geheimdienst als Hacker“ behandelt vorgesehene Eingriffe in fremde Systeme, automatisierte Maßnahmen, Attribution und den Umgang mit Zero-Day-Schwachstellen.

BPFDoor liefert dazu den technischen Realitätscheck. Eine Backdoor dieser Klasse lebt davon, dass Angreifer zuerst einen Zugang finden und anschließend unauffällige Persistenz aufbauen. Jede nicht geschlossene Schwachstelle in VPNs, Firewalls, Routern oder Serverdiensten kann Teil dieser Angriffskette werden.

Wenn staatliche Stellen unbekannte Schwachstellen für eigene Zugriffe zurückhalten, bleiben dieselben Lücken auch für fremde Dienste und kriminelle Gruppen offen. Der Staat kann eine Zero-Day-Lücke nicht exklusiv besitzen. Er kann nur hoffen, dass niemand anderes sie findet oder kauft.

Darum braucht Deutschland ein verbindliches und kontrollierbares Schwachstellenmanagement: Offenlegung und Schließen als Regelfall, eng begrenzte Ausnahmen, unabhängige Risikoprüfung, kurze Neubewertungsfristen und nachvollziehbare Verantwortung. Ohne diesen Vorrang wird der Satz „Wir stärken die Cybersicherheit“ politisch hohl.

Brüssel: NIS2 und CRA reichen allein nicht

NIS2 verlangt von wesentlichen und wichtigen Einrichtungen ein systematisches Risikomanagement und Meldeprozesse für erhebliche Sicherheitsvorfälle. Telekommunikation gehört zum Kernbereich kritischer digitaler Infrastruktur. Der Cyber Resilience Act verpflichtet Hersteller von Produkten mit digitalen Elementen schrittweise zu Sicherheitsanforderungen, Schwachstellenmanagement und Meldungen aktiv ausgenutzter Lücken.

Beide Regelwerke setzen richtige Punkte. Betreiber müssen Risiken beherrschen; Hersteller dürfen Sicherheit nicht nach dem Verkauf einstellen. Doch Regulierung kann zur Papiermaschine verkommen. Eine gepflegte Richtlinie, ein ausgefülltes Auditformular und eine fristgerechte Meldung entdecken keinen passiven Implantatprozess im Arbeitsspeicher.

Entscheidend ist die technische Umsetzung:

belastbare Inventare aller Systeme und Abhängigkeiten;
schnelle Patch- und Notfallwege;
Segmentierung zwischen Rand-, Management- und Kernsystemen;
minimal notwendige Rechte und rotierende Zugangsdaten;
zentrale, manipulationsgeschützte Logs;
Egress-Filter und nachvollziehbare Netzwerkflüsse;
Host- und Speicherforensik für Linux;
regelmäßige Wiederherstellungs- und Neuaufbauproben;
unabhängige Red-Team- und Incident-Response-Übungen.

Digitale Souveränität heißt hier nicht, jeden Server selbst zu betreiben. Sie heißt, Systeme, Schlüssel, Protokolle und Wiederherstellung so zu beherrschen, dass ein Betreiber nicht blind vom Hersteller, einem Cloudanbieter oder einer ausländischen Behörde abhängig bleibt.

Was Betreiber konkret tun können

Ein Verdacht auf BPFDoor ist kein Fall für hektisches Löschen einzelner Dateien. Das System muss isoliert werden, ohne forensische Spuren unnötig zu zerstören. Flüchtige Daten wie Prozesse, Netzwerkverbindungen, Raw Sockets, geladene Filter und Speicherinhalte sind besonders wichtig. Danach müssen Zugangsdaten und Schlüssel aus einer sauberen Umgebung rotiert, seitliche Bewegungen geprüft und betroffene Systeme kontrolliert neu aufgebaut werden.

Ein Backup ist dabei notwendig, aber kein Freispruch. Wer ein komplettes kompromittiertes Systemabbild blind zurückspielt, kann die Hintertür gleich mit restaurieren. Wiederhergestellt werden sollten geprüfte Daten in eine saubere, aktualisierte Umgebung. Konfigurationen gehören mit einer bekannten Referenz verglichen.

Für Community-Infrastruktur gilt derselbe Grundsatz im kleineren Maßstab. Nginx-Logs, Synapse-Tokens, Nextcloud-App-Passwörter und Backupschlüssel müssen getrennt gedacht werden. Ein kompromittierter Reverse Proxy darf nicht automatisch Zugriff auf jede Datenbank und jedes Sicherungsziel besitzen.

Fazit: Verteidigung beginnt mit politischer Ehrlichkeit

BPFDoor zeigt, wie leise ein langfristiger Zugriff auf Linux-Infrastruktur sein kann. Die Backdoor braucht keinen auffälligen offenen Port und kein regelmäßiges Lebenszeichen. Sie kann legitime Kernelmechanismen missbrauchen und sich hinter vertraut wirkenden Prozessnamen verbergen.

Das macht Verteidigung anspruchsvoll, aber nicht aussichtslos. Wer nur Verfügbarkeit überwacht, sieht zu wenig. Wer Host, Netzwerk, Identitäten, Segmentierung und Wiederherstellung gemeinsam prüft, kann solche Angriffe erkennen und eindämmen.

Politisch bleibt der Widerspruch: Berlin und Brüssel fordern zu Recht mehr Cybersicherheit. Gleichzeitig will Berlin Nachrichtendiensten offensive Cybermacht und Zugriff auf Schwachstellen ermöglichen. Beides passt nur zusammen, wenn das Schließen von Lücken nachweisbar Vorrang hat.

Ein Staat, der seine digitale Infrastruktur schützen will, darf Sicherheitslücken nicht wie geheime Dietriche sammeln. Denn jede Tür, die für den eigenen Dienst offenbleibt, steht möglicherweise längst auch für einen fremden offen.

Quellen

1. Rapid7 Labs, „BPFdoor in Telecom Networks: Sleeper Cells in the Backbone“: https://www.rapid7.com/blog/post/tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report/ 2. MITRE ATT&CK, BPFDoor S1161: https://attack.mitre.org/software/S1161/ 3. Fraunhofer FKIE Malpedia, elf.bpfdoor: https://malpedia.caad.fkie.fraunhofer.de/details/elf.bpfdoor 4. EU, NIS2-Richtlinie 2022/2555: https://eur-lex.europa.eu/eli/dir/2022/2555/oj 5. EU, Cyber Resilience Act 2024/2847: https://eur-lex.europa.eu/eli/reg/2024/2847/oj 6. Darknight-Coffee, „Der Geheimdienst als Hacker“: https://carrabelloy.darknight-coffee.org/blog/2026/07/26/der-geheimdienst-als-hacker-mehr-cybermacht-verlangt-staerkere-kontrolle/

CTA

Diskussion: https://treff.darknight-coffee.eu Podcast: https://podcast.darknight-coffee.org/@carrabelloy/episodes/die-stille-tur-im-linux-server-bpfdoor-und-der-politische-preis-offener-schwachstellen Blog: https://carrabelloy.darknight-coffee.org/blog/

Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Dein Server kann frei sein – wenn der Browser alle Konten vermischt, bleibt die Kontrolle löchrig

Du kannst deine Domain kontrollieren, freie Software einsetzen, Backups
testen und jeden Zugang zum Server sauber dokumentieren. Trotzdem reicht ein
einziger falscher Browserkontext, um die mühsam aufgebaute Trennung wieder
einzureißen: Das private Konto, das Projektkonto und die
Administrationssitzung liegen nebeneinander, sehen gleich aus und teilen sich
einen unübersichtlichen Arbeitsraum.

Firefox 153 setzt genau dort an. Mozilla hat die Version am 21. Juli 2026 für
den stabilen Release-Kanal veröffentlicht. Erstmals sind Firefox-Container als
eingebaute Vorschau direkt Teil des Browsers. Nutzerinnen und Nutzer können
Kontexte anlegen, mit Namen, Farben und Symbolen markieren und mehrere Konten
derselben Webseite parallel angemeldet halten.

Das ist keine Revolution. Die Technik existiert in Firefox seit Jahren und
war über die Erweiterung Multi-Account Containers zugänglich. Trotzdem ist
die native Integration politisch und praktisch relevant. Sie verschiebt
Sitzungstrennung vom Add-on-Wissen einiger Eingeweihter in die sichtbare
Produktarchitektur.

Der Browser ist keine neutrale Glasscheibe

Im Browser laufen Cookies, Anmeldesitzungen, lokale Webdaten,
Erweiterungsrechte und Zugriffe auf Dienste zusammen. Er ist die
Vermittlungsschicht zwischen Person, Plattform und selbstgehosteter
Infrastruktur.

Das wird im Alltag schnell konkret. Im einen Tab läuft die öffentliche
Blogansicht, im nächsten die Administration. Ein persönliches Mastodon-Konto
steht neben dem Projektkonto. Im Matrix-Webclient wechseln Menschen zwischen
privater Kommunikation und Moderation. Eine saubere .well-known-Datei kann
den Client zum richtigen Homeserver führen. Sie verhindert aber nicht, dass
die falsche Identität im richtigen Dienst aktiv ist.

Wer digitale Souveränität nur am Server misst, sieht deshalb nur die halbe
Kette. Kontrolle braucht nicht nur freien Code und eigene Daten. Sie braucht
auch eine belastbare Grenze zwischen den Rollen, mit denen wir auf diese
Systeme zugreifen.

Was Firefox-Container technisch leisten

Mozilla bezeichnet die zugrunde liegenden Kontexte als „contextual
identities“. Jeder Kontext besitzt einen eigenen Cookie-Speicher und eine
eigene cookieStoreId. Cookies eines Containers werden nicht mit Tabs
anderer Container geteilt. Die offizielle Beschreibung der bisherigen
Erweiterung spricht darüber hinaus von getrenntem Website-Speicher.

Das ermöglicht beispielsweise zwei parallele Anmeldungen bei derselben
Mastodon-Instanz: „Privat“ im blauen Container, „Redaktion“ im roten. Auch
private und moderierende Matrix-Konten können in getrennten Kontexten
desselben Webclients laufen. Die Farbe ist dabei nicht bloß Dekoration. Sie
macht vor einer Handlung sichtbar, welche Rolle gerade aktiv ist.

Container sind damit mehr als Tabgruppen. Eine normale Tabgruppe sortiert
Seiten. Ein Container weist ihnen einen getrennten Sitzungs- und
Speicherkontext zu.

Neu ist das technische Grundmodell trotzdem nicht. Mozilla baut bei der
nativen Vorschau auf einer vorhandenen Firefox-Architektur auf. Der
Fortschritt liegt vor allem in der Zugänglichkeit: Wer Schutz erst in einem
Add-on-Katalog finden muss, nutzt ihn seltener als eine Person, der die
Funktion direkt im Browser angeboten wird.

Total Cookie Protection ist eine andere Schutzschicht

Container werden häufig mit Total Cookie Protection verwechselt. Beide
Mechanismen trennen Zustände, aber sie beantworten verschiedene Fragen.

Total Cookie Protection und das zugrunde liegende State Partitioning
partitionieren Cookies und weitere Zustände nach der besuchten
Top-Level-Webseite. Das soll verhindern, dass ein eingebetteter Drittanbieter
denselben Identifikator über viele Webseiten hinweg liest.

Container sind dagegen bewusst gewählte Nutzungskontexte. Sie beantworten
die Frage, ob dieselbe Webseite meine private, redaktionelle und
administrative Rolle als eine einzige Sitzung behandeln darf.

Kurz gesagt: State Partitioning begrenzt vor allem websiteübergreifendes
Tracking. Container begrenzen vor allem die Vermischung mehrerer Rollen und
Konten. Das eine macht das andere nicht überflüssig.

Firefox 153 zieht noch zwei weitere Grenzen

Die Release Notes nennen neben den nativen Containern zwei Änderungen, die
für Selfhoster wichtig sind.

Erstens müssen Webseiten eine Berechtigung anfragen, bevor sie auf Geräte,
Anwendungen oder Dienste im lokalen Netz zugreifen. Das betrifft einen
realen Vertrauenskonflikt: Im selben Browser sind möglicherweise eine
öffentliche Webseite, der Router, eine NAS-Oberfläche und ein
Administrationsdienst erreichbar. Technische Erreichbarkeit darf nicht mit
pauschalem Vertrauen verwechselt werden.

Zweitens erhalten Erweiterungen nicht mehr automatisch über die allgemeine
Webseitenberechtigung Zugriff auf lokale Dateien. Firefox 153 führt dafür
eine eigene, widerrufbare Berechtigung. Eine Erweiterung, die Webseiten lesen
darf, soll also nicht stillschweigend auch lokale Backup-Exporte,
Konfigurationen oder andere Dateien erreichen.

Keine dieser Grenzen ersetzt eine sauber konfigurierte Firewall, Nginx,
Zugriffskontrolle oder ein getrenntes Administrationsnetz. Aber sie
reduzieren die Annahme, dass alles, was ein Browser technisch erreichen kann,
zum selben Vertrauensraum gehört.

Was Container ausdrücklich nicht leisten

Container sind kein Anonymisierungswerkzeug. Die geprüften Quellen geben
keine Garantie gegen Wiedererkennung über IP-Adresse oder
Browser-Fingerprinting. Auch ein Anbieter kann Konten möglicherweise über
andere Merkmale zusammenführen.

Container isolieren zudem nicht den gesamten Browser. Gemeinsame Chronik,
Downloads, Lesezeichen oder Passwortspeicher werden nicht automatisch zu
vollständig getrennten Welten. Erweiterungen mit weitreichenden Rechten,
Schadsoftware und Bedienfehler bleiben eigene Risiken.

Für besonders kritische Administration sind getrennte Firefox-Profile,
getrennte Betriebssystemkonten, ein dediziertes Gerät oder eine isolierte
Administrationsumgebung die stärkeren Werkzeuge. Wer Root-nahe Änderungen an
einem Server vornimmt, sollte sich nicht von einer roten Tabfarbe in falsche
Sicherheit wiegen lassen.

Auch die Beispiele aus dem Community-Alltag zeigen diese Grenze:

Ein Administrationscontainer trennt die Sitzung zur
Synapse-Verwaltung. Er verhindert keine falsche Raum- oder
Rechteänderung auf dem Server.
Ein Storage-Container trennt die Anmeldung an Nextcloud oder einer
Backup-Oberfläche. Er erzeugt kein Backup und beweist keinen erfolgreichen
Restore.
Ein Redaktionscontainer trennt Mastodon-Konten. Er ersetzt keine Vorschau
und keine Freigabe vor der Veröffentlichung.

Container sind eine nützliche Grenze innerhalb eines Browserprofils. Sie sind
nicht die vollständige Aufteilung der digitalen Arbeit.

Preview heißt: Die Erweiterung nicht vorschnell entfernen

Mozilla schreibt ausdrücklich, dass die eingebaute Vorschau noch nicht alle
Funktionen der bisherigen Multi-Account-Containers-Erweiterung enthält. Die
Erweiterung kann vorerst parallel zur nativen Funktion genutzt werden.
Bestehende Nutzerinnen und Nutzer müssen sie derzeit nicht deinstallieren.

Eine pauschale Empfehlung „Add-on raus, Firefox kann jetzt alles selbst“ wäre
deshalb falsch. Vor einer Migration müssen mindestens automatische
Webseitenzuordnungen, bestehende Regeln, Sync-Verhalten und das Löschen von
Containern geprüft werden.

Auch der Plattformumfang ist offen. Die Ankündigung beschreibt eine
Desktop-Bedienung mit Rechtsklick auf Tabs. Eine gleichwertige native
Oberfläche für Android und iOS ist durch die geprüften Quellen nicht belegt.
Die zugrunde liegende Recherche hat außerdem keinen eigenen Funktionstest
durchgeführt. Sie ordnet offizielle Produktangaben ein, behauptet aber keine
praktische Erfahrung, die nicht stattgefunden hat.

Klar gekennzeichnete Bewertung

Meine Bewertung: Die native Integration ist vor allem deshalb wichtig,
weil sie ein Sicherheitsmodell normalisiert. Menschen arbeiten längst mit
mehreren digitalen Identitäten, aber viele Browseroberflächen tun so, als
gäbe es nur eine einzige durchgehende Personensitzung. Das ist bequem für
Plattformen, die Konten und Verhalten zusammenführen wollen. Für Nutzerinnen,
Redaktionen und Community-Betreiber ist es ein Risiko.

Meine Bewertung: Browserwettbewerb ist daher Infrastrukturpolitik. Es
geht nicht nur darum, welche Engine eine Seite schneller zeichnet. Es geht
darum, ob ein Browser unterschiedliche Rollen sichtbar trennt, welche
Berechtigungen er als selbstverständlich behandelt und wie viel Kontrolle
bei der Person vor dem Bildschirm bleibt.

Firefox und Gecko sind in einer Chromium-dominierten Landschaft nicht
automatisch gut, nur weil sie anders sind. Mozilla muss die Vorschau
vollständig dokumentieren, Funktionsparität liefern, mobile Plattformen und
Barrierefreiheit berücksichtigen und die Funktion langfristig warten. Aber
das Modell der Kontextidentitäten ist ein konkreter Grund, warum eine
unabhängige Browser-Architektur zählt.

Fazit: Der Server ist der Anfang, nicht das Ende

Firefox 153 macht aus Containern eine eingebaute Vorschau und damit eine
sichtbarere Grenze zwischen digitalen Rollen. Die Funktion kann private,
redaktionelle und administrative Sitzungen derselben Webseite voneinander
trennen. Sie ergänzt den Tracking-Schutz, ersetzt ihn aber nicht. Sie hilft
gegen Vermischung, nicht gegen jede Form der Wiedererkennung oder jeden
Bedienfehler.

Der sinnvolle Umgang ist weder Euphorie noch Abwehr. Native Container zuerst
in einem unkritischen Profil testen. Bestehende Add-on-Regeln nicht
vorschnell abbauen. Für Alltagsrollen klare Namen und Farben verwenden. Für
Hochrisiko-Administration stärkere Trennung beibehalten.

Digitale Souveränität beginnt beim eigenen Server – und scheitert, wenn der
Browser davor alle Identitäten wieder in einen Topf wirft.

Quellen

Abruf der Webquellen in der verwendeten Recherche: 26. Juli 2026.

Mozilla Product Details, firefox_versions.json:
https://product-details.mozilla.org/1.0/firefox_versions.json
Mozilla/Firefox, Firefox 153.0 Release Notes:
https://www.firefox.com/en-US/firefox/153.0/releasenotes/
Mozilla Blog, „Experience Better Browsing: Introducing Native Containers
in Firefox 153“, 21. Juli 2026:
https://blog.mozilla.org/en/firefox/firefox-containers-preview/
MDN Web Docs, contextualIdentities:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/contextualIdentities
Mozilla Add-ons, Firefox Multi-Account Containers:
https://addons.mozilla.org/en-US/firefox/addon/multi-account-containers/
MDN Web Docs, „State Partitioning – Privacy on the web“:
https://developer.mozilla.org/en-US/docs/Web/Privacy/Guides/State_Partitioning
Mozilla Security Blog, „Firefox 86 Introduces Total Cookie Protection“,
Februar 2021:
https://blog.mozilla.org/security/2021/02/23/total-cookie-protection/

CTA

Diskussion: https://treff.darknight-coffee.eu/@carrabelloy
Podcast: https://podcast.darknight-coffee.org/pages/startseite
Blog: https://carrabelloy.darknight-coffee.org/blog/

Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Dein Server steht in Europa – aber wer hält die Schlüssel?

Ein Server in Frankfurt, eine europäische Rechnungsadresse und eine EU-Flagge im Produktnamen: So wird Datensouveränität gern verkauft. Doch der Speicherort beantwortet nicht die entscheidenden Fragen. Wer besitzt die Administratorrechte? Welchem Rechtsraum unterliegen Betreiber, Muttergesellschaft und Unterauftragnehmer? Wer kontrolliert Verschlüsselungsschlüssel, Supportzugriffe und Backups? Und lässt sich der Dienst ohne Erlaubnis des bisherigen Anbieters wiederherstellen?

Diese Fragen sind seit dem 8. Juli 2026 Gegenstand einer gezielten Konsultation der Europäischen Kommission. Sie läuft bis zum 8. September 2026, 23:59 Uhr mitteleuropäischer Sommerzeit. Die Kommission fragt nach Datenabhängigkeiten europäischer Organisationen, Hindernissen beim Zugriff auf Daten in Drittstaaten, Schwierigkeiten beim Transfer in die EU und Risiken durch Drittstaatenzugriffe auf sensible Daten.

Das ist noch kein Gesetzgebungsverfahren mit feststehendem Ergebnis. Die Konsultation hat keine veröffentlichten Resultate, und es ist nicht belegt, dass daraus ein neuer Rechtsakt entsteht. Als politischer Anlass ist sie dennoch wertvoll: Sie zwingt Europa, über Kontrolle statt nur über Speicherorte zu reden.

Datenstandort, Rechtsraum und Kontrolle sind drei verschiedene Dinge

Der Standort sagt, wo eine Maschine steht. Der Rechtsraum beschreibt, welchen Regeln Infrastruktur, Unternehmen und Zugriffe unterliegen. Technische Kontrolle entscheidet, wer den Dienst administrieren, Schlüssel ändern, Daten exportieren und einen Wiederanlauf durchführen kann.

Diese Ebenen können auseinanderfallen. Ein Matrix-Homeserver kann in Frankreich laufen, während allein ein externer Dienstleister Zugriff auf Synapse, Datenbank, DNS und /.well-known besitzt. Ein selbstgehosteter Blog kann hinter dem eigenen Nginx stehen, während sein Backup in einem proprietären Objektspeicher von fremder Anmeldung, API und Abrechnung abhängt.

In beiden Fällen ist die Aussage „Daten liegen in Europa“ richtig und trotzdem unvollständig. Der produktive Speicherort ist europäisch, aber entscheidende Kontrollpfade bleiben ausgelagert.

Das bedeutet nicht, dass jeder externe Dienst schlecht ist. Kleine Communities können nicht jede Komponente allein betreiben. Ein seriöser Dienstleister kann stabiler und sicherer sein als ein ungepflegter Einzelserver. Souveränität verlangt nicht, jede Schraube selbst zu drehen. Sie verlangt, Abhängigkeiten zu kennen, sie bewusst zu wählen und sie wechseln zu können.

Was der Data Act bereits verlangt

Die Diskussion beginnt nicht bei null. Die Verordnung (EU) 2023/2854, der Data Act, gilt grundsätzlich seit dem 12. September 2025.

Artikel 28 verpflichtet Anbieter von Datenverarbeitungsdiensten, auf ihren Webseiten aktuell offenzulegen, welcher Jurisdiktion die für den jeweiligen Dienst eingesetzte ICT-Infrastruktur unterliegt. Sie müssen außerdem technische, organisatorische und vertragliche Maßnahmen nennen, mit denen sie internationale staatliche Zugriffe oder Transfers nicht-personenbezogener Daten verhindern wollen, soweit diese mit EU- oder nationalem Recht kollidieren würden. Die Offenlegungsseite muss auch im Vertrag genannt werden.

Artikel 32 verlangt angemessene technische, organisatorische und rechtliche Maßnahmen gegen entsprechende Drittstaatenzugriffe. Entscheidungen von Gerichten oder Behörden eines Drittstaats sind grundsätzlich nur dann anerkennungs- oder vollstreckungsfähig, wenn sie auf einem einschlägigen internationalen Abkommen beruhen. Für Situationen ohne ein solches Abkommen enthält der Artikel weitere Bedingungen.

Diese Vorschriften sind wichtig, aber sie sind kein magischer Schutzschild. Ihre praktische Wirkung hängt davon ab, ob Offenlegungen verständlich, vollständig und überprüfbar sind. Aus den allgemeinen Regeln lässt sich zudem nicht pauschal beurteilen, wie eine konkrete ausländische Anordnung, Konzernstruktur oder Cloud-Architektur rechtlich zu behandeln ist. Dafür wäre eine juristische Einzelfallprüfung nötig.

Schlüssel und Tokens sind keine Nebensache

Im Serveralltag wird aus dem abstrakten Wort Kontrolle schnell eine Liste konkreter Zugänge. Ein Synapse-Admin-Token kann weitreichende Eingriffe ermöglichen. Der DNS-Zugang bestimmt, wohin eine Domain zeigt. Ein Schlüssel entscheidet, ob ein verschlüsseltes Backup lesbar ist. Recovery-Codes entscheiden, ob eine Verwaltung nach Geräteverlust noch erreichbar ist.

Ein europäischer Matrix-Server bleibt abhängig, wenn ein früherer Betreiber noch einen gültigen Admin-Token besitzt. Eine Community bleibt handlungsunfähig, wenn nur eine Person den zweiten Faktor zum DNS-Konto kontrolliert. Ein Backup bleibt wertlos, wenn sein Schlüssel ausschließlich auf dem ausgefallenen Produktivsystem liegt.

Das Gegenmittel ist nicht die Veröffentlichung vertraulicher Details. Tokens, private Schlüssel und interne Adressen gehören nicht in öffentliche Prüfberichte. Nötig sind dokumentierte Rollen, geregelte Rotation, geschützte Notfallzugänge und eine Übergabe, die im Ausfall nicht an einem einzigen Menschen scheitert.

Redaktionelle Bewertung: Wer Schlüssel, Administratorrollen und DNS nicht kontrolliert, besitzt keine belastbare Kontrolle über den Dienst. Der Serverstandort kann dieses Defizit nicht ausgleichen.

Ein Datenexport ist noch keine Portabilität

Ein Anbieterwechsel scheitert oft nicht am Fehlen eines Exportknopfs, sondern an der Unvollständigkeit des Exports. Eine Datenbank oder ZIP-Datei enthält vielleicht Inhalte, aber nicht automatisch Identitäten, Rollen, Medien, Weiterleitungen, Konfigurationen, Schlüssel und Versionsinformationen.

Bei Matrix reicht eine Sammlung von Nachrichten und Medien nicht, wenn Raumstruktur, Berechtigungen und Identitäten nicht wiederhergestellt werden können. Bei einem Blog hilft der Datenbankdump nur teilweise, wenn Upload-Verzeichnis, Nginx-Regeln, Redirects und passende Anwendungsversion fehlen.

Zur Portabilität gehören auch Kosten und Fristen. Ein technisch möglicher Export, der durch hohe Ausleitungsgebühren oder wochenlange Wartezeit blockiert ist, taugt nicht als Notausgang. Verträge sollten deshalb festlegen:

welche Daten und Konfigurationen exportiert werden;
in welchen offenen oder dokumentierten Formaten der Export erfolgt;
welche Kosten und Fristen gelten;
ob Schlüssel und Rollen übergeben werden können;
welche Unterstützung für den Exit geschuldet ist.

Die European Data Union Strategy spricht dabei ausdrücklich nicht für vollständige Datenautarkie. Sie verbindet Souveränität mit grenzüberschreitendem Austausch unter fairen, sicheren und mit europäischen Werten vereinbaren Bedingungen. Das ist der richtige Ausgangspunkt. Freier Datenfluss ist nicht automatisch Abhängigkeit, und Abschottung ist nicht automatisch Kontrolle.

Der Restore-Test ist der harte Nachweis

Ein vorhandenes Backup beweist zunächst nur, dass Dateien oder Dumps erzeugt wurden. Ob daraus wieder ein funktionsfähiger Dienst entsteht, zeigt erst ein Restore-Test.

Bei einem Matrix-Homeserver müssen Datenbank, Medien, Signierschlüssel, Konfiguration und Versionsstand zusammenpassen. Bei einer Webanwendung kommen Nginx, TLS-Konfiguration, Anwendungscode, Datenbank, Uploads und Secrets hinzu. Liegt ein Teil nur auf dem Produktivserver oder ist das Backup-Passwort nicht unabhängig erreichbar, bricht die Wiederherstellung genau im Störfall.

Ein Restore-Test kann in einer isolierten Umgebung stattfinden. Er sollte dokumentieren, welche Sicherung verwendet wurde, wie lange der Wiederanlauf dauerte, welche Abweichungen auftraten und welche Nutzerwege anschließend funktionierten. Ein erfolgreich erzeugter Dump und eine Prüfsumme reichen nicht: Sie zeigen weder, dass die Schlüssel passen, noch dass Login, Medien, Mail oder Föderation wieder funktionieren.

Redaktionelle Bewertung: Öffentliche Stellen und Unternehmen sollten Souveränität nicht nur mit Erklärungen oder Zertifikaten beschaffen. Ein technischer Anbieterwechsel oder Wiederanlauf muss Teil der Abnahme sein – abgestuft nach Schutzbedarf.

Open Source ist ein Werkzeug, kein Freifahrtschein

Die EU-Open-Source-Strategie vom Juni 2026 stellt offene Alternativen in den Mittelpunkt technologischer Souveränität. Sie nennt Open-Source-freundliche Beschaffung, öffentliche Verwaltungen als Ankernutzer, langfristige Wartung, Abhängigkeitsanalyse sowie Spiegel- und Fork-Fähigkeit. Zugleich benennt sie begrenzte Langzeitfinanzierung, Wartungsprobleme, geringe Sichtbarkeit und Beschaffungshürden.

Damit beschreibt die Kommission selbst die Grenze des Arguments. Offener Code kann Prüfung, Eigenbetrieb und Wechsel ermöglichen. Er finanziert aber keine Maintainer, ersetzt keine Dokumentation und garantiert keinen Restore.

Eine Community kann Synapse als offene Software betreiben und trotzdem bei Container-Registry, Monitoring, Mailversand oder Anmeldung von proprietären Diensten abhängen. Eine Behörde kann den Quellcode einer Anwendung besitzen, aber ohne reproduzierbaren Build, gepflegte Pakete und Betriebskompetenz keinen brauchbaren Fork aufsetzen.

Die angekündigte Idee eines Open Source Maintenance Instrument ist deshalb relevant. Offen sind derzeit noch konkrete Fragen zu Budget, Start, Auswahl und Dauer. Erst deren Umsetzung wird zeigen, ob aus der politischen Anerkennung verlässliche Wartungsfinanzierung entsteht.

Das Gegenargument: Souveränität kann teuer und abschottend werden

Strengere Anforderungen verursachen Aufwand. Zusätzliche Dokumentation, unabhängige Backups, Exit-Unterstützung und Restore-Tests kosten Geld. Eine pauschale Pflicht, alle Daten innerhalb der EU zu halten, könnte globale Zusammenarbeit erschweren und kleine Anbieter benachteiligen, ohne Adminrechte oder Schlüsselkontrolle zu verbessern.

Dieses Gegenargument ist berechtigt. Die Antwort sind risikogerechte Anforderungen statt einer digitalen Festung. Ein öffentlicher Veranstaltungskalender braucht nicht denselben Schutz wie Gesundheitsdaten, Verwaltungsvorgänge oder kritische Infrastruktur. Transparente Jurisdiktion, dokumentierte Unterauftragnehmer, offene Schnittstellen und ein verständlicher Export sollten dennoch zur Grundausstattung gehören.

Bewertung: Souveränität ist kontrollierte Handlungsfähigkeit

Meine Bewertung für diesen Beitrag: Europa braucht keine Datenautarkie. Es braucht die nachgewiesene Fähigkeit, Daten auszutauschen, ohne Weiterbetrieb und Regelsetzung an einen einzelnen undurchsichtigen Anbieter abzugeben.

Daraus folgen sechs brauchbare Prüfsteine:

Jurisdiktionen von Betreiber, Konzern, Infrastruktur und Unterauftragnehmern offenlegen.
Administratorrechte, Schlüssel, Logs und Supportzugriffe nachvollziehbar regeln.
Daten, Identitäten und Konfigurationen vollständig exportierbar machen.
Formate, Kosten, Fristen und Exit-Unterstützung vertraglich festhalten.
Backups unabhängig aufbewahren und den Wiederanlauf nachweisbar testen.
Kritische Open-Source-Komponenten langfristig warten und finanzieren.

Diese Punkte lösen nicht jeden Konflikt zwischen Datenschutz, internationalem Handel, Sicherheit und Innovation. Sie machen aber aus einem politischen Schlagwort eine überprüfbare Eigenschaft.

Fazit

Die EU-Konsultation stellt die richtige Grundfrage: Wo hängen europäische Organisationen von Datenzugängen und Kontrollpfaden außerhalb ihrer eigenen Reichweite ab? Eine belastbare Antwort darf sich nicht auf den Ort des Rechenzentrums beschränken.

Datensouveränität beginnt dort, wo Rechtsräume sichtbar, Zugriffe begrenzt, Schlüssel kontrolliert und vollständige Exporte möglich sind. Sie wird glaubwürdig, wenn ein Betreiber den Dienst unabhängig wiederherstellen kann. Open Source stärkt diesen Weg, sofern Wartung, Build-Kette und Wissen tatsächlich getragen werden.

Der Satz „Unsere Daten liegen in Europa“ ist deshalb kein Abschluss. Er ist der Beginn der Prüfung.

Quellen

Europäische Kommission, „Targeted consultation on safeguarding the EU’s data sovereignty“, 8. Juli 2026:
https://digital-strategy.ec.europa.eu/en/consultations/targeted-consultation-safeguarding-eus-data-sovereignty
Europäische Kommission, EUSurvey zur Konsultation:
https://ec.europa.eu/eusurvey/runner/a921658b-7f28-11c5-d062-3db457c213fa
Europäische Kommission, „European Data Union Strategy“, November 2025:
https://digital-strategy.ec.europa.eu/en/policies/data-union
EUR-Lex, Verordnung (EU) 2023/2854 – Data Act, insbesondere Artikel 28, 32 und 50:
https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng
Europäische Kommission, „The EU Open Source Strategy“, Juni 2026:
https://digital-strategy.ec.europa.eu/en/policies/open-source-strategy
Europäische Kommission, „Strengthening Europe’s Tech Sovereignty“:
https://digital-strategy.ec.europa.eu/en/policies/eu-tech-sovereignty
Europäische Kommission, COM(2026) 503:
https://digital-strategy.ec.europa.eu/en/library/communication-european-tech-sovereignty-accompanied-eu-open-source-strategy

CTA

Wer hält bei euren Diensten die Schlüssel, und wie sieht euer getesteter Rückweg aus? Diskussion:
https://treff.darknight-coffee.eu/@carrabelloy

Podcast:
https://podcast.darknight-coffee.org/pages/startseite

Blog:
https://carrabelloy.darknight-coffee.org/blog/

Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Was bei Hetzner, DNS und YunoHost wirklich passiert ist

In den letzten Tagen hatte ich massive Probleme mit meinem YunoHost-Server bei Hetzner.
Das Admin-Panel war teilweise erreichbar, teilweise nicht. Zertifikate liefen aus, Firefox blockierte Zugriffe wegen HSTS, und Dienste wie Mastodon, WordPress, Matrix, Diaspora,Screensa verhielten sich instabil oder sehr träge. Oder waren nicht aufrufbar. Wie E-Mail-Verkehr.

Das Entscheidende vorweg:
Das Problem lag nicht bei YunHost, nicht bei Firefox und nicht bei meinem Server.
Die Ursache ist die laufende DNS-Migration bei Hetzner.

1. Die Ausgangslage

Mein Setup:

Hetzner VPS

YunHost

mehrere Domains (example.org, .eu, Subdomains wie srv, cloud, netz, treff, mastodon ,wp,dia,)

automatische Let’s-Encrypt-Zertifikate

DNS bisher über die alte Hetzner DNS-Konsole

Hetzner hat angekündigt:

Die alte DNS-Konsole (dns.hetzner.com) wird abgeschaltet.
Bestehende Zonen müssen in die neue Hetzner Console migriert werden.

👉 Klingt harmlos – ist es aber nicht, wenn man Server betreibt.

2. Das sichtbare Problem (Symptome)

Folgende Dinge traten gleichzeitig auf:

Firefox zeigt bei https://example.org/yunhost/sso: dns dmg

HSTS-Fehler

keine Möglichkeit, eine Ausnahme hinzuzufügen

Server YunHost meldet:

„DNS records are different to this server’s IP“

Zertifikate lassen sich nicht erneuern

Mastodon:

Föderation instabil

Verbindungsprobleme

dig zeigt:

intern: 1000.0.0.1

extern: andere IPs als erwartet

👉 Klassisches Zeichen für inkonsistente DNS-Quellen.

3. Warum das so kritisch ist (HSTS erklärt)

example.org nutzt HTTP Strict Transport Security (HSTS).

Das bedeutet:

Browser dürfen nur HTTPS

abgelaufene oder falsche Zertifikate = kompletter Zugriff gesperrt

kein „Ich vertraue trotzdem“-Button

💡 Das ist kein Bug – das ist Sicherheit.

Wenn DNS → falsche IP
dann Zertifikat → falsch
dann Browser → blockiert

Kette geschlossen. Ende.

4. Der entscheidende Hinweis: Zwei DNS-Welten gleichzeitig

Was wirklich passiert ist:

Alte Hetzner DNS-Konsole existiert noch

Neue Hetzner Console existiert schon

Domains sind teilweise migriert

Teilweise zeigen Records noch auf alte IPs

Teilweise schon auf neue IPs

Ergebnis:

Je nach Resolver (Server intern, Cloudflare, ISP, Browser)
bekommst du unterschiedliche Antworten.

Das ist der Worst Case für:

Zertifikate

Mail

Föderation (Mastodon und weitere Anwendungen)

Admin-Portale

5. Warum Hetzner-Support mir nicht helfen konnte

Ich habe:

ein Ticket eröffnet

telefonisch nachgefragt

Antwort (ehrlich & wichtig):

Der aktuelle Telefonsupport ist nur für Hardware & Rechenzentrum zuständig.
DNS-Migration = anderes Team.
Konkrete Hilfe zur neuen DNS-Console: aktuell kaum möglich.

👉 Das ist keine böse Absicht – die Migration läuft noch.

6. Warum der „Workaround“ keine Lösung ist

Ja, man kann:
yunhost domain cert renew DOMAIN –no-checks

Das funktioniert kurzfristig.

❌ Aber:

DNS bleibt falsch

Zertifikate brechen beim nächsten Renew

Mail bleibt fehleranfällig

Mastodon und weitere Programme bleiben instabil.

Das ist Flickschusterei – keine Lösung.

7. Die saubere Lösung (kein Workaround) ✅
Schritt 1: Eine einzige DNS-Quelle

👉 Entscheiden:

Entweder neue Hetzner Console

oder externer DNS (z. B. deSEC, Cloudflare)

❌ Nicht beides gleichzeitig

Da bei mir Cloudflare genauso vorhanden ist, bin ich erst spät darauf gekommen.

Schritt 2: Alle A / AAAA Records korrekt setzen

Für jede Domain & Subdomain:

A → 1000.200.100.10

AAAA → 2e001:4a9:122:39001::3

Keine alten IPs mehr (987.201.222.100, …259d::3).

Schritt 3: Wildcards & Mail sauber nachziehen

* A / AAAA setzen

MX setzen

SPF / DKIM / DMARC aktualisieren

CAA für Let’s Encrypt setzen

(YunHost sagt dir exakt, was fehlt – das ist Gold wert.)

Schritt 4: Warten (leider ja)

DNS braucht:

Minuten bis Stunden

manchmal 24–48 Stunden

Erst danach:

Zertifikate erneuern

Dienste testen

Mastodon stabilisieren

8. Warum jetzt plötzlich wieder manches geht

Du hast es selbst beobachtet:

Zertifikat für example.org geht wieder

Admin-Panel über ddd.example.org funktioniert

Probleme treten nur über das Portal / SSO auf

👉 Das bestätigt:
DNS-Inkonsistenz, nicht Serverfehler.
Per Terminal kommt man weiter partiell

9. Fazit

Das hier ist wichtig – für alle mit Servern:

DNS-Migrationen sind kein Detail.
Sie sind kritisch für alles darüber.

YunoHost funktioniert korrekt.
Firefox reagiert korrekt.
HSTS schützt korrekt.

Nur DNS muss einmal sauber, vollständig und einheitlich gemacht werden.
Und danach sollte Ihr Server wieder sauber laufen.