24
Linux VM ohne Möglichkeit sich anzumelden, Verschlüsselter HD und ohne user und mit nur einem laufendem daemon
Hallo Experten,
der Titel erklärt es schon ganz gut glaube ich.
Ist es möglich eine Linux VM zu erzeugen die man zwar starten kann, aber die keine User enthält und an der man sich nicht anmelden kann?
Die VM würde quasi gestartet werden können, sie macht ihren Job, und keiner wirklich keiner kann sich je wieder an diesem System anmelden, ohne es zu zerstören.
Ist sowas machbar?
LG
Chris
der Titel erklärt es schon ganz gut glaube ich.
Ist es möglich eine Linux VM zu erzeugen die man zwar starten kann, aber die keine User enthält und an der man sich nicht anmelden kann?
Die VM würde quasi gestartet werden können, sie macht ihren Job, und keiner wirklich keiner kann sich je wieder an diesem System anmelden, ohne es zu zerstören.
Ist sowas machbar?
LG
Chris
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 634072
Url: https://administrator.de/forum/linux-vm-ohne-moeglichkeit-sich-anzumelden-verschluesselter-hd-und-ohne-user-und-mit-nur-einem-laufendem-634072.html
Ausgedruckt am: 14.03.2025 um 07:03 Uhr
24 Kommentare
Neuester Kommentar
Für mögliche Wartungsarbeiten/Updates nicht praktikabel.
Was genau möchtest du denn erreichen damit, dass kein Userkonto vorhanden ist?
Was genau möchtest du denn erreichen damit, dass kein Userkonto vorhanden ist?
Wartungsarbeiten muss es nicht geben. Die VM wird bei einem Update einfach neu ausgeliefert. Es soll nicht möglich sein an den Inhalt der VM zu gelangen. Die VM enthält eine REST-API und nur da drüber kann mit ihr kommuniziert werden.
es gibt immer wege.
Wie soll das gehen? Alleine schon Root ist ein User.
Moin,
kann deinen Gedanken nachvollziehen, aber:
Ich fahre die VM herunter, lade ein LiveOS, greife auf die Daten zu. AUßer, du betreibst innerhalb der VM eine Datenverschlüsselung.
Frage zwei:
Deine VM läuft nicht/ verursacht Fehler. Wie willst du den Fehler identifizieren?
Zur Behebung von Fehlern und somit entwickeln von Updates für die API ist es ja sinnvoll zu wissen, was/ warum etwas schief gelaufen ist!!?
Und wenn ihr eine neue VM im Rahmen eines Updates ausrollt: Wie willst du Dinge wie IP-Adresse etc. regeln? ODer wird die VM per DHCP + Reservierung versorgt werden?
Ich würde eine Anmeldung zulassen wollen.
EINEN Benutzer, mit einem hochkomplexen Kennwort.
Der Nutzer darf ggf. zusätzlich per SSH + Zertifikat eine Anmeldung erfahren.
Sollte ausreichend sein.
Gruß
em-pie
kann deinen Gedanken nachvollziehen, aber:
Ich fahre die VM herunter, lade ein LiveOS, greife auf die Daten zu. AUßer, du betreibst innerhalb der VM eine Datenverschlüsselung.
Frage zwei:
Deine VM läuft nicht/ verursacht Fehler. Wie willst du den Fehler identifizieren?
Zur Behebung von Fehlern und somit entwickeln von Updates für die API ist es ja sinnvoll zu wissen, was/ warum etwas schief gelaufen ist!!?
Und wenn ihr eine neue VM im Rahmen eines Updates ausrollt: Wie willst du Dinge wie IP-Adresse etc. regeln? ODer wird die VM per DHCP + Reservierung versorgt werden?
Ich würde eine Anmeldung zulassen wollen.
EINEN Benutzer, mit einem hochkomplexen Kennwort.
Der Nutzer darf ggf. zusätzlich per SSH + Zertifikat eine Anmeldung erfahren.
Sollte ausreichend sein.
Gruß
em-pie
Root muss auch weg 
Die HD muss natürlich verschlüsselt sein.
Die Fehleranalyse geschieht ausschließlich über die API.
Das Gleiche gilt für die Netzwerk configs.
Die Fehleranalyse geschieht ausschließlich über die API.
Das Gleiche gilt für die Netzwerk configs.
Sicher, aber ich möchte es so schwer wie möglich machen. Wenn der Angreifer 100 Jahre braucht zum Knacken, ist das ok für mich. ;)
Wie soll das gehen?
Das kannst Du im Prinzip nur über Verschlüsselung hinbekommen, aber irgendwo mußt beim booten der Schlüssel herkommen. spätestens da kann man in einer VP den abgreifen udn den Inhalt damit entschlüsseln.
Wogegen (d.h. welche Angreife) willst Du Dich denn schützen?
lks
Dm man das einloggen aber untersagen kann.
Aber ein normales Linux hat mindestens ein halbes Dutzend User und Gruppen ehre deutlich mehr.
lks
Dem schließe ich mich an. Aber warum ist es so wichtig dass kein User existiert? Wenn das Passwort nicht bekannt und ausreichend komplex ist und man von außen nicht ran kommt weil die Festplatte verschlüsselt ist spielt das doch keine Rolle oder?
Wo kommt der Schlüssel her? Der liegt entweder auf der VM -> einfach auslesen, oder muß übers Netz geholte werden (Dann liest es der präparierte Hypervisor aus, wenn es im RAM ist.).
lks
Zitat von @christoph.janik:
Sicher, aber ich möchte es so schwer wie möglich machen. Wenn der Angreifer 100 Jahre braucht zum Knacken, ist das ok für mich. ;)
Sicher, aber ich möchte es so schwer wie möglich machen. Wenn der Angreifer 100 Jahre braucht zum Knacken, ist das ok für mich. ;)
15 Minuten, inklusive Kaffeholen udn trinken, bevor man loslegt, wenn ich Deinen Ansatz sehe.
lks
Zitat von @Lochkartenstanzer:
Wo kommte der Schlüssel her? der liegt entweder auf der VM -> einfach auslesen ode rmuß übers Netz geholte werden (dann liest es der hypervisor aus, wenn es im RAM ist.).
lks
Wo kommte der Schlüssel her? der liegt entweder auf der VM -> einfach auslesen ode rmuß übers Netz geholte werden (dann liest es der hypervisor aus, wenn es im RAM ist.).
lks
guter Punkt
das kommt noch dazu. vTPM ginge noch, bliebe dann wieder die Frage wie kommt der dort hin
Moin,
Das was Du machen willst, macht man nicht in einer VM, sondern mit einem raspberry o.ä. den man in eine "tamper-proof"-Box einbaut und der dann explodiert, wenn man das Gehäuse aufmacht.
Dann kann man das System so konfigurieren, daß alle Geheimnisse "in" der Box sind und nur noch über die Netzwerkschnittstellen nach außen kommuniziert wird.
Das kann man natürlich statt mit einem Pi auch mit NUCs oder ganz normalen PCs machen.
lks
Das was Du machen willst, macht man nicht in einer VM, sondern mit einem raspberry o.ä. den man in eine "tamper-proof"-Box einbaut und der dann explodiert, wenn man das Gehäuse aufmacht.
Dann kann man das System so konfigurieren, daß alle Geheimnisse "in" der Box sind und nur noch über die Netzwerkschnittstellen nach außen kommuniziert wird.
Das kann man natürlich statt mit einem Pi auch mit NUCs oder ganz normalen PCs machen.
lks
Zitat von @LeeX01:
guter Punkt das kommt noch dazu. vTPM ginge noch, bliebe dann wieder die Frage wie kommt der dort hin
guter Punkt
das kommt noch dazu. vTPM ginge noch, bliebe dann wieder die Frage wie kommt der dort hinvTPM ist nur Auenwischerei, wenn man sogar aus dem TPM die Schlüssel holen kann
lks
PS: Wir haben in den späten 80ern an der Uni auch sogenante "tamper-proof"-Systeme auseinandergenommen. War meistens nicht allzu kompliziert.
Zitat von @Lochkartenstanzer:
vTPM ist nur Auenwischerei, wenn man sogar aus dem TPM die Schlüssel holen kann
lks
PS: Wir haben in den späten 80ern an der Uni auch sogenante "tamper-proof"-Systeme auseinandergenommen. War meistens nicht allzu kompliziert.
Zitat von @LeeX01:
guter Punkt das kommt noch dazu. vTPM ginge noch, bliebe dann wieder die Frage wie kommt der dort hin
guter Punkt
das kommt noch dazu. vTPM ginge noch, bliebe dann wieder die Frage wie kommt der dort hinvTPM ist nur Auenwischerei, wenn man sogar aus dem TPM die Schlüssel holen kann
lks
PS: Wir haben in den späten 80ern an der Uni auch sogenante "tamper-proof"-Systeme auseinandergenommen. War meistens nicht allzu kompliziert.
Das mit TPM ist klar, Schwachellen hast du überall. Die Frage ist ja letztlich immer die gleiche nach dem Schutzbedürfniss. Warum muss ich mich schützen, vor wem und welche Mittel und Ressourcen stehen dafür zur Verfügung. Vor dem normalen Anwender schützen viele Sachen, vor denen die bei Fireeye eingestiegen sind wohl eher nicht.
Ja, ist wohl nicht machbar. Ich sehe es ja ein. Hatte nicht bedacht das der Schlüssel zum Entschlüsseln der Festplatte ja initial geladen werden muss. Und da kann man immer angreifen. Werde also weiter tüfteln und eine reine Softwarelösung anstreben.
anyway, vielen Dank euch allen!
LG
Chris
anyway, vielen Dank euch allen!
LG
Chris
Zitat von @christoph.janik:
Ja, ist wohl nicht machbar. Ich sehe es ja ein. Hatte nicht bedacht das der Schlüssel zum Entschlüsseln der Festplatte ja initial geladen werden muss. Und da kann man immer angreifen. Werde also weiter tüfteln und eine reine Softwarelösung anstreben.
Ja, ist wohl nicht machbar. Ich sehe es ja ein. Hatte nicht bedacht das der Schlüssel zum Entschlüsseln der Festplatte ja initial geladen werden muss. Und da kann man immer angreifen. Werde also weiter tüfteln und eine reine Softwarelösung anstreben.
Gibbet nicht, genausowenig, wie es es Perpetuum mobile gibt.
Jetzt sag doch Mal, wer der "Angreifer" und was das Schützenswerte Gut denn überhaupt ist?
lks
Es soll ein Masternode für ein p2p Netzwerk werden, der beliebige Daten von anderen Peers enthalten kann. Zwar immer nur Chunks von Daten, aber selbst die hätte ich gerne verschlüsselt. Es soll ein Masternode sein der zwar Ressourcen zur Verfügung stellt, aber keinen Zugriff auf den Inhalt oder die Verarbeitung innerhalb der VM hat. Also als Betreiber eines Masternodes würdest du die VM starten, über die API eine oder mehrere Cryptowallet-Adressen hinterlegen(Nur einmal machbar!) und die Belohnung kassieren, dafür dass du das Netzwerk am Laufen hältst.
Die Geldspielautomatenhersteller schützen ihre Firmware, indem das Betriebssystem auf einer Raspi-großen Platine läuft, die mit einem Gehäuse umgeben ist, durch welches Leiterbahnen fließen. Sobald das Gehäuse geöffnet oder aufgeborht wird, werden die Leiterbahnen unterbrochen, die CMOS Batterie puffert dann nicht mehr und der Code im CMOS geht verloren.
Zitat von @NordicMike:
Die Geldspielautomatenhersteller schützen ihre Firmware, indem das Betriebssystem auf einer Raspi-großen Platine läuft, die mit einem Gehäuse umgeben ist, durch welches Leiterbahnen fließen. Sobald das Gehäuse geöffnet oder aufgeborht wird, werden die Leiterbahnen unterbrochen, die CMOS Batterie puffert dann nicht mehr und der Code im CMOS geht verloren.
Die Geldspielautomatenhersteller schützen ihre Firmware, indem das Betriebssystem auf einer Raspi-großen Platine läuft, die mit einem Gehäuse umgeben ist, durch welches Leiterbahnen fließen. Sobald das Gehäuse geöffnet oder aufgeborht wird, werden die Leiterbahnen unterbrochen, die CMOS Batterie puffert dann nicht mehr und der Code im CMOS geht verloren.
Sag ich doch.
Tamper-Proof- Hardware.
Gibt es sogar als Rack.
lks
PS: ich baue gerne auch ein 'Bumm" mit ein.
