Home > Uncategorized > Meu cachorro tem 3 cabeças ?! :P

Meu cachorro tem 3 cabeças ?! :P

Ola, após um longo e muiiito longo período volto a postar, o principal culpado por esse exílio de postagem é o trabalho, vida pessoal, familia, cachorros, futebol, mãe, pai, namorada, e o principal de todos a falta de tempo devido a todos os outros motivos :). Mas o assunto deste post foi algo que de maneira nenhuma deixaria de postar é um assunto que não encontrei muita informações compilada em um único ponto, mas sim em vários links disponivéis na internet.
Como todo tutorial sobre o assunto e bom falar sobre as origens, é a origem que iremos desvendar é o nome de um dos nossos softwares coadjuvante, o kerberos que veio de cerberus ou cérbero.

Faz parte da mitologia grega, cerberus ou kerberos era um cão de três cabeças e cobras ao redor do pescoço que guardava o reino subterrâneo dos mortos, o qual Hades deus da guerra era o “mentor”, hades irmão de Zeus e filho de Cronos :D. Bom mitologia grega não é o foco, nosso objetivo e falar sobre o software kerberos, assim como o cerberus protege o reino de Hades o nosso kerberos pode proteger nossa infra-estrutura de rede, fazer o controle de acesso.

O kerberos se diferencia dos outros metódos de controle de acesso por autenticar o usuário apenas uma única vez depois disso ele trabalha com o que chamamos de tickets ou “segredos”.
Ele faz a autenticação de usuários, computadores ou hosts e serviços de rede, tais como e-mail, http, ftp esses serviços que suportam kerberos damos o nome de “serviços kerberizados”, cada usuário, host ou serviços na linguagem do kerberos recebe o nome de “principal”. O kerberos utiliza um “meio de campo” para fazer a checagem entre os principals e serviço de autenticação, o kerberos sozinho não autentica nínguem, ele precisa do servidor de autenticação ou base de usuário. Uma observação importante é possivel fazer o kerberos autenticar utilizando sua própria base o que não é muito utilizado. O “meio de campo” utilizado pelo kerberos para interfacear principal e base de dados se chama KDC (Key Distribution Center ­ Centro de Distribuição de Chaves), responsável pela validação da identidade dos principals em conjunto com os serviços kerberizados. No processo de validação e criado uma chave secreta o qual é gerada utilizando a senha do usuário como item obrigatorio.

O KDC armazena a base de dados de principal e suas chaves, que são utilizadas para autenticação.

Vamos descrever alguns conceitos da estrutura kerberos:

  • realm: Um reino ou realm kerberos é um grupo de computadores que compartilham informações contidas numa base de dados de autenticação ou kerberos e fazem uso do KDC.  O reino possui um nome que o identifica e, geralmente, é o mesmo nome do
    domínio DNS, porém em letras maiúsculas. Apesar dessa característica não ser
    obrigatória, ela tem sido comumente usada nas implementações do Kerberos.
  • Principal: Como dito anteriormente o principal é qualquer item que pode fazer uso do kerberos ou ser autenticada. Isso inclui usuários, hosts e serviços de rede. Cada principal possui uma chave secreta o qual é constituida pela sua própria senha. Com isso o KDC e o principal conhecem essa chave.
    O principal é formado por três partes:

    • primário ­ é a primeira parte do principal. Pode ser o nome de um usuário ou serviço. Para um servidor é a palavra host.
    • instância ­ serve para qualificar o primário. É uma palavra que vem antes do principal separado por uma barra (/). Após a barra posso ter termos diferentes, são eles:
    1. Usuário: Após a barra teremos o usuario e sua credencial
    2. Host: Após a barra teremos o nome dns deste host.
    3. reino ou realm: Parte do nome do principal que indica o reino do principal

    Um exemplo de um principal seria: primário/instância@REINO. Para um principal de usuário seria:

    ricardobarbosa@YAMAHA.CORP
    ricardobarbosa/administrator@YAMAHA.CORP

    onde a palavra “administrator” indica que o principal tem privilégios administrativos no Kerberos.

    Exemplo de principais de serviços ou host a parte que seria o primário indica o serviço, um exemplo:

    HTTP/firewall.yamaha.corp@YAMAHA.CORP
    FTP/ftp.yamaha.corp@YAMAHA.CORP

    Se o nome do reino não for informado será usado como o reino padrão do contexto, isso no arquivo de configuração do kerberos ou seja /etc/krb5.conf.

Bom já que falamos demais poderiamos agora ter um pouco de ação ou quase isso fazer um teste de mesa e mostrar o passo a passo da conexão kerberos. Para isso imaginei o seguinte ambiente.

1 – Neste exemplo a estação com serviço de login kerberizado faz um request para o KDC solicitando um TGT.

2 – O KDC recebe o request e busca pelo principal da conexão na base de dados Kerberos ou seja no Active Directory, se o principal existe, o KDC pega a chave secreta do principal gerada com a senha do principal. Com isso ele irá gerar a chave de sessão e o TGT.  Nesse momento o KDC tem a chave secreta do principal, a chave de sessão e o TGT, blz, o KDC nesse momento criptografa o TGT com uma chave que somente ele KDC conhece. Nesse momento eu tenho o TGT criptografado com senha que somente o KDC conhece e a chave de sessão, após isso o KDC criptografa esse dois itens com a chave do usuário e o envia para o mesmo.

3 – Ao receber essa resposta, o cliente (kinit ou login) solicita a senha ao usuário e após a digitação da senha ela é convertida na chave secreta do usuário.

Essa chave é, então, utilizada para descriptografar a mensagem recebida do KDC, que contém a chave de sessão e o TGT
(criptografado pela chave do KDC). Perceba que a senha do usuário nunca foi para o meio somente nos endpoint no caso KDC e cliente. Vamos a um outro conceito para continuar nosso raciocínio.

O arquivo keytab

Cada usuario na base de dados possui uma senha, assim como cada serviço possue uma chave, onde esta chave e conhecida apenas pelo KDC e o próprio principal

No KDC essa chave e armazenada na base de dados. Agora no servidor que esta sendo executado o serviço as chaves são armazenadas localmente em tabelas em arquivos conhecidos como arquivos keytab. O serviço kerberizado utiliza o arquivo keytab da mesma forma que um usuário informa sua senha no ato de login. Quando o serviço precisa se autenticar ele utilizar a senha armazenada no arquivo keytab para se autenticar.

Utilizando o serviço kerberizado.

Para utilizar o serviço kerberizado e necessário o arquivo keytab no servidor onde roda o serviço. Vamos imaginar outro ambiente o qual será o foco do nosso post. Tenho o mesmo ambiente anterior mas agora tenho o Active Directory e KDC no mesmo servidor é o que existe na vida real 🙂 o AD da microsoft já tem o kerberos embutido. Bom acrescentaremos o nosso servidor proxy mas especificamente squid 🙂 veja o diagrama abaixo.

O cliente no navegador fará acesso a internet através do proxy que tem o serviço “HTTP”. O navegador verifica se no cache existe um ticket para acesso ao serviço solicitado. Se não existir, envia ao KDC uma solicitação de acesso ao serviço, ou seja envia um request solicitando um TGS(Ticket Granting Service) a partir do TGT.

1 – O navegador envia ao KDC o TGT a mensagem de solicitação TGS além de informação de horário(timestamp), criptografado com a chave de sessão que ele recebeu na conexão anterior. (lembra que tinha o TGT e a chave de sessão, esta chave e para uso apenas nas conexoes cliente e KDC).

2 – O KDC recebe descriptografa e obtém o TGT(criptografado com a chave conhecida apenas pelo KDC), com isso ele descriptografa o TGT com sua chave secreta e usando a chave de sessão descriptografa a mensagem de horário(timestamp). Presumindo que o KDC obteve exito nesse passos ele assume que o usuário é quem diz ser.

3 – O KDC gera então uma nova chave de sessão esta para ser usado entre servidor Proxy e cliente, cria um novo ticket (TGS) contendo a nova chave de sessão e identificação de usuário. Logo em seguida criptografa com a chave secreta do servidor a mesma chave que esta no keytab local :). O KDC também criptografa a nova chave de sessão para ser usada entre servidor e cliente utilizando a primeira chave de sessão que deve ser usada somente entre KDC e cliente( E chave pra caramba né :P).

