IEEE 802.1X

Introdução O padrão IEEE 802.1X define o controle de acesso à rede baseado em porta, que é utilizado para fornecer acesso autenticado a redes Ethernet. Esse controle de acesso à rede baseado em porta utiliza as características físicas da infra-estrutura de rede local comutada para autenticar dispositivos conectados a uma porta do comutador. A capacidade de enviar e receber quadros usando uma porta do comutador Ethernet será negada se o processo de autenticação falhar. Embora esse padrão seja projetado para redes Ethernet com fio, ele foi adaptado para ser usado em redes locais sem fio IEEE 802.11.

O IEEE 802.1X define os seguintes termos: Entidade de acesso à porta Autenticador Suplicante Servidor de autenticação

Entidade de acesso à porta Uma entidade de acesso à porta (PAE), também conhecida como uma porta de rede local, é uma entidade lógica que oferece suporte ao protocolo IEEE 802.1X associado a uma porta. Uma porta de rede local pode adotar a função de autenticador, suplicante ou ambos.

Autenticador Um autenticador é uma porta de rede local que aplica a autenticação antes de permitir acesso a serviços que são acessados por meio da porta. No caso das conexões sem fio, o autenticador é a porta de rede local lógica em um ponto de acesso (AP) sem fio por meio do qual os clientes sem fio, operando no modo de infra-estrutura, ganham acesso à rede com fio.

Suplicante O suplicante é uma porta de rede local que solicita acesso a serviços acessados por meio do autenticador. No caso das conexões sem fio, o suplicante é a porta de rede local lógica em um adaptador de rede sem fio que solicita acesso à rede com fio. Ele faz isso associando-se a um autenticador e se autenticando. Quando utilizados para conexões sem fio ou conexões Ethernet com fio, o suplicante e o autenticador são conectados por um segmento de rede local ponto a ponto lógico ou físico.

Servidor de autenticação Para verificar as credenciais do suplicante, o autenticador usa um servidor de autenticação. O servidor de autenticação verifica as credenciais do suplicante em nome do autenticador e responde ao autenticador, indicando se o suplicante está ou não autorizado a acessar os serviços do autenticador. O servidor de autenticação pode ser:

Um componente do AP. Uma entidade separada. O AP deve ser configurado com os conjuntos de credenciais de usuário correspondentes aos clientes que estão tentando se conectar. Isso geralmente não é implementado para APs sem fio. Uma entidade separada. O AP encaminha as credenciais da tentativa de conexão a um servidor de autenticação diferente. Geralmente, um AP sem fio usa o protocolo RADIUS para enviar os parâmetros de tentativa de conexão a um servidor RADIUS.

Portas controladas e não controladas O controle de acesso baseado em porta do autenticador define os seguintes tipos de portas lógicas, que acessam a rede local com fio por meio de uma única porta de rede local física: Porta Controlada Porta Não Controlada

Porta controlada A porta controlada permite que os dados sejam enviados entre um cliente sem fio e a rede com fio, mas apenas se o cliente sem fio estiver autenticado. Antes da autenticação, o comutador está aberto e nenhum quadro é encaminhado entre o cliente sem fio e a rede com fio. Depois de o cliente sem fio ser autenticado com êxito usando o IEEE 802.1X, o comutador é fechado e os quadros são encaminhados entre o cliente sem fio e os nós na rede com fio.

Porta não controlada A porta não controlada permite uma troca não controlada de dados entre o autenticador (o AP sem fio) e outros dispositivos de rede na rede com fio, independentemente do estado de autorização dos clientes sem fio. Um bom exemplo é a troca de mensagens RADIUS entre um AP sem fio e um servidor RADIUS na rede com fio, que fornece a autenticação e a autorização de conexões sem fio. Os quadros enviados pelo cliente sem fio nunca são encaminhados pelo AP sem fio por meio da porta não controlada.

