Neuer Mini-PC mit ECC (2025 Edition)

A

Azazyel

Well-Known Member
Meine altgediente PC Engines APU2 ist langsam in die Jahre gekommen und macht Zicken (trotz neuestem BIOS weigert sie sich ab und zu booten, auch nach BIOS-Reset sowie Tausch von SSD und Netzteil).

Sie leistet ansonsten nach wie vor gute Dienste als kombinierter Router und Server für diverse Dienste im 24/7-Betrieb. Man merkt aber, dass die CPU von 2011 ist und die 4 schnarchlangsamen CPU-Kerne schnell überfordert sind. 4 GB RAM sind heutzutage auch etwas wenig.

Jetzt wird es Zeit für neue Hardware. Die Anforderungen:
  • klein
  • leise
  • halbwegs stromsparend
  • solide Leistung
  • 32 GB RAM
  • x64_86 (die Unterstützung für ARM und RISC ist OS-übergreifend für meinen Geschmack zu schlecht)
  • Zumindest FreeBSD und Linux sowie idealerweise OpenBSD sollte die Hardware zu 100% unterstützen (NetBSD ist egal)
  • Ganz wichtig: ECC
Gerade ECC ist nicht trivial. Es gibt reichlich Alternativen, die bis auf ECC alles erfüllen.

Möglichkeiten, die ich bis dato entdeckt habe:
  • ODROID-H4 mit 4-8 Kernen Alder Lake-N passiv gekühlt, 1-2 LAN-Ports, 1 SO-DIMM DDR5 (d.h. aktuell bis zu 48 GB RAM) mit Inline ECC (a.k.a. In-Band ECC oder IBECC) für 150-350€ plus 150€ RAM plus Storage
  • Lattepanda Sigma mit Intel i5-1340P 4 P-Cores plus 8 E-Cores (d.h. 16 CPU-Threads), aktiv gekühlt, 2 LAN-Ports und 32 GB verlötetem LP-DIMM DDR5 (ebenfalls mit In-Band ECC) für 800€ plus Storage
  • Selbstbau mit Intel (ECC braucht anscheinend ein Workstation-Board mit W680-Chipsatz, was auch gleich ordentlich ins Geld geht)
  • Selbstbau mit AMD (ein Threadripper wäre Overkill - zu teuer und energiehungrig)
Der Selbstbau mit AMD hat auch seine Herausforderungen:
  • ein passendes AM5-Mainboard finden, das nicht nur mit ECC-DIMMs läuft (da gibt es reichlich), sondern die ECC-Informationen auch auswertet (ist Asrock hier noch der beste Hersteller?)
  • passende Ryzen Pro CPU
Hat hier jemand im Forum Erfahrungen mit obigen Optionen oder gar andere Empfehlungen, die ich nicht auf dem Radar habe?
 
Ich habe mein APU2 durch ein Protectli getauscht und dort laeuft OpenBSD und FreeBSD sowohl mit normalem BIOS als auch mit Coreboot. Kann ich daher nur empfehlen. Gutes Gehaeuse, luefterlos und daher nicht hoerbar, ausreichend Leistungsreserven und RAM kann man je nach Modell auch tauschen oder aufruesten. Allerdings sind die nicht ganz guenstig, aber ihren Preis meiner Meinung nach wert.

EDIT: Habe die Anforderung von ECC ueberlesen. Da bin ich leider mit Protectli ueberfragt, ob das unterstuetzt wird.
 
midnight schrieb:
Ich habe mein APU2 durch ein Protectli getauscht und dort laeuft OpenBSD und FreeBSD sowohl mit normalem BIOS als auch mit Coreboot. Kann ich daher nur empfehlen. Gutes Gehaeuse, luefterlos und daher nicht hoerbar, ausreichend Leistungsreserven und RAM kann man je nach Modell auch tauschen oder aufruesten. Allerdings sind die nicht ganz guenstig, aber ihren Preis meiner Meinung nach wert.
Zum Vergrößern anklicken....

Die unterstützen meines Wissens aber kein ECC, oder?
 
Azazyel schrieb:
Meine altgediente PC Engines APU2 ist langsam in die Jahre gekommen und macht Zicken (trotz neuestem BIOS weigert sie sich ab und zu booten, auch nach BIOS-Reset sowie Tausch von SSD und Netzteil).
Zum Vergrößern anklicken....

