13.5. Kerberos
Anterior | Capítulo 13. Segurança | Próxima

## 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:

- O domínio (zona) de domínio DNS será `example.org`.

- O realm Kerberos será `EXAMPLE.ORG`.

### 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 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 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]:
    Attributes []:
    Password: xxxxxxxx
    Verifying password - Password: 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
    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 `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`:

    kerberos5_server="/usr/local/sbin/krb5kdc"
    kadmind5_server="/usr/local/sbin/kadmind"
    kerberos5_server_flags=""
    kerberos5_server_enable="YES"
    kadmind5_server_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.

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.

### 13.5.7. Recursos e Outras Informações

- A FAQ do Kerberos

- Criando um Sistema de Autenticação: um Diálogo em Quatro Cenas

- RFC 4120, O Serviço de Autenticação em Rede (V5) do Kerberos

- Página Web do Kerberos MIT

- Página Web do Kerberos Heimdal

Anterior | Acima | Próxima
13.4. TCP Wrapper | Principal | 13.6. OpenSSL

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>.