Root Passwort in Linux/Unix zurücksetzen

[goetz @ 3rz]

Das eine habe ich mit Linux-Mint in der Bucht geschossen und kenne das Root-PW nicht. Das muss ich also komplett neu installieren, um nfs-Geraffel damit machen zu können.

Mußt du deswegen nicht – boote direkt in eine bash:

• Bei Grub den Autoboot unterbrechen
• 'e' für edit
• In der Kernel-Zeile hinten "init=/bin/bash" dranhängen
• Weiterbooten
• Du landest in einer bash und kannst mit "passwd" ein neues Passwort setzen
• Danach neu booten.
• Fertig.

Auf der anderen Seite würde ich unbedingt neu installieren – nichts gegen den Vorbesitzer, aber ich würde keiner Software trauen, die da von irgendwo kommt.

[ari.tao]

Huch, der PW-Schutz einfach ausgehebelt?!

[goetz @ 3rz]

Huch, der PW-Schutz einfach ausgehebelt?!

Der Passwortschutz von Windows, macOS, Linux hilft nicht gegen "jemand setzt sich davor und faßt die Tastatur an". Wenn man physischen Zugriff auf eine Maschine und ein klein wenig Zeit hat, gibt es keinen "Passwortschutz". Das einzige, was gegen unautorisierten Zugriff hilft, ist Festplattenverschlüsselung.

[ari.tao]

^^-- Diese Paßwort-Seuche hat mir nie gefallen.
Schön zu wissen, wie illusionär PWs sind.

[1ST1]

@gh-baden: Genau deswegen (dein letzter Absatz) stecke ich keine Minute in die bestehende Linux-Mint-Installation. Eigentlich ist dieses Notebook aber dazu gedacht, Ersatzteile zu liefern, falls das zweite baugleiche Notebook kaputt ginge. Daher war überhaupt nicht geplant, da überhaupt irgendwas drauf zu installieren. Und eine Verschlüsselung der Festplatte nützt überhaupt nichts sofern der Rechner davon booten kann. Ob ein Entschlüsselungspasswort für eine verschlüsselte Platte sicherer ist als das Anmeldepasswort, darüber kann man vorzüglich diskutieren. Selbst eine biometrische Anmeldung ist mit Fotos, 3D-Drucks und Wachsabdrücken knackbar, wie Apple und Microsoft immer wieder eindrucksvoll zeigen.

[goetz @ 3rz]

Und eine Verschlüsselung der Festplatte nützt überhaupt nichts sofern der Rechner davon booten kann.

Wieso nicht?

Ob ein Entschlüsselungspasswort für eine verschlüsselte Platte sicherer ist als das Anmeldepasswort, darüber kann man vorzüglich diskutieren.

Da würden mich die Argumente interessieren. Denn der dargelegte Fall, jemand hat physischen Zugriff auf die Maschine, bootet sie geschwind, um dann das Root-Passwort oder Dateiinhalte zu ändern, oder Dateien herunterzuladen, genau das funktioniert mit einer Festplattenverschlüsselung nicht mehr.

Selbst eine biometrische Anmeldung ist mit Fotos, 3D-Drucks und Wachsabdrücken knackbar, wie Apple und Microsoft immer wieder eindrucksvoll zeigen.

Das ist doch ein völlig anderes Thema?

[1ST1]

Ich habe hier z.B. ein Bitlockerverschlüsseltes Notebook vor mir. Das bootet von der Platte sobald man es einschaltet (und das BIOS Passwort eingegeben hat). Solange die Platte in dem Notebook verbaut ist, ist der einzige Schutz die Anmeldeprozedur von Windows (die kann nur Passwort sein, oder Smartcard plus Pin). Die Bitlockerverschlüsselung hilft nur, die Platte davor zu schützen, sie an einem anderen Rechner auszulesen. (Und selbst das geht, wenn man den Key kennt). Und welches Passwort ich errate oder per Social Engeneering rausbekomme, ist doch egal?!?

[goetz @ 3rz]

Ich habe hier z.B. ein Bitlockerverschlüsseltes Notebook vor mir. Das bootet von der Platte sobald man es einschaltet (und das BIOS Passwort eingegeben hat). Solange die Platte in dem Notebook verbaut ist, ist der einzige Schutz die Anmeldeprozedur von Windows (die kann nur Passwort sein, oder Smartcard plus Pin). Die Bitlockerverschlüsselung hilft nur, die Platte davor zu schützen, sie an einem anderen Rechner auszulesen. (Und selbst das geht, wenn man den Key kennt). Und welches Passwort ich errate oder per Social Engeneering rausbekomme, ist doch egal?!?

Ich kann dir nicht folgen.

Das Grundproblem im Thread war: bestehendes Linux, root-Passwort nicht bekannt. Ich schrieb daraufhin, wie man das umgeht. Und auf einen Kommentar hin, dass dagegen nur eine Festplattenverschlüsselung hilft.

Du schreibst jetzt, dass die Daten auch „verloren“ sind, wenn jemand das Passwort kennt. Das ist ein grundlegend anderes Szenario. Natürlich kommt man an die Daten ran, wenn man das Passwort hat, sonst wäre es ja auch keine Datenverschlüsselung, sondern eine Datenzerstörung.

