Os atributos RADIUS do IETF são utilizados para comunicação AAA entre cliente e servidor de acordo com a RFCS 2865 e 2866 para o protocolo. O cliente e servidor RADIUS devem aceitar os parâmetros de acordo com a RFC, para uma comunicação adequada.
Os atributos específicos dos fabricantes (RADIUS Vendor-Specific Attributes), chamados de VSAs, derivam do atributo IETF número 26, destinado para os fabricantes utilizarem as funções do RADIUS de acordo com seus produtos. O padrão permite liberdade para integração do RADIUS com funcionalidades proprietárias dos vendors, mas dificulta a integração com os fabricantes concorrentes. Esses VSAs são inseridos dentro do atributo 26.
Formato do Pacote RADIUS
Cada pacote RADIUS contém as seguintes informações:
Code – O campo code contém um 8-bit e define os seguintes tipos de pacotes RADIUS:
Access-Request (1)
Access-Accept (2)
Access-Reject (3)
Accouting-Request (4)
Accouting-Response (5)
Identifier – O campo identifier possui 8-bit e ajuda o servidor RADIUS a identificar a resposta para a determinada requisição. Imaginando que hajam vários pacotes RADIUS trafegando pela rede, o valor da resposta será igual ao valor da requisição ao servidor RADIUS.
Lenght – Campo com 16-bit que especifica o tamanho de todo o pacote.
Authenticator – Campo de 16-bit. Os valores incluídos neste campo do pacote são utilizados para autenticar as respostas do servidor RADIUS e também são utilizados no algoritmo de ocultação de senhas.
Attributes: O campo de Atributos é responsável por carregar informações específicas de autenticação e de autorização, como os detalhes específicos de uma dada requisição ou de uma dada resposta. Dentre os tipos de informações contidas, podemos citar o nome do usuário a ser autenticado, o conjunto de AV pairs, entre outros.
Pulando já para o processo final de autenticação, se o ‘username’ é encontrado na base de dados e a senha é autenticada, o servidor RADIUS retornará a mensagem Access-Accept para o cliente. O Access-Accept carrega a lista de AV pairs que descrevem os parâmetros usados para a sessão. Os atributos podem incluir informações padrão como service-type (Shell ou Framed), protocol type, o IP do cliente, etc; como podem também conter os vendors-specific attributes (Attribute 26).
Na prática, em network, há soluções que incluem envio de URLs dinâmicas para autenticação de usuários com 802.1x, politicas de NAC, níveis diferentes de autorização para gerenciamento de equipamentos dos dispositivos de rede, etc.
Existem inúmeras vulnerabilidades nos switches Ethernet e as ferramentas de ataque para explorá-los estão disponíveis há mais de uma década (talvez duas!). Um atacante pode desviar qualquer tráfego para seu próprio PC para quebrar a confidencialidade, privacidade ou a integridade desse tráfego.
A maioria das vulnerabilidades são inerentes aos protocolos da Camada 2 (enlace de dados, do modelo de referência OSI) e não somente aos switches. Se camada a de enlace de dados estiver comprometida, é mais fácil criar ataques em protocolos das camadas superiores usando técnicas comuns como ataques de man-in-the-middle (MITM) para coleta e manipulação do conteúdo.
Para explorar as vulnerabilidades da camada 2, um invasor deve possuir um dispositivo mesma rede local do alvo. Se o atacante utilizar-se de outros meios de exploração, poderá conseguir um acesso remoto ou até mesmo físico ao equipamento. Uma vez dentro da rede, a movimentação lateral do atacante torna-se mais fácil para conseguir acesso aos dispositivos ou ao tráfego desejado.
No vídeo descrevemos as 8 (oito) principais funcionalidades de segurança para switches.
Em uma implantação tradicional com AAA utilizando RADIUS, após a autenticação, o Servidor RADIUS apenas assina a autorização como resultado de uma requisição de autenticação.
No entanto, existem muitos casos em que é desejável que hajam alterações sem a exigência do NAS para iniciar a troca de mensagens. Por exemplo, pode haver a necessidade de um administrador da rede ser capaz de encerrar a ‘sessão’ de uma porta autenticada com 802.1x.
Alternativamente, se o usuário alterar o nível de autorização, isto pode exigir que novos atributos de autorização sejam adicionados ou excluídos para o usuário.
Outro exemplo, é a limitação da banda disponível a um usuário após exceder a banda liberada em uma rede wifi, por exemplo.
Para superar essas limitações, vários fabricantes implementaram comandos RADIUS adicionais a fim de permitir que mensagens ‘não solicitadas’ sejam enviada para o NAS . Estes comandos estendidos fornecem suporte para desconectar (disconnect) e mudar de autorização (CoA – Change-of-Authorization).
CoA
Com o avanço da tecnologia e o surgimento de novas demandas, o padrão RADIUS CoA (Change of Authorization) permite ao Servidor iniciar a conversação com o equipamento de rede aplicando comandos: shut/ no shut, alterar a VLAN, ACL, banda ou então apenas re-autenticar o usuário. As vezes um endpoint pode ser roubado, infectado, ter o anti-virus desabilitado, ultrapassar do limite dos dados disponíveis para navegação ou então ocorrer outros fatores que possam afetar a postura. Nesse caso a rede deve ser capaz de interagir à essas mudanças e atualizar o nível de acesso e autorização para esse dispositivo.
No cenário acima, o cliente (suplicante) inicia a autenticação; após a troca de certificados e credenciais, o servidor autoriza o usuário enviando uma mensagem RADIUS Access-Accept ao NAD. Uma vez o usuário autenticado, o NAD enviará atualizações de accouting RADIUS para o servidor para atualizá-lo com informações da sessão do usuário: como largura de banda, tempo da sessão etc.
Usando as mensagens de Accounting, o servidor de autenticação pode correlacionar o MAC e o endereço IP de um usuário com o tempo da conexão.
Se pensarmos em uma rede sem fio, podemos habilitar a desconexão com uma mensagem RADIUS Coa Disconnect-Request para a Controller quando um cliente atingir o limite de 100Mb de trafego.
O Controle de Acesso à Rede, ou NAC (Network Access Control) tem como objetivo proteger a rede contra ameaças, garantindo que apenas dispositivos autorizados e em conformidade com as políticas de segurança tenham acesso à rede.
IEEE 802.1X (também chamado de dot1x) é um padrão IEEE RFC 3748 para controle de acesso à rede. Ele prove um mecanismo de autenticação para hosts que desejam conectar-se a um Switch, por exemplo. A funcionalidade é também bastante poderosa para vínculo de VLANs, VLANs Guest e ACL’s dinâmicas. As funcionalidades do 802.1x permitem por exemplo, que caso um computador não autentique na rede, a máquina seja redirecionada para uma rede de visitantes etc.
O padrão 802.1x descreve como as mensagens EAP são encaminhadas entre um suplicante (dispositivo final, como um host da rede) e o autenticador (Switch ou access point), entre o autenticador e o servidor de autenticação. O autenticador encaminha as informações EAP para o servidor de autenticação pelo protocolo RADIUS.
Uma das vantagens da arquitetura EAP é a sua flexibilidade. O protocolo EAP é utilizado para selecionar o mecanismo de autenticação. O protocolo 802.1x é chamado de encapsulamento EAP over LAN (EAPOL). Atualmente ele é definido para redes Ethernet, incluindo o padrão 802,11 para LANs sem fios.
Os dispositivos que compõem a topologia para o funcionamento do padrão 802.1x são:
Suplicante (Supplicant): um suplicante pode ser um host com suporte a 802.1x com software cliente para autenticação, um telefone IP com software com suporte a 802.1x etc.
Autenticador (Authenticator): Dispositivo (geralmente o Switch, AP, etc) no meio do caminho que efetua a interface entre o Autenticador e o Suplicante. O autenticador funciona como um proxy para fazer o relay da informação entre o suplicante e o servidor de autenticação. O Switch recebe a informação de identidade do suplicante via frame EAPoL (EAP over LAN) que é então verificado e encapsulado pelo protocolo RADIUS e encaminhado para o servidor de autenticação. Os frames EAP não são modificados ou examinados durante o encapsulamento. Já quando o Switch recebe a mensagem do RADIUS do Servidor de autenticação, o cabeçalho RADIUS é removido, e o frame EAP é encapsulado no formato 802.1x e encaminhado de volta ao cliente.
Servidor de Autenticação (Authentication Server): O Servidor RADIUS é responsável pelas mensagens de permissão ou negação após validação do usuário. Durante o processo de autenticação o Authentication Server continua transparente para o cliente pois o suplicante comunica-se apenas com o authenticator. O protocolo RADIUS com as extensões EAP são somente suportados pelo servidor de autenticação.
O suplicante envia uma mensagem start para o autenticador.
O autenticador envia uma mensagem solicitando um login ao suplicante.
O suplicante responde com o login com as credenciais do usuário ou do equipamento.
O autenticador verifica o quadro EAPoL e encapsula-o no formato RADIUS, encaminhando posteriormente o quadro para o servidor RADIUS.
O servidor verifica as credenciais do cliente e envia uma resposta ao autenticador com a aplicação das políticas.
Baseado ne mensagem da resposta, o autenticador permite ou nega o acesso a rede para a porta do cliente.
EAP Types
Os tipos de EAP podem ser divididos em duas categorias: ‘EAP native’ e ‘EAP tunneled’ (que usa um túnel TLS entre o suplicante e o autenticador).
Native EAP Types:
EAP-MD5: Envia as credenciais escondidas em hash. O hash é enviado para o servidor que então compara com o hash local. Entretanto o EAP-MD5 não possui mecanismo para autenticação mútua, o servidor valida o cliente, mas o cliente não valida o servidor de autenticação. EAP-MD5 é geralmente utilizado em telefones IP e também permite alguns Switches utilizar o MAB (MAC authentication Bypass).
EAP-TLS: utiliza TLS para prover a transação de identidade de forma segura. Utiliza certificados X.509 e prove a habilidade de suportar autenticação mútua onde o cliente e o servidor devem confiar o certificado. É considerado o mais seguro tipo de EAP pois a captura da senha não é uma opção; o dispositivo final ainda deve ter uma chave privada.
EAP-MSCHAPv2: As credenciais do cliente são enviadas criptografadas para o servidor com uma sessão MSCHAPv2. Permite uma simples transmissão do usuário e senha, ou mesmo nome do computador e senha para o servidor RADIUS que autentica com o Active Directory (AD).
EAP-GTC: EAP-Generic Token Card foi criado pela Cisco como alternativa para o MSCHAPv2 que permite autenticação genérica para virtualmente armazenar qualquer identidade, incluindo servidor de Token OTP, LDAP, Novel E-Directory, etc.
Tunneled EAP Types:
O modo native EAP envia suas credenciais imediatamente enquanto o tunneled EAP forma primeiro um túnel criptografado e então transmite as credenciais dentro do túnel.
PEAP: Protected EAP (PEAP): foi originalmente proposto pela Microsoft e rapidamente tornou-se popular e largamente implementado. O PEAP forma um túnel criptografado entre o cliente e servidor utilizando o certificado x.509. Após a formação do túnel, o PEAP utiliza outro tipo EAP como método interno, autenticando o cliente utilizando o EAP dentro do túnel, utilizando EAP-MSCHAPv2, EAP-GTC e EAP-TLS.
EAP-FAST: Flexible Authentication via Secure Tunnel (FAST) é similar ao PEAP. Assim como o PEAP, FAST forma um túnel TLS externo e então transmite as credenciais dentro do túnel. A diferença do FAST para o PEAP é a habilidade PAC (protected access credentials). O PAC atua como um cookie seguro, armazenando localmente no host uma prova do sucesso da autenticação. Pode utilizar como EAP interno EAP-MSCHAPv2, EAP-GTC e EAP-TLS.
O modo tunneled EAP inclui o conceito de identidade inner e outer (interna e externa). A identidade inner é o dispositivo que autentica utilizando protocolo native EAP. A identidade outer é utilizado entre o suplicante e o servidor de autenticação para estabelecimento do TLS.
RotaDefault 