Auch unter Windows kann man die gewohnten Linux-Befehle nutzen, um entfernte Rechner zu verbinden und darauf zu arbeiten. Dafür sorgen Werkzeugkästen wie MobaXterm.

Quelle

Dies ist der Folgeartikel, den ich in der Einführung in das Advanced Intrusion Detection Environment (AIDE) versprochen hatte. Es handelt sich hierbei um einen Proof of Concept (PoC), der zeigt, wie AIDE mithilfe einer Ansible-Rolle ferngesteuert werden kann. Die Einführung wird als bekannt vorausgesetzt.

Grundlegende Ansible-Kenntnisse, wie die Verwendung von Ansible-Rollen und das Ausführen von Playbooks werden ebenfalls als bekannt vorausgesetzt. Wer Ansible nicht kennt, sei an die offizielle Dokumentation verwiesen.

Welche Aufgaben sind mit Ansible zu lösen?

• Das Paket aide ist auf den Zielsystemen installiert
• Die optionale Generierung und Verteilung der Konfigurationsdatei aide.conf
• Die Initialisierung der AIDE-Datenbank
• Zentrale Speicherung der AIDE-Datenbanken aller verwalteter Hosts auf dem Ansible Control Node (ACN)
• Durchführung von Integritäts-Checks
• Aktualisierung der AIDE-Datenbanken und erneute Speicherung auf dem ACN

Durch die Speicherung der AIDE-Datenbanken und -Konfigurationsdateien auf dem ACN sind diese gegen Veränderung auf einem kompromittierten Host geschützt. Gegen Veränderungen auf dem ACN selbst sind die Dateien nur mit Unix-Dateiberechtigungen geschützt. Doch wenn der ACN kompromittiert ist, hat man eh ein ganz anderes Problem, als sich um AIDE Sorgen zu machen.

Labor-Umgebung

Meine Labor-Umgebung für diesen PoC besteht aus den vier Hosts:

• ansible-ctrl (RHEL 8 mit installiertem ansible-core)
• rhel7
• rhel8
• rhel9

Der ACN kann sich via SSH zu den Zielsystemen (rhel{7,8,9}) verbinden und dort Programmcode mit erhöhten Rechten ausführen.

Die von mir für diesen PoC entwickelte Ansible-Rolle gibt es unter der URL: https://github.com/Tronde/aide

Beschreibung der Ansible-Rolle aide

Die Rolle ist nicht idempotent. Sie ruft das Programm aide auf den Zielsystemen mit verschiedenen Optionen auf und verarbeitet deren Ausgabe. Dazu macht die Rolle Gebrauch des Moduls ansible.builtin.command.

Gesteuert wird die Rolle über Ansible-Tags. Wird die Rolle in einem Playbook ohne Angabe von Tags ausgeführt, werden keinerlei Veränderungen an den Zielsystemen vorgenommen.

Der folgende Code-Block zeigt ein Beispiel-Playbook zum Aufruf der Rolle. Die Tags und die Variable aide_db_fetch_dir werden im Anschluss erläutert.

# SPDX-License-Identifier: MIT
---
- name: Example aide role invocation
  hosts: targets
  tasks:
    - name: Include role aide
      tags:
        - install
        - generate_config
        - init
        - check
        - update
      vars:
        aide_db_fetch_dir: files
      ansible.builtin.include_role:
        name: aide

• install – Bei Angabe dieses Tags stellt die Rolle sicher, dass das Paket aide auf den Zielsystemen installiert ist
• generate_config – Generiert die Datei /etc/aide.conf unter Nutzung von templates/aide.conf.j2; das Template ist an die individuellen Bedürfnisse anzupassen; Details siehe nächster Abschnitt
• init – Hiermit wird die AIDE-Datenbank initialisiert, welche als Referenzdatenbank für zukünftige Checks dient
• check – Führt einen Integritäts-Check unter Verwendung der Referenzdatenbank durch
• update – Führt einen Integritäts-Check durch und erzeugt eine neue AIDE-Datenbank, welche zukünftig als Referenz dient

Die Variable aide_db_fetch_dir erwartet im Auslieferungszustand das Verzeichnis files parallel zum Playbook. In diesem Verzeichnis werden Unterverzeichnisse für jeden Host erstellt, in denen die AIDE-Datenbank der verwalteten Systeme gespeichert wird. Soll ein anderer Speicherort verwendet werden, ist der Wert dieser Variablen entsprechend anzupassen. Die AIDE-Datenbanken werden mit dem Ansible-Module ansible.builtin.fetch von den verwalteten Systemen geholt.

Nutzung für die verschiedenen Anwendungsfälle

In diesem Abschnitt beschreibe ich die fünf Anwendungsfälle für den PoC. Alle Anwendungsfälle wurden gegen RHEL 7, RHEL 8 und RHEL 9 getestet. Für diesen Blog beschränke ich mich jedoch auf Tests gegen RHEL 9, um die Übersichtlichkeit der Ausgaben zu verbessern.