4 – O novo ticket criptografado com a chave do servidor ( a mesma do keytab) e a nova chave de sessão criptografada( a chave para ser usada entre proxy e cliente) com a chave de sessão do usuário( a chave que deve ser usada entre KDC e cliente) são enviados ao usuário.

5 – O cliente recebe o ticket (TGS) e a chave de sessão (para ser usada entre proxy e cliente) enviados pelo KDC, descriptografa a chave de sessão (criptografada pela chave de sessão, aquela usada entre KDC e cliente lembra foi enviada a chave de sessão entre proxy e cliente criptografada com esta chave) e logo em seguida armazena ambas as chaves no cache de credenciais. Ele usa a nova chave de sessão( a que deve ser usado entre proxy e cliente) para criptografar uma mensagem, e envia ao servidor proxy juntamente TGS.

6 – O servidor recebe o pacote e de posse da chave secreta dele mesmo(Aquela que está no arquivo keytab o qual está segura no disco local 😛 ) e a usa para descriptografar o ticket (TGS) recebido do usuário, tendo acesso, portanto, à identidade do usuário e à chave de sessão (aquela que foi criada para ser usada entre proxy e cliente não a chave que foi criada para ser usada entre KDC e cliente :P) . Com essa chave de sessão o servidor abre a mensagem recebida do cliente, com isso automaticamente autentica o usuário.

7 – Após isso se o usuário tem permissão para navegar em determinada URL o acesso e concedido senão negado. Nesse ponto ambos tanto cliente como servidor proxy  têem a chave de sessão criada pelo KDC para comunicação entre eles, e podem utilizá-la para criptografar o tráfego entre eles.

Veja que a comunicação fluiu sem em um único momento a senha ir para a rede 🙂 e para deixar mais seguro se alguém conseguir interceptar os tickets e chave de sessão ainda temos o tempo de expiração que deixará inutil a chave 🙂

Bom agora depois de teoria e explicações ao meu ver satisfatoria vamos a implantação e configuração criei um ambiente de exemplo tenho isso em produção em vários clientes e funciona muito bem. Antes de continuar quero deixar claro que kerberos não envolve somente nisso que expliquei acima a coisa flue da forma que disse mas existe muito detalhes que não abortei aqui para não deixar extenso então se querem conhecer a fundo meu conselho apontem seus links para a página do MIT http://web.mit.edu/kerberos/. 🙂

Segue abaixo o ambiente de exemplo iremos utilizar os seguintes softwares e servidores

servidor proxy :
Softwares:
squid 3.0, kerberos 5.0 versão clientes e config, squid_kerb_ldap um helper de autenticação para o squid desenvolvido pelo Markus Moeller, tive a oportunidade de trocar uma idéia com esse cara na lista squid-users e um cara muito gente boa e sanou várias dúvidas que tinha em relação ao squid_kerb_ldap.

Servidor KDC:
Softwares:
Normalmente você ja deve ter isso na sua empresa ou na empresa que trabalha, tratasse do poderoso servidor de diretório da Microsoft – Active Directory e sim ele já possue um KDC embutido criado pela Microsoft ao contrário do que muitos pensam sim a Microsoft usa Software Livre, implementa e reimplementa e funciona muito bem 😀

Cliente:
Como nosso ambiente é para sistemas Microsoft iremos utilizar qualquer estação que faça parte do domínio.

Segue mais alguns dados:

Dominio: YAMAHA.CORP
Servidor Proxy: 192.168.0.15
Servidor DC Windows 2008 R2: 192.168.0.8
Usuário do AD para criação do keytab: squid
Senha: 123456 ( e apenas para testes)

Vamos por a mão na massa inicialmente instalar o squid estou utilizando a distribuição Ubuntu.

[root@firewall root]# aptitude install squid3 krb5-config krb5-clients krb5-user libsasl2-modules-gssapi-mit

Depois vamos baixar o pacote squid_kerb_ldap no site http://squidkerbauth.sourceforge.net/.

Para compilar o squid_kerb_ldap iremos precisar do pacote de compilação do ubuntu e bibliotecas de desenvolvimento do kerberos

[root@firewall root]# aptitute install build-essential libkrb5-dev

Vamos compilar o squid_kerb_ldap.

[root@firewall root]# cd squid_kerb_ldap
[root@firewall root]# ./configure
[root@firewall root]# make

Após compilar será gerado um binário chamado “squid_kerb_ldap”, copie este binário para o caminho “/usr/lib/squid3/”, na instalação do squid já consta o squid_kerb_auth.

Vamos agora a configuração do squid para que ele passe a reconhecer usuários via kerberos.

auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -s HTTP/proxy.yamaha.local
auth_param negotiate children 10
auth_param negotiate keep_alive on

se for autenticar por usuários utilize

# acl que solicita autenticação para o usuário ricardo barbosa no caso eu 😀
acl ricardobarbosa proxy_auth ricardobarbosa@YAMAHA.CORP
# Acl para dar match nos sites que serão permitidos
acl sites_liberados src “/etc/squid3/sites_liberados.cfg”

# permite o acesso as conexões autenticas via kerberos pelo usuário ricardo barbosa a sites_liberados
http_access allow ricardobarbosa sites_liberados

Se for por grupo utilize

# acl externa que utiliza squid_kerb_ldap
external_acl_type g_restrito ttl=3600 negative_ttl=3600 %LOGIN /usr/lib/squid3/squid_kerb_ldap -g G_restrito@YAMAHA.CORP
# Acl para dar match na acl externa
acl grupo_grestrito external g_restrito
# Acl para dar match nos sites que serão permitidos
acl sites_liberados src “/etc/squid3/sites_liberados.cfg”

# Permitindo o grupo restrito do AD ao lista de sites liberados
http_access allow grupo_gretrito sites_liberados

Agora e hora de gerar o arquivo keytab o windows possue um comando de linha que gera o keytab ai depois e somente necessário copiar para o servidor proxy, segue o comando abaixo.

c:\> ktpass -princ HTTP/proxy.yamaha.corp@YAMAHA.CORP -mapuser YAMAHA\squid -crypto All -mapop set -pass 123456 -ptype KRB5_NT_SRV_HST -out HTTP.keytab

E bem intuitivo vamos a cada item

  • -princ HTTP/proxy.yamaha.corp@YAMAHA.CORP: Principal do servidor proxy, nós lembramos o que é principal senão lembra volte lá em cima no começo do tutorial e leia de novo 😀
  • -mapuser YAMAHA\squid: Nome do usuário que será gerado o keytab
  • -crypto All: Será gerado o keytab com todas os algoritmos de criptografia que o KDC do AD suporta.
  • -mapop set -pass 123456: Definindo a senha
  • -ptype KRB5_NT_SRV_HST: Define que o tipo do principal no caso é um “host service instance”. Outras possiveis opção são:
    1. KRB5_NT_PRINCIPAL: Este o principal de uso geral.
    2. KRB5_NT_SRV_INST: É um instancia de serviço de usuário.
    3. KRB5_NT_SRV_HST: É uma instancia de serviço de host.
  • -out HTTP.keytab: Nome do arquivo keytab gerado

No seguinte link tem mais informações sobre a ferramenta ktpass http://technet.microsoft.com/en-us/library/cc753771%28WS.10%29.aspx

Depois de keytab gerado copie o arquivo para o servidor Linux via ssh pscp te vira :). Um detalhe quando você gera o keytab você não pode resetar a senha no meu caso do usuário squid se você fizer, vai invalidar o arquivo keytab e terá de gerar outro. Isso porque existe um campo no keytab que é chamado kvno que é simplesmente um acrônimo para “número da versão da chave” ou key version number. para ajudar
distinguir entre várias chaves associados com o mesmo principal (por
exemplo, se um usuário alterar sua senha), cada chave é associada a uma versão de chave. Números de versão-chave normalmente começam em zero quando o principal é criado pela primeira vez e são incrementados por um cada vez que a senha é alterada.

Para verificar o kvno do keytab utilize.

[root@firewall root]# kvno HTTP/proxy.yamaha.corp
HTTP/proxy.yamaha.corp@YAMAHA.CORP: kvno = 3
[root@firewall root]#

