Überarbeitetes CachyOS unterstützt Bcachefs und bietet KI-SDK
Die auf Arch Linux basierende Distribution CachyOS bietet gleich drei interessante Neuerungen: Der Installationsassistent kann mit dem Bcachefs-Dateisystem umgehen, es gibt ein SDK für…
Die auf Arch Linux basierende Distribution CachyOS bietet gleich drei interessante Neuerungen: Der Installationsassistent kann mit dem Bcachefs-Dateisystem umgehen, es gibt ein SDK für…
Die Unterstützung von CentOS endet in rund sechs Wochen. SUSE bietet Unternehmen mit SUSE Liberty Linux ein Support-Konzept bis 2028.
Screen Sharing mit dem Raspberry Pi war schon immer ein fehleranfälliges Vergnügen. In der Vergangenheit hat die Raspberry Pi Foundation auf die proprietäre RealVNC-Software gesetzt. Zuletzt war RealVNC aber nicht Wayland-kompatibel. Die Alternative ist wayvnc, ein Wayland-kompatible VNC-Variante: Wie ich unter Remote Desktop und Raspberry Pi OS Bookworm schon berichtet habe, ist wayvnc aber nicht mit allen Remote-Clients kompatibel, insbesondere nicht mit Remotedesktopverbindung von Microsoft.
Anfang Mai 2024 hat die Raspberry Pi Foundation mit Raspberry Pi Connect eine eigene Lösung präsentiert. Ich habe das System ausprobiert. Um das Ergebnis gleich vorwegzunehmen: Bei meinen Tests hat alles bestens funktioniert, selbst dann, wenn auf beiden Seiten private Netzwerke mit Network Address Translation (NAT) im Spiel sind. Das Setup ist sehr einfach, als Client reicht ein Webbrowser. Geschwindigkeitswunder sind aber nicht zu erwarten, selbst im lokalen Netzwerk treten spürbare Verzögerungen auf.

Raspberry Pi Connect setzt voraus, dass Sie die aktuelle Raspberry-Pi-Version »Bookworm« verwenden und dass der PIXEL Desktop in einer Wayland-Session läuft. Das schränkt die Modellauswahl auf 4B, 400 und 5 ein. Ob Ihr Desktop Wayland nutzt, überprüfen Sie am einfachsten im Terminal:
echo $XDG_SESSION_TYPE
wayland
Gegebenenfalls können Sie mit raspi-config zwischen Xorg und Wayland umschalten (Menüpunkt Advanced Options / Wayland).
Die Software-Installation verläuft denkbar einfach:
sudo apt update
sudo apt upgrade
sudo apt install rpi-connect
Nach der Installation erscheint ein neues Icon im Panel des PIXEL Desktops. Über dessen Menüeintrag Sign in gelangen Sie auf die Website https://connect.raspberrypi.com/sign-in. Dort müssen Sie eine Raspberry-Pi-ID einrichten. Die Eingabefelder sind auf ein Minimum beschränkt: E-Mail-Adresse, Passwort (2x) und Name. Fertig!

Um nun von einem anderen Rechner auf den PIXEL Desktop Ihres Raspberry Pis zuzugreifen, melden Sie sich dort ebenfalls auf der Website https://connect.raspberrypi.com/sign-in an. Dort werden alle registrierten Geräte aufgelistet. (Mit einer Raspberry-Pi-ID können als mehrere Raspberry Pis verknüpft werden.)

Bei meinen Tests hat Raspberry Pi Connect ausgezeichnet funktioniert. Der Verbindungsaufbau war problemlos. Der Desktop-Inhalt erscheint in einem neuen Browser-Fenster. Der Desktop-Inhalt wird automatisch auf die Fenstergröße skaliert. Die Bedienung ist denkbar simpel. Über zwei Buttons können Texte über die Zwischenablage kopiert bzw. eingefügt werden.
Raspberry Pi Connect testet beim Verbindungsaufbau, ob sich der Raspberry Pi und Ihr Client-Rechner (z.B. Ihr Notebook) im gleichen Netzwerk befinden. Wenn das der Fall ist, stellt der Client eine direkte Peer-to-Peer-Verbindung zum Raspberry Pi her. Nach dem Verbindungsaufbau fließen keine Daten mehr über den Raspberry-Pi-Connect-Server. Die Verbindungsgeschwindigkeit ist dann spürbar höher. Dennoch ist es empfehlenswert, die Bildschirmauflösung auf dem Raspberry Pi nicht höher einzustellen als notwendig.
Wenn sich Ihr Pi und Ihr Client-Rechner dagegen in unterschiedlichen (privaten) Netzwerken befinden, agiert ein Server der Raspberry Pi Foundation als Relay. Sowohl der Bildschirminhalt als auch alle Eingaben werden verschlüsselt nach Großbritannien und wieder zurück übertragen. Selbst wenn alle Geräte eine gute Internetverbindung haben, ist ein gewisser Lag unvermeidlich.
Details über die Art der Verbindung erfahren Sie, wenn Sie den Mauszeiger auf das Schloss-Icon im Screen-Sharing-Fenster bewegen.

Laut https://www.raspberrypi.com/news/raspberry-pi-connect/ verwendet Raspberry Pi Connect das Verfahren WebRTC. Dieser Standard kommt auch bei Programmen wie Microsoft Teams oder Zoom zum Einsatz.
Wenn die Remote-Desktop-Verbindung nicht im lokalen Netzwerk stattfindet, fließt der ganze Netzwerkverkehr über einen Relay-Server in Großbritannien. Dabei kommt das Protokoll Traversal Using Relays around NAT (kurz TURN) zum Einsatz. Die Daten werden TLS-verschlüsselt.
Der entscheidende Schwachpunkt des Systems besteht darin, dass es aktuell nur einen einzigen TURN-Server gibt. Je mehr gleichzeitige Remote-Desktop-Verbindungen aktiv sind, desto langsamer wird das Vergnügen … (Und besonders schnell ist es schon im Idealfall nicht.)
Raspberry Pi Connect punktet vor allem durch seine Einfachheit.
rpi-connect zu installieren. Allzu hohe Performance-Anforderungen sollten Sie nicht haben. Die Nachlaufzeiten bei Mausbewegungen und gar beim Verschieben eines Fensters sind beachtlich. Für administrative Arbeiten reicht die Geschwindigkeit aber absolut aus.
Schließlich bleibt abzuwarten, wie gut die Software skaliert. Aktuell befindet sich Raspberry Pi Connect noch in einem Probebetrieb. Soweit sich der Raspberry Pi und der Client-Rechner nicht im gleichen lokalen Netzwerk befinden, werden die Bildschirmdaten über einen Relay in Großbritannien geleitet. Aktuell gibt es genau einen derartigen Relay. Je mehr Anwender Raspberry Pi Connect gleichzeitig nutzen, desto langsamer wird es. Die Raspberry Pi Foundation lässt sich aktuell überhaupt offen, ob es den Relay-Betrieb dauerhaft kostenlos anbieten kann.
Seit Nextcloud Hub 8 (29.0.0) ist ChatGPT nicht mehr über den Picker der Nextcloud zu erreichen. Dieser Umstand kann Nerven kosten, wenn OpenAI’s KI-Dienst hin und wieder genutzt wird und man plötzlich feststellt, dass dieser nicht mehr funktioniert. So ging es mir, als ich den in die Nextcloud integrierten KI-Assistenten einem kleinen Publikum vorstellen wollte. Da das neueste Release 29.0.0 noch recht frisch ist, findet man derzeit wenig Hinweise, wie man ChatGPT weiter nutzen kann.
Dies hat mich nun dazu bewogen einen kleinen Artikel hierzu zu schreiben. Grundvoraussetzung ist jedoch ein Account beim US-amerikanischen Softwareunternehmen OpenAI bei dem ein API-Key erstellt wird.
Des weiteren müssen in der Nextcloud die Apps OpenAI and LocalAI integration und Nextcloud Assistant hinzugefügt und aktiviert werden.

Im Anschluss wird der API-Key, wie im Screenshot zu sehen ist, in der App OpenAI and LocalAI integration hinterlegt.

Nun kann man über den neuen Nextcloud-Assistent das KI-Tool nutzen.



