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
(os realms são tradicionalmente em caracteres maiúsculos).user
@REALM
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:
O domínio (zona) de domínio DNS será example.org
.
O realm Kerberos será EXAMPLE.ORG
.
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.
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 a configurar um KDC, adicione estas linhas ao arquivo /etc/rc.conf
:
kdc_enable="YES" 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 88kerberos.example.org
. _kerberos._tcp IN SRV 01 00 88kerberos.example.org
. _kpasswd._udp IN SRV 01 00 464kerberos.example.org
. _kerberos-adm._tcp IN SRV 01 00 749kerberos.example.org
. _kerberos IN TXTEXAMPLE.ORG
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:Verifying password - Master key:
xxxxxxxxxxxxxxxxxxxxxxx
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
Realm max ticket life [unlimited]:EXAMPLE.ORG
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
Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: Password:tillman
Verifying password - Password:
xxxxxxxx
xxxxxxxx
Em seguida, inicie os serviços do KDC executando service kdc start
e service kadmind start
. Embora não haja daemons kerberizados em execução neste momento, é possível confirmar que o KDC está funcionando obtendo um ticket para o principal que acabou de ser criado:
%
kinit
tillman@EXAMPLE.ORG's Password:tillman
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
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 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
kadmin>host/myserver.example.org
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
deve ser usado quando o keytab estiver sendo extraído em outro lugar:path/to/file
#
kadmin
kadmin>ext_keytab --keytab=/tmp/example.keytab
kadmin>host/myserver.example.org
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
.
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
.
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
:
kerberos5_server="/usr/local/sbin/krb5kdc" kadmind5_server="/usr/local/sbin/kadmind" kerberos5_server_flags="" kerberos5_server_enable="YES" kadmind5_server_enable="YES"
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.
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.
O Kerberos permite que usuários, hosts e serviços se autentiquem entre si. Ele não possui um mecanismo para autenticar o KDC para os usuários, hosts ou serviços. Isso significa que um kinit
infectado por um trojan pode registrar todos os nomes de usuário e senhas. As ferramentas de verificação de integridade do sistema de arquivos, como security/tripwire, podem mitigar isso.
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>.