Router Build + allgemeine Fragen.

[deltaexray]

@tuxtom007

Hab's grad mal gecheckt, der MaxCPE wert ist bei mir auf 3 gesetzt. Bin ich ehrlich gesagt sehr froh drüber, möchte mich ungern mehr als nötig mit Vodafone auseinander setzen, das ist hier sowieso schon Glück das alles läuft;D

[Tuxtom007]

Was haltet Ihr eigentlich davon? Overkill oder eher gute Basis/Genug?:
https://shop.opnsense.com/product/dec2750-opnsense-rack-security-appliance/

Ein g..... Teil, aber für Hausgebrauch vollkommen oversized.
Bekannter von mir hat davon zwei in seinem Netz, das ist aber ein Netzwerk welches sich über sein Privathaus und sein Firma nebenan erstreckt, angeschlossen an 2 x 1 GBit Glasfaser.
Die beiden OPN's langweilen sich damit gewaltig.

Ich würde mir lieber einen MiniPC kaufen mit mehren NIC's drin ( achte am besten direkt auf 2,5GBit NIC's ), ordentlich SSD da rein, 16Gb Speicher und ab dafür - kostet dich gerade mal die Hälfte.
Die OPNSense Software ist vom USB-Stick in 5min installiert, die Arbeit fängt dann an mit der Konfiguration.

[stevie]

Wenn ich mir jetzt für OPNsene neue Hardware kaufen würde, dann würde es wahrscheinlich bei mir eine Protectli VP2420 (J6412, 4x 2.5 GBe, OpenCore und deaktivierte Management Engine) oder eine IPU410 von NRG Systems (N100, 4 x 2.5 GBe) werden.
Preislich liegen die gleich. Protectli hat den Vorteil mit OpenCore, dafür hat die IPU4100 die aktuelle CPU.

DEC2750 hat leider einen V1000 verbaut, obwohl dieser schon zwei Nachfolger hat (aktuell ist V3000 basierend auf Zen 3). 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.).

[meyergru]

Und das, obwohl das Design ja ohnehin geändert wurde (I225-V statt I211).

[stevie]

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.

[Tuxtom007]

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.).

Nicht unbedingt ist das Neuste immer das Beste - gerade Hardware die im 24/7 Dauerbetrieb beim prof. Anwendern, muss stabil laufen und das über lange Zeit und vor allem über lange Zeit auch supportet werden.

Ich hab schon oft genug erlebt, das neue Hardwarekomponenten massiv Ärger machen.

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.

Ich arbeite selber im IT-Bereich 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.

[stevie]

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.

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 Bundesamt für Sicherheit in der Informationstechnik (BSI) hat am 10.10.2023 einen Sicherheitshinweis für F5 BIG-IP veröffentlicht. Der Bericht weist auf mehrere Schwachstellen hin, die von Angreifern ausgenutzt werden können. Betroffen von der Sicherheitslücke sind das Betriebssystem BIOS/Firmware sowie das Produkt F5 BIG-IP. Zuletzt wurde diese Warnung am 11.10.2023 aktualisiert."

Ich arbeite selber im IT-Bereich

Vulnerability & Patch Management?!

[meyergru]

Naja, das ist der Vergleich zwischen Äpfeln und Birnen... bei F5 spricht man zwar von "Firmware" Bugs, das ist in dem Fall aber die komplette F5-Software. Für derlei Patches ist dann ja OpnSense selbst zuständig.

Bei OpnSense ist "Firmware" ja nur für das Booten und eventuell noch für Microcode-Updates zuständig. Letzteres kann man in OpnSense selbst erledigen, auch wenn man z.B. mit einer China-Box kaum eine Chance auf solche Security-Updates hat.

[stevie]

Improper access control in the  BIOS firmware for some Intel(R) Processors

K000134744: Intel BIOS vulnerability CVE-2022-38087
https://my.f5.com/manage/s/article/K000134744

K000137201: Intel BIOS vulnerability CVE-2022-37343
https://my.f5.com/manage/s/article/K000137201

Ist auch egal und war nur das erst beste Beispiel, das ich gefunden hatte.
In der Firmware (oder in der CPU) kann es Schwachstellen geben, die über UEFI/Firmware-Updates beseitigt werden. 

[deltaexray]

@Tuxtom007

Interessante Einsicht, vor allem da man als Privatkunde sowieso nicht bei TK Bestellen kann und ich sowieso schon in Frage gestellt habe, wie aktuell die Hardware da ist.
Zumal die neueren, wie ein N100, Ja durchaus sehr sehr gut sind. Wie bei NRG

@stevie

Habe den auch im Blick, alleine weil die Dinger klein sind und jetzt nicht die Welt einem vom Kopf fressen.
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.

[stevie]

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.

Ich nehme seit Jahren zeitnah jedes Update mit. Egal ob Software oder Firmware (bei mir OpenCore). Bei mir läuft das Ding ebenfalls 24/7.
Ein Security-Gerät sich hinzustellen, aber dann die Beseitigung von Security-Schwachstellen (die auch die Firmware/UEFI betreffen kann) teilweise zu ignorieren, ich weiß nicht. Gut, muss jeder selber entscheiden.

Ob die IPU Systeme hinsichtlich Firmware (UEFI) gepflegt werden oder nicht, ist mir zumindest nicht klar.

[meyergru]

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.

[Tuxtom007]

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

Meine Aussage bezieht sich auf "mich" als Privatperson.

ich hab auch keine F5's zuhause rumstehen.

[deltaexray]

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.

Im Großen und ganzen: Ja. Das Sicherheitslücken immer beseitigt werden sollten bzw. das man sich darum immer sofort kümmern sollte, ist glaube ich jedem hier soweit klar.
Das es aber manchmal, je nach Update, ein paar extra Probleme erzeugen ist so der einzige Grund, warum viele Updates erst einmal abwarten und dann erstmal schauen wie es performt - Siehe Windows Updates.

Ich glaube im großen und ganzen, ist es immer ein "Wie sehr habe ich mich mit dem Thema auseinander gesetzt/Wie sehr bin ich bereit das alles abzuwägen und mich dort einzuarbeiten."
Denke aber, das zum Beispiel die NRG Systeme durchaus eine sehr gute Anlaufstelle sind, wenn man etwas möchte was gut ist. Sicher gibt's auch auf Amazon genug und genügende Geräte, eine seriöse Anlaufstelle zu haben schadet jedoch nie.

[deltaexray]

Hallo an alle, die eventuell hier noch mitlesen 👋🏽

Die Tage gab's bei Amazon ein zeitlich begrenztes Angebot für die HUNSN I3 N305, was mich schlussendlich dazu bewegt hat dieses Projekt aus der Planungsphase in die Umsetzungsphase zu bringen. Gerät ist bestellt, kommt Ende April bzw. Anfang Mai, der Speicher kommt die Tage.

Jetzt geht's nur daran die ganzen Dienste einzurichten aber das ist ja auch der Spaß;)