13.5. Kerberos

Contribuído por Tillman Hodgson.
Baseado em uma contribuição de Mark Murray.

O Kerberos é um protocolo de autenticação de rede que foi originalmente criado pelo Instituto de Tecnologia de Massachusetts (MIT) como uma maneira segura de fornecer autenticação em uma rede potencialmente hostil. O protocolo Kerberos usa criptografia robusta para que tanto um cliente quanto um servidor possam provar sua identidade sem enviar nenhum segredo não criptografado pela rede. O Kerberos pode ser descrito como um sistema proxy de verificação de identidade e como um sistema confiável de autenticação de terceiros. Depois que um usuário autentica com Kerberos, suas comunicações podem ser criptografadas para garantir privacidade e integridade dos dados.

A única função do Kerberos é fornecer a autenticação segura de usuários e servidores na rede. Ele não fornece funções de autorização ou auditoria. Recomenda-se que o Kerberos seja usado com outros métodos de segurança que forneçam serviços de autorização e auditoria.

A versão atual do protocolo é a versão 5, descrita na RFC 4120. Várias implementações gratuitas deste protocolo estão disponíveis, abrangendo uma ampla gama de sistemas operacionais. O MIT continua desenvolvendo o pacote Kerberos. É comumente usado no US como um produto de criptografia e, historicamente, está sujeito aos regulamentos de exportação dos US. No FreeBSD, o MIT Kerberos está disponível como o pacote ou port security/krb5. A implementação do Kerberos do Heimdal foi explicitamente desenvolvida fora do US para evitar regulamentações de exportação. A distribuição Kerberos do Heimdal está incluída na instalação base do FreeBSD, e outra distribuição com opções mais configuráveis está disponível como security/heimdal na Coleção de Ports.

No Kerberos, os usuários e serviços são identificados como principals, que estão contidos em um agrupamento administrativo chamado de realm. Um usuário principal típico teria o formato user@REALM (os realms são tradicionalmente em caracteres maiúsculos).

Esta seção fornece um guia sobre como configurar o Kerberos usando a distribuição Heimdal incluída no FreeBSD.

Para fins de demonstração de uma instalação do Kerberos , os namespaces serão os seguintes:

Nota:

Use nomes de domínio reais ao configurar o Kerberos, mesmo que ele seja executado internamente. Isso evita problemas de DNS e garante a interoperabilidade com outros realms do Kerberos.

13.5.1. Configurando um KDC do Heimdal

O Centro de Distribuição de Chaves (KDC) é o serviço de autenticação centralizada que o Kerberos fornece, a a parte de terceiros confiáveis do sistema. É o computador que emite os tíquetes Kerberos, que são usados para autenticação dos clientes nos servidores. Como o KDC é considerado confiável por todos os outros computadores no realm do Kerberos, isso aumenta as preocupações com a segurança. O acesso direto ao KDC deve ser limitado.

Embora a execução de um KDC exija poucos recursos de computação, uma máquina dedicada que atua apenas como um KDC é recomendada por motivos de segurança.

Para começar, instale o pacote security/heimdal assim:

# pkg install heimdal

Em seguida, edite o /etc/rc.conf como a seguir:

# sysrc kdc_enable=yes
# sysrc kadmind_enable=yes

Em seguida, edite o arquivo /etc/krb5.conf como a seguir:

[libdefaults]
    default_realm = EXAMPLE.ORG
[realms]
    EXAMPLE.ORG = {
	kdc = kerberos.example.org
	admin_server = kerberos.example.org
    }
[domain_realm]
    .example.org = EXAMPLE.ORG

Neste exemplo, o KDC usará o nome completo do host kerberos.example.org. O nome do host do KDC precisa ser resolvido no DNS.

O Kerberos também pode usar o DNS para localizar os KDCs, em vez de uma seção [realms] no arquivo /etc/krb5.conf. Para grandes organizações que possuem seus próprios servidores DNS, o exemplo acima pode ser reduzido para:

[libdefaults]
      default_realm = EXAMPLE.ORG
[domain_realm]
    .example.org = EXAMPLE.ORG

Com as seguintes linhas sendo incluídas no arquivo de zona do domínio example.org:

_kerberos._udp      IN  SRV     01 00 88 kerberos.example.org.
_kerberos._tcp      IN  SRV     01 00 88 kerberos.example.org.
_kpasswd._udp       IN  SRV     01 00 464 kerberos.example.org.
_kerberos-adm._tcp  IN  SRV     01 00 749 kerberos.example.org.
_kerberos           IN  TXT     EXAMPLE.ORG

Nota:

Para que os clientes possam encontrar os serviços Kerberos, eles devem ter um /etc/krb5.conf totalmente configurado ou um /etc/krb5.conf minimamente configurado e um servidor DNS corretamente configurado.

Em seguida, crie o banco de dados do Kerberos que contém as chaves de todos os principals (usuários e hosts) criptografados com uma senha master. Não é necessário lembrar essa senha, pois ela será armazenada no arquivo /var/heimdal/m-key; Seria razoável usar uma senha aleatória de 45 caracteres para essa finalidade. Para criar a chave master, execute kstash e digite uma senha:

# kstash
Master key: xxxxxxxxxxxxxxxxxxxxxxx
Verifying password - Master key: xxxxxxxxxxxxxxxxxxxxxxx

Depois que a chave master é criada, o banco de dados deve ser inicializado. A ferramenta administrativa do Kerberos kadmin(8) pode ser usada no KDC em um modo que opera diretamente no banco de dados, sem usar o serviço de rede kadmind(8), como kadmin -l. Isso resolve o problema do ovo e da galinha de tentar se conectar ao banco de dados antes de criá-lo. No prompt do kadmin, use o init para criar o banco de dados inicial do realm:

# kadmin -l
kadmin> init EXAMPLE.ORG
Realm max ticket life [unlimited]:

Por fim, enquanto ainda estiver no kadmin, crie o primeiro principal usando add. Atenha-se às opções padrão para o principal por enquanto, pois elas podem ser alteradas posteriormente com modify. Digite ? no prompt para ver as opções disponíveis.

kadmin> add tillman
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Principal expiration time [never]:
Password expiration time [never]:
Attributes []:
Password: xxxxxxxx
Verifying password - Password: xxxxxxxx

Em seguida, inicie o serviço KDC executando:

# service kdc start
# service kadmind start

Embora não tenha nenhum daemon do kerberos em execução neste ponto, é possível confirmar que o KDC está funcionando obtendo um ticket para o principal que acabou de ser criado:

% kinit tillman
tillman@EXAMPLE.ORG's Password:

Confirme se um ticket foi obtido com sucesso usando klist:

% klist
Credentials cache: FILE:/tmp/krb5cc_1001
	Principal: tillman@EXAMPLE.ORG

  Issued                Expires               Principal
Aug 27 15:37:58 2013  Aug 28 01:37:58 2013  krbtgt/EXAMPLE.ORG@EXAMPLE.ORG

O ticket temporário pode ser destruído quando o teste terminar:

% kdestroy

13.5.2. Configurando um Servidor para Usar o Kerberos

A primeira etapa na configuração de um servidor para usar a autenticação Kerberos é garantir que ele tenha a configuração correta no arquivo /etc/krb5.conf. A versão do KDC pode ser usada como está, ou pode ser regenerada no novo sistema.

Em seguida, crie o arquivo /etc/krb5.keytab no servidor. Esta é a parte principal de Kerberizar um serviço - ele corresponde a gerar uma chave secreta compartilhada entre o serviço e o KDC. O segredo é uma chave criptográfica, armazenada em um keytab. O keytab contém a chave do host do servidor, que permite que ele e o KDC verifiquem a identidade um do outro. Ele deve ser transmitido para o servidor de maneira segura, pois a segurança do servidor pode ser quebrada se a chave for tornada pública. Normalmente, o keytab é gerado na máquina confiável de um administrador usando o kadmin, e então transferido com segurança para o servidor, por exemplo, com scp(1); Ele também pode ser criado diretamente no servidor, se isso for consistente com a política de segurança desejada. É muito importante que o keytab seja transmitido para o servidor de forma segura: se a chave for conhecida por outra parte, essa parte pode representar qualquer usuário para o servidor! Usar o kadmin diretamente no servidor é conveniente, porque a entrada para o principal do host no banco de dados do KDC também é criada usando o kadmin.

Naturalmente, o kadmin é um serviço kerberizado; um tíquete Kerberos é necessário para autenticar-se no serviço de rede, mas para garantir que o usuário que está executando o kadmin esteja presente (e sua sessão não tenha sido invadida), o kadmin solicitará a senha para obter um novo ticket. O principal autenticando no serviço kadmin deve ter permissão para usar a interface kadmin, conforme especificado no arquivo /var/heimdal/kadmind.acl. Veja a seção intitulada Administração Remota em info heimdal para detalhes sobre a criação de listas de controle de acesso. Em vez de ativar o acesso remoto ao kadmin, o administrador pode conectar-se com segurança ao KDC através do console local ou por ssh() e executar a administração localmente usando o kadmin -l.

Depois de instalar o arquivo /etc/krb5.conf, use o add --random-key no kadmin. Isso adiciona o principal do host do servidor ao banco de dados, mas não extrai uma cópia da chave principal do host para um keytab. Para gerar o keytab, use ext para extrair a chave principal do host do servidor para seu próprio keytab:

# kadmin
kadmin> add --random-key host/myserver.example.org
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Principal expiration time [never]:
Password expiration time [never]:
Attributes []:
kadmin> ext_keytab host/myserver.example.org
kadmin> exit

Note que o ext_keytab por padrão armazena a chave extraída no arquivo /etc/krb5.keytab. Isso é bom quando executado no servidor que está sendo kerberizado, mas o argumento --keytab path/to/file deve ser usado quando o keytab estiver sendo extraído em outro lugar:

# kadmin
kadmin> ext_keytab --keytab=/tmp/example.keytab host/myserver.example.org
kadmin> exit

O keytab pode então ser copiado com segurança para o servidor usando o scp(1) ou uma mídia removível. Certifique-se de especificar um nome de keytab não padrão para evitar a inserção de chaves desnecessárias na keytab do sistema.

Neste ponto, o servidor pode ler mensagens criptografadas do KDC usando sua chave compartilhada, armazenada no arquivo krb5.keytab. Agora ele está pronto para ativar os serviços de uso do Kerberos. Um dos serviços mais comuns é o sshd(8), que suporta o Kerberos através do GSS-API. No arquivo /etc/ssh/sshd_config, adicione a linha:

GSSAPIAuthentication yes

Depois de fazer essa alteração, o sshd(8) deve ser reiniciado para que a nova configuração tenha efeito: service sshd restart.

13.5.3. Configurando um cliente para usar o Kerberos

Assim como foi no servidor, o cliente requer configuração no arquivo /etc/krb5.conf. Copie o arquivo no local (com segurança) ou insira-o novamente conforme necessário.

Teste o cliente usando o kinit, klist e kdestroy a partir do cliente para obter, mostrar e excluir um ticket para um principal existente. Os aplicativos Kerberos também devem poder se conectar a servidores habilitados pelo Kerberos. Se isso não funcionar, mas a obtenção de um ticket ocorrer, provavelmente o problema está no servidor e não no cliente ou no KDC. No caso do ssh(1) kerberizado, o GSS-API está desabilitado por padrão, portanto teste usando ssh -o GSSAPIAuthentication=yes hostname.

Ao testar um aplicativo Kerberizado, tente usar um sniffer de pacote, como o tcpdump, para confirmar que nenhuma informação confidencial é enviada sem proteção.

Várias aplicações Kerberos cliente estão disponíveis. Com o advento de uma ponte para que aplicações usando SASL para autenticação possam usar mecanismos GSS-API, grandes classes de aplicativos clientes podem usar o Kerberos para autenticação, de clientes Jabber a clientes IMAP.

Os usuários em um realm geralmente têm seu principal Kerberos mapeado para uma conta de usuário local. Ocasionalmente, é necessário conceder acesso a uma conta de usuário local a alguém que não tenha um principal Kerberos correspondente. Por exemplo, tillman@EXAMPLE.ORG pode precisar de acesso à conta de usuário local webdevelopers. Outros diretores também podem precisar de acesso a essa conta local.

Os arquivos .k5login e .k5users, colocados no diretório home de um usuário, podem ser usados para resolver este problema. Por exemplo, se o seguinte .k5login for colocado no diretório inicial de webdevelopers, os dois principals listados terão acesso a essa conta sem exigir uma senha compartilhada:

tillman@example.org
jdoe@example.org

Consulte ksu(1) para obter maiores informações sobre o .k5users.

13.5.4. Diferenças com a implementação do MIT

A principal diferença entre as implementações do MIT e a Heimdal é que o kadmin tem um conjunto de comandos diferente, mas equivalente, e usa um protocolo diferente. Se o KDC for MIT, a versão Heimdal do kadmin não poderá ser usada para administrar o KDC remotamente, e vice versa.

Aplicações cliente também podem usar opções de linha de comando ligeiramente diferentes para realizar as mesmas tarefas. Seguir as instruções em http://web.mit.edu/Kerberos/www/ é recomendado. Cuidado com os problemas de caminho: o port MIT é instalado em /usr/local/ por padrão, e os aplicativos do sistema FreeBSD serão executados em vez das versões do MIT se o PATH listar os diretórios do sistema primeiro.

Ao usar o MIT Kerberos como um KDC no FreeBSD, as seguintes edições também devem ser feitas no rc.conf:

kdc_program="/usr/local/sbin/kdc"
kadmind_program="/usr/local/sbin/kadmind"
kdc_flags=""
kdc_enable="YES"
kadmind_enable="YES"

13.5.5. Dicas, Truques e Solução de Problemas do Kerberos

Ao configurar e solucionar problemas do Kerberos, tenha em mente os seguintes pontos:

  • Ao usar o Heimdal ou MIT Kerberos do ports, certifique-se de que o PATH liste as versões do port dos aplicativos clientes antes das versões do sistema.

  • Se todos os computadores no realm não tiverem configurações de horário sincronizadas, a autenticação poderá falhar. Seção 29.11, “Sincronização de Relógio com NTP” descreve como sincronizar os relógios usando o NTP.

  • Se o nome do host for alterado, o host/ principal deve ser alterado e o keytab atualizado. Isso também se aplica a entradas de keytab especiais como o HTTP/ principal usado para o www/mod_auth_kerb do Apache.

  • Todos os hosts no realm devem ser resolvidos tanto de forma direta quanto reversa no DNS ou, no mínimo, no arquivo /etc/hosts. Os CNAMEs funcionarão, mas os registros A e PTR devem estar corretos e no lugar. A mensagem de erro para hosts não resolvidos não é intuitiva: Kerberos5 refuses authentication because Read req failed: Key table entry not found.

  • Alguns sistemas operacionais que agem como clientes para o KDC não definem as permissões para o ksu para serem setuid root. Isso significa que o ksu não funciona. Este é um problema de permissões, não um erro do KDC.

  • Com o MIT Kerberos, para permitir que um principal tenha uma duração de ticket maior que a duração padrão de dez horas, use modify_principal no kadmin(8) para alterar o maxlife do principal em questão e do krbtgt principal. O principal pode então usar o kinit -l para solicitar um ticket com uma vida útil mais longa.

  • Ao executar um sniffer de pacotes no KDC para auxiliar na solução de problemas enquanto executa kinit de uma estação de trabalho, o Ticket de Concessão de Tickets (TGT) é enviado imediatamente, mesmo antes da digitação da senha. Isso ocorre porque o servidor Kerberos transmite livremente um TGT para qualquer solicitação não autorizada. No entanto, cada TGT é criptografado em uma chave derivada da senha do usuário. Quando um usuário digita sua senha, ela não é enviada para o KDC, ela é usada para descriptografar o TGT que o kinit já obteve. Se o processo de descriptografia resultar em um tíquete válido com um registro de data e hora válido, o usuário terá credenciais do Kerberos válidas. Essas credenciais incluem uma chave de sessão para estabelecer comunicações seguras com o servidor Kerberos no futuro, bem como o TGT, que é criptografado com a chave do próprio servidor Kerberos. Essa segunda camada de criptografia permite que o servidor Kerberos verifique a autenticidade de cada TGT.

  • Os principals do host podem ter uma vida útil maior do ticket. Se o usuário do principal tiver uma vida útil de uma semana, mas o host ao qual está conectado tiver uma vida útil de nove horas, o cache do usuário terá um host principal expirado e o cache do ticket não funcionará como esperado.

  • Ao configurar o arquivo krb5.dict para evitar que senhas incorretas específicas sejam usadas, conforme descrito em kadmind(8), lembre-que só se aplica a entidades que tenham uma política de senha atribuída a elas. O formato usado em krb5.dict é uma string por linha. Criar um link simbólico para /usr/share/dict/words pode ser útil.

13.5.6. Atenuando as Limitações do Kerberos

Uma vez que com o Kerberos a abordagem é tudo ou nada, cada serviço habilitado na rede deve ser modificado para funcionar com o Kerberos ou ser protegido contra ataques de rede. Isso impede que as credenciais do usuário sejam roubadas e reutilizadas. Um exemplo é quando o Kerberos está habilitado em todos os shells remotos, mas o servidor de email POP3 não-Kerberizado envia senhas em texto simples.

O KDC é um ponto único de falha. Por design, o KDC deve ser tão seguro quanto seu banco de dados de senhas master. O KDC não deve ter absolutamente nenhum outro serviço sendo executado e deve estar fisicamente seguro. O perigo é alto porque o Kerberos armazena todas as senhas criptografadas com a mesma chave mestra que é armazenada como um arquivo no KDC.

Uma chave mestra comprometida não é tão ruim quanto se pode temer. A chave mestra é usada apenas para criptografar o banco de dados do Kerberos e como um seed para o gerador de números aleatórios. Desde que o acesso ao KDC seja seguro, um invasor não poderá fazer muito com a chave mestra.

Se o KDC não estiver disponível, os serviços de rede não poderão ser utilizados, pois a autenticação não poderá ser executada. Isso pode ser mitigado com um único KDC master e um ou mais slaves, e com a implementação cuidadosa da autenticação secundária ou de fallback usando PAM.

Kerberos allows users, hosts and services to authenticate between themselves. It does not have a mechanism to authenticate the KDC to the users, hosts, or services. This means that a trojaned kinit could record all user names and passwords. File system integrity checking tools like security/tripwire can alleviate this.

13.5.7. Recursos e Outras Informações

All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/

Questions that are not answered by the documentation may be sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.