Es ging also gerade nicht darum, dass das Passwort bekannt ist, sondern darum, dass die Kenntnis des Passworts irrelevant ist, wenn man an die Daten ranmöchte und vor dem Rechner sitzt. Das geht auch ganz ohne Passwort. Und ohne Social Engineering und ohne Waterboarding.

Und natürlich ist eine Festplattenverschlüsselung alleine nicht selig machend, Sicherheit besteht immer aus mehr als aus einer Komponente. Aber gegen den gar nicht so seltenen Fall "Laptop weg" oder "Wohnung ausgeräumt, iMac weg" mit einhergehendem "ohje, was ist mit all meinen Daten" hilft es sehr effektiv. Und heutzutage ist das auch trivialst einzurichten, Systemeinstellungen, FileVault anknipsen, fertig.

[Johannes]

Ich glaube das ist gut auf den Punkte gebracht - dem kann ich mich nur uneingeschränkt anschließen.

Gruß
Johannes

[1ST1]

Nein, das Grundproblem war nicht "Linux Root Passwort unbekannt", sondern Rootpasswort egal, interessiert nicht, da die Installation eh nicht gebraucht wird. Dass man das knacken kann, ist mir bekannt, aber in dem Fall völlig irrelevant.

Übrigens, auch das Anmeldepasswort von Windows ist knack- oder umgehbar. "Ultimate Boot CD" knackt Anmeldepasswort des lokalen Admins. und man kann eine Hilfefunktion von Windows für barrierefreien Zugang zur Windows-Anmeldung so umbiegen, dass eine CMD-Shell aufgeht, mit Admininstrator-Rechten. Geht alles, diese Manipulation kann man aber mit Festplattenverschlüsselung erschweren. Anleitungen für diese Hacks gibts im Netz.

[mfro]

Um das zumindest zu erschweren (hier wie dort), muss man doch bloss das Booten von USB/CD (oder was auch immer) im BIOS unterbinden und ein BIOS-Passwort setzen.

Dann müsste schon einer die Platte ausbauen, um an die Daten zu kommen. Festplattenverschlüsselung macht das noch ein wenig wasserdichter.

[1ST1]

So gut wie jedes Mainboard hat einen CMOS-Clear-Jumper. Damit ist die Bootreihenfolge und das BIOS-Passwort weg.

[yalsi]

Bei Grub kann man ein eigenes Passwort setzen, das den Aufruf der Kommandozeile schützt. Das empfehle ich immer für Rechner, dienin zutrittsgeschützten Räumen stehen und im Normalbetrieb per KVM Switch remote gemanaged werden. Eine Festplattenverschlüsselung ebenso- die entschärft vor allem das Entsorgungsproblem defekter Platten (wobei mechanische Zerstörung immer noch das beste ist). Natürlich ist dann das Passwort-Knacken ein Angriffsszenario, aber eben nicht so ein Triviales wie die init-Manipulation. Es geht ja immer darum, Hürden möglichst hoch zu machen- unüberwindbar sind keine Sicherheitsmaßnahmen.

[1ST1]

Genau so ist es.

Aber aus Bequemlichkeit sind BIOS- und Plattenverschlüsselungspasswörter immer recht einfach gehalten, Bitlocker frag aber nicht nach einem PW, sondern schaut ins NVRAM ob es eine Signatur findet, wonach Platte zu Rechner passt. Sonderzeichen werden auf der Ebene meistens eher nicht verwendet, da die an der Stelle unzuverlässig sind (z.B. bei Dell Servern werden zwar beim Festlegen des BIOS-Passworts Zeichen wie # angenommen, aber nicht gespeichert und später beim Eingeben ist das dann falsch, quasi aus "#passwort#" wird dann "passwort"). Außerdem die Sache mit deutscher/englischer Tastatur, wo dann die Belegung zwischen BIOS und Betriebssystem differenziert, und damit zusammenhängend dann noch Konvertierungsprobleme der eigegebenen Zeichen zu Scancodes durch die diversen KVM-Lösungen, iDrac, ILO, usw. Mehr als "Start123" oder ein Kürzel des Benutzernamens ist es dann meistens nicht, zumal zuminestens früher die BIOSse öfters auch noch ein Standardpasswort als Hintertürchen hatten... Also alles nicht unüberwindbar!

[yalsi]

Wieso redest Du eigentlich immer von Bitlocker? Unter Linux gibts ganz andere Verschlüsselungslösungen. Bitlocker ist doch MS und hinterlegt u.U. noch einen Nachschlüssel in der MS cloud- das ist eh Nonsens.

[1ST1]

Der Schlüssel von Bitlocker liegt (optional!!!) meines Wissens nicht auf Azure, sondern im Computerobjekt im Active Directory, gemanaged wird das dann mit einem MBAM-Server.

Aber jetzt sind wir offtopic von offtopic und Johannes scheint momentan viel Zeit zum Aufräumen zu haben...

[Johannes]

Haha, ich bin es nur einfach leid, gute Threads in sinnlose Diskussionen abdriften zu lassen...

Es gibt drei Möglichkeiten den Bitlocker Recovery Key zu speichern: Lokal, On Premise AD, Azure AD. Wenn das Gerät im Azure AD join läuft, dann wir der Key automatisch im Azure AD gespeichert. Gerade nochmal nachgesehen ;-)

[1ST1]

Ok, die Azure-Variante kannte ich noch nicht, in meinem Kundenkreis wird das kaum genutzt, die betreiben lieber ihre eigene Infrastruktur.