Ich kann nicht zu 100% helfen aber 1,2 noch sehr frische Erfahrungen berichten.
Letztes Jahr hab ich mehrere Systeme, einen OpenBSD Homeserver mit uralten ASROCK-Passiv-Board und einen QOTOM Mini-PC der den Router gespielt hat sowie ein paar extern gemietete VMs durch einen neuen Homeserver ersetzt.
Da das Gerät auch etwas spaß machen sollte, ist es nach etwas Beratung von @mr44er ein AMD Ryzen 5 7600 mit Asus-Board, 128GB Ram und neben NVME und SATA-SSD auch 3x SAS-HDD geworden. Das passt so nicht mehr in ein kleines Gehäuse, so das es ein ordentliches Midi-Gehäuse geworden ist mit Full-Size Mainboard, SAS und 10G Ethernetcontroller und den 3,5" Platten und guter Belüftung. Dadurch ist das auch nicht unbedingt "Flüsterleise" (Aber auch nicht super laut, am ehesten hört man noch die Platten etwas IO drauf ist). Das ding braucht auch etwas Strom was preislich aber dtl. unter den gekündigten externen VMs liegt. Damit bin ich momentan SEHR sehr zufrieden.
Das hilft dir nur bedingt weiter da du es ja klein und leise haben möchtest, aber was für dich villeicht interessant ist:

Die Entscheidung AM5 + DDR5 mit diesem ECC "light" nenn ich es mal war WIRKLICH gut, das macht sehr viel spaß und ein drauf virtualisiertes OpenBSD schafft easy 10-20Gbit* zu routen und mit einfachen regeln zu pfen.
Da du das nicht ausgeschlossen hast wäre das auf jedenfall mein tipp in die Richtung zu schauen. Da gibt es ja auch wenn das wichtig ist durchaus kompaktere Optionen. Und wenn man etwas schaut kann man sich ja z.B. mehr Ram, mehr Speicher, villeicht ne größere NIC oder so als Zukunftsoption offen halten. Das ist bei den sehr kompakten Geräten ja leider nur begrenzt möglich.

(Da läuft als Host ein Archlinux, ZFS und als routing-vm ein OpenBSD unter qemu und ein paar andere vms mit unterschiedlichen Betriebsystemen)
*(Ich hatte für gute Messungen ab irgend nen Punkt gewisse Probleme einen guten Test zu bauen)
 
roema schrieb:
Warum unbedingt ECC?
Zum Vergrößern anklicken....

Weil ich in 30 Jahren in der IT schon genug (schleichende) Datenkorruption und Systeminstabilität durch RAM-Defekte erlebt habe, um die paar Euro Aufpreis zum Ausschluss dieser fiesen Fehlerquelle gerne in Kauf zu nehmen.

Wer einmal erlebt hat, wie ein simples cp fileA fileB zu einem vorerst unbemerkt defekten fileB geführt hat, weil es einen unbemerkten RAM-Fehler gab, möchte nicht mehr auf ECC verzichten - bei keinem System.

CommanderZed schrieb:
Das ist bei den sehr kompakten Geräten ja leider nur begrenzt möglich.
Zum Vergrößern anklicken....

Merci für den ausführlichen Bericht. :)

Ich liebäugele auch mit der AM5-Option, habe aber noch keine verifiziert ECC-fähige Kombination aus Mainboard und CPU gesehen.

Das bisschen Mehrbedarf an Platz und Strom nehme ich zugunsten der besseren Erweiterbarkeit wohl auch gerne in Kauf.
 
Zuletzt bearbeitet:
Naja, da gäbe es einfache Möglichkeiten um zu verifizieren ob fileb gleich filea ist...

Ich persönlich finde das etwas übertrieben und muss zugeben, dass ich in meinen 20 Jahren noch keinen solchen Fall hatte...

Mich würde die Meinung von @Yamagi zum Thema ECC interessieren.

Ich würde übrigens NIE Firewall und andere Dienste auf einer Hardware kombinieren.
 
roema schrieb:
Naja, da gäbe es einfache Möglichkeiten um zu verifizieren ob fileb gleich filea ist...
Zum Vergrößern anklicken....

Das problem ist ja nicht unbedingt wenn es auffällt, sondern wenn es nicht auffällt. Wie oft prüfst du ob files die du kopierst hast tatsächlich richtig kopiert worden? Und auch die 875 anderen Fälle wo der Ram an komischen Problemen Schuld ist. Wenn ich in den letzten Jahren "komische Hardwareprobleme" hatte war es fast im RAM oder VRAM, dann laaaaange nichts und dann so allgemeine elektronische Probleme, meist irgendwas vom Mainboard.

roema schrieb:
Ich würde übrigens NIE Firewall und andere Dienste auf einer Hardware kombinieren.
Zum Vergrößern anklicken....
Warum genau, sofern man es virtualisiert voneinander dann doch wieder recht sauber trennt? (Insb. im privaten Rahmen und nicht in größeren Business-Umgebungen?)

Ich hab das vor nem Jahr begonnen und bin weiterhin sehr zufrieden und hab 0 Nachteile bislang bemerkt.

Aus sicherheitssicht müsste dazu ja jemand das OpenBSD mit der pf bei mir übernehmen (das neben dhcp, slaac und DNS ausschließlich per SSH von ausgesuchten lokalen Clients erreichbar ist und dieser angriff müsste dann noch im idealfall irgenwas mit der virtualisierung zu tun haben damit es so richtig als damit zusammenhängendes Problem zählt)) und dann noch aus dem QEMU ausbrechen. Das halte ich schon für so private Umgebungen für sehr an den Haaren herbei gezogen. Wenn du das anders siehst hast du ja sicher links zu echten Fällen wo das passiert ist.
 
Im privaten Bereich habe ich auch schon OpenBSD als Host und ein paar virtuelle Maschinen (vmm) mit OpenBSD Guests betrieben. Der Host hat die Firewall uebernommen (pf und relayd), die Guests dann die Dienste. Das halte ich persoenlich recht sicher, solange man dem Host trauen kann. Das ist vermutlich unter FreeBSD mit jails aehnlich. Anders saehe es allerdings aus, wenn ich z.B. vmware oder hyper-v als Host nutzen wuerde und dann eine OpenBSD Firewall als Guest. Auch wenn alles ueber den OpenBSD Guest nach aussen ins Internet geroutet wird, ist noch immer hyper-v oder vmware als Host-Abstaktionsschicht darunter. Es ist schon oefter vorgekommen, dass vmware oder hyper-v schwerwiegende Sicherheitsluecken hatten und von aussen angreifbar war oder zum crashen gebracht werden konnte. Von daher wuerde ich CommanderZed schon zustimmen, dass man das sauber trennen kann, solange man dem Host vertraut.
 
CommanderZed schrieb:
Das problem ist ja nicht unbedingt wenn es auffällt, sondern wenn es nicht auffällt. Wie oft prüfst du ob files die du kopierst hast tatsächlich richtig kopiert worden?
Zum Vergrößern anklicken....

Oder ob dein Backup nicht nur erfolgreich durchläuft, sondern auch der Restore identische Dateien produziert. Ohne ECC speichert dein Backup nämlich brav Dateien mit Bitfehlern und stellt die Bitfehler auch genauso wieder her.

CommanderZed schrieb:
Und auch die 875 anderen Fälle wo der Ram an komischen Problemen Schuld ist. Wenn ich in den letzten Jahren "komische Hardwareprobleme" hatte war es fast im RAM oder VRAM, dann laaaaange nichts und dann so allgemeine elektronische Probleme, meist irgendwas vom Mainboard.Beim Kompilieren auf FreeBSD schlägt auf einmal der Build fehl. Beim nächsten Versuch läuft er einfach durch. RAM?
Zum Vergrößern anklicken....

All die kleinen Glitches, Abstürze und vieles mehr, was sich in vielen Fällen als mehr oder minder sporadischer RAM-Fehler herausstellt.

CommanderZed schrieb:
Warum genau, sofern man es virtualisiert voneinander dann doch wieder recht sauber trennt? (Insb. im privaten Rahmen und nicht in größeren Business-Umgebungen?)
Zum Vergrößern anklicken....

Anhand der Beschreibung sollte es vielleicht hervorgegangen sein, es ist für meinen Privatgebrauch zuhause. Und Router ist auch relativ, steht das Ganze doch sowieso hinter einer FRITZ!Box und ist von außen nur via Wireguard erreichbar.

CommanderZed schrieb:
Ich hab das vor nem Jahr begonnen und bin weiterhin sehr zufrieden und hab 0 Nachteile bislang bemerkt.
Zum Vergrößern anklicken....

Mit 32 GB RAM plus VT-x oder AMD-V wird es bei mir sowieso auf Virtualisierung hinauslaufen. Qemu/KVM habe ich auch im Einsatz und ich bin sehr zufrieden damit. Der Overhead ist minimal; die Möglichkeiten enorm.

CommanderZed schrieb:
Aus sicherheitssicht müsste dazu ja jemand das OpenBSD mit der pf bei mir übernehmen (das neben dhcp, slaac und DNS ausschließlich per SSH von ausgesuchten lokalen Clients erreichbar ist und dieser angriff müsste dann noch im idealfall irgenwas mit der virtualisierung zu tun haben damit es so richtig als damit zusammenhängendes Problem zählt)) und dann noch aus dem QEMU ausbrechen. Das halte ich schon für so private Umgebungen für sehr an den Haaren herbei gezogen. Wenn du das anders siehst hast du ja sicher links zu echten Fällen wo das passiert ist.
Zum Vergrößern anklicken....

Das sieht bei mir ähnlich aus. Meine realistischen Bedrohungsszenarien sind ganz andere.
 
midnight schrieb:
Im privaten Bereich habe ich auch schon OpenBSD als Host und ein paar virtuelle Maschinen (vmm) mit OpenBSD Guests betrieben. Der Host hat die Firewall uebernommen (pf und relayd), die Guests dann die Dienste. Das halte ich persoenlich recht sicher, solange man dem Host trauen kann. Das ist vermutlich unter FreeBSD mit jails aehnlich. Anders saehe es allerdings aus, wenn ich z.B. vmware oder hyper-v als Host nutzen wuerde und dann eine OpenBSD Firewall als Guest. Auch wenn alles ueber den OpenBSD Guest nach aussen ins Internet geroutet wird, ist noch immer hyper-v oder vmware als Host-Abstaktionsschicht darunter. Es ist schon oefter vorgekommen, dass vmware oder hyper-v schwerwiegende Sicherheitsluecken hatten und von aussen angreifbar war oder zum crashen gebracht werden konnte. Von daher wuerde ich CommanderZed schon zustimmen, dass man das sauber trennen kann, solange man dem Host vertraut.
Zum Vergrößern anklicken....

Also bei mir ist es halt QEMU - allerdings ist der "HOST" ja nur in so fern beteiligt das er auf Layer2 die Pakete bridged. Soviel ich weiß gab es bei so reinen "ich nehm paket von interface a und pack es auf das virtuelle interface b über meine bridge" auch in hyperv oder vmware selten schwerwiegenden Angriffe, sondern meist auf den TCP/IP Stack z.B. der Verwaltungsoberfläche bei VM-Ware oder aber auf das Host-OS direkt bei Hyper-V - der aber da ja noch garnicht beteiligt ist.

Mein Host-OS-Linux ist auf Layer3 0,0 mit dem echten Internet direkt verbunden und muss wie jeder client brav über den OpenBSD Router / die PF gehen.

Natürlich gibt es da schon eine theoretische zusätzliche angriffsoberfläche gegenüber Bare-Metal, das wäre in meinen fall die Bridge-Implementierung vom Linux, die tap-interface implementierung vom linux und die virt-io implementierung vom qemu aber soweit ich weiß gab es da nur sehr wenig sicherheitsauffälligkeiten die letzten 10, 20 Jahre - dazu patche ich das Hostsystem natürlich regelmäßig.

*(Theoretisch natürlich auch der Treiber von der NIC aber den hat man ja bei Bare-Metal ja auch)

(Kleines PS: Einige dieser technologien nutzt man ja auch z.B. bei Bare-Metal sachen, wenn ich z.B. mehrere Interfaces zusammenschalten möchte oder was mit vlans mache muss ich die gleichen pakete ja auch über sehr ähnliche Bridges schicken, da wird die Frage dann schon sehr komplex ob das dann zusätzlich noch ne Angriffsoberfläche ist wenn man die gleiche Technik eh nutzt)
 