Viel Spaß!
Da ich einiges an Zeit in meine auf dem Raspberry Pi 4 laufende Nextcloud investiert habe, wäre es schade, für das aktuelle Raspberry Pi OS 12, alles noch einmal aufsetzen und konfigurieren zu müssen. Obwohl die Entwickler des Betriebssystems von einem Upgrade generell abraten, habe ich mich auf die Suche nach einer guten und funktionierenden Anleitung gemacht und bin auf den vielversprechenden Artikel „Raspberry Pi OS – Update von Bullseye (11) auf Bookworm (12)“ von Sascha Syring gestoßen.
Um das Ganze ausgiebig zu testen, habe ich das Upgrade zuerst auf einem Raspberry Pi 4 durchgeführt, auf dem ein Mumble-Server läuft, den unsere Community produktiv zum Erfahrungsaustausch nutzt. Nachdem dies alles problemlos funktioniert hat, habe ich mich an meinen Nextcloud-RasPi gewagt. Was es weiter zu beachten gab, darauf gehe ich am Ende des Artikels noch ein.
Bevor es los geht muss das System auf den aktuellsten Stand unter Raspberry Pi OS 11 Bullseye gebracht werden. Hierzu führt man Folgendes aus:
sudo apt update && sudo apt upgrade && sudo apt dist-upgrade
Danach werden die Paketquellen auf das neue System Bookworm angepasst. Hierzu öffnet man die /etc/apt/sources.list
sudo nano /etc/apt/sources.list
und kommentiert alle aktiven Quellen, indem man vor jede aktive Zeile eine Raute „#“ setzt. Danach fügt man die drei Zeilen
deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
am Anfang ein und speichert die Datei mit Ctr + o ab und verlässt dann den Editor mit Ctr + x.

Das Gleiche Spiel wiederholt man mit den zusätzlichen Paketquellen.
sudo nano /etc/apt/sources.list.d/raspi.list
Hier wird nun folgende Zeile an den Anfang gesetzt:
deb http://archive.raspberrypi.org/debian/ bookworm main
Die Datei wird mit Ctr + o gespeichert und der Editor mit Ctr + x verlassen. Ist dies geschehen, können die Paketquellen neu eingelesen werden.

sudo apt update
Nun kommt der kniffligste Teil. Die Bootpartition muss an die neuen Gegebenheiten angepasst werden. Dazu wird die alte Boot-Partition ausgehängt.
sudo umount /boot
Dann wird das neue Verzeichnis /boot/firmware erstellt.
sudo mkdir /boot/firmware
Jetzt bearbeitet man die Partitionstabelle:
sudo nano /etc/fstab
Hier wird der Eintrag der Bootpartition entsprechend eingetragen. Bei mir sieht das so aus:

Die Datei wird wieder mit Ctr + o gespeichert und der Editor mit Ctr + x verlassen. Damit die Änderungen wirksam werden, wird systemd neu geladen
sudo systemctl daemon-reload
und die neue Boot-Partition gemountet.
sudo mount /boot/firmware
Im Nachgang werden die aktuelle Firmware und der aktuelle Kernel für das Raspberry Pi OS 12 (Bookworm) installiert
sudo apt install raspi-firmware linux-image-rpi-v8
und der alte Bootloader und Linux-Kernel entfernt.
sudo apt remove raspberrypi-kernel raspberrypi-bootloader
Ist dies geschehen, müssen die Paketquellen nochmalig mit
sudo apt update
eingelesen werden.
Nun kann das eigentlich Upgrade durchgeführt werden. Hierbei stoppt der Vorgang bei den wichtigsten Konfigurationsdateien. Diese werden in der Regel alle beibehalten.
sudo apt full-upgrade
Nun wird das System noch aufgeräumt.
sudo apt autoremove sudo apt clean
Nach dem Neustart
sudo reboot now
sollte nun das aktuelle Raspberry Pi OS 12 laufen. Das installierte Betriebssystem lässt man sich mit
cat /etc/os-release
anzeigen.
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" NAME="Debian GNU/Linux" VERSION_ID="12" VERSION="12 (bookworm)" VERSION_CODENAME=bookworm ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/"
Mit
uname -a
kann man nun den aktuellen Kernel checken. Meine Ausgabe sieht wie folgt aus:
Linux nextcloud 6.6.20+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.20-1+rpt1 (2024-03-07) aarch64 GNU/Linux
(„nextcloud“ in dieser Zeile ist der Hostname)
Abschließend sei darauf hingewiesen, dass das Upgrade einige Gefahren in sich birgt. Bitte vorher unbedingt an ein Backup denken, was im Bedarfsfall wieder eingespielt werden kann!
Eingangs des Artikels hatte ich erwähnt, dass es Weiteres zu beachten gibt. Durch das Upgrade wurden die Einstellungen des Dienstes zu meinem Turn-Server zurück gesetzt. Ein funktionierender Turn-Server ist wichtig, um reibungslosen Verlauf in Videokonferenzen zu ermöglichen.
Wer also wie ich eine Nextcloud auf dem Raspberry Pi installiert hat und bisher meinen Anleitungen gefolgt ist, muss den zeitverzögerten Start des Turnservers, wie im Artikel „coTurn zeitverzögert auf Raspberry Pi starten“ beschrieben, wieder neu konfigurieren. Dazu editiert man die Datei /lib/systemd/system/coturn.service:
sudo nano /lib/systemd/system/coturn.service
Nun fügt man den folgenden Eintrag unter [Service] ein und speichert die Änderung mit Ctlr + o.
ExecStartPre=/bin/sleep 30
Den Editor verlässt man dann wieder mit Ctrl + x. Durch den Eintrag wird nun eine Verzögerung von 30 Sekunden erzwungen. Mit
sudo service coturn restart
wird der Turnserver zeitverzögert neu gestartet. jetzt arbeitet coTURN nach dem nächsten Reboot des Raspberry Pi wie gewünscht.
Viel Erfolg!
Nicht immer lässt sich zeitnah über jede Neuigkeit berichten, manche Ereignisse sind es aber dennoch Wert, Erwähnung zu finden. In dieser Zusammenfassung überblickt die Redaktion alle wichtigen Meldungen aus der Linux-Welt der vorangegangen Woche.
Unser Handbuch zum Raspberry Pi ist soeben in der 8. Auflage erschienen:
Umfang: 1045 Seiten
Ausstattung: Farbdruck, Hard-Cover, Fadenbindung
ISBN: 978-3-8362-9666-3
Preis: Euro 44,90 (in D inkl. MWSt.)
Autoren: Michael Kofler, Christoph Scherbeck und Charly Kühnast
Umfassendes Raspberry-Pi-Know-how!
Highlights der 8. Auflage
Mehr Details zum Buch finden Sie hier.
Heute erscheint die 46. Episode des Risikozone-Podcasts und die zweite Episode, in der es um die xz-Lücke geht. Während es in der vorangegangenen Folge um die technischen Details ging, haben wir uns diesmal der Frage gewidmet, wie so ein Eingriff gegen ein Open-Source-Projekt überhaupt möglich werden konnte. Antwort: Es war umfangreiche psychische Manipulation im Spiel.
Deswegen haben wir den Social-Engineering-Experten Stephan G. Humer eingeladen. Er hat eines der ersten regelmäßigen Social-Engineering-Seminare in Deutschland etabliert und erläutert, was Social Engineering eigentlich ist, welche Methoden angewendet werden und wie man sich davor schützen kann.
Mit der heutigen Episode versuchen wir unserem ganzheitlichen Slogan "Der Podcast über Sicherheit und Zuverlässigkeit moderner Technologien" gerecht(er) zu werden und reden nicht nur über technische Details, sondern auch über sozialwissenschaftliche Aspekte und Kultur. Open-Source-Projekte bestehen nämlich nicht nur aus Code, sondern auch aus vielen zwischenmenschlichen Interaktionen, die eine - wie wir mit der Lücke sehen - auch im Bezug auf Sicherheit nicht zu vernachlässigende Rolle einnehmen.
Um dem knapp zweistündigen Interview in einem Punkt vorwegzugreifen: es gibt keine Patentlösung. Social Engineering ist unvermeidbar und wer glaubt, er wäre dem gefeit, ist umso verwundbarer gegenüber Angriffen. Ein entscheidender Punkt ist aber Gelassenheit und damit verbunden Verantwortungsbewusstsein. Wer ein Projekt beginnt und damit wächst, sollte sich als Maintainer in der heutigen Welt umso mehr Gedanken machen, wie man die Last verteilt, wieder aussteigt und Entscheidungen nicht auf eine Person konzentriert. Die Situation, als Maintainer wenig Zeit für ein Projekt zu haben, ist zwar im Einzelfall natürlich menschlich verständlich, aber ein Warnsignal.
Wir werden auf Zeiten keine zufriedenstellende Lösung finden und mit vereinfachten Lösungsansätzen arbeiten. Trotzdem ist es wichtig, ob solcher Angriffe zu wissen und wenigstens eine gesunde Skepsis an den Tag zu legen.
Wie seht ihr das? Wir freuen uns auf euer Feedback!
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.
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.
Volla Systems hat bereits mehrere Crowdfunding-Kampagnen erfolgreich abgeschlossen. Jetzt startet die Kampagne für das gut ausgestattete Volla Tablet.
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.
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.
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.
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. ;-)
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.
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.
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.