Funcionamento Em um comutador Ethernet autenticado, o cliente Ethernet com fio pode enviar quadros Ethernet à rede com fio assim que a autenticação é concluída. O comutador identifica o tráfego de determinado cliente Ethernet com fio usando a porta física à qual o cliente Ethernet está conectado. Geralmente, somente um único cliente Ethernet é conectado a uma porta física no comutador Ethernet.

Como vários clientes sem fio disputam acesso e enviam dados usando o mesmo canal, é necessária uma extensão para o protocolo IEEE 802.1X básico a fim de permitir que um AP sem fio identifique o tráfego seguro de um cliente sem fio específico. Isso é feito por meio da determinação mútua de uma chave de sessão por cliente de difusão ponto a ponto realizada pelo cliente e o AP sem fio.

Somente os clientes sem fio autenticados têm uma chave de sessão por cliente de difusão ponto a ponto determinada corretamente. Sem uma chave de sessão de difusão ponto a ponto válida, ligada a uma autenticação bem-sucedida, os quadros enviados por um cliente sem fio não autenticado são descartados silenciosamente pelo AP sem fio.

Protocolo de autenticação extensível Para fornecer um mecanismo de autenticação padrão para o IEEE 802.1X, o IEEE optou pelo protocolo de autenticação extensível (EAP). EAP é uma tecnologia de autenticação baseada no protocolo ponto a ponto (PPP) que foi adaptada para uso em segmentos de rede local ponto a ponto.

O EAP-TLS, com certificados de usuário e computador baseados no Registro, é o método de autenticação para a conectividade sem fio baseada no Windows devido aos seguintes motivos: O EAP-TLS não requer nenhuma dependência na senha da conta de usuário. A autenticação EAP-TLS ocorre automaticamente, sem intervenção do usuário. O EAP-TLS usa certificados, que fornecem um esquema de autenticação de alta segurança.

Como as mensagens EAP originalmente eram definidas para serem enviadas como a carga de quadros PPP, o padrão IEEE 802.1X define o EAP através de rede local (EAPOL), que é um método de encapsular mensagens EAP para poderem ser enviadas através de segmentos Ethernet ou rede local sem fio.

Para a autenticação de conexões sem fio, o Windows usa o protocolo de nível de transporte EAP (EAP-TLS), que é definido na RFC 2716 e usado em ambientes de segurança baseados em certificado. A troca de mensagens EAP-TLS fornece autenticação mútua, negociação de conjuntos de codificação de integridade protegida e determinação mútua de material de chave de assinatura e criptografia entre o cliente sem fio e o servidor de autenticação (o servidor RADIUS). Após a autenticação e a autorização, o servidor RADIUS envia as chaves de criptografia e assinatura ao AP sem fio usando a mensagem de aceitação e acesso RADIUS.

LDAP

O que é um Diretório? O que é um diretório? É um banco de dados especializado com informações descritivas baseadas em atributos e organizadas em forma de árvore. Característica de um diretório: Resposta rápida a grande quantidade de consultas. Tipos de diretórios: De aplicações: diretório do MS Exchange, etc. De sistemas operacionais de rede: NIS (Sun), AD (Microsoft) De propósito específico: DNS De propósito geral: LDAP

O que é o LDAP? Lightweight Directory Access Protocol Protocolo Leve de Acesso a Diretórios. Trabalha na camada de aplicação da pilha de protocolos TCP/IP, como por exemplo o SMTP, HTTP, FTP, TELNET e tantos outros. RFCs 2251 – 2830 e 3377 Cliente-Servidor. Orientado a mensagens.

História do LDAP X.500 A CCITT (atual ITU) cria a versão Standard X.500 , ISO 9594 Data Communications Network Directory 1988 DAS: Directory Assistance Service (RFC 1202) DIXIE: Protocol Specification (RFC1249) LDAP: X.500 Lightweight Access Protocol (RFC 1487) LDAP (RFC 1777) LDAP v2 LDAP v3 (RFC 3377) 1998