CommanderZed schrieb:
Also bei mir ist es halt QEMU - allerdings ist der "HOST" ja nur in so fern beteiligt das er auf Layer2 die Pakete bridged. Soviel ich weiß gab es bei so reinen "ich nehm paket von interface a und pack es auf das virtuelle interface b über meine bridge" auch in hyperv oder vmware selten schwerwiegenden Angriffe, sondern meist auf den TCP/IP Stack z.B. der Verwaltungsoberfläche bei VM-Ware oder aber auf das Host-OS direkt bei Hyper-V - der aber da ja noch garnicht beteiligt ist.
Zum Vergrößern anklicken....
Bei QEMU ist die Angriffsflaeche auch sehr klein. Bei Schwergewichten wie vmware oder hyper-v sind kritische CVEs schon recht haeufig. Selbst wenn sie nicht direkt aus dem Internet angreifbar sind, haengen noch immer irgendwo Clients dahinter. Wenn sich dieser Client z.B. eine Schadsoftware einfaengt, dann kann sie aus dem lokalen Netz agieren und die Weboberflaeche angreifen. Oder wenn z.B. ein Guest korrupt ist, dann gabs auch schon Faelle, dass von einem Windows Guest Zugriff mit Adminrechten auf Hyper-V genommen werden konnte. Die ganzen Admin-VM-Management-Tools sind da meist die Schwachstelle. Das sind natuerlich recht seltene und spezifische Szenarien, aber dennoch real.

Mein Bruder hat in Nuernberg das groesste Microsoft-Rechenzentrum in Europa mit aufgebaut. Der hat auch viele solche Geschichten zu erzaehlen, da Microsoft viel auf VM setzt. Er hat mich auch immer gewarnt, einen Hyper-V direkt ins Internet zu haengen und immer echte Hardware-Firewalls davor zu setzen.
 
Eine Firewall gehört auf dedizierte Hardware, so arbeitet sie zuverlässig, stabil und vorhersehbar. Virtualisierte Firewalls erhöhen die Komplexität, vergrößern die Angriffsfläche und hängen vom Hypervisor sowie anderen VMs ab – ein einzelner Fehler kann damit das gesamte Netzwerk lahmlegen.


Eine physische Firewall ist dagegen isoliert, unabhängig und frei von unnötigen Abhängigkeiten.

Gute Hardware kostet heute kaum mehr als 200 Dollar und bietet genug Leistung für viele Jahre. Sie trennt Sicherheitsfunktionen klar von der restlichen Infrastruktur und verhindert „Single Points of Failure“.

Die Frotzbox ist keine Firewall, das ist ein Sammelsurium von irgendwelchen Funktionen wie DECT etc ...

Sie bietet keine echte Kontrolle des Datenverkehrs.

Aber das ist meine Ansicht, natürlich kann jeder machen, wie er will.
 
midnight schrieb:
Bei QEMU ist die Angriffsflaeche auch sehr klein. Bei Schwergewichten wie vmware oder hyper-v sind kritische CVEs schon recht haeufig. Selbst wenn sie nicht direkt aus dem Internet angreifbar sind, haengen noch immer irgendwo Clients dahinter. Wenn sich dieser Client z.B. eine Schadsoftware einfaengt, dann kann sie aus dem lokalen Netz agieren und die Weboberflaeche angreifen. Oder wenn z.B. ein Guest korrupt ist, dann gabs auch schon Faelle, dass von einem Windows Guest Zugriff mit Adminrechten auf Hyper-V genommen werden konnte. Die ganzen Admin-VM-Management-Tools sind da meist die Schwachstelle. Das sind natuerlich recht seltene und spezifische Szenarien, aber dennoch real.

Mein Bruder hat in Nuernberg das groesste Microsoft-Rechenzentrum in Europa mit aufgebaut. Der hat auch viele solche Geschichten zu erzaehlen, da Microsoft viel auf VM setzt. Er hat mich auch immer gewarnt, einen Hyper-V direkt ins Internet zu haengen und immer echte Hardware-Firewalls davor zu setzen.
Zum Vergrößern anklicken....
Ahh ich glaub ich verstehe ein bisschen wie du das meinst.

Ja das ist natürlich korrekt und kommt dann wieder sehr stark auf die Betrachtungsweise an.

Ich könnte ja Hyper-V auch nur über die Firewall für die Firewall erreichbar machen, nicht für hosts dahinter und hab da z.B. nur deutlich sicherere OpenBSD Gäste villeicht drinn und keine Windows-Gäste. (Warum man auch immer man sowas machen würde)
Dann ist wieder nur die Frage wie gut die Brücken-Implementierung von Windows ist ähhhh ... naja da fühle ich mich auf jedenfall nicht so sicher wie bei Linux oder gar OpenBSD.
Also ich geh komplett mit das Hyper-V oder auch VMWARE generell leichter angreifbar sind als z.B. ein Linux mit QEMU und würde mir das zuhause nicht hinstellen, da kommt es aber irgendwann bei der Betrachugn dann für mich aber schon sehr stark auf die Details an.

roema schrieb:
Eine Firewall gehört auf dedizierte Hardware, so arbeitet sie zuverlässig, stabil und vorhersehbar. Virtualisierte Firewalls erhöhen die Komplexität, vergrößern die Angriffsfläche und hängen vom Hypervisor sowie anderen VMs ab – ein einzelner Fehler kann damit das gesamte Netzwerk lahmlegen.
Zum Vergrößern anklicken....

Ein einzelner Fehler kann immer das gesamte Netz Lahmlegen, natürlich ist es in manchen stellen komplexer aber an manchen stellen auch einfacher, das kann man so pauschal nicht sagen wie das gerade behauptest.
Ich hab mich da etwas mehr mit die letzten 2 Jahre auseinandergesetzt - du dich auch? Zeig mir bitte mal die CVEs etc wo es z.B. um Probleme der Bridge implemtierung von Linux ging, was hier die Kern-Angriffsläche wäre.

Das mit der Hardware ist sogar der viel größere - Sorry - Bullshit. Wenn ich z.B. für einen Homeserver und Router 1200€ übrig hab kann ich für 1200€ virtualisierte Hardware dtl. hochwertigere Komponenten kaufen als z.B. 800€ für den Virtualisierungshost für die anderen Dienste und nochmal 400€ villeicht für die dedizierte Firewall.

Dazu ist vermutlich mein Client-Rechner mit Windows bzw. Browser etc der SSH-Zugriff sowohl auf den VM-Host als auch die Firewall hat bei all diesen Betrachtungen das gefährdetere Gerät und das völlig unabhängig davon was als ziel auf echter Hardware läuft oder nicht.

roema schrieb:
Eine physische Firewall ist dagegen isoliert, unabhängig und frei von unnötigen Abhängigkeiten.

Gute Hardware kostet heute kaum mehr als 200 Dollar und bietet genug Leistung für viele Jahre. Sie trennt Sicherheitsfunktionen klar von der restlichen Infrastruktur und verhindert „Single Points of Failure“.
Zum Vergrößern anklicken....

Die meisten Geräte mit 2x 10G Interfaces kosten auch heute dtl. mehr, erst recht wenn man die auch befeuern möchte, da sollte es nach meinen Messungen mit OpenBSD dtl. mehr als nen passiv gekühlter Atom/Celeron oder so sein.

roema schrieb:
Die Frotzbox ist keine Firewall, das ist ein Sammelsurium von irgendwelchen Funktionen wie DECT etc ...

Sie bietet keine echte Kontrolle des Datenverkehrs.

Aber das ist meine Ansicht, natürlich kann jeder machen, wie er will.
Zum Vergrößern anklicken....
Also es wäre schon hilfreich wenn du liest was wir hier schreiben, es wurde mit keinen Wort eine Fritzbox erwähnt und ist bei mir auch garnicht vorhanden. Bist du sicher das du verstehst wovon wir hier schreiben?
 
Ich ignoriere mal geflissentlich die nicht-technischen Aspekte im Thread.

roema schrieb:
Eine Firewall gehört auf dedizierte Hardware, so arbeitet sie zuverlässig, stabil und vorhersehbar. Virtualisierte Firewalls erhöhen die Komplexität, vergrößern die Angriffsfläche und hängen vom Hypervisor sowie anderen VMs ab – ein einzelner Fehler kann damit das gesamte Netzwerk lahmlegen.
Zum Vergrößern anklicken....

Das ist bei meinen Heimnetz - bei dem ich im Zweifelsfalle einfach mit meinem Laptop via LTE arbeiten kann - kein Beinbruch. Downtime ist da nicht kritisch, zumal ich meine Basteleien eh zu unkritischen Zeiten durchführe.

roema schrieb:
Gute Hardware kostet heute kaum mehr als 200 Dollar und bietet genug Leistung für viele Jahre. Sie trennt Sicherheitsfunktionen klar von der restlichen Infrastruktur und verhindert „Single Points of Failure“.
Zum Vergrößern anklicken....

Dann ist doch mein Hardware-Router mein Single Point of Failure? Für 200€ kriege ich einen Rechner, der mit Linux und nftables o.ä. meine Pakete filtert. Also das, was meine VM am dediziertem LAN-Port auch macht - wie auch in vereinfachter Form die davorgeschaltete Fritzbox.

Heutzutage fährt man doch außerdem ein Zero-Trust-Modell, d.h. man vertraut auch allen Rechnern hinter der Firewall nicht - wohlwissend, dass die heutigen Angriffsszenarien sich meist nicht mit einer Firewall am Perimeter aufhalten lassen. Das war vielleicht vor 20 Jahren Stand der Technik.

Zumal ich mit meinem geplanten (flexiblen) Budget mit Virtualisierung eine viel bessere Trennung der einzelnen Dienste in meinem Heimnetzwerk erreichen kann, als dies ohne Virtualisierung möglich wäre.

roema schrieb:
Die Fritzbox ist keine Firewall, das ist ein Sammelsurium von irgendwelchen Funktionen wie DECT etc ...
Zum Vergrößern anklicken....

Praktischerweise ist eine der Funktionen die Integration von nftables, die standardmäßig alle Pakete von außen einfach abweist und somit schon mal die Skript-Kiddies fernhält.

roema schrieb:
Sie bietet keine echte Kontrolle des Datenverkehrs.
Zum Vergrößern anklicken....

Dafür habe ich ja meine Router-VM. Die einzige Verbindung zur Fritzbox, über die alle Clients bzw. anderen VMs müssen.

Der Zugriff auf den Router - egal ob in Hardware oder als VM - erfolgt natürlich von meinem normalen Desktop zuhause. Das ist wohl das viel größere Einfallstor für Schadsoftware als ein hypothetisches Angriffsszenario auf eine Linux-Bridge.

roema schrieb:
Aber das ist meine Ansicht, natürlich kann jeder machen, wie er will.
Zum Vergrößern anklicken....

The right tool for the right job. In meinem Heimnetzwerk brauche ich keine hochverfügbaren Firewalls, die ich zumal als VMs viel leichter realisieren könnte.

Da ist es in meinem Anwendungsfall viel wichtiger, dass ich VMs - falls mal ein physikalischer Rechner abkackt - viel leichter auf einem anderen Rechner wiederherstellen kann, um die MTTR zu optimieren.
 
Die APU2 war und ist ein guter Router/Firewall.
Die Leistung ist aber begrenzt. Meine 500MBit/s Leitung wird gerade noch ausgenutzt, manchmal geht der CPU die Puste aus.
Als BIOS benutze ich die neueste Coreboot Version von 3mdeb. Das Betriebssystem ist OpenBSD.
Die Hardware unterstützt ECC RAM. Das war aber auch erst nach einigen Jahren der Fall, obwohl schon vorher mit Support dafür geworben wurde.
Das hatte glaube ich irgendetwas mit AMD selbst zu tun.

Die Protectli Geräte finde ich sehr interessant, aber leider kein ECC.


Linus Torvalds findet ECC essentiell. Meine Tätigkeiten zu Hause sind für andere Leute vielleicht nicht so wichtig wie die Arbeit von Linus Torvalds. Aber es ist scheinbar realistisch "dass manchmal etwas passiert". Ich habe seit Jahren eine ähnliche Meinung und versuche immer echtes ECC für meinen RAM zu realisieren, egal welche Maschine.

Virtualisierung vs. Bare Metal
Viele Eigenheiten der jeweiligen Lösung wurden bereits genannt. Die beste Lösung hängt immer von der Applikation bzw. den Anforderungen ab.
Nach Ewigkeiten werde ich vermutlich zukünftig eine meiner Maschinen virtualisieren. Es wird aber der Server sein, der wohl in die Workstation kommt. Nicht die Firewall in den Server.

Ich habe auch SFP Anschlusstechnik für mich entdeckt. Dabei gefällt mir der geringe Stromverbrauch und Latenz, wenn man DAC Verbindungen verwendet. In meinem nächsten Router hätte ich deshalb gerne auch einige SFP+ Anschlüsse. Protectli sieht sehr gut aus, was das betrifft.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben