Frage:
Warum brauche ich Kerberos, wenn ich nur einen Benutzernamen und ein Passwort für den Zugriff auf Dienste verwenden kann?
Minaj
2016-07-21 00:17:54 UTC
view on stackexchange narkive permalink

Ich habe gelesen, dass Kerberos zur Authentifizierung von Benutzern verwendet wird, die auf Dienste auf verschiedenen Servern in einem Unternehmensnetzwerk zugreifen möchten, aber ich verstehe den Zweck von Kerberos immer noch nicht. Warum erstellt der Systemadministrator nicht einfach ein Benutzerkonto für jeden Benutzer auf jedem Server, damit die Benutzer mit ihrem Benutzernamen und Kennwort auf die Ressourcen zugreifen können, auf die sie zugreifen möchten? Warum ist ein so ausgeklügeltes Authentifizierungsprotokoll erforderlich?

dafür: "für jeden Benutzer auf jedem Server".Stellen Sie sich die Wartung und den Albtraum für die Benutzer vor
Wie würden Sie diese Passwörter synchronisieren?
Kerberos dient für Unternehmensnetzwerke dem gleichen Zweck wie OpenID für Websites. So wie Sie Ihre Google- oder Facebook-Anmeldesitzung für den Zugriff auf Stack Exchange verwenden können, können Sie sich einmal bei Ihrem Netzwerk anmelden und dann alle darin enthaltenen Dienste verwenden.
Von @LuisCasillas answer: "Stellen Sie sich vor, Sie haben 50 Benutzer ...".Ich bin auf einen Server mit mehr als 300.000 definierten Benutzern gestoßen, und viele von uns können sich weit mehr vorstellen.Das Erstellen von Konten ist nicht trivial, wenn Sie sichere Server wünschen.
Fünf antworten:
#1
+42
Luis Casillas
2016-07-21 01:55:28 UTC
view on stackexchange narkive permalink

Warum erstellt der Systemadministrator nicht einfach ein Benutzerkonto für jeden Benutzer auf jedem Server, damit die Benutzer mit ihrem Benutzernamen und Kennwort auf die Ressourcen zugreifen können, auf die sie zugreifen möchten?

Stellen Sie sich vor, Sie haben 50 Benutzer und 50 Server. Nehmen wir der Einfachheit halber an, dass alle 50 Benutzer Zugriff auf alle 50 Server haben sollen, alle auf allen Servern die gleichen Berechtigungen haben und wir diese Berechtigungen niemals ändern müssen. Dies sind insgesamt 2.500 Kennworteinträge, die erstellt werden müssen.

Hinzufügen eines neuen Benutzers

Wenn Sie einen neuen Benutzer hinzufügen, muss der Administrator gehen zu allen 50 Servern und fügen Sie diesen einen Benutzer zu allen hinzu. Dazu müsste der Administrator den Befehl create user auf allen 50 Servern ausführen. Dieses Bit kann automatisiert werden, aber der Teil, der nicht sicher automatisiert werden kann, besteht darin, dass der Benutzer sein Kennwort 50 Mal einmal pro Server eingeben muss.

Warum dieses letztere Problem? Da Kennwortauthentifizierungssysteme so konzipiert sind, dass sie keine Kopie des Kennworts behalten, nicht einmal eine verschlüsselte Kopie. Wenn der Benutzer sein neues Kennwort auf Server 1 eingibt, vergisst dieser das Kennwort sofort, sodass er es für Server 2 und 3 usw. erneut eingeben muss.

Hinzufügen eines neuen Servers

Vielleicht denken Sie jetzt, Sie könnten ein Skript schreiben, das:

  1. auf Server X ausgeführt wird;
  2. Fordert den neuen Benutzer auf, sein neues Kennwort einzugeben.
  3. Fragt den Administrator nach seinem Kennwort.
  4. Meldet sich bei den Servern Nr. 1 bis Nr. 50 an und erstellt das Benutzerkonto auf jeder von ihnen mit dem gleichen Passwort.
  5. ol>

    Das ist ein bisschen zwielichtig, aber selbst wenn Sie es versuchen, haben Sie immer noch ein anderes, größeres Problem. Angenommen, Ihr Unternehmen kauft einen neuen Server und wir benötigen jetzt unsere 50 Benutzer, um Zugriff auf diesen Server zu haben. Da keiner der Server eine Kopie der Benutzerkennwörter enthält, müsste der Administrator zu jedem Benutzer gehen und ihn ein Kennwort für sein Konto auf dem neuen Server eingeben lassen. Und es führt kein Weg daran vorbei, es sei denn, Sie haben Kopien der Benutzerkennwörter aufbewahrt - was wiederum eine unsichere Praxis ist.

    Zentralisierte Kennwortdatenbank

    Um diese Probleme zu lösen, muss Ihre Benutzer- / Kennwortdatenbank wirklich an einem Ort zentralisiert sein und alle Server müssen diese Datenbank konsultieren, um Benutzernamen und Kennwörter zu authentifizieren. Dies ist wirklich das absolute Minimum, das Sie für eine verwaltbare Multiuser / Multiserver-Umgebung benötigen. Jetzt:

    1. Wenn Sie einen neuen Benutzer hinzufügen, übernehmen alle Server ihn automatisch aus der zentralen Datenbank.
    2. Wenn Sie einen neuen Server hinzufügen, werden automatisch alle Benutzer abgerufen die Benutzer aus der zentralen Datenbank.
    3. ol>

      Hierfür gibt es eine Vielzahl von Mechanismen, auch wenn sie immer noch nicht das bieten, was Kerberos bietet.

      Kerberos

      Sobald Sie über eine solche zentralisierte Datenbank verfügen, ist es sinnvoll, diese mit mehr Funktionen zu erweitern, sowohl zur Vereinfachung der Verwaltung als auch zur Vereinfachung. Kerberos fügt die Möglichkeit hinzu, dass sich ein Dienst, wenn sich ein Benutzer erfolgreich bei einem Dienst angemeldet hat, an die Tatsache "erinnert" und anderen Diensten "beweisen" kann, dass sich dieser Benutzer erfolgreich angemeldet hat. Diese anderen Dienste, denen ein solcher Nachweis vorgelegt wird, lassen den Benutzer ein, ohne ihn nach einem Kennwort zu fragen.

      Dies bietet eine Mischung aus Komfort und Sicherheit:

      1. Benutzer ziehen nicht an Sie werden nicht immer wieder nach ihrem Passwort gefragt, wenn sie es an diesem Tag bereits einmal erfolgreich eingegeben haben.
      2. Wenn Sie Programmierer haben, die Programme schreiben, die auf mehrere Server zugreifen, und diese Server eine Authentifizierung erfordern, können sich die Programme jetzt bei diesen Servern authentifizieren, ohne ein Kennwort angeben zu müssen, indem sie die Anmeldeinformationen des Serverkontos wiederverwenden, unter dem sie ausgeführt werden.
      3. ol>

        Letzteres ist wichtig, da es eine unsichere, aber allzu häufige Praxis minimiert oder beseitigt: automatisierte Programme, bei denen Sie Kopien von Benutzernamen und Kennwörtern in Konfigurationsdateien ablegen müssen. Auch hier ist eine Schlüsselidee der sicheren Kennwortverwaltung, keine Kopien von Kennwörtern zu speichern, auch keine verschlüsselten Kopien .

Hinzufügen eines neuen Servers: Sie können `/ etc / passwd` und` / etc / shadow` (d. H. Hashes von Passwort + Salt) auf den neuen Server spiegeln.Sie erhalten kein Single-Sign-On, lösen jedoch die meisten anderen Probleme.Ich habe ein Skript geschrieben, das dies tat (nur für UID 500 und höher), und es funktionierte gut in einigen kleinen Rechenclustern.Die meisten Benutzer verwendeten jeweils nur einen Cluster, sodass das Fehlen von SSO kein Problem darstellte.Diese Ghetto-Lösung verhinderte, dass ein Cluster unbrauchbar wurde, nur weil ein * anderer * Computer ausgefallen war. Es gab also keinen Fehlerpunkt, ohne dass eine replizierte Authentifizierung oder LDAP-Server erforderlich waren.
Dies war in einer Universitätsumgebung, in der die meisten Benutzer ihre eigenen Desktops verwalteten und ihre Desktop-Benutzerkonten nicht mit ihren Konten in den Forschungsgruppenclustern verbunden waren.Wie gesagt, kleine und hackige Lösung, aber sehr zuverlässig und nie ein Problem verursacht.:) Kleiner Nachteil: Leute konnten nur ihr Passwort im Master-Cluster ändern.
@PeterCordes: Ja, das fällt unter meine Kategorie "Zentralisierte Passwortdatenbank".Mein Konzept, in jeden Computer zu gehen und das Passwort manuell einzugeben, ist zwar hyperbolisch, aber ich habe es gewählt, weil es den Punkt hervorhebt, dass sichere Passwortbehandlung bedeutet, dass die Passwörter nicht aufgezeichnet werden - eine Voraussetzung, um zu verstehen, ob Ihre Lösung sicher ist.Eine weitere Überlegung ist, dass Sie möglicherweise Nicht-Unix-Systeme haben, die die Unix-Kennwort-DBs nicht verwenden können.
Eine zentralisierte Kennwortdatenbank ist sehr anfällig für seitliche Eskalation.Wenn ein Angreifer einen Server gefährdet, kann er Kennwörter abhören und diese verwenden, um andere Server zu gefährden.Kerberos versucht zumindest, dies zu stoppen.
@paj28: Ich stimme größtenteils zu, aber ich habe Kerberos-Umgebungen gesehen, in denen Benutzer direkt auf einzelne Server ssh und ihre Passwörter über SSH senden.Die einzelnen Server beschaffen dann die Kerberos-Token.Wenn jemand einen dieser Server kompromittiert, haben Sie die gleichen Risiken.Während Kerberos tatsächlich * versucht *, dies zu stoppen, ist "Versuche" dort ein Schlüsselwort.
@LuisCasillas Zumindest theoretisch sollten Sie ein Ticket weiterleiten.Wenn ich ein Ticket auf meinem lokalen Computer habe, kann ich mich über GSSAPI beim SSH-Server anmelden (mich durch das lokal vorhandene Kerberos-Ticket authentifizieren) und ein Ticket auf der Fernbedienung erhalten.Sicher, nichts hindert TLS_NULL_WITH_NULL_NULL daran, zu existieren, aber der auf TLS_NULL_WITH_NULL_NULL konfigurierte Server ist nicht weniger ein Fehler von TLS, als Benutzer zu zwingen, sich über das Kennwort von SSH von Kerberos über das Kennwort anzumelden.
#2
+27
DKNUCKLES
2016-07-21 00:27:54 UTC
view on stackexchange narkive permalink

Einfach ausgedrückt, das wäre ein administrativer Albtraum.

Mit Kerberos können Administratoren beliebig viele Mitarbeiter dieselben Anmeldeinformationen verwenden, um sich in Ressourcen in ihrer gesamten Domäne anzumelden.

Nehmen wir an, dass dies in einem einfachen Netzwerk nicht vorhanden war.

  1. Der Benutzer gibt ein Kennwort ein, um seinen Computer zu entsperren.
  2. Der Benutzer möchte a zuordnen Netzlaufwerk. Sie müssen jetzt ihr Passwort erneut eingeben.
  3. Der Benutzer möchte dann eine E-Mail erhalten. Sie öffnen Outlook und müssen dann ein weiteres Kennwort eingeben.
  4. Der Benutzer muss sich dann im Intranet des Unternehmens anmelden. Das ist ein anderes Passwort.
  5. ol>

    Sie haben die Idee. Wenn Kerberos nicht verwendet wird, muss der Benutzer Kennwörter für alle Server verwalten, auf denen Dienste gehostet werden, auf die er zugreifen muss. Dies würde sowohl Benutzern als auch Administratoren Kopfschmerzen bereiten. Die meisten Unternehmensrichtlinien besagen, dass Benutzer ihr Kennwort alle X Tage ändern müssen. Können Sie sich vorstellen, ein Endbenutzer zu sein und Ihr Kennwort jedes Mal auf 5 Servern ändern zu müssen, wenn Sie dies tun müssen?

    Aus Sicherheitsgründen erhält der Administrator alle Anmeldeversuche (sowohl erfolgreich als auch fehlgeschlagen) Ein einzelner Ort, anstatt auf 5 verschiedenen Servern angemeldet zu sein. Dies hilft bei der Behebung von Anmeldeproblemen (z. B. Sperren) und erleichtert die Überwachung von Protokollen erheblich.

Sie sagen also im Grunde, dass Benutzer über Kerberos nur Anmeldeinformationen für einen Server verwalten?Dann authentifiziert sich dieser Server bei den verschiedenen Diensten?
@Minaj mit Kerberos verwalten Benutzer Anmeldeinformationen für eine * Domäne * und nicht für einen Server.Der Kerberos-Authentifizierungsserver teilt dann verschiedenen Ressourcen in der gesamten Domäne mit, auf welche Ressourcen der Benutzer Zugriff hat (z. B. Dateien auf einer Dateifreigabe, Drucker usw.).Dies wird als Single Sign On (oder kurz SSO) bezeichnet.
WARUM gibt dieser Authentifizierungsserver nicht einfach meinen Benutzernamen und mein Kennwort an den Dienst (oder Server, auf den ich zugreifen möchte?) Weiter.Beispiel: Wenn ich auf Dienst A zugreifen möchte, kontaktiere ich den Authentifizierungsserver B, der meine Identität nachweist, und dann leitet Server B meine Anfrage an A weiter. Wenn ich Server C kontaktieren möchte, kontaktiere ich erneut den Authentifizierungsserver B, der meine Anmeldeinformationen überprüftund leitet meine Anfrage dann an C weiter. Warum benötigen wir ein ausgeklügeltes Authentifizierungsprotokoll?Es scheint mir, dass die unkomplizierte Weiterleitung authentifizierter Anfragen, die ich oben erklärt habe, gut funktionieren würde.
@Minaj Da in Ihrem Fall Kennwörter an all diesen Orten gespeichert werden müssen, ist das Speichern von Kennwörtern (oder besser Passwort-Hashes) schwierig.Sie müssten sich auch mit Kennwortänderungen befassen - jede Kennwortänderung auf jeden Server replizieren und verschiedene Serveränderungen behandeln.Was ist, wenn ein Server die Kennwortänderung ablehnt (aufgrund von Stärkeanforderungen), andere sie jedoch akzeptieren?SSO ist eine viel sauberere und bessere Antwort mit weitaus weniger Verwaltungsaufwand.Kerberos ist nur einer von vielen SSO-Standards, aber es ist ein sehr alter, angesehener
@crovers Auf dem soeben beschriebenen System werden nur Kennwort-Hashes auf Server B gespeichert. Server B überprüft meine Identität.Dann kann es meine Anfrage an die Server A oder C weiterleiten, die ihr bereits vertrauen (und daher darauf vertrauen, dass sie mich korrekt authentifiziert hat).
Das Problem, @Minaj, ist dieses Vertrauen.Das Sprichwort lautet "Vertrauen, aber Verifizieren", und eine Verifizierung ist mit dem von Ihnen beschriebenen System nicht möglich.Darüber hinaus wird das Weitergeben von Passwörtern für den Widerruf schwierig.Sie können ein Ticket widerrufen.Sie können ein Passwort nicht einfach widerrufen, während das Konto intakt bleibt.
Wenn sich der Kennwort-Hash nur auf Server B befindet, ist das, was Sie beschreiben, SSO sehr ähnlich - außer dass in SSO Server B (der Authentifizierungsserver) nicht in der Zeile aller Anforderungen steht.In Ihrem Schema hat Server B bei jeder Anforderung seine Finger, was die Latenz erhöht und erfordert, dass B wesentlich kräftiger ist.In SSO spricht der Benutzer direkt mit dem Server, der die Ressource bereitstellt, sobald Server B sein Ticket an den Benutzer ausgestellt hat.Dies bedeutet, dass der Benutzer alle Lokalitätsvorteile des lokalen Servers erhält, wenn sich der Auth-Server in einem Land und der Dateiserver in der Nähe des Benutzers befindet.
@Minaj, Das Problem bei der Weiterleitung von Anforderungen besteht darin, dass auf Server B, dem Authentifizierungsserver, alle Anforderungen an und von Servern weitergeleitet werden.Dies bedeutet, dass der Server mehr Netzwerkbandbreite benötigt und zusätzliche Ressourcen für die Verarbeitung der Anforderungen benötigt.Mit dem Kerberos-Protokoll können Server A & C einfach bei Server B einchecken, ohne dass die Kommunikation über B verschoben werden muss.
Außerdem müsste jeder Server ein Kennwort (Hash) für jeden Benutzer haben.Das erhöht das Risiko, dass sie auslaufen, um ein Vielfaches.
DKNUCKLES ist absolut korrekt.Ich bin der Administrator über ein Netzwerk mit mehr als 100 Benutzern, Dutzenden von Servern, Anwendungen, Druckern, Freigaben usw. Die Verwaltung der Anmeldung jedes einzelnen Benutzers auf jedem einzelnen System ist ein administrativer Albtraum. Außerdem bietet der Endbenutzer einen RIESIGEN Vorteil und Zeitersparnis.Stellen Sie sich vor, der Benutzer verwendet ständig 5-10 verschiedene Systeme oder Anwendungen und müsste sich kontinuierlich anmelden und von diesen Anwendungen abmelden, Kennwörter vergessen, gesperrt werden usw. Dies würde seine Produktivität beeinträchtigen.
DKNUCKLES hat noch nie von Grabfiles gehört.
@Minaj, Wenn Literal-Passwörter weitergeleitet werden, bedeutet dies, dass jeder Dienst, der einen Benutzer validieren muss, auf sein Literal-Passwort zugreifen kann und dieses Passwort verlieren kann, wenn es kompromittiert wird.Wenn Sie viele verschiedene Dienste haben, die von verschiedenen Personen mit unterschiedlichem Sicherheitsbewusstsein geschrieben und verwaltet werden, bedeutet dies, dass das schwächste Leck angegriffen werden kann, um wörtliche Kennwörter aller Benutzer zu stehlen, die diesen Dienst nutzen - während dies bei Kerberos nur der Fall istder (gehärtete) Kerberos-Server, der alle hat.
#3
+12
duffbeer703
2016-07-21 01:47:01 UTC
view on stackexchange narkive permalink

Kerberos ist nicht als Annehmlichkeit da, sondern eine erweiterte Sicherheitsmaßnahme. Bequemlichkeit ist ein sekundärer Vorteil.

Eine gute Erklärung ist Entwerfen eines Authentifizierungssystems: Ein Dialog in vier Szenen

Grundsätzlich, anstatt nur einen magischen Token zu übergeben Um (dh Ihr Passwort) erhalten Sie ein "Ticket", das von einer vertrauenswürdigen Quelle der Wahrheit (z. B. Kerberos KDC, Microsoft AD usw.) signiert ist. Ihr Ticket teilt den Diensten mit, wer wer ist und zu welchen Berechtigungsgruppen Sie gehören. Stellen Sie sich vor, Sie kaufen eine Eintrittskarte für einen Vergnügungspark oder geben einem Begleiter bei jeder Fahrt in einem Park Geld.

#4
+8
paj28
2016-07-21 23:55:32 UTC
view on stackexchange narkive permalink

Um eine seitliche Eskalation zu verhindern .

Die administrative Komplexität der Kennwortverwaltung kann durch Verwendung einer zentralen Kennwortdatenbank wie LDAP verringert werden. Dies birgt jedoch das Risiko einer seitlichen Eskalation. Wenn ein Angreifer die Kontrolle über einen Server übernimmt, kann er still bleiben und Kennwörter abhören. Diese Kennwörter können dann verwendet werden, um andere Server zu gefährden - seitliche Eskalation.

Kerberos versucht, dies zu lösen: Benutzer senden ihr Kennwort nicht an jeden Server. Sie senden es nur an den Authentifizierungsserver und legen anderen Servern ein Ticket vor. In jüngster Zeit wurden einige Fehler festgestellt, die von Tools wie Mimikatz ausgenutzt werden. Zumindest Kerberos soll jedoch eine seitliche Eskalation verhindern. LDAP unternimmt nichts, um dies zu verhindern.

Solange alle Server so eingerichtet sind, dass sie Kerberos (d. H. Mit Tickets) _ful_ verwenden, und nicht nur Kennwörter für ein KDC mit pam_krb5 überprüfen, wie dies einige Administratoren tun.
Wer auch immer gerade abgestimmt hat: Es würde mich interessieren, was mit meiner Antwort falsch ist
#5
  0
Joshua
2016-07-21 21:35:55 UTC
view on stackexchange narkive permalink

Der Hauptvorteil von Kerberos besteht darin, dass Kontoänderungen und Kennwortänderungen sofort synchronisiert werden können.

Ich habe Lösungen für die zentrale Verwaltung verteilter Konten und clientseitige Kennwortagenten zur Verfügung, die auf 99% reagieren Nach der Anmeldung werden Sie aufgefordert, das Kennwort zu ändern. Wir gehen jedoch davon aus, dass das Ändern des Kennworts durch den Benutzer selten ist und dass wir bis zum nächtlichen Stapeljob warten können, bis die Kennwortänderung tatsächlich wirksam wird. Gleiches gilt in den meisten Fällen für Berechtigungsänderungen. Wenn wir eine Berechtigungsänderung benötigen, um jetzt wirksam zu werden, können die kleineren Tools dies nicht.

Kerberos listet in seinen Fähigkeiten die Fähigkeit auf, Verbindungen sicher zu authentifizieren, ohne sie zu verschlüsseln. Dies erweist sich in der Praxis als weniger wünschenswert, und auf diese Fähigkeit sollte man sich nicht verlassen. Der Diebstahl von Kerberos-Tickets war die Essenz eines Angriffs auf SMB vor einem Jahr, der den gesamten Zugriff als Benutzer ermöglichte, vorausgesetzt, der Benutzer verwendete irgendwo eine Netzwerkfreigabe.

Der hier angegebene "Hauptvorteil" kann nur von LDAP erhalten werden. Dies deckt also nicht wirklich ab, warum man Krb5 + LDAP nur über LDAP (mit gehashten Passwörtern im Verzeichnis) haben möchte.
@CharlesDuffy: Ich kämpfe darum, einen "Nutzen" zu zählen, der nicht wirklich einen Nutzen bringt.
Eh?Es gibt sicherlich praktische Vorteile gegenüber anderen (dh nur LDAP-reinen) Verzeichnisdienstansätzen;Sie erhalten Single-Sign-On (Benutzer geben Kennwörter nicht erneut ein, erhöhen den Komfort, verringern den Platz für Sniffer und entmutigen Dinge wie "erwartungsbasiertes" Skript für die Eingabe von Kennwörtern / gespeicherte Literale).Sie erhalten Widerstand gegen seitliche Eskalation (wenn Sie sich bemühen, es richtig zu machen).Sie erhalten Unterstützung für zwischengespeicherte Anmeldeinformationen auf eine Weise, die für einen einzelnen Dienst und einen konfigurierbaren Zeitraum spezifisch ist und eine weitaus bessere Kontrolle als die üblichen Mittel ermöglicht.Sie haben eine zentrale Protokollierung.
@CharlesDuffy: Ich habe Single Sign-On ohne Krb5 erhalten.Der seitliche Eskalationsschutz von Krb5 ist größtenteils defekt.Das Zeitlimit für zwischengespeicherte Anmeldeinformationen ist interessant, steht mir jedoch normalerweise im Weg (lang laufende Prozesse können nicht zeitlich begrenzt werden oder sie brechen ab).Vor LDAP gab es eine zentrale Protokollierung, geschweige denn Krb5.
Natürlich kann die zentrale Protokollierung auch anders durchgeführt werden, aber Sie müssen dies explizit anders einrichten. Mit Kerberos können Sie Authentifizierungsversuche zentral zentral kostenlos protokollieren.Betreff: "SSO ohne krb5", wie genau?Betreff: "Der seitliche Eskalationsschutz ist größtenteils defekt", das liegt an den Leuten, die ihn falsch einsetzen.(Ja, das Hinzufügen von GSSAPI-Unterstützung überall ist Arbeit, aber es lohnt sich, verdammt noch mal).
Wenn Sie eine GSSAPI-Verbindung zu einem gefährdeten Server herstellen und Ihr Konto über hohe Berechtigungen verfügt, wundern Sie sich nicht, wenn Ihren Master-Servern etwas wirklich Schlimmes passiert.Ich habe Code herumliegen, der speziell geschrieben wurde, um dies auszunutzen.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...