Beiträge von m_ueberall

    Kannst du das ausführen? Habe bisher nichts schlechtes von Wero gehört.

    https://search.brave.com/search?q=was+spricht+gegen+wero fasst eigentlich die wesentlichen Kritikpunkte zusammen (und enthält mehrere weiterführende Links): Abhängigkeit von Banken, Datenschutz-Bedenken, kein Käuferschutz, geringe Händlerakzeptanz, US-Abhängigkeit (AWS), fehlender Kundensupport

    (Wobei ich als Besitzer eines Bankkontos innerhalb der EU eigentlich überhaupt keinen Grund finde, der gegen die Nutzung eines SEPA-Lastschriftmandats spricht, sofern dieses unterstützt wird. Aber jeder wie er mag.)

    CVE:CVE-2026-43501
    Blog-Artikel:Route of Death patch bypass: an intermediate-hop RPL wrap gives a remote OOB write and Linux LPE [nebusec.ai]
    Proof-of-Concept:Route of Root (Linux) [github.com]
    Betroffene Distributionen / Hosts:

    Alle (Kernelversionen 5.7-rc1 – 7.1-rc1)

    net.ipv6.conf.*.rpl_seg_enabled muss 1 sein (aus der Ferne erreichbar) oder nicht-privilegiert {user,net}

    Workaround:Das temporäre Deaktivieren von „unprivileged user namespaces“ beseitigt den lokalen Angriffsvektor, Einstellung rpl_seg_enabled=0 eliminiert denjenigen aus der Ferne.

    mainziman : Worauf bezieht sich " dieses komische "Link"-Zeug? "

    Wenn es das ist, was ich vemute (Weiterleitung): Bei "easybank" (ex-"Barclays") muss ich bei Kartenzahlungen an einen "neuen"* Empfänger, die in Zukunft automatisch durchlaufen sollen, beim ersten Mal online mein Einverständnis dazu bekunden, ansonsten ist derselbe Vorgang (Zugriff über Portal des Kreditinstituts) immer zu wiederholen.

    * kann sein, dass aufgrund von (geänderten?) Vorschriften auch vorherige Empfänger betroffen wären, für welche ich die Karte vor X Jahren schon einmal verwendet hatte, aber die obige Abfrage noch nicht kam/implementiert war. Ich vermute, dass das der Grund war, warum die letzte Amazon-Prime-Rechnung nicht automatisch durchlief (was extrem seltsam war, weil "normale" Einkäufe direkt über das ebenfalls verknüpfte Bankkonto laufen, aber das ist ein anderes Thema).

    Vielleicht habe ich es in der EOS-Dokumentation nur nicht gefunden, aber gibt es hier ein paar "Minimalausstattungsmerkmale" der VMs (oder sind derartige geplant), welche sich von den bisherigen VPS-Modellen unterscheiden? Mit Blick auf die "Confidential Computing"-Bestrebungen/-Hardware-Unterstützung (vgl. u. a. die aktuelle Canonical-Ankündigung des "virtualization hardware enablement (HWE) stack[s]") fällt mir hier der Stichpunkt "Confidential VMs with AMD SEV-SNP or Intel TDX" ein.

    Habe früher neben opendkim, opendmarc auch policyd-spf genutzt . Mittlerweile nutze ich rspamd. Damit können alle Dienste eingebunden werden.

    Ja, rspamd hat die Mailserverkonfiguration deutlich vereinfacht. Dank der großen Nutzerbasis ist auch die sehr aktive Weiterentwicklung sichergestellt.

    EDIT: Unabhängig davon sollte man neue Versionen für eine derart zentrale Komponente immer im Auge haben und selbige entsprechend absichern:

    rspamd_critical414.png

    Mir ist allerdings immer noch nicht klar, warum der Einsatz einer Virenscanner Software ein Sicherheitsrisiko darstellen soll.

    So pauschal formuliert ist es auch keins, sofern man davon nicht ableitet, dass Software virenfrei ist, weil der Virenscanner nicht anschlägt.

    Jetzt fragen sich wohl einige: Bist du verrückt?

    […]

    Wie oben erwähnt, läuft der Live-Testserver bereits mit dem eigenen Serverdienst. […] Später werde ich vielleicht sogar mal einen Link teilen (der Testserver läuft auf einem Netcup-Server).

    Sofern der "Live-Testserver (mit PHP-Unterstützung)" von außen erreichbar ist und nicht innerhalb eines nicht-privilegierten System-Containers läuft, ist das leider grober Leichtsinn. Gerade bei Webservern (in Verbindung mit "angebundenen" Script-Sprachen) gibt es für Linux eine Vielzahl von RCE-Einbruchtests (remote code execution). Und im "Security"-Unterforum finden sich ein paar ausgewählte Beispiele, warum es gerade heute gefährlich ist, nicht mit entsprechender Erfahrung/Vorbereitung in abgeschlossenen Umgebungen zu testen* (unter Verwendung von Werkzeugen, welche Sicherheitslücken aufspüren) oder überhaupt das Rad neu zu erfinden. (Je größer die Nutzergruppe, um so höher die Wahrscheinlichkeit, dass das Mehraugenprinzip Fehler aufdeckt; "selbstgestrickte" Lösungen, insbesondere, wenn alles von Grund auf neu gebaut wird, sind extremst anfällig.)

    Wenn wie oben geschrieben zunächst der Fokus auf Windows liegt (ohne Nutzung des dortigen Linux-Subsystems), gelingt dort eine Abschottung eigentlich nur mithilfe einer virtuellen Maschine (was bei Netcup ohne nested virtualization keine Option ist). (Und generell ist die Absicherung von Windows auf einem öffentlich erreichbaren (Einzel-)Host (ohne vorgeschaltete externe Zugangskontrollen), zumal in Eigenregie, sowieso nicht machbar.)

    In einer Zeit, wo es (trotz einer – im Vergleich mit den vor 20–30 Jahren verfügbaren teuren Ressourcen – "relativ überschaubaren" Kostenexplosion, was RAM/Festplatten anbelangt) überhaupt kein Problem darstellt, Testumgebungen daheim (entweder offline oder stark abgeschirmt) innerhalb weniger Minuten "aus dem Boden zu stampfen" (unter Verwendung eines NUC/SBC/des eigenen Laptops, der noch 8GB RAM übrig hat für eine VM), verstehe ich immer weniger, warum Tests unbedingt in Umgebungen durchgeführt werden, über die man keine vollständige Kontrolle hat. Das ist so, als würde man irgendwelche Geräte/Aufbauten die meiste Zeit des Tages unbewacht auf dem Marktplatz stehen lassen oder Fotos der eigenen VISA-Karte (Vorder- und Rückseite) irgendwo im Freien aufhängen. Intuitiv muss doch klar sein, dass das keine Bombenidee ist, alleine schon deswegen, weil es die Mehrheit der Mitmenschen eben nicht macht … ?

    *und zwar, weil fast alle Linux-Kernelversionen derzeit bekannte/laufend bekannt werdende ("Gruppen von") Sicherheitslücken aufweisen, die durch Administratoren nicht umgehend geschlossen werden können (inklusive einer großen Zahl von LPE-Lücken (local privilege escalation), welche kombiniert mit einem funktionierenden RCE-Einbruch ganz schnell die Kontrolle des betreffenden Hosts kosten können).

    • Läuft Canonical Livepatch zuverlässig auf Produktivservern?
    • Gab es Probleme oder unerwartete Nebenwirkungen?
    • Gab es Probleme im Zusammenhang mit DKMS-Modulen oder anderen Kernel-Modulen nach der Verwendung von Livepatch?

    Ich verwende Livepatch seit einigen Jahren auf mehreren amd64-Hosts (Erfahrungen mit arm64-Hosts sammle ich gerade erst, hier dauerte die Einführung etwas länger) und kann obige Fragen mit ja, nein, nein (Einsatz von OpenZFS*-DKMS-Modulen auf allen Servern) beantworten.

    (Was ebenfalls länger dauerte, war übrigens die Klärung/Implementation, dass eine Livepatch-Lizenz für alle Ubuntu-Installationen, also inklusive aller Container auf dem Host, nutzbar ist. Das ist bspw. wichtig für die Build-Server hier.)

    Auch die von SiebenG genannte Verzögerung kann ich aus der Erinnerung nicht generell nachvollziehen; ich hatte dies einmal vor Jahren anhand eines Beispiels kontrolliert (auf einem Server, der zu diesem Zeitpunkt nicht zeitnah neu gestartet werden konnte), und da ging es entsprechend der Kritikalität wirklich zügig. Ansonsten würde der Einsatz von Livepatch – welcher bei einer entsprechenden Anzahl von Hosts ja kostenpflichtig wird und für mich einer der wenigen (und leider immer weniger werdenden) Gründe ist, bei Ubuntu zu bleiben – auch nicht viel Sinn machen. Die neuen Versionen von canonical-livepatch listen die verfügbaren Livepatches für installierte Kernel mit Zeitstempeln auf; allerdings habe ich diese historisch niemals archiviert (und obiges Beispiel/Log von einem Vereinsserver hier bei Netcup wurde durch eine Neuinstallation schon lange wieder restlos entfernt).


    * Bzgl. "OpenZFS": Das sind selbstgebaute Pakete aus dem Upstream-Repository, welche alle modifizierten ZFS-Pakete von Canonical (zwecks Vereinheitlichung auch über Betriebssystemgrenzen hinweg) ersetzen; andere DKMS-Module verwende ich nicht:

    CVE:CVE-2026-43499
    Blog-Artikel:GhostLock, a stack-UAF that has existed in ALL Linux distributions for 15 years [nebusec.ai]
    Proof-of-Concept:

    GhostLock (Linux) [github.com]

    "We'll soon publish how we use GhostLock to root Android and bypass KASLR and KCFI." [x.com]

    Betroffene Distributionen:Alle (Kernelversionen 2.6.39–7.0.x); laut Blogartikel betrifft dies insbesondere auch alle Android-Geräte!
    Workaround:Kernelupdate erforderlich