Murena erleichtert den Datenschutz für /e/os
Murena liefert mit /e/os die Datenschutz-App Advanced Privacy aus. Ein Update soll jetzt den Zugang zu den Funktionen vereinfachen.
Murena liefert mit /e/os die Datenschutz-App Advanced Privacy aus. Ein Update soll jetzt den Zugang zu den Funktionen vereinfachen.
Ubuntu richtet eine Snapshot-Dienst ein, der über ein Repository alle Pakete bis zurück zum 1. März 2023 zur Installation bereitstellt. Debian bietet Snapshots bereits seit 2010 an.
Ich bin in meiner Familie der Nerd. Ich kümmere mich um den Internetzugang, das WLAN, die Speicherung der Familienfotos, etc. Ja manchmal kümmere ich mich sogar um Drucker.
Meine Familie vertraut darauf, dass das Heimnetzwerk die meiste Zeit des Jahres reibungslos funktioniert. Und wenn dies nicht der Fall ist, ist es mein Job, die Sache wieder in Ordnung zu bringen.
Erkennt ihr euch in dieser Beschreibung wieder? Dann habe ich gleich noch weitere Fragen an euch.
Stellt euch vor, dass ihr eines Tages nicht mehr für eure Familie da sein könnt und eure Angehörigen plötzlich allein mit der IT-Umgebung zurechtkommen müssen, die ihr hinterlassen habt.
Bitte teilt eure Erfahrungen und Ideen in den Kommentaren zu diesem Beitrag. Habt ihr selbst schon zu diesem Thema gebloggt? Dann teilt doch bitte den Link zu eurem Beitrag mit mir und den Leserinnen und Lesern dieses Blogs.
Gerade der Abschnitt zur Entstörung von IT-Komponenten wird sicherlich eine Herausforderung. Generationen von Supportern werden ein Lied davon singen können, doch es hilft ja nunmal alles nichts. Wir sind unseren Angehörigen diese Informationen schuldig, wollen wir sie nicht hilflos zurücklassen.
Für mich ist eine Dokumentation, mit der ein Mensch mit IT-Affinität arbeiten kann das Muss und Hinweise zur Entstörung für technische Laien die Kür.
Wie viele Nerds betreibe auch ich ein kleines Heimlabor. Beim Aufbau des Heimnetzwerks habe ich darauf geachtet, dass mein Heimlabor komplett abgeschaltet werden kann, ohne die Funktion des Heimnetzwerks und den Internetzugang negativ zu beeinflussen.
Dies ermöglicht es mir, in meinem Heimlabor häufige Änderungen durchführen zu können, ohne dass dadurch Änderungen an der Notfalldokumentation notwendig werden.
Dann werde ich mal ein Git-Repository im Heimnetzwerk erstellen und ein LaTeX-Dokument beginnen.
Ich freue mich, an dieser Stelle von euren Ideen und Vorgehensweisen zu lernen und das Thema mit euch zu diskutieren.
In KW 16 ist in der FOSS Welt einiges passiert. Von LXQt, COSMIC, GNOME und Niri.


Das fnordkollektiv bietet mit WA-Backstage eine quelloffene Arbeitsplatzverwaltung auf der Arbeitsplatz-Suite WorkAdventure. Damit lassen sich Remote-Arbeitsplätze genauso wie Online-Konferenzen verwalten.


Es gibt eine neue Version der speziellen Linux-Distribution Clonezilla Live. Neben diversen Bugfixes gibt es auch nennenswerte Verbesserungen. Clonezilla Live 3.1.2-22 basiert auf dem Debian Sid Repository mit Stand 8. April 2024. Der Linux-Kernel wurde bei der speziellen Linux-Distribution auf 6.7.9-2 aktualisiert. Mit an Bord ist auch ezio 2.0.11. Zudem gibt es ein neues Format für Meldungen, die an ocsmgrd gesendet werden. Um die Nachrichten zu trennen, benutzt das System ein Komma. Clonezilla-bezogenen Log-Dateien rotiert das Betriebssystem nun und empfängt […]
Der Beitrag Clonezilla Live 3.1.2-22 – wichtige Verbesserungen und Bugfixes ist von bitblokes.de.
Ab sofort kannst Du Tor Browser 13.0.14 herunterladen oder bestehende Installationen aktualisieren. Aktuelle Versionen des Browsers aktualisieren sich selbst. Hier siehst Du, wie das bei mir abläuft. Tor Browser 13.0.14 bringt wichtige Sicherheits-Updates bezüglich Firefox mit sich. Ein Bugfix beschäftigt sich mit Fingerprinting, beziehungsweise ist eine Schutzmaßnahme gegen Fingerprinting. Bei der neuesten Version wurde Tor auf 0.4.8.11 aktualisiert. Für Linux, macOS und Windows basiert Tor Browser 13.0.14 auf Firefox 115.10.0esr. Für Android wurde die Software auf GeckoView 115.10.0esr aktualisiert. Für […]
Der Beitrag Tor Browser 13.0.14 – Mullvad Browser 13.0.14 ist von bitblokes.de.
In der Welt des Spielens gibt es nur wenige Erlebnisse, die so zeitlos und fesselnd sind wie Flipper. Der Reiz, eine Metallkugel durch ein Labyrinth von Stoßstangen und Zielen zu lenken, hat Jahrzehnte überdauert.


Volla Systems hat bereits mehrere Crowdfunding-Kampagnen erfolgreich abgeschlossen. Jetzt startet die Kampagne für das gut ausgestattete Volla Tablet.
Edge Computing und Künstliche Intelligenz beschleunigen die Integration von IT und OT in der Fertigung. Francis Chow von Red Hat erklärt die Vorteile offener Technologien und die Partnerschaft mit Intel, die Automatisierung und Effizienz in der Fertigung durch einheitliche Plattformen steigert.
Martin Loschwitz von True West erklärt die Bedeutung offener Schnittstellen und Standards für digitale Souveränität. Er kritisiert die Reduktion souveräner Clouds auf geografische Serverstandorte und betont die Notwendigkeit echter Anbieterwahl zur Erreichung wahrer digitaler Souveränität.
Europäische Unternehmen nutzen die Cloud zunehmend als zentralen Bestandteil ihrer Strategie, um in der dynamischen Geschäftswelt flexibel und reaktionsfähig zu bleiben, während sie komplexe regulatorische und datenschutzrechtliche Anforderungen erfüllen.
Entdecken Sie die neueste Version 24.3 der Stackable Data Platform, eine umfassende Open-Source-Datenplattform auf Kubernetes-Basis. Diese Version bietet erweiterte Sicherheitsfeatures, verbesserte Authentifizierung und neue Funktionen für effiziente Datenverarbeitung.
Die neueste Version der kostenlosen Virtualisierungs-Software VirtualBox 7.0.16 ist eine Wartungs-Version und bringt daher keine allzu großen Neuerungen mit sich. Nennenswert ist allerdings die anfängliche Unterstützung für Linux-Kernel 6.9 (Linux Host und Gast) und 6.8 (Linux-Gast-Erweiterungen). Die Unterstützung für Linux-Kernel 6.8 bedeutet, dass Du ab sofort auch Distributionen innerhalb einer virtuellen Maschine betreiben kannst, die Kernel 6.8 einsetzen. Die anfängliche Unterstützung für Kernel 6.9 bedeutet, dass Du VirtualBox auch auf Computern installieren kannst, die mit Linux 6.9 laufen. Für Linux […]
Der Beitrag VirtualBox 7.0.16 – anfängliche Unterstützung für Linux 6.8 und 6.9 ist von bitblokes.de.
Am 25. April 2024 öffnet der „Girl’s Day“ deutschlandweit Türen zu Unternehmen, die junge Frauen für technische und naturwissenschaftliche Berufe begeistern wollen. Erfahren Sie mehr über die Angebote unserer Mitgliedsunternehmen und entdecken Sie, wie Sie teilnehmen können. Freie Plätze sind noch verfügbar!
Explicit Sync ist ein wichtiger Schritt, damit sich Wayland und proprietäre Nvidia-Treiber besser vertragen. Die kürzlich in ein Wayland-Protokoll gegossene Technik wird in Plasma 6.1 verfügbar sein.
Western Digital hat auf der NAB 2024 einige neue und spannende Technologien sowie Storage-Lösungen angekündigt. Ziemlich beeindruckend finde ich die Ankündigungen von microSD-Karten mit 2 TByte Speicher und SD-Karten mit 4 TByte Platz. Ein Raspberry Pi 5 mit so viel Speicherplatz ist fast schon ein vollwertiger Computer. Wobei man hier anmerken muss, dass es microSD-Karten mit 1,5 TByte bereits gibt und das ebenfalls ordentlich viel Platz ist. Genügend Platz kann man allerdings nie haben und daher ist die Ankündigung von […]
Der Beitrag SD-Karten mit 4 TByte Speicher angekündigt ist von bitblokes.de.
In der weiten Welt der Videospiele, wo Blockbuster um Aufmerksamkeit buhlen, gibt es immer wieder kleine Perlen, die leicht übersehen werden. Mindustry ist so ein Exemplar.


Der Raspberry Pi hat sich in den letzten Jahren von einem kleinen Minicomputer für Bastler und Nerds zu einem vollwertigen und verhältnismäßig leistungsfähigem Rechner entwickelt. Nicht wenige Anwender freuen sich darüber, für wenig Geld einen vollwertigen Miniserver zu bekommen.
Beim Einsatz des Raspberry Pi für den produktiven Einsatz als Server ist zu beachten, dass auch die angeschlossene Hardware hierfür geeignet sein sollte. Ein Gehäuse, bei dem er Pi überhitzt, ist genau so schädlich wie eine SD-Karte als Festplatte, da diese nicht für den Dauerbetrieb geeignet ist.

Durch den Einsatz rund um die Uhr gibt es sehr viele Schreib- und Lesevorgänge auf der SD-Karte. Hierfür sind diese Karten aber nur bedingt geeignet. Bei den ersten Raspberry Pi Generationen hatte ich sehr häufig Datenverlust, weil die SD-Karte den Geist aufgegeben hat.
Inzwischen läuft auf dem Pi bei mir eine Instanz von Home Assistant. Hier werden rund um die Uhr Daten aufgezeichnet und Automationen ausgeführt. Auch andere Dienste laufen hier, von denen ich keinen Ausfall erleiden möchte.
Außerdem sind die Lese- und Schreibgeschwindigkeiten einer SD-Karte sehr limitiert. Eine moderne SSD ist um ein Vielfaches schneller. Das wird vor allem dann deutlich, wenn man in Home Assistant Datenmengen abfragt, z.B. Diagramme anzeigt. Ladezeiten von mehreren Sekunden sind dann keine Seltenheit.
Die Konsequenz daraus ist, dass ich den Raspberry von einer SD-Karte auf eine SSD-Karte umziehen möchte. Dadurch, dass hier ein Produktivsystem läuft, möchte ich alle Installationen, Daten und Einstellungen möglichst verlustfrei auf das neue Medium umziehen. Wie ich das gemacht habe, erfahrt hier in folgendem Tutorial.
Um einen Geschwindigkeitsvorteil in messbare Größen zu fassen, kann man als Referenz einen Geschwindigkeitstest der SD-Karte machen. Mit dem folgenden Befehl werden Beispieldateien geschrieben. Der Befehl gibt aus, wie schnell die Geschwindigkeit dabei war.
$ dd if=/dev/zero of=/tmp/speedtest1.img bs=20MB count=5
5+0 records in
5+0 records out
100000000 bytes (100MB, 95 MiB) copied, 11.9403 s, 8.4 MB/s
Wenn der Umzug fertig ist, kann man diesen Test wiederholen. Bei mir kam ich von ca. 8,4 MB/s Schreibgeschwindigkeit auf 168 MB/s. Das hat sich mal gelohnt!
In meinem Fall handelt es sich um eine externe SSD, die über USB 3.0 angeschlossen wird. Nachdem ich sie angesteckt habe, prüfe ich ob sie rechtmäßig erkannt wird, indem ich den folgenden Befehl eingebe und in der Ausgabe nach der SSD suche.
$ lsblk
Auf Github gibt es ein kleines Projekt, das viele Funktionen beinhaltet. Das Programm kopiert den Inhalt der SD-Karte auf die SSD, sodass von ihr gebootet werden kann und alle Einstellungen vorhanden sind.
$ git clone https://github.com/billw2/rpi-clone.git
$ cd rpi-clone
$ sudo cp rpi-clone /usr/local/sbin/sys-clone
$ sudo cp rpi-clone-setup /usr/local/sbin/sys-clone-setup
Am besten ist es, wenn kein Service mehr läuft und der Kopiervorgang ungestört durchlaufen kann. Daher erst prüfen, was alles läuft, danach einzeln beenden
$ sudo systemctl stop cron
$ sudo systemctl stop nginx
$ sudo systemctl stop docker usw.
Aus dem Check von Schritt 1 kennen wir bereits die Bezeichnung der Festplatte. Auf diese müssen wir nun verweisen mit dem Befehl:
$ rpi-clone sda
Der Wizard hält zunächst an und berichtet uns über den Zustand des Systems. Wenn alles korrekt ist, kann der Vorgang mit der Eingabe von „yes“ gestartet werden.
Nach Ende des Kopiervorgangs fährt man den Raspberry Pi herunter.
$ sudo shutdown now
Anschließend von der Stromversorgung trennen, die SD-Karte entfernen, und die Spannungsversorgung wieder herstellen. Jetzt bootet der Raspberry von SSD und ist sehr viel schneller.
The post Raspberry Pi: Umzug von SD-Karte auf SSD in wenigen Schritten first appeared on bejonet - Linux | Smart Home | Technik.
SuperTuxKart erstrahlt als Leuchtfeuer in der Open-Source-Spielegemeinschaft und bietet Spielern eine reizvolle und immersive Erfahrung ohne die Notwendigkeit von proprietärer Software.


Ich bin ein ziemlicher Fan des Deckbau-Roguelike Slay the Spire. Ich habe das Spiel in einem Humble Bundle erworben und bereue es nicht. Das macht ziemlich Spaß. Das Entwickler-Team von Mega Crit hat nun Slay the Spire 2 angekündigt. So groß die Vorfreude auch ist, Du wirst Dich in Geduld üben müssen. Veröffentlichungsdatum für Slay the Spire 2 ist 2025. Auf Steam schreibt das Team, dass das Spiel komplett neu in einer neuen Spiel-Engine programmiert wurde. Mega Crit ist Sponsor […]
Der Beitrag Slay the Spire 2 angekündigt – mit neuer Spiele-Engine ist von bitblokes.de.
Seit 1,5 Jahren produziere ich den Podcast Risikozone, in dem es um Themen der IT-Sicherheit und Open-Source-Software geht. Die xz-Backdoor ist natürlich ein heißes Thema, weswegen es in der heute veröffentlichten Episode 45 genau darum geht.
Die knapp einstündige Podcastepisode ist für alle interessant, die nochmals einen technisch orientierten Überblick über die Geschehnisse suchen. Da die Thematik recht komplex ist und aus verschiedenen Blickwinkeln beobachtet werden kann, können weitere Podcastepisoden hierüber noch folgen. Ich möchte aber darauf eingehen, dass man diese Backdoor nicht nur auf den Code beschränken sollte. Es gibt es viele verschiedene Ebenen, die allesamt jeweils Beachtung finden sollten:
Technisch ist der Exploit ausgeklügelt: Die Backdoor beschränkt sich nicht nur auf die bloße Möglichkeit einer Remote-Code-Execution, sondern verwendet darüber hinaus noch ein eigenes Protokoll, mit dem die Befehle signiert und verschlüsselt innerhalb des unscheinbaren N-Wertes im Zertifikat eines SSH-Handshakes übermittelt werden. Durch die Signatur können nur Befehle ausgeführt werden, die mit einem (wahrscheinlich nur dem Angreifer bekannten) ED448-Schlüssel signiert wurden. Die Verschlüsselung erfolgt zwar mit einem statischen Schlüssel, der aus dem ED448-PubKey abgeleitet wird, erfüllt jedoch trotzdem seinen Zweck: Obfuskierung. Mit anderen Worten: wäre die Lücke nie aufgefallen, hätte man sie in der freien Wildbahn nahezu unmöglich durch Traffic-Analysen finden können.
Das ist allerdings nur die erste von drei Ebenen: die Art und Weise, wie die Lücke hereingeschummelt wurde, weist Komponenten des Social Engineering auf. Die Mühe, über mehrere Jahre eine Identität in verschiedenen Projekten mit teils anfangs legitimen Beiträgen aufzubauen, zeugt auch von einem Plan und Ausdauer.
Schlussendlich sollte man auch nicht vergessen, dass hier eine besondere Konstellation im Ökosystem ausgenutzt wurde. Am einfachsten (und auffälligsten) wäre es, eine solche Lücke in OpenSSH unterzubringen. Es wurde aber auf eine deutlich unbeachtetere und einfacher zu infiltrierende Variante ausgewichen. Die xz-Bibliothek wurde zudem nicht zum Einfallstor, weil OpenSSH darauf zurückgreift (das tut es nämlich nicht), sondern weil einige Distros systemd-notify reinpatchen, was wiederum auf die xz-Lib zurückgreift. Außerdem rüttelt dieser Fall an einem Grundpfeiler der IT-Sicherheits-Praktiken: Updates. Diese Hintertür fand geradezu durch die (häufigen) Updates der Rolling-Release-Distros Einzug - die stabilen Versionen waren noch verschont geblieben. Ist also (zu) häufiges Updaten nun auch nicht mehr richtig? Bringen bald Updates mehr Lücken als sie schließen?
Das alles macht es vor allem noch schwieriger, solche Angriffe zuverlässig zu erkennen. Zudem ist davon auszugehen, dass die Angreifer sich die Verteidigungsstrategie jetzt ganz genau anschauen. Die zukünftige Diskussion sollte sich also darauf konzentrieren, wie man diese Art von Angriffen detektiert und frühzeitig eindämmt.
Mehr Geschwindigkeit und höhere Reaktionszeiten? Da bin ich dabei. Das Team von Linux Mint möchte so viele Beta-Tester wie möglich für die neuen und schnelleren Repositories haben. Daher ruft das Team so viele Community-Mitglieder wie möglich auf, die neuen Repos zu testen. So testest Du die neuen, schnelleren Repos Zunächst startest Du das Tool Anwendungspaketquellen und stellst die Standardeinstellungen wieder her. Damit stellst Du sicher, dass Du den offiziellen Mirror benutzt. Im Anschluss bearbeitest Du die Datei /etc/apt/sources.list.d/official-package-repositories.list mit dem […]
Der Beitrag Beta-Tester für schnellere Repos bei Linux Mint gesucht ist von bitblokes.de.
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.
aide ist auf den Zielsystemen installiertaide.confDurch 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.
Meine Labor-Umgebung für diesen PoC besteht aus den vier Hosts:
ansible-core)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
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
aide auf den Zielsystemen installiert ist/etc/aide.conf unter Nutzung von templates/aide.conf.j2; das Template ist an die individuellen Bedürfnisse anzupassen; Details siehe nächster AbschnittDie 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.
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.
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
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.
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.
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.
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.
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. ;-)
In der Welt der Flugsimulationen gibt es einen unbestrittenen Stern am Himmel: FlightGear. Doch was macht dieses Programm so besonders?

