Was haltet Ihr eigentlich davon? Overkill oder eher gute Basis/Genug?: https://shop.opnsense.com/product/dec2750-opnsense-rack-security-appliance/
Finde es immer ärgerlich wenn in so Appliance jahrelang die gleichen bzw. veraltete CPUs verbaut werden, auch wenn es schon lange Nachfolger gibt, selbst wenn die Performance nach wie vor gut ist (z.B. z.B. Security-Schwachstellen in der Hardware, man könnte etwas aktuelles für den gleichen Preis bekommen, etc.).
Wie sieht es denn bei den IPU Systemen von NRG Systems und auch DEC mit der Firmwarepflege (UEFI/BIOS) aus? Dazu konnte ich eben nichts finden.
und ich laufe nicht jedem Firmware-Update hinterher. Ich hab ein NRG-System für meine OPNsense, das wird kein Firmwareupdate drauf gemacht, das Teil läuft stabil und das soll so bleiben. Das Risiko einer neuen Firmware gehe ich garnicht ein, weil ich keinen Grund für sehe.
Ich arbeite selber im IT-Bereich
Overkill geht ja immer, das ist leicht. Es bedacht für den Homeuser zu machen ist die Kunst mittlerweile. Und wie hier schon erwähnt, wenn es einmal richtig läuft werden sehr sehr sehr selten Updates gemacht, alleine weil das Ding 24/7 läuft. Support ist ja da.
Security Schwachstellen kommen Dir offenbar nicht in den Sinn oder scheinen keinen Grund darzustellen.Aktuelles Beispiel: https://www.msn.com/de-de/nachrichten/digital/f5-big-ip-it-sicherheitslücke-mit-hohem-risiko-warnung-erhält-update/ar-AA1i5vom
Das mit den Security-Updates habe ich auch mal so vereinfacht betrachtet. Man kann da nach der Maxime "better be safe than sorry" vorgehen - nur funktioniert das leider ohne weiteres nicht:1. Wenn man mal wirklich mit einem Security-Checker wie z.B. Wazuh einen Vulknerability-Scan durchführt, stellt man fest, dass bei weitem nicht alle bekannten Bugs auch gefixt werden. Beispielsweise waren in meinem voll gepatchten Ubuntu 22.04-Server zu meiner Überraschung noch ca. 80 ungepatchte CVEs enthalten, teilweise 5 Jahre alt. Als ich da stichprobenartig nachgesehen habe, waren es bekannte CVEs, wo schon Debian als Ubuntu-Basis "wontfix" zu gesagt hat.2. Ein weiteres Beispiel um Thema Microcodes: Ich habe oben schon meine Anleitung für OpnSense verlinkt. Allerdings gibt es auch da ein "aber": in den von FreeBSD und Linux bereitgestellten Microcode-Paketen sind nicht immer die neuesten Microcodes drin. Die kann man sich unter Linux aber selbst bauen: https://www.reddit.com/r/linux/comments/15xvpfg/updating_your_amd_microcode_in_linux/. Das gilt u.a. auch für die in der Deciso 27x0 und 7x0 verbauten AMD Ryzen Embedded V1500B.3. In vielen Fällen sind die Entscheidungen, ein bestimmtes Paket nicht zu fixen, nachvollziehbar - nämlich, wenn das Szenario, in dem es eingesetzt wird, nicht zum Tragen kommt. Ein gutes Beispiel ist aktuell curl (siehe hier), weil der in OpnSense eben keinen Socks5-Proxy verwendet.4. Bei Open-Source gibt es immer einen Tradeoff zwischen Sicherheit und Funktionalität: Da es für die wenigsten Pakete gleichzeitig LTS- und aktuelle Versionen gibt, hat man das Problem, dass bei Bekanntwerden von Sicherheitslücken ein Patch auf die "alte", eingesetzte Version nicht stattfindet, die "neue", gepatchte Version aber leider andere Funktionen und/oder APIs hat, die zum Rest des Systems nicht passen und umfangreiche Änderungen zur Folge hätten.Insbesondere Nummer 4 ist in der Realität ein großes Problem. Ich habe einen Freund, der Embedded-Systeme baut, die auf einer alten Version von OpenWRT basieren. Darin ist OpenSSL 1.0 enthalten, worauf der SFTP-Client basiert. Inzwischen haben fast sämtliche Provider von FTP-Servern auf OpenSSL 1.1.x oder höher umgestellt, so dass keine Verbindungsmöglichkeit mehr besteht, weil die Ciphers inkompatibel sind, da OpenSSL 1.1 die "unsicheren" Ciphers abgeschaltet hat und OpenSSL 1.0 die neueren noch nicht kann.Er müsste die gesamte Basis seines Systems auf eine neuere Version von OpenWRT umstellen, was aber nicht geht, weil er mangels Speicherplatz nicht alles im Flash-ROM unterbringen kann und Teile der Software ins RAM nachladen muss.Gleiches Problem bei kommerziellen Anwendungen - ich arbeite viel im Homebanking-Umfeld. Wenn dort z.B. Java-Basisbibliotheken zum Einsatz kommen, müsste man in Zweifel bei aufkommenden Sicherheitslücken den gesamten Basis-Stack für die Anwendung austauschen. Bevor man das macht und die Anwendung produktiv setzen kann, braucht man wochenlange Tests, ob die Funktionalität danach noch gegeben ist.Diese Lücke zwischen "Rückwärts-Kompatibilität" und "Sicherheit" wird aktuell z.B. beim Linux-Kernel noch weiter aufgerissen, weil die Supportdauer für LTS-Kernels verkürzt wird.Für die Anbieter von Downstream-Anwendungen (wie Deciso mit OpnSense) ist das eine Gratwanderung: Sollen sie - bevor die Upstream-Pakete gefixt sind (falls sie das tun) - selber patchen? Eher nicht.Als Endnutzer ist die Strategie "sofort patchen" tragfähig - kann halt sein, dass man dann irgendein Problem bekommt. Selbst wenn man bei OpnSense immer aktuell bleibt, gibt es immer wieder diese Situationen, wie dieses Forum beweist. Nicht zuletzt hinkt deswegen die Business-Variante immer ein wenig hinterher, weil dort eben die Auswirkung von Bananen-Ware auf potentiell viele Benutzer unerwünscht ist.
