KDC Hardware
Jeffrey Hutzelman
jhutz at cmu.edu
Mon Jan 9 18:10:55 EST 2006
On Saturday, January 07, 2006 11:38:47 AM +0100 Turbo Fredriksson
<turbo at bayour.com> wrote:
> Security? Nah, both need _extra ordinary security_ so it's easier to
> safegard ONE machine than two (* nr of slaves of course :).
On the contrary, depending on what you are using your LDAP directory for,
it may not require any more security than any other application. Even if
this is not the case, traditional operational practice dictates extreme
paranoia where KDC's are concerned, because of the massive impact of a
compromise.
If your LDAP server is compromised, you reinstall the machine, restore the
database from backups, and get on with life, just like for any other
service. Depending on what you store in the directory, it's possible the
intruder obtained sensitive information, but that's also true of other
services, such as a mail server.
Again, depending on what you store in the directory, it's possible that an
intruder who gains the ability to modify the LDAP database has used that to
gain access to other services. Such things might be annoying to track down
and fix, but they can be fixed. Any changes the intruder made can be
rolled back; any deleted data can be restored from backups, etc.
If a KDC is compromised, it becomes necessary to assume that the intruder
has a complete copy of the Kerberos database, including the keys for every
principal. Recovering from such a compromise requires issuing new
passwords to _every_ user and re-keying _every_ service -- and doing it in
such a way that someone who knows the old keys does not discover the new
ones. Any service which has not been re-keyed is vulnerable to the
attacker; since he knows the service's key, he can impersonate any user,
EVEN IF THE KDC IS SHUT DOWN. A similar problem applies in the reverse
direction; an attacker can impersonate the KDC and any service to a user
whose key he knows, EVEN IF THE REAL KDC IS SHUT DOWN.
This is such a massively bad situation that it is worth taking every effort
to protect the Kerberos database from compromise. Running other services
on the same machine is simply not worth the potential pain.
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
More information about the Kerberos
mailing list