Sicherheit

Sicherheit

Wie Emona MFT und der jFiltra-Kern Ihre Dateien schützen – und wo ihre technischen Grenzen liegen.

Vom BLUEGEM-Team · Aktualisiert am 4. November 2026

Im jFiltra-Kern enthalten

• Selbst gehostet. Dateien gehen von Ihren Clients an Ihren eigenen Server. Nichts wird an BLUEGEM oder einen Cloud-Dienst gesendet.
• Integritätsprüfung. Jede Datei erhält einen SHA-256-Hash; der Server prüft ihn nach der Entschlüsselung, und der Client löscht das Original oder verschiebt es nach sent/ erst nach einer bestätigten, geprüften Zustellung.
• Komprimierung und Inhaltsverschlüsselung. Dateiinhalte werden mit GZIP komprimiert und mit einem für jeden Client eindeutigen Schlüssel AES-verschlüsselt.
• Trennung pro Client. Der Server speichert die Dateien jedes Clients in dessen eigenem Verzeichnis. Er weist unbekannte Client-Labels und jeden Dateinamen mit Pfadangabe (etwa ../) ab, sodass ein Client nicht außerhalb seines Verzeichnisses schreiben kann.
• Verbindungslimits. Header- und Transfer-Timeouts, ein Verbindungslimit pro IP und eine maximale Dateigröße verhindern, dass eine einzelne Verbindung den Server blockiert.
• Datenbankzeilen, sicher. Seit jFiltra 1.1 sendet ein separater DB-Client das Ergebnis einer SQL-Abfrage als CSV-, TSV- oder JSON-Lines-Datei und führt Ihr SQL nach der Übertragung erst aus, wenn der Server die Datei bestätigt hat; bei jedem Fehler wird die Transaktion zurückgerollt. Passwörter in JDBC-URLs und Fehlermeldungen werden in den Logs maskiert.
• Läuft fast überall. Java 8 oder neuer (jeder OpenJDK-Build, getestet mit 8, 11, 17, 21 und 25) unter Linux, macOS oder Windows, mit Apache Log4j 2 als einziger Abhängigkeit.
• Quellcode, den Sie prüfen können. Der Kern ist auf GitHub source-available unter PolyForm Noncommercial 1.0.0, sodass Sie genau nachvollziehen können, was er tut.

Nicht im jFiltra-Kern enthalten

• Die Verbindung ist nicht mit TLS verschlüsselt, daher gehen Client-Labels, Dateinamen, Größen und Hashes im Klartext über das Netz. jFiltra verzichtet bewusst darauf, um einfach zu bleiben.
• Dateiinhalte nutzen AES im ECB-Modus, keine authentifizierte Verschlüsselung, und die Schlüssel werden aus einer Passphrase ohne langsame, gesalzene Schlüsselableitungsfunktion abgeleitet.
• Clients werden nicht mit Zertifikaten authentifiziert, und es gibt keinen Schutz gegen wiederholt eingespielte Übertragungen.

Empfehlung: Betreiben Sie den jFiltra-Kern nur in einem vertrauenswürdigen Netz, einem VPN oder einem SSH-Tunnel (wie das geht, zeigt die README von jFiltra), und machen Sie seinen Port nicht aus dem Internet erreichbar.

Ergänzt in Emona MFT: Protokolle 2 und 3

• Gegenseitige Authentifizierung. Client und Server weisen nach, dass sie den Schlüssel des Clients kennen, bevor Dateidaten gesendet werden; der Client löscht eine Datei erst nach einer Antwort, die nur der echte Server erzeugen kann.
• Authentifizierte Verschlüsselung. Dateinamen und Inhalte werden mit AES-256-GCM in nummerierten 64-KB-Blöcken verschlüsselt, sodass Änderungen, Umsortierung und Abschneiden erkannt werden.
• Replay-Schutz. Frische Sitzungsschlüssel für jede Verbindung (HKDF-SHA256 über zufällige Nonces), sodass eine aufgezeichnete Übertragung nicht erneut gesendet werden kann.
• Standardmäßig Protokoll 2. Neue Installationen nutzen Protokoll 2. Das ursprüngliche Protokoll 1 wird abgelehnt, sofern es nicht ausdrücklich erlaubt ist. Eine Abweichung wird abgelehnt, dem Client gemeldet und protokolliert. Im Netz ist nur das Client-Label sichtbar.
• Protokoll 3: hybrider Post-Quanten-Schlüsselaustausch. Optional seit 1.7.0. Jede Verbindung fügt einen neuen X25519- und ML-KEM-768-Schlüsselaustausch (NIST FIPS 203) hinzu, gebunden an einen Hash des gesamten Handshakes. Die Sitzungsschlüssel benötigen den Schlüssel des Clients und beide ausgetauschten Geheimnisse, und die privaten Schlüssel des Austauschs existieren nur im Arbeitsspeicher, sodass aufgezeichneter Verkehr später selbst mit dem Schlüssel des Clients nicht entschlüsselt werden kann (Forward Secrecy).
• Kein Downgrade. Ein Server kann die Protokolle 2 und 3 gleichzeitig annehmen, sodass Clients einzeln umsteigen, aber ein auf Protokoll 3 eingestellter Client fällt nie auf Protokoll 2 zurück, sodass ein Angreifer im Netz kein schwächeres Protokoll erzwingen kann.
• Schlüsselwechsel ohne Ausfallzeit. Während eines Schlüsselwechsels akzeptiert der Server den neuen und den bisherigen Schlüssel eines Clients, liest seine Schlüsseldatei ohne Neustart neu ein, protokolliert, welchen Schlüssel jede Verbindung verwendet hat, und meldet Clients, die noch den alten Schlüssel nutzen.

Emona MFT verwendet für Übertragungen kein TLS. Mit den Protokollen 2 und 3 sieht ein Beobachter weiterhin Client-Labels, ungefähre Dateigrößen und Zeitpunkte; ein VPN oder SSH-Tunnel verbirgt auch diese. Wer den Schlüssel eines Clients kennt, kann als dieser Client Dateien senden; schützen Sie daher die Schlüssel. Ein Handshake mit Protokoll 3 kostet den Server mehr CPU als Protokoll 2 (etwa das 1,4-Fache in einem Test mit einer Flut von Verbindungen); behalten Sie daher die Verbindungslimits und eine Firewall-Regel für den Port bei. Symbolische Links werden nie gesendet, und Dateigrößenlimits sind in jFiltra und Emona MFT konfigurierbar.

Der Server hält außerdem auf jedem Speicherdatenträger einen konfigurierbaren freien Speicherplatz frei (min.free.space.mb) und lehnt Dateien, die ihn füllen würden, mit Insufficient storage ab, sodass ein voller Datenträger weder andere Clients aufhalten noch gespeicherte Dateien beschädigen kann.

Gespeicherte Dateien

• Optionale Verschlüsselung im Ruhezustand. Der Server kann die Dateien einiger oder aller Clients mit AES-256-GCM verschlüsselt speichern. Jede Datei erhält einen eigenen Zufallsschlüssel, der mit einem Master-Schlüssel umhüllt wird; geänderte Bytes, abgeschnittene Dateien, verschobene oder vertauschte Blöcke, umbenannte Dateien und falsche Schlüssel werden erkannt. Standardmäßig ist sie ausgeschaltet, weil Programme, die die Dateien abholen, sie zuerst entschlüsseln müssen – mit dem mitgelieferten Werkzeug emonamft-decrypt oder einer Java-API.
• Wechsel des Master-Schlüssels. Ein neuer Master-Schlüssel wird ohne Neustart übernommen, und ältere Dateien können neu umhüllt werden, ohne ihre Daten zu entschlüsseln.
• Aufbewahrung. Empfangene Dateien eines Clients können nach einer festgelegten Anzahl von Tagen automatisch gelöscht werden, mit einem Probelauf, der nur meldet, was gelöscht würde. Jede Löschung wird als Ereignis protokolliert.
• Berechtigungen. Dateien mit Schlüsseln, Passwörtern oder personenbezogenen Daten, die Emona MFT schreibt, werden nur für den Eigentümer angelegt, Logs nur für Eigentümer und Gruppe, und empfangene Dateien können eingeschränkte Berechtigungen erhalten. Schlüsseldateien, die andere Benutzer lesen können, werden beim Start gemeldet.

Die Verschlüsselung im Ruhezustand verbirgt nicht die Größe einer Datei, und das Ereignisprotokoll enthält Größe und SHA-256 des Klartexts; schützen Sie das Ereignisprotokoll daher wie die Dateien. Sichern Sie die Master-Schlüsseldatei separat: Ohne sie kann niemand die Dateien entschlüsseln, auch BLUEGEM nicht. Eine Festplattenverschlüsselung des Betriebssystems bleibt für gestohlene Datenträger und Backups sinnvoll.

Logs und Überwachung

• Manipulationserkennende Logs. Ereignisprotokolle von Servern und Clients sowie Audit-Log und Vorfallregister des Dashboards sind hashverkettet und werden in regelmäßigen Abständen versiegelt. Sie werden stündlich geprüft, und eine unterbrochene Kette löst einen kritischen Alarm aus.
• SIEM-Weiterleitung. Jede Ereignis- und Audit-Zeile kann als RFC-5424-Syslog über UDP, TCP oder TLS an Ihr SIEM oder Ihren Log-Server gesendet werden, direkt von Servern und Clients oder vom Dashboard. Während eines Ausfalls geschriebene Zeilen werden danach gesendet.
• Prüfung gegen die Kopie. Eine Prüfung auf der Kommandozeile vergleicht die Dateien mit der SIEM-Kopie und zeigt geänderte, hinzugefügte oder entfernte Zeilen, auch am Ende einer Datei.
• Personenbezogene Daten. Dateinamen können als HMAC-SHA256-Hashes mit Schlüssel in das Ereignisprotokoll geschrieben werden (Pseudonymisierung). Schlüssel und Dateiinhalte werden nie protokolliert; stattdessen werden Schlüssel-Fingerabdrücke protokolliert.

Manipulationserkennend bedeutet, dass Änderungen erkannt werden, zuverlässig beim Vergleich der Dateien mit einer anderswo aufbewahrten Kopie; es hindert niemanden mit Schreibzugriff daran, die Dateien zu ändern. Bewahren Sie die SIEM-Kopie dort auf, wo die Betreiber des Servers sie nicht erreichen.

Dashboard

Jede Emona-MFT-Installation enthält mindestens eine Instanz des Web-Dashboards, und alle lizenzierten Emona-MFT-Server verbinden sich damit. Server und Clients senden ihm Ereignisse über eine eigene AES-256-GCM-Verbindung mit einem Schlüssel pro Agent; das Dashboard sendet ihnen nie Befehle. Die Anmeldung unterstützt Zwei-Faktor-Authentifizierung (TOTP) und Single Sign-on mit OpenID Connect, Anmeldungen werden pro Benutzer und Adresse gesperrt, jede Anmeldung und Änderung landet in einem hashverketteten Audit-Log, und die Weboberfläche lauscht nur auf 127.0.0.1, sofern Sie nichts anderes konfigurieren. Details und Grenzen auf der Dashboard-Seite.

Releases und Lieferkette

• Signierte Releases. Jedes Release hat eine SHA256SUMS-Datei, offline signiert mit ML-DSA-65 (FIPS 204, Post-Quanten) und ECDSA P-256. Die privaten Schlüssel liegen nie auf GitHub; die Fingerabdrücke der öffentlichen Schlüssel stehen in der Datei SECURITY.md jedes Releases.
• SBOM. Jedes Release enthält eine CycloneDX-Softwarestückliste mit Version, Lizenz und SHA-256 jeder Komponente.
• Zwei Bibliotheken, fest gepinnt. Emona MFT nutzt nur Apache Log4j 2 und, für Protokoll 3, Bouncy Castle. Ihre Versionen und Hashes sind fest vorgegeben und werden wöchentlich gegen Maven Central geprüft.
• Bei jeder Änderung geprüft. Statische Analyse mit CodeQL, Dependabot sowie Smoke-Tests der Protokolle 1, 2 und 3 und des Dashboards unter Java 8, 11, 17, 21 und 25.

Sicherheitsprobleme melden

Wenn Sie ein Sicherheitsproblem in Emona MFT, jFiltra oder auf dieser Website finden, melden Sie es bitte vertraulich statt in einem öffentlichen Issue: per E-Mail an rumanko@bluegem.sk mit einem Betreff, der mit [Emona MFT security] beginnt, oder über bluegem.sk. Für Emona MFT bestätigen wir eine Meldung innerhalb von 3 Werktagen und geben innerhalb von 10 Werktagen eine erste Einschätzung. Kritische und schwerwiegende Probleme werden innerhalb von 30 Tagen nach der Bestätigung behoben, bei aktiver Ausnutzung früher. Den Veröffentlichungstermin stimmen wir mit Ihnen ab und nennen Sie, sofern Sie nicht anonym bleiben möchten.

Diese Website

emonamft.com ist eine statische Website mit einer strikten Content Security Policy und ohne Schriftarten von Drittanbietern. Google Analytics ist das einzige Skript eines Drittanbieters und wird erst geladen, wenn Sie Analyse-Cookies akzeptieren. Bestellungen werden in eine Datei auf unserem eigenen Server geschrieben und per E-Mail an BLUEGEM gesendet; siehe Datenschutzerklärung.