Origem do LDAP – Diretórios X.500 Características Principais do X.500 Conexão de Serviços de Diretórios locais a fim de formar um diretório global distribuído. Parte do diretório fica global e sua informação é disponibilizada através de um Agente do Sistema de Diretórios Trabalha com funções de gerenciamento, isto é, adição, modificação e deleção de entradas.

Origem do LDAP – Cliente do X.500 O LDAP foi desenvolvido para ser um cliente para o X.500, o serviço de Diretório OSI. O X.500 define o Protocolo de Acesso a Diretório (DAP) para os clientes usarem quando estiverem em contato com servidores de Diretório.

Origem do LDAP - DAP O DAP era um protocolo difícil de trabalhar e implementar, e protocolos mais fáceis foram desenvolvidos com a maior parte de sua funcionalidade, mas com muito menos complexidade.

Origem do LDAP – Pilha de Protocolos O LDAP roda diretamente sobre o TCP e fornece a maioria das funcionalidades do DAP, a um custo muito menor.

Origem do LDAP – Versões Versões LDAP 1993 primeira versão 1996 LDAP v2 Autenticação forte com Kerberos v4. 1997 LDAP v3 (atual) Esta última foi desenvolvida para solucionar uma série de limitações existentes na anterior, incluindo aspectos de segurança, passando a suportar protocolos de autenticação forte como o Simple Authentication Security Layer (SASL) e o Transport Layer Security (TLS)

Por que usar o LDAP? Integração entre sistemas Operacionais Interligação ( Windows , Linux, Unix , MacOS) Integração entre Serviços Serviços de e-mail, FTP , Web etc. Desempenho nas consultas: Desenvolvido com ênfase na leitura, ou seja, os dados serão lidos rapidamente por um número maior de consultas simultâneas. Difundido no mercado Não requer hardware pesado para operações

Por que usar o LDAP?

Diretório LDAP Representação gráfica de parte de um diretório LDAP:

O que é LDIF? LDAP Data Interchange Format Formato de intercâmbio de informações para o LDAP Definido na RFC 2849 - The LDAP Data Interchange Format Esse formato de dados descreve o diretório e suas entradas em formato texto Formato básico: dn: <indentificador_único> <atributo>: <valor> <atributo>:: <valor codif. em base-64> <atributo>: < <URL> ...

LDIF Exemplo Simples com 2 entradas version: 1 dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com objectclass: top objectclass: person objectclass: organizationalPerson cn: Barbara Jensen cn: Barbara J Jensen cn: Babs Jensen sn: Jensen uid: bjensen telephonenumber: +1 408 555 1212 description: A big sailing fan. dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com cn: Bjorn Jensen

LDIF Exemplo com uma entrada codificada em base-64 version: 1 dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com objectclass: top objectclass: person objectclass: organizationalPerson cn: Gern Jensen cn: Gern O Jensen sn: Jensen uid: gernj telephonenumber: +1 408 555 1212 description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVlIGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdGVyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQgb3V0IG1vcmUu

LDIF Exemplo com uma entrada referenciando um arquivo externo version: 1 dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com objectclass: top objectclass: person objectclass: organizationalPerson cn: Horatio Jensen cn: Horatio N Jensen sn: Jensen uid: hjensen telephonenumber: +1 408 555 1212 jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg

LDIF Representação gráfica de um arquivo LDIF:

Operação do protocolo LDAP Recebimento de uma única entrada: Caso o LDAP Server ache apenas um valor para a operação de Search realizada, esse valor é retornado. Na requisição, o cliente envia um ID único (msgid). Esse ID é usado nas respostas para identificar as mensagens.

Operação do protocolo LDAP Recebimento de várias entradas: Caso o LDAP Server ache diversos valores para a operação de Search realizada, eles são retornados em mensagens separadas. Cada entrada retornada tem um nome único chamado de distinguished name (DN).

Operação do protocolo LDAP Requisição de várias operações: Como o LDAP é orientado a mensagem, é possível realizar diversas operações ao mesmo tempo. Isto torna o protocolo mais flexível e eficiente, pois não há a necessidade de esperar uma resposta do server antes de realizar outra operação, como no HTTP.

Operação do protocolo LDAP Tipos de operações do LDAP, divididas em 3 classes: Operações de pergunta: Search Compare Operações de atualização: Add Delete Modify Modify DN (Rename) Operações de autenticação e controle: Bind (Cliente se autentica com o Servidor) Unbind (Cliente termina sessão com o Servidor) Abandon (Cliente não está mais interessado nas respostas da requisição anteriormente enviada)

Operação do protocolo LDAP Troca completa de mensagens entre Cliente e Servidor: 1. O cliente abre uma conexão TCP com o servidor LDAP e envia uma operação de bind. Esta operação inclui o nome da entrada do diretório com a qual ele deseja se autenticar, seguido das credenciais que serão usadas na autenticação. As credenciais podem ser simples senhas ou até mesmo certificados digitais. 2. Após o servidor conferir se as credenciais são válidas, ele retorna uma mensagem de sucesso ao cliente. 3. O cliente envia uma operação de Search. 4 e 5. O servidor realiza a operação e retorna as duas entradas encontradas para o pedido. 6. O servidor envia uma mensagem com o resultado total (result message). 7. O cliente envia um pedido de unbind, indicando que o cliente deseja se desconectar. 8. O servidor obedece terminando a conexão.

Operação do protocolo LDAP A combinação de simples operações podem realizar tarefas complexas, exemplo: Exemplo: Ajuda em tarefas simples como envio de emails O seu cliente de emails pode te ajudar procurando os emails de todos os destinatários da sua mensagem no diretório. Também é possível adquirir os certificados digitais de seus destinatários a fim de criptografar a mensagem antes de enviá-la.

A Segurança no LDAP Protegendo informações de acessos indevidos: Autenticação. LDAP, só autenticação simples (texto aberto) LDAPv2, autenticação simples e pode utilizar Kerberos v4 e v5 LDAPv3, utiliza framework SASL (Simple Authentication and Security Layer) – múltiplos mecanismos de autenticação Transmissão de dados segura (criptografia). Modelos de controle de acesso.

Métodos de Autenticação LDAPv3: métodos de autenticação definidos na RFC 2829 (Authentication Methods for LDAP). Nessa RFC, os servidores foram quebrados em 3 grupos: Servidores LDAP públicos Somente-leitura (permitem login anônimo, sem senha). Servidores com autenticação usando senhas (usa mecanismo SASL DIGEST-MD5). Servidores com autenticação e criptografia de dados (usa StartTLS para camada de transporte segura e certificados com chaves públicas para autenticação de ambos os lados). SASL DIGEST-MD5 (RFC 2831 - Using Digest Authentication as a SASL Mechanism) StartTLS RFC 2830 (LDAPv3: Extension for Transport Layer Security)

Método de Criptografia Transport Layer Security (TLS) TLS proporciona: Autenticidade, Integridade e Criptografia de dados Clientes que usam TLS na comunicação: Suas mensagens não serão decifradas caso sejam capturadas. Suas mensagens não serão alteradas (homem do meio) Podem autenticar o servidor (usando certificados com chaves públicas) Podem verificar a autenticidade de servidores nos quais ele já está conectado (usando certificados com chaves públicas)

Método de Criptografia LDAP usando SASL com SSL/TLS

Método de Criptografia Step 1. Open a TCP connection to the server. Step 2. Send a StartTLS extended operation. Lower-layer protocols then negotiate encryption and authentication according to the TLS specification. Step 3. Bind using the SASL EXTERNAL mechanism if a certificate was provided during TLS negotiation, or using another SASL mechanism, such as DIGEST-MD5. After TLS has been established and a bind operation performed, the client has a secure, authenticated connection to the directory.

Modelo de Controle de Acesso Define os direitos de acesso as informações do diretório para cada usuário ou grupo: Ex: Somente leitura de nomes para usuário Administrator; Alteração de descrição para todos os usuários; Leitura de informações básicas do diretório para usuário Anônimo; Não foi padronizado pela IETF (ainda estão definindo um padrão). Cada fabricante tem um padrão distinto  muito trabalho de migração caso seja necessário mudar de fabricante.

Tipos de Otimizações Replicação do serviço de diretórios  Conceito de prover mecanismos de tolerância a falhas afim que manter o acesso as informações dos usuário sempre integra. Diretórios distribuídos  Conceito que visa reduzir os pontos de falhas , alem de prover menor consumo de banda e tempo quando uma consulta é realizada. O principal benefício é a possibilidade de redução de custos com hardware

Replicação de Diretório Problema: Muitos computadores acessando um servidor  ponto de falha.

Replicação de Diretório Solução: Usar o conceito de Diretórios Replicados para usar uma redundância quando for necessário.

Replicação de Diretório Quando temos uma falha no serviço o outro servidor entra em operação de forma automática.

Diretórios Distribuídos Problema: Muitos Computadores acessando o local que reside a informação. ( Tempo elevado e utilização do hardware para consulta)

Diretórios Distribuídos Solução: Utilização de vários computadores na formação na arvore de Diretórios.

Exemplo Prático – Windows Conceitos e Nomenclaturas: Forest Root  Principal Servidor da Floresta. Global Catalog  Arquivo que reúne todas as informações sobre os Componentes do Domínio computadores, usuários , impressoras e seus atributos. Member Server : Servidor membro, roda aplicações (Banco de Dados, Controle de Versões, Servidor de Arquivos etc) Domain Controler  Controlador do Domínio, controla os objetos do domínio.

Exemplo Prático – Windows - Cenário

Exemplo Prático – Windows - Cenário Nesta parte do Exemplo temos o Forest Root , onde fica armazenado o Global Catalog(Arquivo de Diretórios) principal da Floresta.

Exemplo Prático – Windows - Cenário www.microsoft.com

Active Directory – Considerações Interface LDAP para Windows  Atualmente ADFS Cada Domain Controler tem o Active Directory Instalado para controlar os objetos do seu Domínio. As informações são replicadas de tempos em tempos para manter a consistência dos dados. Informações Urgentes são replicadas no momento da alteração.

Ferramentas Linux php LDAP admin Módulo Web para administração do servidor LDAP Visualização hierárquica da árvore LDAP Intuitivo, fácil e LIVRE! Funciona também em outros SOs Suporte internacional (8 línguas) Mais informações: http://phpldapadmin.sourceforge.net/

phpLDAPadmin - Criação

phpLDAPadmin - Edição

phpLDAPadmin - Buscas

Conclusão Protocolo leve – não necessita de muitos recursos computacionais; Padrão aberto – é possível a construção de produtos para várias plataformas (OpenLDAP); Expansível – podem ser adicionadas novas funcionalidades para atender às necessidades dos serviços de diretório e de segurança (framework SASL); Porém não é a solução para todos os problemas, pois não substitui tão eficientemente serviços como Servidores FTP, Servidores WEB ou Sistemas de Arquivos, por exemplo.

Bibliografia http://www.microsoft.com/technet/columns/cableguy/cg0302.as http://www.microsoft.com/windows2000/technologies/communications/wifi/default.asp Timothy A. Howes Ph.D., Mark C. Smith, Gordon S. Good, Understanding and Deploying LDAP Directory Services, 2nd Edition, 2003, Ed. Addison Wesley http://www.ldap.org.br/ http://penta2.ufrgs.br/~mfiorese/tutorial_quipu/x500.htm http://www.openldap.com http://www.rnp.br/newsgen/0203/processamento_dinamico.html#ng-2-2 http://phpldapadmin.sourceforge.net/ http://www.microsoft.com