Intel ME, potenzielle Backdoors und Netzwerkabsicherung – welche sinnvollen Ansätze gibt es?

Juma001

Neuling
Thread Starter
Mitglied seit
03.10.2025
Beiträge
7
Hallo zusammen,

ich habe in den letzten Monaten mit ein paar Hardwarekomponenten etwas Home-Server-Erfahrung gesammelt und mich dabei vor allem mit Themen wie Virtualisierung, Storage und Netzwerk beschäftigt.

Eigentlich wollte ich mein Setup nur etwas besser absichern – dabei bin ich allerdings ziemlich schnell in ein Rabbit Hole gefallen.

Im Zuge dessen bin ich über Intel ME (Management Engine) gestolpert. Soweit ich das verstanden habe, handelt es sich dabei um ein eigenes Subsystem mit quasi einem kleinen separaten Betriebssystem, das tief im Chipsatz sitzt und Zugriff auf verschiedene Hardwarekomponenten hat.

Das Problem aus meiner Sicht:
Intel ME ist nicht open source, und man weiß daher nicht wirklich im Detail, was dort alles läuft. Theoretisch hätte dieses System ja sehr weitreichende Möglichkeiten – bis hin zu Zugriff auf Hardware, Netzwerk und Daten.

Mir ist klar, dass das schnell etwas paranoid klingen kann. Andererseits denke ich mir: Wenn ich komplett darauf vertraue, dass so etwas niemals missbraucht werden könnte, könnte ich meine Daten im Zweifel auch direkt bei amerikanischen Cloud-Dienstleistern hosten und müsste keinen eigenen Home-Server betreiben.

Mir ist auch bewusst, dass ähnliche Management-Subsysteme inzwischen nicht nur bei Intel existieren, sondern in anderer Form auch bei AMD und teilweise sogar in ARM-Systemen vorkommen. Mir geht es also nicht darum, Intel speziell an den Pranger zu stellen. Ich erwähne Intel hier nur explizit, weil ich deren Plattformen von der Leistungsaufnahme und Effizienz her aktuell am attraktivsten finde und sie deshalb in meinem Setup verwende.

Daher stellt sich für mich die Frage:

Wenn man möglichst auf Nummer sicher gehen möchte – welche Ansätze gibt es überhaupt, um das Risiko zu minimieren?

Mein aktueller Gedankengang:
  • Intel ME ist auf moderner Intel-Hardware praktisch immer vorhanden.
  • Die meisten guten NICs sind ebenfalls von Intel.
  • Wenn Intel ME theoretisch Netzwerkzugriff hätte, wäre ein Zugriff über Intel-NICs zumindest denkbar.
Ich habe daher gelesen, dass manche Leute bewusst Realtek-NICs einsetzen, um zumindest diesen direkten Weg zu vermeiden. Allerdings weiß ich nicht, ob das wirklich einen Unterschied macht oder eher eine Scheinsicherheit ist.

Netzwerktechnisch bin ich leider auch nicht tief genug drin, um beurteilen zu können, ob man so etwas z.B. über OPNsense / pfSense sinnvoll unterbinden könnte – ohne sich gleichzeitig die normale Internetnutzung komplett zu zerschießen (z.B. weil man plötzlich jede Verbindung manuell freigeben müsste).

Was ich bisher als mögliche Ansätze überlegt habe:

1. Realtek NIC in der Firewall statt Intel NIC
  • Idee: mögliche direkte Interaktion zwischen Intel-Hardware und Netzwerk minimieren
  • Problem: teilweise schlechtere Treiber, Stabilität und Performance
2. OpenWRT-Router vor dem eigentlichen Netzwerk

Beispielaufbau:

DSL-Modem → OpenWRT → dahinter Home-Server mit virtualisiertem OPNsense
Die Idee wäre, eine zusätzliche Netzwerk-Trennungsebene einzubauen.

3. OPNsense direkt auf dedizierter Hardware

Also klassisch:

DSL-Modem → OPNsense-Firewall → internes Netzwerk
Ohne zusätzliche OpenWRT-Schicht.

4. Coreboot / Libreboot / “gesäuberte” Hardware

Ich bin auch über Projekte wie Coreboot und Libreboot gestolpert, bei denen teilweise versucht wird, Firmware möglichst transparent zu machen oder Funktionen wie Intel ME zumindest stark einzuschränken.

Allerdings scheint kompatible Hardware dafür:
  • relativ selten
  • teilweise sehr teuer
  • und im Falle eines Hardwaredefekts auch entsprechend kostspielig zu ersetzen.
Deshalb frage ich mich auch hier:
Ist das am Ende vielleicht tatsächlich der einzige wirklich saubere Ansatz, wenn man dieses Thema ernst nimmt?


Leider habe ich im Internet und auf YouTube hauptsächlich Diskussionen darüber gefunden, dass Intel ME theoretisch sehr viele Möglichkeiten hätte, aber kaum konkrete Strategien oder praktische Lösungen, wie man damit im Homelab-Kontext umgehen sollte.

Deshalb würde ich mich sehr über eure Einschätzungen freuen – besonders von Leuten, die sich mit OPNsense/, Netzwerk-Security oder Homelab-Architekturen intensiver beschäftigt haben.

Vielleicht gab es hier ja auch schon jemanden, der ähnliche Gedanken hatte und dafür eine pragmatische Lösung gefunden hat.

Vielen Dank schon mal :)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Bzgl. Firewall mit Coreboot und deaktivierter Intel ME (via HAP/AltMEDisable) kannst mal auf https://eu.protectli.com/products/ schauen, die VaultPro (VP in der Modellbezeichnung) können HAP setzen und damit die Intel ME deaktivieren. Zusätzlich kannst die direkt mit Coreboot installiert ordern. Preis ist natürlich höher als vergleichbare Chinakisten.
 
@sch4kal Sorry für die späte Rückmeldung.

Danke für deinen Vorschlag.
Wie erwähnt, ist das für mich keine wirkliche Option,da:
1. zu teuer
2. je nach Modell begrenzt aufrüstbar
3. Verbrauch kann relativ hoch werden, da durch Coreboot gewisse C-States nicht erreichbar sind.

Bei einigen Punkten bin ich mir noch technisch unsicher, weshalb ich sie hier nicht erwähne, aber wahrscheinlich könnte man noch 1-2 Punkte noch finden, wenn man sehr kritisch ist und einige Punkte bewertet, die ich jetzt nicht tue.

Ich habe aus meiner Sicht eine bessere Alternative gefunden, die ich dir und anderen Interessierten vorstellen wollte. Eventuell kann man auf Basis der Alternative das Ganze weiter ausbauen. :-)

Ich bin über den NanoPi R5S gestolpert. Basiert auf ARM und wird von OpenWRT supportet. Hat drei Ports (2x 2.5G und 1x 1G) und hat ein Anschluss für eine SSD. Für alle die nur 2x Ports (2.5G) brauchen, wäre die R5C ebenfalls eine Alternative. Dieser wird nur etwas wärmer und hat ein Port weniger. Zudem kann keine SSD eingebaut werden
Verbrauch bewegt sich laut Youtube zwischen 3 - 7 Watt. OpenWRT wäre auch eine tolle Alternative, für alle die weniger Ressourcen brauchen.

Bei meinem Vorschlag kommt relativ viel Open Source zum Einsatz, und ARM hat meines Wissens keine mit der Intel Management Engine vergleichbare Backdoor. Spätestens mit installiertem OpenWrt sollte man auf der sicheren Seite sein – vorausgesetzt, es ist korrekt konfiguriert.


Ihr könnt mich gerne korrigieren und Verbesserungsvorschläge machen, aber ich werde wahrscheinlich das Projekt mit einem NanoPi umsetzen.
 
Ich würde diese Variante auf jeden Fall bevorzugen: DSL-Modem → OPNsense-Firewall → internes Netzwerk
weil: wenn der Hypervisor Server mal down / in Wartung ist, brauchst Du / willst Du auf jeden Fall Internet zur verfügung haben-

Für OpenWRT würde ich keinen NanoPi, RPI oder ähnliches verwenden, da gibt es deutlich bessere / performantere Hardware:
- PCengines APU - der Klassiker, der sogar ECC supportet
- originale Router von OpenWRT
- GL.inet Router haben unter der Haube OpenWRT, und lassen sich auch safe auf Vanilla OpenWRT umflashen, da uBoot Bootloader
 
Ich würde diese Variante auf jeden Fall bevorzugen: DSL-Modem → OPNsense-Firewall → internes Netzwerk
weil: wenn der Hypervisor Server mal down / in Wartung ist, brauchst Du / willst Du auf jeden Fall Internet zur verfügung haben-
Sehe ich auch so.
All in one immer schön und gut, aber ohne Backupstrategie biste dann am Ende im Steinzeitalter, wenn der eine Server streikt.
Klar, wenn der eine HW-Router defekt ist, biste auch offline, nur kann man sich da mit nem billigen OfficePC behelfen, den man evtl. noch rumstehen hat.
Dafür hat man dann eben für jeden Scheiß ne extra Kiste.
Bei mir ist Modem, Router/FW, Netzwerk, WLAN (controller), Server, NAS getrennt.
Wenn der Server nicht geht, sind ein paar Dienste offline.
Fällt der Router aus, biste offline, kannst aber durch umstecken und etwas Netzconfig zumindest die Dienste vom Server oder vom NAS noch konsumieren.

Wenn man vor der ME-Engine Angst hat, ist das einfachste, man nimmt nonIntel HW und da gibt es, zum Glück ja viel Auswahl.
Gerade OpenWRT läuft ja gefühlt auch auf nem Toaster, so flexibel ist das. Und damit kann man echt ne Menge anfangen auch wenn das evtl. nicht die superperfekte Lösung ist, kommt man doch mit Grundnetzwerksachen @home schon sehr weit.
 
Ich würde diese Variante auf jeden Fall bevorzugen: DSL-Modem → OPNsense-Firewall → internes Netzwerk
weil: wenn der Hypervisor Server mal down / in Wartung ist, brauchst Du / willst Du auf jeden Fall Internet zur verfügung haben-
Daran hatte ich auch gedacht. Das Problem ist Intel ME und AMD PSP, die immer mit der x86 Hardware leider mitkommt.
Bei der Variante mit "DSL-Modem → OpenWRT → dahinter Home-Server mit virtualisiertem OPNsense" wollte ich alle größeren Aufgaben an die VM auslagern, da die OpenWRT Hardware teilweise wenig Luft hat.

- PCengines APU - der Klassiker, der sogar ECC supportet
Hier wird doch auf Intel und AMD gesetzt, oder? -> Intel ME, AMD PSP

- originale Router von OpenWRT
- GL.inet Router haben unter der Haube OpenWRT, und lassen sich auch safe auf Vanilla OpenWRT umflashen, da uBoot Bootloader
Ich hatte mich nur für die NanoPi entschieden, wegen: Verbrauch, Anschlüsse, Aufrüstbar, Leistung (relativ gut für ein ARM System und genug RAM für OpenWRT)


Wenn man vor der ME-Engine Angst hat, ist das einfachste, man nimmt nonIntel HW und da gibt es, zum Glück ja viel Auswahl.
AMD hat leider auch das gleiche Problem, nennt sich nur anders "AMD PSP".

Gerade OpenWRT läuft ja gefühlt auch auf nem Toaster, so flexibel ist das. Und damit kann man echt ne Menge anfangen auch wenn das evtl. nicht die superperfekte Lösung ist, kommt man doch mit Grundnetzwerksachen @home schon sehr weit.
Ich wollte OpenWRT, Adguard und Unbound drauf installieren, dann kann es leider schon einmal etwas knapp mit dem RAM werden.


Fällt euch eine Möglichkeit ein, wie man mit OPNsense den Traffic blockieren könntet, wenn Intel ME / AMD PSP "raus telefonieren" will? So wie ich es verstanden habe, könnten beide potenziell die FW überspringen.
 
PCengines APU hat Coreboot Bios und basiert auf älteren Amd G-Series CPUs.

Oder wenn Du ganz safe sein willst, nehm einen GL.inet Flint oder Flint 2, da sind weder Intel noch AMD CPUs drin, sondern MediaTek Quadcore.
 
PCengines APU hat Coreboot Bios und basiert auf älteren Amd G-Series CPUs.
Gibt es eventuell Seiten, wo man Erfahrungsberichte zu solchen Boards lesen kann? Sprich Verbrauch, Wärme etc.?
Nutzt man auf der PC Engines eher OPNsense / pfSense oder OpenWRT und warum?

Ich bin auch darauf gestoßen, dass Protectli eigentlich Coreboot geflashte Yangling Nucs sind (wird zumindest hier beschrieben, für die Einsteigermodelle).
Hast du oder jemand aus dem Forum Erfahrungen mit dem selber flashen? Man kann zwar die Anleitung von Protectli selbst sich ansehen (Youtube Video - Protecli flash), aber da kann auch so einiges schief gehen laut Video und dem ersten Link.


Oder wenn Du ganz safe sein willst, nehm einen GL.inet Flint oder Flint 2, da sind weder Intel noch AMD CPUs drin, sondern MediaTek Quadcore.
Warum präferierst du z.B. die Flints? Ich hatte den Flint 2 vor Augen gehabt, was CPU-technisch genug Power hat für OpenWRT, aber mit dem vorhanden RAM könnte es etwas knapp werden, zumindest laut chatGPT, weshalb ich mich schlussendlich für die NanoPi R5S entschieden hatte. Auf der NanoPi R5S soll auch OpenWRT super funktionieren, zumindest sah es auf den Videos auf Youtube so aus (siehe hier) . OpenWRT One wäre meine erste Wahl, hat aber leider die niedrigsten Ressourcen (RAM + CPU).


Ich bin auch noch am schwanken, ob OPNsense oder OpenWRT. Ich will langfristig nicht alles komplizierter machen als es sein muss, aber würde gerne auch etwas experimentieren, um Konzepte und Technologien besser verstehen zu können. Laut chatGPT kann OpenWRT alles was OPNsense kann auch, aber nur in umständlicher. Dafür läuft es auf jedem Toaster. Stimmt das, oder gibt ist es andere Punkte die für OPNsense oder OpenWRT sprechen?


Danke für eure Geduld und die Antworten (y)
 
Gibt es eventuell Seiten, wo man Erfahrungsberichte zu solchen Boards lesen kann? Sprich Verbrauch, Wärme etc.?
Nutzt man auf der PC Engines eher OPNsense / pfSense oder OpenWRT und warum?
Geh mal von ca. 10w aus, passiv gekühlt. Die Plattform ist fast 10 Jahre alt, und war halt so mit eines der ersten x86 kompatiblem Systeme, das ECC RAM und m2 Slots supported hat. Wenn man kein Coreboot braucht, wäre irgenein Intel n100 die alternative, aber derartige System gibt es noch nicht so lange.

Warum präferierst du z.B. die Flints? Ich hatte den Flint 2 vor Augen gehabt, was CPU-technisch genug Power hat für OpenWRT, aber mit dem vorhanden RAM könnte es etwas knapp werden, zumindest laut chatGPT, weshalb ich mich schlussendlich für die NanoPi R5S entschieden hatte. Auf der NanoPi R5S soll auch OpenWRT super funktionieren, zumindest sah es auf den Videos auf Youtube so aus (siehe hier) . OpenWRT One wäre meine erste Wahl, hat aber leider die niedrigsten Ressourcen (RAM + CPU).
Die Flints haben genug Power, mehrere LAN Anschlüsse und lassen sich mit Vanilla OpenWRT flashen. Sofern Du keine Unmengen an Paketen nachinstallierst, ist OpenWRt sehr genügsam, was Ram angeht.
Laut chatGPT kann OpenWRT alles was OPNsense kann auch, aber nur in umständlicher. Dafür läuft es auf jedem Toaster. Stimmt das, oder gibt ist es andere Punkte die für OPNsense oder OpenWRT sprechen?
OpenWRT braucht kaum Ressourcen und ist primär ein Router, das bedeutet: kann die ganzen Basics und noch Dinge mehr, und kann auch mit Paketen erweitert werden. Die Konfiguration oberhalb der Basics, sprich wenn man mit VLANs, Policy Based Routing, Firewall etc anspruchsvoll Dinge umsetzen möchte. ist das kein Zuckerschlecken.

OPNsense ist eine vollständige Firewall - bessere Oberfläche, unendliche Möglichkeiten, braucht halt ein paar Ressourcen mehr. Für anspruchsvollere Aufgaben benötigt es mehr Backgroud Wissen, ist aber leichter umzusetzen.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh