Request for help: How do I get tickets to these workstations?
rra at stanford.edu
Tue Jun 5 13:01:10 EDT 2012
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:
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
## 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
* 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
* 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/>
More information about the Kerberos