Linux-Benutzer Kennwort ändern? [Gelöst]

[DeletedUserReAsG]

Hmm. Fehlen zuviele Infos. Wenn’s aber vor dem Ausliefern, nicht im Betrieb, gemacht wird, kann man die /etc/shadow auch manuell bearbeiten/generieren. Außerdem sehe ich nicht, warum das Auslieferungspasswort soviel Aufwand benötigen sollte – eine der ersten Sachen, die ein Empfänger von solchen Geräten machen sollte, wäre, das Passwort zu ändern.

[jmar83]

Geht um u.A. um primär- sowie sekundär-Betrieb, wenn das primäre Gerät ausfällt übernimmt das Sekundäre. Kennwort wird aus der MAC-Adresse generiert. Jedem Gerät wird die MAC des anderen Gerätes hinterlegt. Daraus wird dann das Kennwort errechnet, welches eine SSH-Verbindung aufbaut. U.A. Zwecks Synchronisation: Primäres Gerät zum Sekundären, wenn man nach einem Ausfall Daten auf dem Sekundären verändert, welches in dieser Situation die Rolle des Primären annimmt, und dann später wieder das Primäre zum Verbund hinzufügt, dann sollen die Daten wieder in die andere Richtung synrchonisiert werden...

Einfach mal den Algorithmus für die Kennwort-Generierung zu ändern ist zu heikel: "Einfache" Lösungen wie "-" oder "?" durch andere Zeichen zu ersetzen - angesichts der Tatsache dass gewisse Zeichen scheinbar nur am Anfang des Kennworts Probleme machen. (Siehe erster Problemfall, ohne die "--" davor mit dem "-") Das später zur Synchronisation aus der MAC generierte Kennwort würde dann nicht mehr zum ursprünglich mit "usermod", "password" sowie "openssl" gesezten Kennwort passen.

Die Systeme, welche bereits in Betrieb sind wären dann also nach einem Update nicht mehr in der Lage aufeinander zuzugreifen - es sei denn, man würde manuell eingreifen und überall beim entsprechenden User das Kennwort von Hand ändern...

[jmar83]

Und für den Kunden ist es gar nicht vorgesehen, das Kennwort zu ändern. Das würde gar nicht funktionieren: Passt das gesetzte Kennwort (Linux- sowie MySQL-Benutzer) nicht mehr zur MAC-Adresse auf dem Gerät selbst, so verweigert das Gerät den Dienst. Damit man nicht einfach die SD-Karte vom einen in das andere Gerät tauschen kann. Und, noch wichtiger, auch nicht die SD-Karte kopieren kann!

[DeletedUserReAsG]

Ich befürchte, an dieser Stelle muss ich dann passen. Hartcodierte Passwörter sind für erheblich viele Sicherheitsprobleme in der letzten Zeit verantwortlich, da will ich nix mit zu tun haben.

[mludwig]

Die Sicherheit des Systems (oder noch schlimmer: aller Systeme) basiert bei euch dann allein auf dem (geheimen?) Algorithmus, der aus der MAC-Adresse das Passwort generiert. Ist dieser einmal einem Angreifer bekannt, kann er die Passwörter aller Systeme berechnen. MAC-Adressen sind nicht wirklich geheime Informationen ... und der Algorithmus lässt sich vermutlich in eurem System aus dieser SD-Karte auslesen ...

Ich hoffe ich irre mich.

[jmar83]

Na ja, so gravierend ist es auch nicht:

- Wird in einem eigenen Subnetz betrieben (u.A. mit spez. VLAN- und Layer3-Switches sowie Access Points welche mehrere SSIDs haben und damit die versch. VLANs und Subnetze abbilden), wo nicht jeder den WLAN-Key kennt...

- Ist nicht dafür ausgelegt, mit offenem SSH-Port im Internet zu sein. Kein Problem jedoch mit VPN. (Web-GUI wäre möglich, aber da ist ein eigenes Kennwort zum Account. Wenn man Port 80 in eigenen Netz nicht dem Web aussetzen will, dann kann man das Gerät über eine öffentliche Webseite steuern)

- Ein grosser Teil des Codes (wichtige Teile der Logik) liegt in compilierter Form vor, und nur das (eher dumme) GUI in PHP, ein Bisschen MySQL, HTML, JavaScript, CSS etc..

[jmar83]

Ja, das man die Karte auf einem anderen Linux-System einlesen kann, ist fakt. Aber der Algorithmus ist definitiv nicht im Klartext...

Das Auslesen auf einem anderen System könnte man z.B. verhindern mit:

- Partitionen verschlüsseln mit Linux-Dateisystemverschlüsselung. (Aber ein System, wo der Schlüssel welcher entschlüsselt gleich auf demselben Datenträger ist und zwangsweise wohl in unverschlüsselten Bereich liegt -> SOWAS MISSTRAUE ICH PERSÖNLICH!!)

- HW-Verschlüsselung (Teuer, aufwändig und hat wohl auch das eine oder andere Problem..)

- Speicherkarte mit Sekundenkleber festkleben. (Na ja, die brachiale Tour halt..)

[jmar83]

"Ist nicht dafür ausgelegt, mit offenem SSH-Port im Internet zu sein. Kein Problem jedoch mit VPN. "

Jedoch nicht für den Kunden selbst damit er mit SSH selbst rumspielen kann. Wenn schon für den Support...

[mludwig]

Mag sein das dieses Verfahren bei Euch so ok ist, ich wollte aber darauf hinweisen dass dieses Design problematisch ist. Wenn die Systemsicherheit darauf vertraut, dass kein System jemals gehackt wird und euch dieser Algo nicht abhanden kommt (also auch kein System geklaut wird), dann ist das in meinen Augen schlechtes Design. In eurem Fall wird die Sicherheit dann vielleicht durch den Aufbau des übrigen Netzes erhalten, aber Defense in Depth ist eben besser, d. h. dem Angreifer immer mehrere Hürden in den Weg legen.

Wenn ich das so ansehe: ihr hinterlegt die MAC-Adresse des Slave-Systems auf dem Master, damit dieser das ssh-Passwort für eine Art Synchronisierung berechnen kann. Diese Berechnung und die Art wie die Verbindung dann aufgebaut wird wäre für den Angreifer dann hoch interessant, die MAC für das gegenüber hat er dann ja gleich mit.

Wieso hinterlegt ihr nicht den ssh-Key des anderen Systems, also key-Auth? und das Individuell für jedes System, so dass auch nur jeweils ein System oder ein Paar kompromitiert wäre. Wenn ein System abhanden kommt oder kompromitiert ist kann man auch einfach den Key tauschen. Das ist dann auch das normale Verfahren für ssh, tausendfach auf vielen Systemen erprobt, sogar direkt im Internet.

[jmar83]

Vielen Dank - natürlich kann dies kaum dementiert werden, das ist mir schon klar. Über ein Redesign müsste man bei Version 2.0 nachdenken, auf jeden Fall!

Habe es nun mit dem Mitarbeiter abgeklärt - Hochkommas werden im Kennwort nicht verwendet. Das macht nämlich aus Stress, denn man kann die Hochkommas nicht einfach mit einem \ escapen:

Code: Alles auswählen

usermod -p $(openssl passwd -- '\'.......') pi

...das hat nämlich zur Folge, dass der Befehl gar nicht zu Ende ausgeführt wird - man gelangt nicht wieder zu Konsole zurück, sondern ein '>' erscheint dann in der Unteren Zeile der Konsole, nach dem Eingeben dieses Befehls.

Da wie bereits gesagt keine Hochkommas verwendet werden, werden wir's wohl mal so versuchen alle Kennwörter in Hochkommas zu nehmen:

Code: Alles auswählen

usermod -p $(openssl passwd -- 'Kennwort_ohne_Hochkommas') pi

Hoffe mal das läuft so, aber das werden wir dann früher oder später sehen...

[jmar83]

"Das macht nämlich aus Stress, denn man kann die Hochkommas nicht einfach mit einem \ escapen:"

...jedoch kann man Hochkommas verwenden, wenn diese in normalen Anführungszeichen sind:

Code: Alles auswählen

usermod -p $(openssl passwd -- "'") pi

-> Das Kennwort ist in diesem Fall ein '. Wenn dann aber Hochkommas sowie normale Anführungszeichen im Kennwort sind, dann wird's dann richtig "lustig", na ja...

Aber glücklicherweise sind weder Anführungszeichen noch Hochkommas mit im Kennwort drin - wie bereits erwähnt.

[jmar83]

Genug der Sonderzeichen...!! Nun wird das Problem "gelöst" (na ja, eher ein "Notnagel") dass GAR KEINE Sonderzeichen mehr im Kennwort mehr drin sind. Macht es sicherheitstechnisch nicht sicherer, allerdings was den Betrieb (Zuverlässigkeit) betrifft. Auf den vorhandenen Systemen müssen dann halt nach einem Update der in C/C++ geschriebenen Services (welche das PW aus der MAC generieren) das Kennwort des entsprechenden Users von Hand geändert werden. (Dafür haben wie ein Windows-Kommandozeilen-Tool, welches das macht.)