Es wird stets das Playbook aus dem Abschnitt Beschreibung der Ansible-Rolle aide verwendet und mit unterschiedlichen Tags ausgeführt.

Anwendungsfall 1: Installation von AIDE

Um AIDE nutzen zu können, muss es zuerst installiert sein. Dies wird mit folgendem Playbook-Aufruf festgestellt:

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags install

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Ensure required packages are installed] ***************************
changed: [rhel9]

PLAY RECAP *********************************************************************
rhel9                      : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Für diesen Anwendungsfall arbeitet die Rolle idempotent. Bei einer zweiten Ausführung werden keine weiteren Änderungen am System vorgenommen:

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags install

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Ensure required packages are installed] ***************************
ok: [rhel9]

PLAY RECAP *********************************************************************
rhel9                      : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Anwendungsfall 2: Generierung der Datei /etc/aide.conf

Zusammen mit der Rolle wird die Datei templates/aide.conf.j2 ausgeliefert. Dabei handelt es sich um die Standardkonfigurationsdatei aus einer RHEL9-Installation, in welcher zusätzlich der Pfad /root/.ansible* von der Überwachung ausgenommen wurde, um falsch positive Ergebnisse zu vermeiden.

Diese Datei ist an die individuellen Bedürfnisse anzupassen. Wer Hilfe zum Templating mit Jinja2 benötigt, findet in der Ansible-Dokumentation einen Einstieg.

Ausgerollt wird die Konfigurationsdatei dann wie folgt:

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags generate_config

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Generate /etc/aide.conf] ******************************************
changed: [rhel9]

PLAY RECAP *********************************************************************
rhel9                      : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Auch mit diesem Tag arbeitet die Rolle idempotent.

Wird dieser Schritt ausgelassen, wird in allen folgenden Anwendungsfällen die Standardkonfigurationsdatei verwendet, welche bei der Installation des Pakets aide mitinstalliert wurde.

Anwendungsfall 3: Initialisierung der AIDE-Datenbank

Um Integritäts-Checks durchführen zu können, muss zuerst die AIDE-Datenbank initialisiert werden. Dies geschieht mit dem folgenden Aufruf:

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags init

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Initialize AIDE database] *****************************************
changed: [rhel9]

TASK [aide : Fetch AIDE database] **********************************************
changed: [rhel9]

TASK [aide : Remove remote AIDE database file] *********************************
changed: [rhel9]

PLAY RECAP *********************************************************************
rhel9                      : ok=4    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Nach der Initialisierung der AIDE-Datenbank wird diese auf den ACN kopiert und von den verwalteten Systemen entfernt. Dies hat den Hintergrund, dass es sich beim ACN um ein sehr gut gesichertes System handelt und die Datenbanken hier am besten vor einer Kompromittierung geschützt sind.

Wird der Standardwert der Variable aide_db_fetch_dir verwendet, findet sich die AIDE-Datenbank jetzt im Pfad files/rhel9/var/lib/aide/aide.db.new.gz. Dabei entspricht rhel9 in der Pfadangabe dem inventory_hostname des jeweiligen Zielsystems.

Dieser Teil der Rolle ist nicht idempotent. Wird das Playbook erneut ausgeführt, wird eine neue AIDE-Datenbank erstellt, auf den ACN heruntergeladen und vom Zielsystem gelöscht.

Anwendungsfall 4: Ausführung einer Integritätsprüfung

Der nun folgende Code-Block zeigt den Playbook-Aufruf zur Integritätsprüfung. Hier wird zuerst die AIDE-Datenbank auf das Zielsystem kopiert, anschließend ein AIDE-Check ausgeführt. Da im folgenden Beispiel keine Änderungen detektiert wurden, besitzt der Task „[aide : Check against AIDE reference database]“ den Status „ok“.

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags check

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Copy AIDE reference database to remote] ***************************
changed: [rhel9]

TASK [aide : Check against AIDE reference database] ****************************
ok: [rhel9]

PLAY RECAP *********************************************************************
rhel9                      : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Dieser Teil der Rolle ist nicht idempotent. Bei jedem Aufruf wird ein neuer Integritäts-Check ausgeführt.

Ich habe die Datei /etc/hosts auf dem Zielsystem manipuliert, um auch den Fall zu zeigen, wenn eine Änderung erkannt wurde.

Zu Beginn der folgenden Ausgabe ist zu erkennen, dass der Task „[aide : Copy AIDE reference database to remote]“ den Status „ok“ besitzt. Ansible hat erkannt, dass die AIDE-Datenbank bereits in unverändertem Zustand auf dem Zielsystem existiert, und hat sie deshalb nicht erneut übertragen. Der Task „[aide : Check against AIDE reference database]“ schlägt nun allerdings fehl (Status: „fatal“), da Veränderungen erkannt wurden. Die zugegeben etwas unübersichtliche Ausgabe enthält die Nachricht, dass die Datei /etc/hosts verändert wurde.

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags check

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Copy AIDE reference database to remote] ***************************
ok: [rhel9]

TASK [aide : Check against AIDE reference database] ****************************
fatal: [rhel9]: FAILED! => {"changed": true, "cmd": ["aide", "--check"], "delta": "0:00:27.177397", "end": "2024-03-29 05:16:50.682795", "msg": "non-zero return code", "rc": 4, "start": "2024-03-29 05:16:23.505398", "stderr": "", "stderr_lines": [], "stdout": "Start timestamp: 2024-03-29 05:16:23 -0400 (AIDE 0.16)\nAIDE found differences between database and filesystem!!\n\nSummary:\n  Total number of entries:\t45541\n  Added entries:\t\t0\n  Removed entries:\t\t0\n  Changed entries:\t\t1\n\n---------------------------------------------------\nChanged entries:\n---------------------------------------------------\n\nf   ...    .C... : /etc/hosts\n\n---------------------------------------------------\nDetailed information about changes:\n---------------------------------------------------\n\nFile: /etc/hosts\n  SHA512   : YobgpcvAMPey0QX1lK4K+5EFySF1xrB/ | 7nIivvNa5ozfhOqSFLmPIiu6g04Wbx1n\n             9FRzTCPNC93+13Y5/lm2inC4x4rydlf2 | iGNf0/QTgFjaMGug8HywxTiO2PREZRNS\n             EcvonCf3pHuXj6lEmAjBnw==         | 3qNEi4Qm6an5inSY72sjfA==\n\n\n---------------------------------------------------\nThe attributes of the (uncompressed) database(s):\n---------------------------------------------------\n\n/var/lib/aide/aide.db.gz\n  MD5      : gMgRyMOExVAdOAvdgt4QDA==\n  SHA1     : w7tmPKNvRYggY/JZ5wv+7ZdcSZM=\n  RMD160   : CO0pK5tfg66MaO17YB8eaRuyyMw=\n  TIGER    : n8UbZJNt9gL672+pR9IPjoyhpAsUJ46O\n  SHA256   : k8UHnv2CK4zYrfZN+bDp6SCcLkx21px6\n             GNZlwySPKcY=\n  SHA512   : DFw5wlBoJQOBCrs0ulvVxaMvoQk/oBEQ\n             TkOmhfHAdevUWNAgCJ0KH0q26LsynEMj\n             MWQpsGf7v12iACc4SP9ANA==\n\n\nEnd timestamp: 2024-03-29 05:16:50 -0400 (run time: 0m 27s)", "stdout_lines": ["Start timestamp: 2024-03-29 05:16:23 -0400 (AIDE 0.16)", "AIDE found differences between database and filesystem!!", "", "Summary:", "  Total number of entries:\t45541", "  Added entries:\t\t0", "  Removed entries:\t\t0", "  Changed entries:\t\t1", "", "---------------------------------------------------", "Changed entries:", "---------------------------------------------------", "", "f   ...    .C... : /etc/hosts", "", "---------------------------------------------------", "Detailed information about changes:", "---------------------------------------------------", "", "File: /etc/hosts", "  SHA512   : YobgpcvAMPey0QX1lK4K+5EFySF1xrB/ | 7nIivvNa5ozfhOqSFLmPIiu6g04Wbx1n", "             9FRzTCPNC93+13Y5/lm2inC4x4rydlf2 | iGNf0/QTgFjaMGug8HywxTiO2PREZRNS", "             EcvonCf3pHuXj6lEmAjBnw==         | 3qNEi4Qm6an5inSY72sjfA==", "", "", "---------------------------------------------------", "The attributes of the (uncompressed) database(s):", "---------------------------------------------------", "", "/var/lib/aide/aide.db.gz", "  MD5      : gMgRyMOExVAdOAvdgt4QDA==", "  SHA1     : w7tmPKNvRYggY/JZ5wv+7ZdcSZM=", "  RMD160   : CO0pK5tfg66MaO17YB8eaRuyyMw=", "  TIGER    : n8UbZJNt9gL672+pR9IPjoyhpAsUJ46O", "  SHA256   : k8UHnv2CK4zYrfZN+bDp6SCcLkx21px6", "             GNZlwySPKcY=", "  SHA512   : DFw5wlBoJQOBCrs0ulvVxaMvoQk/oBEQ", "             TkOmhfHAdevUWNAgCJ0KH0q26LsynEMj", "             MWQpsGf7v12iACc4SP9ANA==", "", "", "End timestamp: 2024-03-29 05:16:50 -0400 (run time: 0m 27s)"]}

PLAY RECAP *********************************************************************
rhel9                      : ok=2    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0

An dieser Stelle wurde gezeigt, dass sowohl unveränderte Systeme als auch Systeme mit Veränderungen erkannt und gemeldet werden. Dabei muss natürlich niemand die Standardausgabe beobachten. Stattdessen kann Logging für Ansible Ausgaben konfiguriert werden.

Anwendungsfall 5: Update der AIDE-Datenbank

Dieser Anwendungsfall nimmt an, dass erfolgte Änderungen legitim sind und in die AIDE-Referenzdatenbank aufgenommen werden sollen. Dies geschieht wie folgt:

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags update

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Update AIDE database] *********************************************
changed: [rhel9]

TASK [aide : Fetch AIDE database] **********************************************
changed: [rhel9]

TASK [aide : Remove remote AIDE database file] *********************************
changed: [rhel9]

PLAY RECAP *********************************************************************
rhel9                      : ok=4    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Nachdem die Referenzdatenbank aktualisiert wurde, wird diese wieder auf den ACN kopiert und vom Zielsystem entfernt.

Das folgende Beispiel zeigt, dass auf dem Zielsystem der AIDE-Check nun ohne Fehler absolviert wird:

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags check

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Copy AIDE reference database to remote] ***************************
changed: [rhel9]

TASK [aide : Check against AIDE reference database] ****************************
ok: [rhel9]

PLAY RECAP *********************************************************************
rhel9                      : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Ansible hat erkannt, dass die AIDE-Datenbank auf dem Zielhost nicht mit der aktuellen Referenzdatenbank übereinstimmt und hat letztere daher auf das Zielsystem übertragen. Die Überprüfung endet mit dem Status „ok“. Das System entspricht dem Soll-Zustand.

Zusammenfassung

Der Proof of Concept hat gezeigt, dass AIDE mit der verwendeten Ansible-Rolle ferngesteuert genutzt werden kann. AIDE-Datenbank und Konfigurationsdatei werden dabei getrennt von den verwalteten Systemen gespeichert und sind daher gegen Veränderung bei Kompromittierung der Zielsysteme geschützt. Bei Bedarf, wenn Ansible Abweichungen des Ist- zum Soll-Zustand erkennt, werden diese Dateien auf die Zielsysteme übertragen.

Der größte Arbeitsaufwand steckt in der Erstellung einer oder mehrerer AIDE-Konfigurationsdateien, die optimal zur eigenen Umgebung passen und möglichst keine falsch positiven Ergebnisse erzeugen. Dieser Aufwand besteht jedoch auch, wenn man AIDE ohne Ansible einsetzt.

Einen Punkt hat dieser PoC unberücksichtigt gelassen. Es nützt natürlich nichts, wenn man die Ausgaben der Playbooks nur protokolliert, die Protokolle jedoch nicht analysiert, um entsprechende Alarme in Monitoring- oder Ticket-Systemen zu erzeugen. Dies sei den Anwendern zur selbstständigen Übung überlassen. ;-)

Kodi 21 »Omega« wurde jetzt nach 15 Monaten Entwicklung freigegeben. Die wichtigsten Neuerungen sind die Einführung von FFmpeg 6.0 und die Bereitstellung als Flatpak.

Quelle

Das Entwickler-Team hat Kodi 21 Omega zur Verfügung gestellt. Seit der Veröffentlichung von Version 20.0 Nexus am 15. Januar 2023 wurden mehr als 3.750 Änderungen vorgenommen. Erwartungsgemäß gibt es natürlich einige wichtige und nennenswerte Änderungen. FFmpeg 6 in Kodi 21 Kodi setzt stark auf FFmpeg. Laut eigenen Angaben haben in den vergangenen 15 Monaten viele Personen dazu beigetragen, das Projekt an die neueren FFmpeg-Versionen anzupassen. Zunächst war das FFmpeg 5 und später dann FFmpeg 6. DolbyVision On-the-Fly-Profilkonvertierung Androis User dürfen […]

Der Beitrag Kodi 21 Omega ist veröffentlicht ist von bitblokes.de.

Malwarebytes hat eine sogenannte Malwertising-Kampagne auf Bing entdeckt, die einen Trojaner auf den Geräten der User einschmuggeln sollte. Dabei tarnt sich die bösartige Kampagne als die VPN-Software NordVPN. Laut den Security-Experten ist Bing neben Google wohl auch ein lukratives Ziel, da die Microsoft-Suchmaschine mit Windows und dem Browser Edge verknüpft ist. Fällt ein User auf die bösartige Werbung herein, landet er auf einer Website, die dem Original täuschen ähnlich sieht. Laut Malwarebytes gingen die Cyberkriminellen aber noch einen Schritt weiter. […]

Der Beitrag Bing-Anzeige für NordVPN führt zu SecTopRAT (Trojaner) ist von bitblokes.de.

Die beiden unter dem Dach von Linux Containers entwickelten Projekte LXC und Incus, ehemals LXD, erhielten eine Aktualisierung auf Version 6.0 LTS mit je fünf Jahren Unterstützung.

Quelle

Vor wenigen Tagen ist wieder eine neue Ausgabe des kostenlosen Magazins FCM erschienen. Das Full Circle Magazine 203 kommt nun genau richtig zum Wochenende und Du kannst es gratis herunterladen. Im Magazin werden folgende Themen behandelt: Wobei der Test von Cubuntu eher ein Blick in die Vergangenheit ist. Das Projekt wurde von 2012 bis 2017 entwickelt und ist damit seit einigen Jahren tot. Allerdings kannst Du die letzte Version, Cubuntu 16.04.3 LTS weiterhin von der SourceForge-Seite herunterladen. Mit dem erweiterten […]

Der Beitrag Full Circle Magaine 203 veröffentlicht – Cubuntu-Test ist von bitblokes.de.

Deutschlands nördlichstes Bundesland Schleswig-Holstein geht konsequent den 2020 eingeschlagenen Kurs weg von proprietärer Software.

Quelle

Opera stellt in Opera One Developer 150 lokale KI-Sprachmodelle zum Test bereit. Damit können Anwender verhindern, dass Daten ihrer Anfragen an externe Server abfließen.

Quelle

Die am Karfreitag entdeckte Hintertür im Paket xz-utils löst in vielen Projekten Betriebsamkeit aus. Canonical verschiebt die Beta zu Ubuntu 24.04 um eine Woche.

Quelle

Das Team von Nextcloud hat ein großes Update für den Nextcloud KI-Assistenten zur Verfügung gestellt. Ab sofort gibt es Context Chat und Context Write. Zudem ist GPU-Beschleunigung möglich und der Nextcloud-Server lässt sich vom KI-Server abspalten. Ferner arbeitet das Nextcloud-Team mit mehreren bekannten europäischen Hosting-Unternehmen zusammen, darunter IONOS und OVHcloud, um KI-as-a-Service-Lösungen anzubieten, die Privatsphäre und digitale Souveränität respektieren. In diesem Fall benötigst Du selbst keine teuren GPUs, um KI und Nextcloud zu vereinen. Nextcloud Assistant 2.0 Die Oberfläche wurde […]

Der Beitrag Nextcloud veröffentlicht großes Update für KI-Assistant – 2.0 ist von bitblokes.de.

Canonical hat angekündigt, dass die Beta-Version von Ubuntu 24.04 LTS Noble Numbat wegen CVE-2024-3094 (Sicherheitsproblem / Backdoor in den xz-utils) auf 11. April verschoben wird. Das Entwickler-Team hat sich entschieden, alle Binärpakete zu entfernen und neu zu erstellen. Mit dieser Aktion will Canonical sicherstellen, dass keine Binärdatei von der Sicherheitslücke betroffen ist. Bisher war der Plan, Ubuntu 24.04 LTS Beta am 4. April zu veröffentlichen. Am 25. April soll laut Zeitplan die finale Version erscheinen. Ob dieser Termin ebenfalls betroffen […]

Der Beitrag Ubuntu 24.04 LTS Beta auf 11. April verschoben (xz-Backdoor) ist von bitblokes.de.

Nitrux ist eine unabhängige Distribution, die dem KDE-Projekt nahesteht. Trotzdem soll noch in diesem Jahr der Umstieg von Plasma zu Maui-Shell vollzogen werden.

Quelle

DMA und Geräteneutralität +++ Abstimmung über CRA & PLD +++ EU-Wahlen: aktiv werden!

Im letzten Monat trat der DMA in Kraft, wir haben eine Website zur Geräteneutralität eingerichtet, das EU-Parlament hat über den CRA und die PLD abgestimmt und wir haben einen Leitfaden für die bevorstehenden EU-Wahlen veröffentlicht. Sehen Sie sich die Videos aus unseren Devrooms auf der FOSDEM an!

• Lassen wir Geräteneutralität in Europa Wirklichkeit werden!
• CRA & PLD Abstimmung im Europäischen Parlament
• Sehen Sie sich die Aufzeichnungen von der FOSDEM an!
• Werden Sie aktiv für die Wahlen in der Europäischen Union!
• Nachrichten von ZOOOM
• Vergangene und kommende Veranstaltungen

Lassen wir die Geräteneutralität in Europa Wirklichkeit werden!

Am 7. März letzten Jahres ist in der Europäischen Union der Digital Markets Act (DMA) in Kraft getreten. Dieser Meilenstein markiert den Beginn der Geräteneutralität als greifbare Realität in der Europäischen Union. Die FSFE begrüßt die neue Gesetzgebung, aber wir möchten anmerken, dass dies nur der erste Schritt ist, und dass weiteres Engagement notwendig ist!Lesen Sie diesen Artikel um mehr zu erfahren.

Um das öffentliche Bewusstsein für die Geräteneutralität zu schärfen, hat die FSFE deviceneutrality.org ins Leben gerufen. Diese Seite bietet detaillierte Einblicke in das Thema Geräteneutralität und Freie Software, Werbematerial zum Herunterladen und weitere Möglichkeiten zur Verbreitung des Themas. Probieren Sie es aus!

CRA & PLD Abstimmung im Europäischen Parlament

