ÍNDICE
1 - INTRODUÇÃOA insegurança na Rede não é novidade, porém o que muitos não sabem é que o problema pode vir de dentro na sua rede local. Muitos usam firewalls com o objetivo de proteção contra invasores externos, porém o acionamento de executáveis por usuários da sua rede é bastante comum, gerando uma invasão que não é tratada pelo firewall, já que veio de dentro da rede.
Outro problema é a autenticação do usuário na rede, um login e uma senha não é o suficiente para garantir autenticidade quando essa senha deve ser mandanda pela rede. Um eavesdropper pode facilmente pegá-la em trânsito e posteriormente utilizá-la para se passar por um usuário.
Uma vez que autenticação por senha não era confiável e era trabalhoso ao usuário (o usuário deve digitar login e senha toda vez que fizer uma interação com o servidor), foi usado em seguida autenticação por afirmação. Esse sistema é ainda pior do que o anterior, pois tudo que o aplicativo faz é dizer que é um determinado usuário que está usando o aplicativo e o servidor aceita isso como verdade. O aplicativo pode ser facilmente alterado por terceiros para fazer com que haja falsidade de usuários.
Por isso, houve a necessidade de um método mais seguro de autenticação. Uma solução surgiu em meados da década de 80, como parte do Project Athena do MIT. O protocolo de autenticação de rede por eles criado, Kerberos, age através de autenticação por encriptação, tornando seguro o caminho entre o servidor que requeriu a autenticação e o cliente que o deve fazer.
Devido seu rápido ganho de popularidade e necessidade de se adaptar a novos contextos. Foi lançado em 1989 a versão 5 do Kerberos com o intuito de superar os problemas que a versão 4 ainda possuía (as versões de 1 a 3 foram internas ao MIT) e em 2005 a versão 5 foi atualizada pelo IETF.
2 - O QUE É KERBEROSKerberos é um protocolo de autenticação de rede criado pelo MIT (Massachusetts Institute of Technology) pelos membros do projeto Athena. Ele surge com a proposta de garantir a segurança interna, colocada em risco pelos próprios integrantes, através da autenticação, para que não seja realizada nenhuma ação danosa à rede.
2.1- TERMINOLOGIARealm -
O termo se refere a um domínio administrativo de autenticação. Cada instalação do Kerberos define um domínio administrativo de controle que é distinto de todas as outras instalações do Kerberos. Por convenção, o Kerberos utiliza como Realm o nome do domínio DNS convertido para letras maiúsculas. Por exemplo um empresa fictícia Keydrop que possui o domínio "keydrop.com" teria como realm "KEYDROP.COM". Um Realm existe para definir até onde o servidor de autenticação tem autoridade para autenticar um determinado usuário ou serviço. Não é necessário que o nome do Realm seja o mesmo do domínio DNS, mas isso facilita a configuração do Kerberos, além disso o nome do Domínio difere letras maiúsculas e minúsculas.
Principal -
Toda entidade que contém uma instalação do Kerberos, seja ela um usuário individual, um computador ou serviços executados em servidores, todos tem um principal associado a si. Todo principal começa com um nome de usuário ou de serviço. Esse nome é então seguido por uma instância opcional. Essa costuma ser usada em duas situações: Para principal de serviços ou para criar um principal com poderes de administrador. No Kerberos, cada indentidade, conjunto de nome de usuário e instância, é único dentro de um domínio. A identidade de um usuário em Kerberos é escrita da seguinte forma "Usuário/Instância[opcional]@DOMÍNIO". Caso seja uma identidade de serviço, ela assume outras especificações "NomedoServiço/NomedoHost@DOMÍNIO". Enquanto o primeiro componente é o nome do serviço escolhido pelo usuário, o segundo componente tem que ser exatamente o hostname da máquina que está oferecendo o serviço. Por último, existem identidades que não estão ligadas a um usuário ou a um serviço, mas fazem parte das operações do sistema de autenticação.
Ticket
Tickets são o meio usado no Kerberos para que o
usuário mostre sua identidade de
forma autêntica perante o servidor da
aplicação. São emitidos pelo servidor
de
autenticação e encriptados com uma chave
conhecida apenas pelo servidor de
autenticação e o servidor da
aplicação. Por isso, o conteúdo do
ticket é invisível e
imutável até mesmo para o usuário que
o pediu. Dentre as infomarções normalmente
contidas no ticket, temos:
- O principal do usuário que solicitou o ticket
- O principal do serviço para o qual
o ticket é destinado
- O endereço do IP da máquina do
usuário no qual o uso do ticket
é válido.
- A data e a hora em que o ticket é emitido (todo ticket tem
uma data de
validade)
-
A chave de sessão
Centro de Distribuição de chave (KDC)-
Esse é o servidor de autenticação do Kerberos propriamente dito e pode ser dividido em 3 partes: Banco de Dados, Servidor de Autenticação (AS) e Servidor de Concessão de Tickets (TGS)
1 - Banco de Dados
No banco de dados estão todas as entradas associadas a usuários e serviços. Cada entrada contém informações sobre: o principal ao qual ela está associado, a chave de encriptação, tempo de expiração de um ticket relacionado ao usuário, tempo máximo de renovação de um ticket, e até mesmo o tempo de expiração do usuário e/ou sua senha.
2 - Servidor de Autenticação (AS)
É ele que responde ao pedido original de autenticação do cliente, quando o usuário ainda não confirmou sua identidade com a senha. O AS gera um ticket de concessão de tickets (TGT) associado ao usuário. Se o usuário for autenticado, ele pode usar o TGT para obter outros tickets, sem a necessidade de digitar sua senha outra vez.
3 - Servidor de Concessão de Tickets (TGS)
O TGS distribui tickets de serviço para todo usuário previamente autenticado e que tenha um TGT.
Chave de Sessão -
É uma chave compartilhada entre cliente e serviço, gerada aleatóriamente pelo KDC toda vez que um ticket é solicitado. Ela é enviada ao serviço dentro do ticket para ele expedido. E é enviada ao usuário criptografada por sua senha.
Autenticador -
Um hacker pode capturar o ticket enviado à aplicação por um usuário que já foi previamente autenticado e guardá-lo para uso posterior de forma ilegal. Para evitar esse tipo de ataque o usuário envia junto com o ticket de serviço um outro pacote, encriptado com a chave de sessão, contendo seu principal e um carimbo com a data de emissão do pacote. Esse carimbo tem um tempo de expiração (padrão de 2 minutos). Se a aplicação receber o pacote antes desse tempo, a autenticação é um sucesso. Caso contrário, o ticket é rejeitado. Por esse motivo, é importantíssima a sincronização das máquinas num mesmo Realm.
Cache de Repetição -
Com a possibilidade ainda de um hacker roubar o ticket e o autenticador e usá-lo antes do tempo de expiração, os servidores dos aplicativos contam com um cache que guarda a informação de todos os tickets e autenticadores usados nos últimos dois minutos, se por um acaso ele receber uma réplica, a mesma é descartada.
Cache de Credenciais -
Para que o kerberos tenha sua característica conhecida de ter que apenas digitar senha uma vez por sessão (e também manter sua característica de não guardar senhas no servidor da aplicação) é necessário manter informação dos tickets e da chave de sessão correspondente. O lugar onde isso fica armazenado é o Cache de Credenciais.
Autenticação
é o
processo que verifica a identidade de um determinado
usuário.
É dado o nome de
Principal
à parte que
está
sendo
identificada
e
Verificador à parte que está solicitando a
autenticação.
Existem 3
principais formas
disso ser feito:
1
– Conhecimento do Usuário: Pedir do
usuário algo
que
2
– Pertence do Usuário:Pedir do usuário
algo que
ele tenha,
3
– Informações Biométricas:
Embora não
exista nada no Kerberos que escolha o
uso de um
Encriptografar
refere-se
ao processo de converter
uma
O Kerberos v4 usava DES como tipo de Encriptação,
um
dos
Chave de encriptação -
O Kerberos se utiliza de uma função hash "string2key" para que a senha de um usuário não fique guardada em uma forma não-encriptada, nem mesmo no bando de dados do servidor de autenticação. Essa função é chamada toda vez que o usuário altera sua senha, ou a usa para identificar-se. Sendo uma função hash, o processo de encriptação da senha não é reversível, os algoritmos mais comuns pra isso são o MD5 e o CRC32.
Tempero de Chave -
Ao invés de usar-se diretamente a funçao string2key na senha do usuário, usa-se essa função numa concatenação de sua senha com seu principal. As vantagens disso incluem: dois usuários diferentes num mesmo Realm, mas com mesma senha, não possuem senhas criptografadas iguais; e um usuário que possua principals em dois realms diferentes, e que use da mesma senha nos dois, não tem ambas as contas comprometidas no caso de uma delas ser.
2.2 - FUNCIONAMENTOOperações do Kerberos -
1 - Pedido ao Servidor de Autenticação (Authentication Server Request, AS_REQ) Nessa fase o usuário solicita o TGT ao AS. Esse comando não é encriptado e funciona da seguinte forma "AS_REQ = (Principal do Cliente, Principal da Aplicação, Lista de IP, Tempo de Expiração)". Onde cada argumento é Principal do Cliente: Principal do usuário que deve se identificar para uma aplicaçãoPrincipal da Aplicação: Principal da aplicação na qual o usuário deve ser identificado, e por tanto a aplicação da qual se quer o ticket de serviço.Lista de IP: Lista com todos os possíveis endereços de IP onde é possível usar o ticket que vai ser emitido pela aplicaçãoTempo de Vida: Tempo máximo de validade do pedido. Cancelar o pedido se o ticket não for emitido até o tempo limite.
2 - Resposta do Servidor de Autenticação (Authentication Server Reply, AS_REP) Primeiro, o AS confere se os dois Principais do AS_REQ existem no banco de dados. Caso ambos existam, o AS irá gerar a chave de sessão e o TGT. No TGT ele irá colocar o principal do cliente, o principal da aplicação, a lista de IP, o carimbo de tempo desse momento do servidor, o tempo de expiração do pedido e a chave de sessão. Então o AS irá gerar sua resposta que segue a seguinte fórmula "AS_REP = (Principal da Aplicação, Carimbo de tempo, Tempo de expiração, Chave de sessão) encriptadas com a chave do usuário e (TGT) encriptado com a chave do aplicativo" Quando o cliente receber essa reposta, será solicitada a senha dele. Caso esteja correta, a senha, depois de temperada e de ser usada na função string2key, será capaz de decodificar a parte dos dados encriptados com a chave do usuário. Ele então pega a chave de sessão e o TGT e os armazena no Cache de Credenciais.
3 - Pedido ao Servidor de Concessão de Ticket ( Ticket Granting Server Request, TGS_REQ)
O Usuário, já tendo provado sua identidade,
possuindo no cache a chave de sessão e o
TGT mas não um ticket adequado ao serviço que ele
quer utilizar, faz um pedido ao
Servidor de Concessão de Ticket segundo os seguintes
passos:
- Cria um autenticador usando o principal do usuário, um
carimbo de tempo
encriptados usando a chave de sessão.
- Cria-se o pedido própriamente dito, contendo o principal
do serviço, o tempo de
expiração, o autenticador e o TGT (já
encriptado com a chave do aplicativo).
4 - Resposta do Servidor de Concessão de Ticket (Ticket Granting Server Reply, TGS_REP)
Primeiro o TGS verifica se o Principal
do Aplicativo realmente existe no banco de
dados. Depois ele usa a chave correspondente a chave mestra para a
abrir o TGT, de
onde ele tira a chave de sessão que por sua vez é
usada para decriptar o
autenticador. Tendo feito isso, ele irá enviar o ticket de
serviço se as seguintes
condições não tiverem sido violadas: o
TGT não está expirado; o principal do cliente
contido no autenticador é o mesmo do TGT; o autenticador
não está no cache de
repetição nem expirou; se existem IPs na lista,
verifica se quem enviou o pedido é
um dos IPs esperados.
O TGS, então, gera uma chave de sessão
aleatória que será o segredo comum entre o
aplicativo e o usuário. E agora ele gera o ticket de
serviço que contém o
principal
do cliente, o principal do
serviço, a lista de IP, carimbo de tempo, tempo de
expiração e a nova chave de sessão.
Por último o pacote de reposta TGS_REP irá ter o
ticket recém criado, criptografado com a chave do
serviço e além do
principal
do
serviço, o carimbo de tempo, o tempo de
expiração e a nova chave de sessão,
todos
criptografados com a antiga chave de sessão.
Quando o cliente
recebe a resposta, ele decodifica parte da mensagem com sua chave de
sessão e grava a nova chave de sessão e o ticket
de serviço.
5 - Pedido à Aplicação (Application Request, AP_REQ)
Com suas credenciais em mãos (Chave de Sessão e
Ticket de Serviço) o cliente agora
pode pedir a aplicação para acessar seus
recursos, esse pedido porém, não é
mais
padrão. E cabe ao programador determinar como ele vai usar
as credenciais para
verificar a identidade do usuário. (Por padrão
pode ser usada a mesma estratégia
utilizada
pelo TGS para autenticar o usuário)
- Cross-Realm
Authentication
É a autenticação de serviços, através do Kerberos, entre domínios diferentes. Dessa forma, um usuário do realm 1 que não tenha determinado recurso poderá usar o do realm 2 através da autenticação do Kerberos. Para isso, há o compartilhamento de uma chave encriptada entre os dois realms. Essa é a chave principal do TGS e cada realm criará uma principal (linkando os dois realms). Sendo essas chamadas de chaves principals remotas do TGS. Após a comunicação estabelecida o realm 1 faz a requisição do ticket do serviço.
A confiança, no entanto,não é necessariamente bidirecional. A versão 4 só suporta a cross-realm direta, onde cada 2 realms precisam ter um par de chaves, o que não é escalável, dado que quanto mais realms você desejar se comunicar mais chaves seriam criadas, criando um número muito grande de chaves. Já a versão 5 aceita a criação de um “caminho” entre o realm que faz o pedido e o realm que possui o recurso. Utilizando-se de realm intermediários. Exemplo, o realm 1 possui uma cross-realm com o 2 e o 2, com o 3. Se o realm 1 quiser comunicar-se com o 3 o realm 2 servirá como intermediário. E a comunicação ocorrerá apesar de o realm 1 não ter uma cross-realm direta com o 3.
- Keytab
As chaves de serviço de cada serviço são armazenadas no servidor do mesmo em um arquivo chamado keytab.
- PAM – Pluggable Authentication Modules
Em alguns Sistemas Operacionais a aquisição do TGT não é automática assim que o usuário faz o login, nesses casos uma solução é o PAM que também provê uma interface de plug-in padrão capaz de realizar a autenticação independente do suporte do Sistema Operacional. Porém, sua melhor utilização é na autenticação local, ou seja, que não seja baseada em serviços da internet, já que sua senha seria enviada em texto pela Rede, ao contrário da autenticação nativa do Kerberos.
4 - IMPLEMENTAÇÕES4.1- MIT KERBEROS
É o Kerberos autêntico criado pelo MIT, pela equipe do projeto Athenas. Ele foi primeiramente criado para ser o protocolo de autenticação universal padrão. Dentre suas vantagens, podemos ressaltar que ele é atualmente open-source (passou a ser open-source após a criação do Heimdal), além de receber maior assistência, inclusive das implementações Shishi e Heimdal. Porém, seu processamento é custoso devido ao uso de criptografia e é menos compatível com sistemas específicos como o GNU (onde a implementação Shishi é a mais adequada)
4.2 - SHISHIShishi é a implementação do protocolo de autenticaçãoKerberos 5 para sistemas GNU (linux). Dentre suas vantagens pode-se ressaltar sua biblioteca ("libshishi") que permite que programadores possam prover suporte ao Kerberos. Essa implementação também possui uma linha de comando ("shishi") para ser usada pelos usuários e suporta trocas AS/TGS para adquirir pré-autenticação, além de suportar trocas AP para a criação de autenticação de servidores e de clientes compatível com sistemas GNU. Qualquer erro pode ser reportado para a assistência efetiva. No entanto, assim como o Kerberos, possui um processamento custoso e exige um uso muito alto de processamento para uma segurança que nem sempre é necessária.
4.3 - HEIMDALÉ a implementação gratuita do protocolo de autenticação Kerberos 5, foi criado quando este não era "open source". Por ser um aplicativo gratuito, ele ganha em escalabilidade, além de ser compatível com protocolos já existentes é compatível e suporta o kerberos 5 e compatibiliza-se com a maioria das funções do Kerberos 4 e assim como o Kerberos 5, possui um aassistência efetiva. Todavia, seu grande atrativo era o fato de ser "open source", como o Kerberos já superou esse atrativo, ele deve tornar-se obsoleto em pouco tempo.
5 - LIMITAÇÕES E FRAQUEZAS
Está
sendo discutido usar o protocolo do Kerberos como padrão,
porém alguns
artigos como
"
Limitations of Kerberos
authentication system"
mostram
que essa visão talvez seja
prematura,
pois
o
Kerberos
possui ainda limitações e
fraquezas.
5.1 - LIMITAÇÕES
-
Eficiência e Funcionalidade
O Kerberos
é um sistema seguro, porém, ele perde em
funcionalidade e
eficiência por usar
um
método de Criptografia que gasta em processamento. Para
atividades comuns
isso não
seria útil pois
não há real
necessidade de um protocolo de segurança
para todas
as atividades
na net assim usar o Kerberos como padrão pode ser
exagerado para algumas
situações.
-
Não possui um protocolo
de
Host-to-host
O
Kerberos5 é Usuário para usuário e o 4
é
somente Usuário para Servidor assim
não sendo
possível em nenhuma das
verões a
comunicação direta de um servidor a
outro
5.2 - FRAQUEZAS
Além
dessas limitações, o
Kerberos possui uma fraqueza contra alguns ataques. Como
exemplo,
podemos
citar:
O
protocolo do Kerberos não está devidamente
protegido
contra ataques do tipo
“Replay
atack”.O principal problema
é que o
autenticador depende
de uma ``estampa de
tempo`` para evitar o
reuso da sua autenticação, isso é
problemático porque você
assume que nenhuma
repetição da sua
autenticação vai ocorrer
no tempo estipulado que
normalmente é
de 5 minutos. Com isso um invasor
pode
simplesmente esperar por uma
sessão de ``mailchecking`` e
entrar
rapidamente
com o autenticador, ler algumas
mensagens e depois sair.
Ainda
nesse problema, na versão 5 proposta, querem implementar um
protocolo de
comunicação
bidimensional onde um
ataque desse tipo seria mais fácil de fazer.
Uma
solução proposta é a de armazenar
dados de todos
os autenticadores, assim, um
sistema para negar um autenticador de
acesso se
aquele já foi autorizado
anteriormente, poderia ser implementado.
Havia
propostas de implementação desse
armazenamento, porém elas
nunca chegaram a
ser realizadas.
Um
armazenamento, porém, não deve ser a
solução para esse problema, pois em
servidores baseados em TCP (como o do
UNIX) é
muito difícil implementar, porque
ele
usa um processamento diferente para as
novas pedidos
de validação e esse
pedido não
recebe nenhuma
informação de pedidos
anteriores.
Para
sistemas baseados em UDP, um sistema de memória seria de
mais
fácil
implementação,
pois ele usa um mesmo
processo para todos os pedidos de
validação,
porém ele teria um problema
com a
retransmissão caso a autenticação
fosse perdida, um
sistema UDP não garante a
transmissão
e todas as
retransmissões acontecem em nível
de aplicação e
podem assim ser vistos
por
esse, assim uma legitima autenticação
poderia ser negada e o alarme ativado
desnecessariamente. Uma solução para isso seria
o autenticador gerar um novo
pedido na retransmissão e isso seria aceitável se
não
fosse pelos outros
problemas do projeto do autenticador.
-password guessing atack
Um invasor
pode guardar informações de login e montar um
programa
que ”chute”
senhas, pois
quando um usuário pede um ticke,t ele vem encriptado com a
chave
derivada, por
um algoritmo conhecido publicamente da senha do usuário,
assim
um
invasor que
tenha conseguido muitos logins tem uma grande chance de achar novas
senhas, já
que os usuários não costumam escolher boas senhas
a menos
que sejam
obrigados a
isso.
Uma
solução para isso seria usar um método
exponencial
para a chave. Aumentando,
assim,
a segurança da criptografia e assim evitando um invasor
conseguir o equivalente
a senha, mas esse processo é
mais trabalhoso,
sendo necessário mais de um
processador.
-Secure
Time
Services
Autenticadores
dependem do clock estar em sincronismo perfeito, pois se o receptor
estiver
enganado quanto ao tempo, um autenticador pode ser clonado sem maiores
problemas, como pessoas usam protocolos
ruins mesmo
existindo melhores, esse
tipo de
ataque pode não ser
difícil.
Como
solução, podemos usar um protocolo de
desafio/resposta no
lugar. Assim, após o
pedido de permissão o
receptor envia um
identificador encriptado com a senha KCS,
então o autenticador
responderia com uma
função desse identificador. O Problema
dessa
solução
é que você dobra
a quantidade de mensagem trocada para o login, tornando
mais
grave o problema de passwordguessing
anteriormente citado (entre outros).
-SpoofingLogin
Esse
problema se coloca por ser fácil a troca de um sistema de
login
por um que
tenha
armazenamento de dados. Dessa forma, em
um local
compartilhado, podemos
sofrer a
cópia da senha por um desses
programas e
esse
problema é mais grave em
Kerberos,
pois ele impede a
utilização de
um meio de evitar isso, a senha de
acesso único.
Poderia
também ser resolvido com a
implementação de um
sistema de desafio/resposta
como
senha com os mesmos problemas anteriormente citados.
Após este estudo, pode-se afirmar que o Kerberos não é o protocolo perfeito, porém é a ferramenta mais poderosa que temos hoje em autenticação. E apesar de apresentar um ponto único de falha, sua eficiência ainda supera suas desvantagens.