Para deixar esse “controle” do kvno automático você pode colocar o servidor proxy no domínio utilizando samba com kerberos, e utilizar o keytab a partir do samba ai seus problemas acabaram :P.

Para autenticar a partir do keytab utilize o comando.

[root@firewall root]# kinit -V -k -t /etc/krb5.keytab HTTP/proxy.yamaha.corp
Authenticated to Kerberos v5
[root@firewall root]#

Agora vamos testar navegar. Alguns navegadores não suportam autenticação kerberos é o caso do Safari e Opera. O Internet Explorer e Firefox funciona nativamente, o IE precisa a opção “autenticação integrada do windows” estar marcada dentro da aba avançado dentro de propriedades de internet o que já vem padrão.

1318895606.294 224 172.31.1.51 TCP_MISS/204 674 GET http://www.google.com.br/csi? thor@YAMAHA.CORP DIRECT/74.125.91.106 image/gif
1318895671.192 672 172.31.1.51 TCP_MISS/200 15648 GET http://www.google.com.br/ aquaman@YAMAHA.CORP DIRECT/74.125.91.104 text/html
1318895672.040 264 172.31.1.51 TCP_MISS/204 391 GET http://www.google.com.br/csi? kakaroto@YAMAHA.CORP DIRECT/74.125.91.104 image/gif
1318895695.747 0 172.31.1.51 TCP_DENIED/407 3222 GET http://www.google.com.br/search? – NONE/- text/html
1318895696.402 507 172.31.1.51 TCP_MISS/200 13464 GET http://www.google.com.br/search? ironman@YAMAHA.CORP DIRECT/74.125.91.104 text/html
1318895696.845 0 172.31.1.51 TCP_DENIED/407 3140 GET http://www.google.com.br/csi? – NONE/- text/html
1318895697.426 421 172.31.1.51 TCP_MISS/204 674 GET http://www.google.com.br/csi? hulk@YAMAHA.CORP DIRECT/74.125.91.99 image/gif
1318895718.361 0 172.31.1.51 TCP_DENIED/407 3027 GET http://www.google.com.br/url? – NONE/- text/html
1318895718.636 262 172.31.1.51 TCP_MISS/302 1009 GET http://www.google.com.br/url? spiderman@YAMAHA.CORP DIRECT/74.125.91.99 text/html
1318895723.604 0 172.31.1.51 TCP_DENIED/407 3019 GET http://www.google.com.br/url? – NONE/- text/html
1318895723.908 292 172.31.1.51 TCP_MISS/302 993 GET http://www.google.com.br/url? superman@YAMAHA.CORP DIRECT/74.125.91.99 text/html
1318895724.972 414 172.31.1.51 TCP_MISS/200 13980 GET http://www.google.com.br/search? batman@YAMAHA.CORP DIRECT/74.125.91.99 text/html
1318895725.115 0 172.31.1.51 TCP_DENIED/407 3140 GET http://www.google.com.br/csi? – NONE/- text/html
1318895725.572 421 172.31.1.51 TCP_MISS/204 674 GET http://www.google.com.br/csi? ricardobarbosa@YAMAHA.CORP DIRECT/74.125.91.105 image/gif

Parece que este servidor de proxy e da liga da justiça ou o QG dos superheróis :P.

Até a próxima qualquer dúvida post uma pergunta.

Advertisements
Categories: Uncategorized
  1. October 19, 2011 at 1:17 am

    Esse é o meu mestre! Excelente POST!

  2. Ricardo Lopes
    October 19, 2011 at 3:26 pm

    Parabens Ricardo, ótima postagem e uma ajuda ótima para aqueles que ainda tinham duvida do que era ou o que significava o Kerberos.

  3. Jorge Vilela
    May 25, 2012 at 4:20 pm

    Cara, vc conhece alguma forma de usar o Samba3 com kerberos?
    Eu não queria usar AD e nem Samba4, mas queria que o meu servidor de domínio me desse um ticket que eu pudesse usar com o squid ou outros softwares…

    • May 27, 2012 at 11:48 pm

      Ola,

      Voc pode usar o prprio squid para obter os tickets diretamente sem necessidade de samba, conforme o tutorial do meu blog. Voc chegou a tentar?

      Att.

      ________________________________

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: