Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung		Vorhergehende Überarbeitung
wiki:kerberos [2013/01/30 16:11] – wynekenwiki:kerberos [2022/03/17 16:51] (aktuell) – angelegt wyneken
Zeile 1: Zeile 1:
 ====== Umgang mit Kerberos ====== ====== Umgang mit Kerberos ======
  
 +
 +===== Kerberos-Ticket =====
  
  
Zeile 17: Zeile 19:
 </code> </code>
    
 +
 +===== Lebensdauer der Tickets =====
 +
  
 Die Default-Lebensdauer der Tickets werden in ''/etc/krb5.conf'' definiert. Die Angaben im Abschnitt [pam] gelten für das Einloggen direkt an der Konsole. [Und auch über ''ssh''?] Die Werte im Abschnitt [libdefaults] gilt für alles andere. Die Default-Lebensdauer der Tickets werden in ''/etc/krb5.conf'' definiert. Die Angaben im Abschnitt [pam] gelten für das Einloggen direkt an der Konsole. [Und auch über ''ssh''?] Die Werte im Abschnitt [libdefaults] gilt für alles andere.
Zeile 28: Zeile 33:
  
 Vgl. ''man kinit'' für weitere Details.  Vgl. ''man kinit'' für weitere Details. 
 +
 +==== Tickets automatisch erneuern für einen längeren Job ====
 +
 +Wenn man einen Job hat, der länger geht als der aktuelle Ticket es erlaubt, setzt man den Befehl ''krenew'' ein.
 +
 +Zunächst richtet man eine neue Datei ein, in der man den Ticket speichert: 
 +
 +  export KRB5CCNAME=/tmp/mykerbcred 
 +
 +Der Dateiname in /tmp kann natürlich auch anders sein.
 +
 +Dann kinit aufrufen:
 +
 +  kinit -r28day 
 +
 +Das generiert einen Ticket, der 28 Tage lang gültig ist.
 +
 +Schließlich starte man den Job mit ''krenew'':
 +
 +  krenew -k /tmp/mykerbcred -t <jobname> 
 +
 +Mehr Details mit ''man krenew''.
 +===== "Stolen Tickets" und Ticket-Verlängerung =====
 +
  
 Die Tickets werden in einer Datei im Verzeichnis /tmp gehalten, wie man bei der Ausgabe von ''klist'' sieht. Wenn ein Fremder die Ticketdatei kopieren kann, kann er das Ticket für dessen Lebensdauer benutzen. Aus diesem Grund sollte man die Lebensdauer eines Tickets nicht zu lange definieren. Allerdings kann im Prinzip nur ''root'' die Ticketdatei kopieren. Die Tickets werden in einer Datei im Verzeichnis /tmp gehalten, wie man bei der Ausgabe von ''klist'' sieht. Wenn ein Fremder die Ticketdatei kopieren kann, kann er das Ticket für dessen Lebensdauer benutzen. Aus diesem Grund sollte man die Lebensdauer eines Tickets nicht zu lange definieren. Allerdings kann im Prinzip nur ''root'' die Ticketdatei kopieren.
Zeile 48: Zeile 77:
 fi fi
 </code> </code>
 +
 +===== Tickets löschen =====
 +
 +Mit dem Befehl ''kdestroy'' löscht man alle Tickets. 
 +
 +:!: Die Tickets werden aber __noch eine Weile gecachet__, und man kann noch eine bis 1 1/2 Stunde auf das Homeverzeichnis zugreifen.
 +
 +Es heißt, dass man eigentlich beim Ausloggen etwa in ''.logout'' den Befehl ''kdestroy'' ausführen sollte, damit alte Tickets nicht geklaut werden können. Allerdings scheint es so zu sein, dass die Tickets beim Ausloggen automatisch gelöscht werden.
 +
 +===== Kerberos und Condor =====
 +
 +Das ist ein potentielles Problem, aber es heißt, man kann Condor so einrichten, dass es in einer Kerberos-Umgebung gut funktioniert. Momentan ist das also "work in progress".
 +
 +===== Infos und Links zu Schwachstellen von Kerberos =====
 +
 +  * Von http://www.cmf.nrl.navy.mil/krb/kerberos-faq.html 
 +
 +<file>
 +One practical problem with Kerberos is that the tickets eventually expire. A practical
 +balance has to be made between the desire to reduce the usefulness of stolen tickets
 +(short lifetime) versus the ease-of-use for the user (long lifetime).
 +
 +This problem becomes a much larger issue when dealing with long-running user processes.
 +Jobs run on some supercomputer systems can run for days or weeks, but having tickets that
 +last that long can be a security nightmare.
 +
 +The compromise for this problem that was introduced in Kerberos 5 is the support for
 +renewable tickets. Renewable tickets have expiration times, like normal tickets. However,
 +they also have a maximum renewable lifetime.
 +
 +A renewable ticket can be renewed by asking the KDC for a new ticket with an extended
 +lifetime. However, the ticket itself has to be valid (in other words, you cannot renew a
 +ticket that has expired; you have to renew it before it expires). A renewable ticket can
 +be renewed up until the maximum renewable ticket lifetime.
 +</file>
 +
 +----
 +
 +  * http://www.cmf.nrl.navy.mil/krb/kerberos-faq.html
 +
 +**Subject: 1.18. Are there any known weaknesses in Kerberos?**
 +
 +<file>
 +Kerberos makes no provisions for host security; it assumes that it is running on trusted
 +hosts with an untrusted network. If your host security is compromised, then Kerberos is
 +compromised as well.
 +
 +However, the degree to which Kerberos is compromised depends on the host that is
 +compromised. If an attacker breaks into a multi-user machine and steals all of the tickets
 +stored on that machine, he can impersonate the users who have tickets stored on that
 +machine …. but only until those tickets expire.
 +
 +Kerberos uses a principal's password (encryption key) as the fundamental proof of
 +identity. If a user's Kerberos password is stolen by an attacker, then the attacker can
 +impersonate that user with impunity.
 +
 +Since the KDC holds all of the passwords for all of the principals in a realm, if host
 +security on the KDC is compromised, then the entire realm is compromised.
 +
 +In Kerberos 4, authenticators are valid for 5 minutes. If an attacker sniffs the network
 +for authenticators, they have a 5 minute window in which they can re-use it and gain
 +access to the same service you used. Kerberos 5 introduced a replay cache which prevents
 +any authenticator from being used more than once.
 +
 +Since anybody can request a TGT for any user, and that ticket is encrypted with the user's
 +secret key (password), it is simple to perform a offline attack on this ticket by trying
 +to decrypt it with different passwords. Kerberos 5 introduced preauthentication to solve
 +this problem.
 +</file>
 +
 +
 +----
 +
 +  * http://www.diablotin.com/librairie/networking/puis/ch19_06.htm
 +
 +<file>
 +Kerberos doesn't work well in a time-sharing environment. Kerberos is designed for an
 +environment in which there is one user per workstation. Because of the difficulty of
 +sharing data between different processes running on the same UNIX computer, Kerberos keeps
 +tickets in the /tmp directory. If a user is sharing the computer with several other
 +people, it is possible that the user's tickets can be stolen, that is, copied by an
 +attacker. Stolen tickets can then be used to obtain fraudulent service
 +</file>
 +
 +----
 +
 +  * http://web.mit.edu/Kerberos/krb5-current/doc/user/tkt_mgmt.html
 +
 +<file>
 +Your Kerberos tickets are proof that you are indeed yourself, and tickets could be stolen
 +if someone gains access to a computer where they are stored. If this happens, the person
 +who has them can masquerade as you until they expire. For this reason, you should destroy
 +your Kerberos tickets when you are away from your computer.
 +</file>
 +
 +

Zuletzt angesehen:

QR-Code
QR-Code Umgang mit Kerberos (erstellt für aktuelle Seite)