Hi, Liste! Wenn ich auf einem NIS-Client als Benutzer ypcat passwd eingebe, bekomme ich eine passwd angezeigt, in der die Passwörter verschlüsselt mit drinstehen (also kein "x" an der Stelle, wie man es erwarten würde). Damit hat ein Benutzer ein file zur Hand, dass er bequem mit z.B. john bearbeiten kann, um die Passwörter zu entschlüsselt. Auf einem System ohne NIS (etwa lokaler Rechner) ist es nicht möglich, diese Informationen zu erhalten, da die Benutzer ja keine Leserechte auf die /etc/shadow haben. Da es durchaus möglich ist, dass jemand auf Grund von mehr CPU-Power etwaige schwache Passwörter schneller entschlüsselt als die Admin- Prüf-Kiste, würde mich interessieren, wie gängige Workarounds für dieses Problem aussehen? Ich habe festgestellt, dass ich mich als Benutzer weiterhin anmelden kann, wenn die Rechte auf ypcat so gesetzt sind, dass Benutzer diesen Befehl nicht ausführen können. Ist das die einzige Möglichkeit, wie ich o.g. Problem lösen kann? CU Martin
Hallo, Am Sonntag, 27. Oktober 2002 19:10 schrieb Martin Oehler:
Wenn ich auf einem NIS-Client als Benutzer
ypcat passwd
eingebe, bekomme ich eine passwd angezeigt, in der die Passwörter verschlüsselt mit drinstehen (also kein "x" an der Stelle, wie man es erwarten würde). Damit hat ein Benutzer ein file zur Hand, dass er bequem mit z.B. john bearbeiten kann, um die Passwörter zu entschlüsselt.
Ja.
Auf einem System ohne NIS (etwa lokaler Rechner) ist es nicht möglich, diese Informationen zu erhalten, da die Benutzer ja keine Leserechte auf die /etc/shadow haben.
NIS ist älter als das shadow Konzept.
Da es durchaus möglich ist, dass jemand auf Grund von mehr CPU-Power etwaige schwache Passwörter schneller entschlüsselt als die Admin- Prüf-Kiste, würde mich interessieren, wie gängige Workarounds für dieses Problem aussehen?
evtl. NIS+ ? Gibt's für Linux aber nur Client-seitig. Und ob es das Problem tatsächlich löst weiß ich auch nicht. LDAP statt NIS sollte helfen.
Ich habe festgestellt, dass ich mich als Benutzer weiterhin anmelden kann, wenn die Rechte auf ypcat so gesetzt sind, dass Benutzer diesen Befehl nicht ausführen können. Ist das die einzige Möglichkeit, wie ich o.g. Problem lösen kann?
Ich bezweifle, dass du das Problem damit gelöst hast. Schöne Grüße aus Bremen hartmut
On Sun, Oct 27, Hartmut Meyer wrote:
Hallo,
Am Sonntag, 27. Oktober 2002 19:10 schrieb Martin Oehler:
Wenn ich auf einem NIS-Client als Benutzer
ypcat passwd
eingebe, bekomme ich eine passwd angezeigt, in der die Passwörter verschlüsselt mit drinstehen (also kein "x" an der Stelle, wie man es erwarten würde). Damit hat ein Benutzer ein file zur Hand, dass er bequem mit z.B. john bearbeiten kann, um die Passwörter zu entschlüsselt.
Ja.
Und deswegen läßt ein guter SysAdmin john selber regelmässig laufen und sperrt solche Accounts.
Ich habe festgestellt, dass ich mich als Benutzer weiterhin anmelden kann, wenn die Rechte auf ypcat so gesetzt sind, dass Benutzer diesen Befehl nicht ausführen können. Ist das die einzige Möglichkeit, wie ich o.g. Problem lösen kann?
Ich bezweifle, dass du das Problem damit gelöst hast.
Ist nicht. Jeder kann sich ein ypcat schnell selber compilieren. Ausserdem gibt es noch getent und zig andere Tools. Wer NIS einsetzt, muß selber regelmässig john und Co laufen lassen. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Deutschherrnstr. 15-19 D-90429 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B
Hi! Am Son, 2002-10-27 um 22.28 schrieb Thorsten Kukuk:
Und deswegen läßt ein guter SysAdmin john selber regelmässig laufen und sperrt solche Accounts.
Das ist richtig und wird auch gemacht, ich will mich allerdings ungern darauf verlassen, dass ich schwache Passwörter schneller entschlüssele als ein potentieller Cracker. Leider ist John auch nicht wirklich darauf ausgelegt, verteilt zu arbeiten. Im Moment verteile ich die zu prüfenden Passwörter einigermassen gleichmäßig auf die verfügbare Anzahl von Prozessoren. Jedoch ist prinzipiell davon auszugehen, dass jemand, der sich die passwd mit nach Hause nimmt, wohl einen schnelleren Prozessor aufbieten kann als der Schnitt bei uns (unsere Server-Prozessoren sind lahm weil Suns, auf den aktuellen PCs läuft...fragt nicht). Außerdem kann so etwas IMHO nicht die Basis eines vernünftigen Sicherheits-Konzepts sein. Die in der FAQ von john genannte Adresse zum Download von wordlists (sable.ox.ax.uk) funktioniert nicht, man muß die files wohl als CD ordern. Die mitgelieferte wordlist ist ziemlich kurz (2290 Einträge), das schränkt mein Vertrauen in john erheblich ein.
Ist nicht. Jeder kann sich ein ypcat schnell selber compilieren. Ausserdem gibt es noch getent und zig andere Tools.
Ja, ist nicht wirklich ernsthaft.
Wer NIS einsetzt, muß selber regelmässig john und Co laufen lassen.
Gibt es einen PW-Cracker, der echt parallel arbeitet oder ist da Handarbeit angesagt? Danke für die Infos, ich werde wohl einen Umstieg auf LDAP oder NIS+ in Erwägung ziehen (habe gerade Dein NIS+-Howto gefunden). CU Martin
On Mon, Oct 28, Martin Oehler wrote:
Hi!
Am Son, 2002-10-27 um 22.28 schrieb Thorsten Kukuk:
Und deswegen läßt ein guter SysAdmin john selber regelmässig laufen und sperrt solche Accounts.
Das ist richtig und wird auch gemacht, ich will mich allerdings ungern darauf verlassen, dass ich schwache Passwörter schneller entschlüssele als ein potentieller Cracker.
Leider ist John auch nicht wirklich darauf ausgelegt, verteilt zu arbeiten. Im Moment verteile ich die zu prüfenden Passwörter einigermassen gleichmäßig auf die verfügbare Anzahl von Prozessoren.
Passwort aendern nur mit rpasswd/rpasswdd erlauben. Da wird der Check fuer das neue Password auf dem Server durchgefuehrt. Wenn Du also einmal alle Passwoerter mit john gecheckt hast und auf dem Server mit Cracklib und Co arbeitest, duerfte es sehr schwer werden, unsichere Passwoerter als neues zu benutzen. Einfach vorbeugen und nicht hinterherlaufen. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Deutschherrnstr. 15-19 D-90429 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B
Hi! Am Son, 2002-10-27 um 22.06 schrieb Hartmut Meyer:
Am Sonntag, 27. Oktober 2002 19:10 schrieb Martin Oehler:
Da es durchaus möglich ist, dass jemand auf Grund von mehr CPU-Power etwaige schwache Passwörter schneller entschlüsselt als die Admin- Prüf-Kiste, würde mich interessieren, wie gängige Workarounds für dieses Problem aussehen?
evtl. NIS+ ? Gibt's für Linux aber nur Client-seitig. Und ob es das Problem tatsächlich löst weiß ich auch nicht.
Dass NIS+ für Linux nur Client-seitig verfügbar ist, ist kein Problem, da auf dem Server (noch) Solaris läuft. Warum gibt es das Server-seitig nicht für Linux? Gibt es da Lizenzprobleme mit Sun?
LDAP statt NIS sollte helfen.
Ist LDAP sicherer als NIS+? Nach kurzer Recherche erscheint es mir, dass LDAP wohl beliebter ist, google spuckt einen Haufen Informationen bzgl. der Migration von NIS/NIS+ zu LDAP aus.
Ich habe festgestellt, dass ich mich als Benutzer weiterhin anmelden kann, wenn die Rechte auf ypcat so gesetzt sind, dass Benutzer diesen Befehl nicht ausführen können. Ist das die einzige Möglichkeit, wie ich o.g. Problem lösen kann?
Ich bezweifle, dass du das Problem damit gelöst hast.
Richtig, das hilft nur bei usern, deren Linux-Kenntnisse sich darauf beschränken, wie man sich einloggt und den Citrix-Client startet. ;) Das Konzept "security by obscurity" soll auch nicht die Grundlage einer solchen Lösung sein. Vielen Dank für die Antwort, Martin
On Mon, Oct 28, Martin Oehler wrote:
Hi!
Am Son, 2002-10-27 um 22.06 schrieb Hartmut Meyer:
Am Sonntag, 27. Oktober 2002 19:10 schrieb Martin Oehler:
Da es durchaus möglich ist, dass jemand auf Grund von mehr CPU-Power etwaige schwache Passwörter schneller entschlüsselt als die Admin- Prüf-Kiste, würde mich interessieren, wie gängige Workarounds für dieses Problem aussehen?
evtl. NIS+ ? Gibt's für Linux aber nur Client-seitig. Und ob es das Problem tatsächlich löst weiß ich auch nicht.
Dass NIS+ für Linux nur Client-seitig verfügbar ist, ist kein Problem, da auf dem Server (noch) Solaris läuft.
Warum gibt es das Server-seitig nicht für Linux?
Weil Du es noch nicht implementiert hast? ;)
Gibt es da Lizenzprobleme mit Sun?
Nein, nur keine Infos.
LDAP statt NIS sollte helfen.
Ist LDAP sicherer als NIS+?
Nein. Ob ein Dienst sicher ist, haengt von der Konfiguration des Dienstes und des Netzwerkes ab. Und je nachdem, was Du unter "sicher" verstehst, ist sogar NIS sicher. Password Aging (shadow) ist z.B. mit LDAP nicht machbar. Es gibt zwar ein schema dafuer, da aber der Benutzer Schreibzugriff auf die Attribute braucht, ist es damit witzlos. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Deutschherrnstr. 15-19 D-90429 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B
Am Mon, 2002-10-28 um 09.40 schrieb Thorsten Kukuk:
On Mon, Oct 28, Martin Oehler wrote:
Ist LDAP sicherer als NIS+?
Nein. Ob ein Dienst sicher ist, haengt von der Konfiguration des Dienstes und des Netzwerkes ab. Und je nachdem, was Du unter "sicher" verstehst, ist sogar NIS sicher.
Richtig sicher gibt es IMHO eh nicht (nenn mich paranoid). Ich bemühe mich erstmal, die ganz offensichtlichen Löcher zu stopfen und Probleme sowie Einbrüche zu erkennen. CU Martin
Hallo, Am Montag, 28. Oktober 2002 09:40 schrieb Thorsten Kukuk:
On Mon, Oct 28, Martin Oehler wrote:
Am Son, 2002-10-27 um 22.06 schrieb Hartmut Meyer:
LDAP statt NIS sollte helfen.
Ist LDAP sicherer als NIS+?
Nein. Ob ein Dienst sicher ist, haengt von der Konfiguration des Dienstes und des Netzwerkes ab. Und je nachdem, was Du unter "sicher" verstehst, ist sogar NIS sicher. Password Aging (shadow) ist z.B. mit LDAP nicht machbar. Es gibt zwar ein schema dafuer, da aber der Benutzer Schreibzugriff auf die Attribute braucht, ist es damit witzlos.
Aber ist es mit LDAP basierter Benutzerauthentifizierung (login) nicht möglich zu verhindern, dass jeder Benutzer Zugriff auf die verschlüsselten Passwörter hat? Schöne Grüße aus Bremen hartmut
On Mon, 28 Oct 2002, Hartmut Meyer wrote:
Hallo,
Am Montag, 28. Oktober 2002 09:40 schrieb Thorsten Kukuk:
On Mon, Oct 28, Martin Oehler wrote:
Am Son, 2002-10-27 um 22.06 schrieb Hartmut Meyer:
LDAP statt NIS sollte helfen.
Ist LDAP sicherer als NIS+?
Nein. Ob ein Dienst sicher ist, haengt von der Konfiguration des Dienstes und des Netzwerkes ab. Und je nachdem, was Du unter "sicher" verstehst, ist sogar NIS sicher. Password Aging (shadow) ist z.B. mit LDAP nicht machbar. Es gibt zwar ein schema dafuer, da aber der Benutzer Schreibzugriff auf die Attribute braucht, ist es damit witzlos.
Aber ist es mit LDAP basierter Benutzerauthentifizierung (login) nicht möglich zu verhindern, dass jeder Benutzer Zugriff auf die verschlüsselten Passwörter hat?
ein richtig konfigurierter LDAP (siehe Kommentar oben) zeigt nur das was der Admin will. Ein User sihet keine Passwoerter, auch nicht verschluesselt. Und schon gar nicht die eines anderen Users. Und wenn der Admin das will, sieht selbst der User seine eigenen Daten nicht, kann sich aber trotzdem authentifizieren. Das ist keine security by obscurity, sondern aktiv konfigurierte Sicherheit. Ausserdem kann LDAP via SSL betrieben werden. Gegen Brute-Force Attacken ist aber natuerlich auch LDAP machtlos. Beantwortet das deine Frage bzgl LDAP? Achim
On Mon, Oct 28, Hartmut Meyer wrote:
Hallo,
Am Montag, 28. Oktober 2002 09:40 schrieb Thorsten Kukuk:
On Mon, Oct 28, Martin Oehler wrote:
Am Son, 2002-10-27 um 22.06 schrieb Hartmut Meyer:
LDAP statt NIS sollte helfen.
Ist LDAP sicherer als NIS+?
Nein. Ob ein Dienst sicher ist, haengt von der Konfiguration des Dienstes und des Netzwerkes ab. Und je nachdem, was Du unter "sicher" verstehst, ist sogar NIS sicher. Password Aging (shadow) ist z.B. mit LDAP nicht machbar. Es gibt zwar ein schema dafuer, da aber der Benutzer Schreibzugriff auf die Attribute braucht, ist es damit witzlos.
Aber ist es mit LDAP basierter Benutzerauthentifizierung (login) nicht möglich zu verhindern, dass jeder Benutzer Zugriff auf die verschlüsselten Passwörter hat?
Wenn Du es entsprechend konfigurierst, ja. Ist aber auch mit NIS+ so und sogar mit NIS machbar. Wie ich geschrieben habe, die "Sicherheit" eines Dienstes hängt von der Konfiguration ab. Ich kann auch einen LDAP Dienst so aufsetzen (in dem ich die Einstellungen der default config Dateien beibehalte), das im Vergleich selbst telnet noch ein sehr sicherer Dienst ist. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Deutschherrnstr. 15-19 D-90429 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B
Hallo, Am Montag, 28. Oktober 2002 23:27 schrieb Thorsten Kukuk:
On Mon, Oct 28, Hartmut Meyer wrote:
Am Montag, 28. Oktober 2002 09:40 schrieb Thorsten Kukuk:
On Mon, Oct 28, Martin Oehler wrote:
Am Son, 2002-10-27 um 22.06 schrieb Hartmut Meyer:
LDAP statt NIS sollte helfen.
Ist LDAP sicherer als NIS+?
Nein. Ob ein Dienst sicher ist, haengt von der Konfiguration des Dienstes und des Netzwerkes ab. Und je nachdem, was Du unter "sicher" verstehst, ist sogar NIS sicher. Password Aging (shadow) ist z.B. mit LDAP nicht machbar. Es gibt zwar ein schema dafuer, da aber der Benutzer Schreibzugriff auf die Attribute braucht, ist es damit witzlos.
Aber ist es mit LDAP basierter Benutzerauthentifizierung (login) nicht möglich zu verhindern, dass jeder Benutzer Zugriff auf die verschlüsselten Passwörter hat?
Wenn Du es entsprechend konfigurierst, ja. Ist aber auch mit NIS+ so und sogar mit NIS machbar. Wie ich geschrieben habe, die "Sicherheit" eines Dienstes hängt von der Konfiguration ab. Ich kann auch einen LDAP Dienst so aufsetzen (in dem ich die Einstellungen der default config Dateien beibehalte), das im Vergleich selbst telnet noch ein sehr sicherer Dienst ist.
Gibt es ein Howto oder ähnliches, indem beschrieben ist, wie man das (verschlüsselte Passwörter für jeden Nutzer sichtbar) für NIS abstellen kann? Das wäre dann ja möglicherweise die direkteste Antwort auf Martins ursprüngliche Frage in diesem Thread. Und mich würde es auch interessieren. Schöne Grüße aus Bremen hartmut
Hi! Am Die, 2002-10-29 um 03.35 schrieb Hartmut Meyer:
Gibt es ein Howto oder ähnliches, indem beschrieben ist, wie man das (verschlüsselte Passwörter für jeden Nutzer sichtbar) für NIS abstellen kann?
Das wäre dann ja möglicherweise die direkteste Antwort auf Martins ursprüngliche Frage in diesem Thread. Und mich würde es auch interessieren.
Ich kann mir vorstellen, dass das eine ganze Menge von Leuten interessieren könnte... :) CU Martin
Hallo Martin, Am 2002-10-27 18:10 GMT, Martin Oehler schrieb:
ypcat passwd
eingebe, bekomme ich eine passwd angezeigt, in der die Passwörter verschlüsselt mit drinstehen (also kein "x" an der Stelle, wie man es erwarten würde).
Hmmm, mal probieren:
ypcat passwd
...
user:x:510:100:full name:/home/user:/bin/bash
...
ypcat shadow
No such map shadow. Reason: No such map in server's domain
Sieht doch eigentlich ganz gut aus.
--
Ralf Cirksena
participants (5)
-
Achim Hoffmann -
Hartmut Meyer -
Martin Oehler -
Ralf Cirksena -
Thorsten Kukuk