Request for help: How do I get tickets to these workstations?

[Russ Allbery]

Eray Aslan <eray.aslan at caf.com.tr> writes:
> On 2012-06-05 9:54 AM, Russ Allbery wrote:

>> Our KDCs have always been open to the Internet.

> Ugh.  Any do's and dont's?  How do you harden the KDC (not the host but
> the kerberos side)?

I've never felt like Kerberos needed any particular hardening beyond
ensuring that people have strong passwords, which we do with:

    http://www.eyrie.org/~eagle/software/krb5-strength/

We do get compromised accounts, but they're mostly from phishing, not
brute force attacks.

For the general security measures that we take, here's an excerpt from our
architecture document, but it's all fairly obvious stuff.  Note that we
don't expose kadmin to the world, just kpasswd and the regular Kerberos
protocol.

## System-Level Security Controls

Due to the sensitivity of the Kerberos KDCs and their critical position as
the cornerstone of the rest of our system security, they are managed with
a different configuration and a more restricted set of users than our
regular systems.  The following extra precautions are taken in the
production and UAT environments above our normal security measures for a
server:

* All IDG staff are not routinely given accounts on the Kerberos KDCs as
  they are with other servers.  Instead, individual staff memebers are
  added if and only if they have a role in maintaining the Kerberos KDCs.

* The systems use a distinguished root password not shared by other
  servers.

* Kerberos /root instances are not used for root authentication and remote
  remctl management as they are for other servers.  Instead, distinguished
  /admin principals are used.  Those principals are used only for Kerberos
  administrative actions and not used for any other purpose, and the
  password for those accounts is never entered except on a staff
  workstation (for remote administrative actions) or via an encrypted
  connection on the KDC itself.

* Puppet is run in no-op mode so that no changes are made automatically.
  Instead, reports are sent to the administrators and manually reviewed,
  and only pushed via manual action after that review.  They are done
  first in the UAT environment before the production environment.

* More restrictive versions of the normal iptables rules are used to limit
  remote logins only to networks used by IDG staff or controlled by IDG.

* TCP wrappers are used in addition to the iptables rules to redundantly
  restrict remote logins to known IDG staff subnets.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>