Das Europäische Parlament hat am 12. März über den Cyber Resilience Act (CRA) und die Produkthaftungsrichtlinie (PLD) abgestimmt. Hinsichtlich der Einführung von Haftungsregeln für Software wurde eine weitreichende Ausnahme für Freie Software gemacht, so dass nach langen und intensiven Debatten einzelne Entwickler und gemeinnützige Arbeit geschützt sind. Wir werden daher die Umsetzung genau beobachten und darauf achten, ob die Softwarefreiheit entsprechend geschützt wird.

Lesen Sie die vollständige Erklärung der FSFE

Sehen Sie sich die Aufzeichnungen von der FOSDEM an!

Haben Sie die FOSDEM 2024 verpasst oder hatten Sie nicht die Möglichkeit, an den Devrooms teilzunehmen, an denen wir mitgewirkt haben? Wir haben die Aufzeichnungen für Sie bereitgestellt.

Wir haben wieder den inzwischen wohlbekannten Devroom "Legal & Policy Issues" mitorganisiert. Die Diskussionen in diesem Programm behandelten wichtige Themen für die Softwarefreiheit, wie CRA, RHEL und die Beendigung der Rechte unter der GPL. Darüber hinaus halfen wir bei der Organisation eines Devrooms über Freie Software in der europäischen Gesetzgebungslandschaft.

Werden Sie aktiv bei den Wahlen in der Europäischen Union!

Die europäischen Bürgerinnen und Bürger werden vom 6. bis 9. Juni 2024 zu den Wahlurnen gehen, um ihre zukünftigen Vertreter im Europäischen Parlament zu wählen. In der heißen Phase des Wahlkampfs ist es wichtig, aktiv zu werden und dafür zu sorgen, dass die Softwarefreiheit Teil der breiten politischen Debatte ist.

Wie können Sie das tun? Hier finden Sie praktische Vorschläge, wie Sie sich in den kommenden Monaten für Freie Software einsetzen können! Ihre Unterstützung bei der Übersetzung des Leitfadens wäre eine große Hilfe, um so viele europäische Bürger wie möglich zu erreichen!

Neuigkeiten von ZOOOM

Im Rahmen ihrer Zusammenarbeit mit dem Zooom-Konsortium hat die FSFE vier Kapitel in zwei umfassenden Berichten zu rechtlichen und wirtschaftlichen Aspekten Freier Software erstellt. Diese Berichte befassen sich mit einer breiten Themenpalette und liefern empirische Daten zu Freie- Software-Themen in Europa in Bezug auf kritische Technologien, wie z.B. KI. Die FSFE hat außerdem eine Studie darüber beigesteuert, wie der Begriff "offen" fälschlicherweise für KI-Projekte verwendet wird, die keine Freie Software sind.

Vergangene und kommende Veranstaltungen

Am Wochenende des 16. und 17. März besuchten einige unserer Mitarbeiter zusammen mit Freiwilligen die Chemnitzer Linux-Tage! Wir haben uns sehr gefreut, so viele von Ihnen zu treffen und mit Ihnen über so viele Themen rund um die Softwarefreiheit zu sprechen. Wir standen auch auf der Bühne, um über Youth Hacking 4 Freedom zu informieren!

"Ada & Zangemann - Eine Geschichte von Software, Skateboards und Himbeereis" kommt nach Belgien! Besuchen Sie die Lesung in Brüssel am Donnerstag, den 4. April um 15:00 Uhr!

Am 15. und 16. April findet die foss-north im Chalmers Conference Centre in Göteborg, Schweden, statt. Die Veranstaltung wird als Präsenzveranstaltung durchgeführt.. Weitere Informationen

Zitat des Monats

Die Lösungen von morgen müssen mit öffentlichem Code entwickelt werden. Dies nicht nur, um eine vernünftige Verwendung öffentlicher Gelder zu gewährleisten, sondern auch, um die Wahlfreiheit zu fördern und die Bindung an bestimmte Anbieter zu vermeiden.

~ EU-Kommissar Johannes Hahn zum Thema "Öffentliches Geld, öffentlicher Code".

Tragen Sie zu unserem Newsletter beir

Wir würden uns freuen, von Ihnen zu hören. Wenn Sie uns Ihre Gedanken, Bilder oder Neuigkeiten mitteilen möchten, senden Sie uns diese bitte an newsletter@fsfe.org. Sie können uns auch unterstützen, einen Beitrag zu unserer Arbeit leisten und unserer Gemeinschaft beitreten. Wir möchten unserer Gemeinschaft und allen Freiwilligen, Unterstützern und Spendern danken, die unsere Arbeit möglich machen. Ein besonderer Dank geht an unsere Übersetzer, die es Ihnen ermöglichen, diesen Newsletter in Ihrer Muttersprache zu lesen.

Ihre Redakteure, Ana and Tommi

Support FSFE

Fedora mit KDE Plasma als Standard? Ein Aprilscherz? Mitnichten, der jetzt eingereichte Vorschlag ist ernst gemeint und überzeugend ausgearbeitet.

Quelle

Das für den Sommer zu erwartende Linux Mint wartet mit sinnvollen Neuerungen auf. So werden Kernel künftig in aktuelleren Versionen angeboten.

Quelle

Nach einem kleinen Rücksetzer im Februar ist Steam auf Linux im März 2024 wieder knapp an die 2 % herangerückt. Nun muss man dazu sagen, dass diese Umfragen mit Vorsicht zu genießen sind, da nicht alle Steam-User gefragt werden und nicht alle, die gefragt werden, teilnehmen müssen. Dennoch sind die Steam-Statistiken ein guter Indikator, wie es um Linux und Spiele steht. Die Umfrage im März hat einen Marktanteil von 1,94 % ergeben (Februar 2024 1,76 %). Damit ist Steam unter […]

Der Beitrag Steam unter Linux kratzt wieder an den 2 % ist von bitblokes.de.

openSUSE baut Tumbleweed komplett neu, Debian verschiebt ein Point-Release. Auswirkungen eines gerade noch rechtzeitig entdeckten Angriffsszenarios.

Quelle

Der Monatsbericht von Linux Mint ist da und es gibt einige Neuigkeiten bezüglich Linux Mint 22, das bekanntlich auf Ubuntu 24.04 LTS Noble Numbat basieren wird. Zunächst einmal gibt es Verbesserungen, dass sich Installationen von Linux Mint 22 besser lokalisieren lassen und weniger Speicherplatz als bisher benötigen. Vorinstallierte Pakete für andere Sprachen als Englisch und die von Dir gewählte Sprache werden am Ende der Installation entfernt. Laut eigenen Angaben wird durch das Entfernen dieser Pakete in Linux Mint 22 nach […]

Der Beitrag Linux Mint 22 wird Thunderbird als .deb-Paket bieten ist von bitblokes.de.

Die Hölle friert zu: Microsoft kündigt Office 2024 für Linux an. Details und weitere Informationen erfahrt ihr nach dem Klick auf Weiterlesen!

Quelle

Debian verschiebt die Aktualisierung auf v12.6 wegen der teils noch ungeklärten Hintergründe von CVE-2024-3094. Zunächst wird das Archiv einer gründlichen Analyse unterzogen.

Quelle

Bei Technik-affinen Leuten wie die Leser dieses Blogs dürfte sich bereits wie ein Lauffeuer verbreitet habe, dass das weit verbreitete Paket xz-utils (Datenkompressions-Tools), beginnend mit den Versionen 5.6.0 bis 5.6.1, eine Backdoor hat (CVE-2024-3094). Diese Hintertür könnte es einem böswilligen Akteur ermöglichen, die sshd-Authentifizierung zu kompromittieren. Damit könnte sie oder er unbefugten Fernzugriff auf das gesamte System erhalten. Die gute Nachricht ist, dass aktuelle LTS-Versionen von Ubuntu nicht betroffen sind. Das gilt auch für Linux Mint und die stabile Version […]

Der Beitrag Kali von xz-utils Backdoor betroffen, Debian / Ubuntu nicht ist von bitblokes.de.

Durch jahrelange Vorarbeit ist es Angreifern gelungen, den Quellcode der Kompressions­software xz zu kompromittieren. Gezielt eingereichte Patches schufen Sicherheitslücken und diese wurden proaktiv in aktuelle Linux-Distributionen eingepflegt. Zum Update auf ein bereinigtes Paket wird dringend geraten.

Die weitverbreiteten Datenkompressionswerkzeuge XZ Utils (früher LZMA Utils) enthalten in Version 5.6 eine Backdoor. Ziel der Backdoor ist nach aktuellem Kenntnisstand eine Kompromittierung von SSH-Servern. Dies wurde gestern auf der oss-security-Mailingliste von Andres Freund nebst einer umfangreichen Analyse des Sachverhalts bekannt gegeben. Durch den Einsatz der Werkzeuge in Linux-Distributionen haben wir hier einen Fall einer Supply-Chain-Attacke. Red Hat hat dem Vorfall die CVE-Nummer CVE-2024-3094 vergeben.

Vorab eine Liste mit weiteren Links:

• Stellungsnahmen von verschiedenen Distributoren
  • Arch Linux
  • Debian
  • Red Hat
  • SUSE
• FAQ
• Hacker-News-Diskussion
• Zeitleiste

Wirkungsweise

Dabei wird die Backdoor nur unter bestimmten Bedingungen ausgeführt, wie das FAQ beschreibt. Im Wesentlichen muss argv[0] auf /usr/sbin/sshd gesetzt sein und eine Reihe an Umgebungsvariablen entweder gesetzt oder nicht gesetzt sein. Normalerweise hängt OpenSSH nicht von liblzma ab. Einige Distributoren patchen OpenSSH allerdings so, dass systemd-Notifcations funktioniert, welches wiederum auf liblzma setzt und die Backdoor möglich macht. Technisch werden einige Checks durchgeführt und anschließend mittels IFUNC Bibliotheksaufrufe umgeleitet. Dies betrifft nach aktuellem Stand auch Aufrufe während der Kryptoroutinen bei der SSH-Authentifizierung.

Betroffenheit

Der Wirkungsweise der Payload ist noch nicht abschließend geklärt. Besonders auch aus diesem Grund wird ein unverzügliches Update angeraten. Im Folgenden einige unverbindliche Faktoren, die eine Verwundbarkeit wahrscheinlich machen. Auf diese Weise kann man priorisieren, welche Systeme zuerst aktualisiert werden sollten.

Versionierte Distros wie z. B. Debian oder RHEL sind nach aktuellem Kenntnisstand mit ihren stabilen Versionen nicht direkt betroffen, da die Versionen 5.6 noch keinen Einzug in das System gefunden haben. Die Testing-Versionen dieser Distros wie z. B. Debian Sid wurden allerdings aktualisiert und sind betroffen.

Rolling-Release-Distros sind naturgemäß auch betroffen, wenn sie schon Version 5.6 in ihre Pakete aufgenommen haben. Dies betrifft zum Beispiel Arch Linux oder Gentoo. Da allerdings einige Distributionen wie Arch Linux OpenSSH nicht gegen liblzma linken, wird die Bibliothek nicht direkt in die Ausführung der Komponenten eingebunden.

Nach aktuellem Stand wird eine Verwundbarkeit besonders kritisch, wenn auf dem betroffenen Host ein öffentlich erreichbarer SSH-Server läuft, da die oben beschriebenen Faktoren ein Laden der Payload auslösen können.

Wie kam es?

Aufgefallen ist die Backdoor nur durch Zufall durch das Debugging von Performanceproblemen, die durch die Backdoor verursacht wurden. Die Backdoor wurde obfuskiert im Rahmen von Buildskripten untergebracht, sodass aufgrund der Komplexität die Lücken noch nicht direkt aufgefallen sind.

Das Repository hinter xz kann als kompromittiert gesehen werden und ist auch auf GitHub schon gesperrt worden. Auffällig ist, dass die Backdoor in den Tarballs der Releases enthalten war, nicht jedoch im Repository-Dump selber. Auch personell gab es einige Auffälligkeiten, da es vor kurzem einen Maintainerwechsel beim Projekt gab und die Lücken vom neuen Maintainer, der seit 2 Jahren am Projekt mitarbeitet, zumindest begünstigt wurden. Die Art und Weise lässt auch auf ein koordiniertes, von langer Hand geplantes Vorgehen schließen.

Einfluss und Folgen

Das große Ganze ist ein Paradebeispiel von xkcd 2347 "Dependency". Wir sehen hier Live ein Beispiel einer Supply-Chain-Attacke. Ein kleines, scheinbar unbedeutendendes Projekt wird übernommen, nur um strategisch Commits zu platzieren, die automatisch "flussabwärts" ihren Weg in größere Distributionen finden, die allesamt auf das Projekt setzen. Alles passiert trotz Open Source. Besonders pikant: der Maintainer hat aktiv versucht, die Backdoor-begünstigenden Umgebungsfaktoren, konkret das Umbiegen von Bibliotheksaufrufen mittels ifunc, in Fuzzing-Projekten wie oss-fuzz, die aktiv nach sowas suchen, zu deaktivieren.

Software wird immer bedeutender und benötigt Vertrauen. Dabei ist jetzt schon klar, dass niemand selber solch komplexe Systeme von alleine bauen kann. Aber auch die Kontrolle der Quellen ist eine große Herausforderung. Neue Gesetzgebung wie der geplante Cyber Resilience Act in der EU versuchen in der Industrie Anreize zu schaffen, die Softwarequalität zu erhöhen.

Diese Attacke konnte einigermaßen abgewendet werden, sollte die umfassende Analyse der Payload keine belastenden Neuigkeiten hervorbringen. Eines ist aber auch klar: Die Angreifer studieren das Verhalten der Verteidiger und werden in Zukunft ihre Vorgehensweise dahingehend optimieren, nicht so einfach mehr gefunden zu werden. Es ist also möglich, Backdoors in so ein Ökosystem hineinzuschummeln. Umso besser müssen aber die Identifikations- und Abwehrmöglichkeiten werden, damit solche Angriffe wirksam verhindert werden können.

Es handelt sich um Wartungsversionen und die laufen normalerweise schnell und problemlos durch. Die Updates bringen verschiedene Korrekturen und Leistungsverbesserungen in allen unterstützten Versionen von Nextcloud Hub. In Versionsnummern gibt es ab sofort Nextcloud 26.0.13, 27.1.8 sowie 28.0.4. Ich habe es schon mehrmals erwähnt, finde den Mix aus Hub und Versionsnummern echt verwirrend, zumal eine große Versionsnummer nicht zwingend eine große Hub-Nummer repräsentiert. Klar, es ist ein kosmetisches Problem, aber weniger Verwirrung wäre dennoch besser. Nextcloud 26 hat ihr Lebensende […]

Der Beitrag Nextcloud – Updates für Hub 6 und 7 – EOL für Hub 4 ist von bitblokes.de.