Beiträge von m_ueberall

    und werden diese in einer Linux Distri auch tatsächlich integriert od. ist hier doch bei allen der Platzhirsch OpenSSL da nicht wegzubringen?

    Beide Alternativen werden von allen größeren Linux-Distributionen nicht direkt unterstützt. LibreSSL ist "bei OpenBSD angesiedelt" und wolfSSL ist primär ein kom­mer­ziel­les Pro­dukt. In beiden Fällen sollte schon ein konkreter "business case" vorliegen, um die Integration in eine eigene Linux-Umgebung vorzunehmen/zu beauftragen (Stich­wort Zer­tifizierungen, kommerzieller Support, …). Bislang hat sich meines Wissens niemand gefunden, der eine frei verfügbare Integration aufgrund ab­wei­chen­der APIs/er­for­derlicher Tests in eine Linux-Distribution stemmen wollte/konnte (vgl. den Versuch von Alpine Linux). Und die Distributionen selbst können – zumal OpenSSL ja seit vielen Jahren macht, was es soll – kein Interesse haben, mehrere Alternativen parallel zu warten. Schon die API-Änderungen bei OpenSSL in der jüngsten Vergangenheit haben Distributionen mangels verfügbarer "Arbeitskräfte" teilweise vor große Herausforderungen gestellt, was man auch an fehlenden offiziellen v1.1.1*-Backports für im­mer noch unterstützte Releases (Bsp.: Debian Stretch) sehen kann.

    wüßte jetzt nicht dass Apache, NGINX, ... f. des SSL-Zeug eine Eigenentwicklung haben,

    und nicht auf OpenSSL-Bibliotheken zurückgreifen;

    Es gibt durchaus alternative SSL-Implementationen (LibreSSL, wolfSSL, …) und dementsprechend auch immer wieder Ansätze, diese mit Apache2/Nginx zu kombinieren.

    Benutzt jemand OpenSSL? Da gibbet wohl einen neuen CVE zum Thema BufferOverflow

    https://www.openssl.org/news/secadv/20210824.txt

    Ja, heute um 04:30h hat das Monitoring zuerst wegen CVE-2021-35368 (modsecurity-crs) angeschlagen, ein paar Stunden später, gerade als der zugehörige Backport an­ge­stoßen wurde, kamen dann CVE-2021-3711/CVE-2021-3712 (openssl) dazu. Glücklicherweise ging das ob des guten Timings in einem Aufwasch und in ca. 20 Mi­nu­ten war alles ausgerollt (und beinahe hätte auch der Neustart aller Dienste glatt funktioniert… Instanzen einer gewissen Datenbank sind momentan aus irgendeinem Grun­de et­was "restartresistent"). Mit der Zeit bekommt man dadurch aber ein wenig Übung. :S

    thex : Könnte ich für eine Bezugnahme (gerne hier oder per privater Konversation) die Ticketnummer haben? Laut eigenem Monitoring sind nämlich alle meine .de-Domänen derzeit wieder einmal wie folgt mit Warnungen versehen, was darauf hinweist, dass die automatisierte Re-Signierung (ich selbst habe seit Wochen keine DNS-Einträge verändert) hier noch mindestens einen Fehler hat (lies: alte RRSIG-Einträge werden nicht korrekt entfernt):

    <domäne>.de [2021-08-24T00:10:02+0200]

    <domäne>.de

    Found an invalid RRSIG record in the published zone data.

    This is only a warning, rather than an error, since the zone may contain additional (valid) RRSIG records. However, there is no legitimate reason to have an invalid signatures in the zone data.

    The zone should be resigned or the RRSIG record should be manually removed.

    Haben die netcup Resolver aktuell wieder Schluckauf? :/

    Ich nutze diese eigentlich nicht (gehe stattdessen über dnscrypt-proxy), aber der IRC-Bouncer hatte auch kurz keine Verbindung. Da aber dnsdist "vorne" sitzt (und "mit-" cachen sollte), müßte das bedeuten, dass alle Netcup-Hosts im Cluster temporär keine (DNS-)Anbindung hatten. Gute Gelegenheit, dort nochmal zu gewährleisten, dass hier wirklich verschiedenen DNS-Quellen verwendet werden. (Hilft natürlich nicht, wenn der gesamte IP-Traffic unterbrochen wird.)

    Other than setting up firewalls at operating system level, is there any other approach? The web service has firewall operations. Do they work with the KVM VPS/RS?

    There isn't. The VCP firewall interface doesn't work with KVM (and the SCP you'd use normally does not have any related functionality either).

    Womit man sich so den Samstagabend vertreibt…

    (Erwähnung von debsecan – in Kombination mit ust2dsa auch für Ubuntu-Suiten nutzbar – und debcvescan)

    Nachdem das letztere Projekt inzwischen mit einer Whitelist auf Basis von CVE-IDs und Paketnamen arbeiten kann, ist es bislang mein Favorit, auch wenn der feh­len­de Zu­griff auf die Liste der Ubuntu-CVEs potenziell ein paar (Erwartung: wirklich nicht sehr viele[*]) offene CVE "unterschlagen sollte". Heute habe ich mir auf einen Tip des debcvescan-Autors das eher weniger bekanntere CVEScan-Projekt von Canonical selbst angesehen, und was soll ich sagen? Bei einem ersten Testlauf auf ei­nem Ubun­tu-Fo­cal-Produktivsystem mit 1325 Paketen (davon allerdings einige aus Dritt-Repositories)…

    • spuckt mir debcvescan (unter Verwendung einer manuell erstellten Whitelist für virtuelle Maschinen) eine Liste von 3–4 offenen Sicherheitslücken/CVE-IDs aus (eine davon niedrig priorisiert) – drei, wenn man dem Canonical-Sicherheits­team Glauben schenkt, dass eine Anpassung eines Perl-Moduls nicht erforderlich ist, für welches das Debian-Sicherheitsteam eine Anpassung vorgenommen hat.
    • listet cvescan 500 offene CVE-IDs der Prioritäten low/medium/high/untriaged(=unkategorisiert?) – teilweise mehrere Pakete der Focal-Suite betreffend – auf; dummerweise lässt sich diese Liste standardmäßig nicht direkt mit der Liste installierter Pakete abgleichen, was ich einigermaßen unsinnig finde (muss mir die Dokumentation nochmals zu Gemüte führen). Mal sehen, was nach einer Filterung hiervon übrigbleibt.
      EDIT: Über die Erzeugung eines "Manifests" soll die gewünschte Filterung ("ebenfalls") funktionieren; warum ich diesen Umweg aber auch auf dem lokalen System gehen muss, erschließt sich mir noch nicht. Ergebnis: 0 offene CVE-IDs der vorgenannten Prioritäten. Jetzt bleibt die Frage, warum unter anderem die oben er­wähn­ten drei Einträge auch nicht mehr auftauchen. Es bleibt spannend…

    [*] abgesehen von Kernel-Paketen, die sich stark unterscheiden können; hier baut man u. a. aber auch darauf, dass der Canonical-LivePatch-Dienst zeitnah das Schlimmste verhindert.

    Was wären denn "große" Probleme gewesen? Ich hatte irgendwie in Erinnerung, dass du da öfters mal geflucht hattest? :/

    Große Probleme wären aus meiner Sicht definitiv (a) nicht-dokumentierte Änderungen an den Interna, welche alle Diejenigen kalt erwischt hätten, die nicht grundsätzlich einen Blick auf die Änderungen zentraler Softwarepakete anhand des Quellcodes werfen und alle x.0/x.y.0-Versionen sowieso nur zeitverzögert in Produktivumgebungen einspielen und/oder (b) lang-anhaltende Probleme nach funktionalen Änderungen gewesen. [Ein Beispiel vor allem aus Kategorie (b) und teilweise (a), welches zweifelsohne am oberen Ende der akzeptablen Problemgröße/-schwere liegt – was noch viel zu freundlich ausgedrückt ist – wäre hier die Ersetzung des Enigma-Plugins in Thunderbird. Da ha­be ich tatsächlich geflucht wie ein Kesselflicker, wie man so schön sagt, und werde auch noch eine ganze Weile weiterfluchen.]

    Zur Verteidigung von Rspamd bzgl. der "ARC-Angelegenheit" muss man sagen, dass die Implementation "nicht ganz trivial" ist und die Änderungen letztlich notwendig waren; an­hand der aktuellen Änderungen, welche DMARC betreffen, sieht man inzwischen jedoch, dass die Autoren wirklich Zeit und Mühe darauf verwenden, problematische Punkte zu adressieren (wofür sie ggf. auch bezahlt werden, was keinesfalls zu beanstanden ist; wichtig ist aber, dass es einer großen Masse "für lau" zugutekommt).

    Rspamd spielt nach eigener Einschätzung aufgrund der obenzitierten Punkte also mindestens im oberen Mittelfeld mit, was die Produktpflege anbelangt und könnte alleine durch einen weiteren Repository-Zweig neben dem "stable branch" (etwa durch Einführung eines "latest-stable-Zweigs") den Paketmanagementstrategien vielen An­wen­der entgegenkommen, welche keinen regelmäßigen Blick auf die experimentellen/Debug-Builds werfen (wollen), vergleichbar etwa der Paketierung von LibreOffice für Ubuntu. [Als Nebeneffekt eines laufenden internen Projekts werde ich einen solchen aber demnächst für eigene Zwecke nachbauen können, um bislang fehlende Regeln für ein "Apt-Pinning" und äquivalente Regeln für .rpm-basierte Distributionen zu umschiffen.]

    Habe dazu geradeeben ein video entdeckt welches Fragen aufwirft […]

    Achte auf jeden Fall darauf ob du auch die richtige Version bekommst welche du bestellt hattest!

    Guter Hinweis; die bestellte Version GS305EP ist aber nach dem Bericht von ServeTheHome nicht von einer Modellüberarbeitung betroffen (wahrscheinlich, weil diese von Anfang an für PoE+ spezifiziert wurde). Auf der deutschen Amazon-Seite werden übrigens die beiden Varianten der Version GS305P (PoE/PoE+) oben neben­einander angeboten. Ob da der referenzierte Bericht innerhalb eines Tages Wirkung gezeitigt hat?

    (Mal sehen, ob PoE+++ nach den aktuellen Spezifikationen PoE/PoE+/PoE++ später 90 oder 120W pro Port liefern wird, dann kann man da überall passende NUC 'dran­hängen.)

    Was tut es?

    Beim Überfliegen ist mir jetzt nix Böses aufgefallen. Wolltest du auf etwas bestimmtes hinweisen?

    Ich bin mal faul und kopiere aus #nc-kunden:

    #Lesenswert: AppleNeuralHash2ONNX: Issue #1: Working Collision? (Anmerkung: Laut Kommentaren handelt es sich um ein "[second] pre-image", also ein bereits existierendes Bild mit demselben Hashwert [auf Basis eines problematischen Ausgangsbilds, was es nicht unbedingt besser macht])

    In dem Moment, in dem eine hinreichend große Liste [von Hashwerten] von einschlägigen Bilder verfügbar ist und der Hash-Algorithmus durch Apple nicht (schnell genug) angepasst werden kann, hat dies das Potenzial, ein großes Problem für iPhone-Nutzer zu werden.

    Man kann Sicherheitsupdates auch automatisch einspielen lassen bzw. in regelmäßigen Abständen auch die Software auf dem Server updaten.

    Fürs Protokoll: Diese Aussage halte ich für stark übervereinfacht und in dieser Form keinesfalls dazu geeignet, um eigene Dienste sicher zu betreiben. (Und dieser Meinung war ich… hust… schon vor über einem Vierteljahrhundert, als ich ein paar Jahre Erfahrung damit gesammelt hatte; seitdem haben sich die Voraussetzungen dafür nicht geändert.)