RadSec: Como o RADIUS over TLS Melhora a Segurança da Autenticação WiFi

RadSec: Como o RADIUS sobre TLS Melhora a Segurança de Autenticação WiFi Um Informativo de Inteligência de WiFi Corporativo da Purple Tempo aproximado de leitura: 10 minutos --- [INTRODUÇÃO & CONTEXTO — aprox. 1 minuto] Bem-vindo à série de Inteligência de WiFi Corporativo da Purple. Eu sou o seu anfitrião e hoje vamos abordar um tema que está exatamente na interseção entre segurança de rede e risco operacional: o RadSec — formalmente definido na RFC 6614 — e por que ele deve estar no seu planejamento de infraestrutura se ainda não estiver. Se você é um gerente de TI, arquiteto de rede ou CTO responsável pelo WiFi corporativo de um grupo hoteleiro, uma rede de varejo, um estádio ou um campus do setor público, este informativo é para você. Vamos abordar o que realmente é o RadSec, por que o protocolo RADIUS tradicional deixa você exposto, como implantar o RadSec em um ambiente real e as armadilhas que costumam pegar as equipes de surpresa. Sem teoria pela teoria — apenas as informações de que você precisa para tomar uma decisão neste trimestre. Vamos começar. --- [APROFUNDAMENTO TÉCNICO — aprox. 5 minutos] Então, vamos começar com o problema. O RADIUS — Remote Authentication Dial-In User Service — tem sido a espinha dorsal da autenticação de WiFi corporativo desde a década de 1990. Quando um usuário ou dispositivo se conecta ao seu WiFi corporativo ou de visitantes, o ponto de acesso atua como um cliente RADIUS, encaminhando as solicitações de autenticação para um servidor RADIUS, que valida as credenciais em seu diretório — Active Directory, LDAP ou um provedor de identidade em nuvem — e concede ou nega o acesso. Este é o modelo de autenticação 802.1X que sustenta as redes WPA2-Enterprise e WPA3-Enterprise. O problema é que o RADIUS tradicional foi projetado para uma era diferente. Ele roda sobre UDP — User Datagram Protocol — nas portas 1812 e 1813. O UDP é sem conexão, o que significa que não há handshake, não há estado de sessão e, fundamentalmente, não há criptografia nativa. A única proteção entre o seu ponto de acesso e o seu servidor RADIUS é um segredo compartilhado — essencialmente uma senha — usado para ofuscar a senha do usuário em trânsito usando hash MD5. O MD5, como a maioria de vocês sabe, está criptograficamente quebrado. Está quebrado há anos. O que isso significa na prática? Significa que em qualquer segmento de rede onde um invasor possa interceptar o tráfego RADIUS — e isso inclui switches comprometidos, dispositivos não autorizados na sua VLAN de gerenciamento ou qualquer ponto entre um ponto de acesso remoto e um servidor RADIUS hospedado na nuvem — ele pode potencialmente capturar trocas de autenticação, tentar ataques de dicionário offline contra o segredo compartilhado e, em algumas configurações, expor totalmente as credenciais do usuário. Para um grupo hoteleiro que opera WiFi de visitantes em 200 propriedades, ou uma rede de varejo com pontos de acesso em cada loja enviando dados de volta para um servidor RADIUS central através da internet pública, este não é um risco teórico. É uma superfície de ataque ativa. Isso é exatamente o que o RadSec resolve. O RadSec — definido na RFC 6614 e atualizado pela RFC 7360 — envolve o tráfego RADIUS dentro de um túnel TLS. Em vez de UDP, ele usa TCP na porta 2083. Em vez de um segredo compartilhado e MD5, ele usa autenticação TLS mútua com certificados X.509. Tanto o cliente RADIUS quanto o servidor RADIUS apresentam certificados, verificam a identidade um do outro e estabelecem uma sessão criptografada antes que qualquer dado de autenticação seja trocado. O TLS 1.3 é a versão recomendada atualmente, fornecendo sigilo de encaminhamento (forward secrecy) e eliminando uma série de vulnerabilidades de cifras legadas. O efeito prático é significativo. Dados de credenciais, atributos de usuário e tokens de sessão são criptografados de ponta a ponta entre o ponto de acesso — ou um proxy RadSec — e o servidor RADIUS. Um invasor que intercepte o tráfego na rede verá apenas registros TLS criptografados. O segredo compartilhado ainda está presente para compatibilidade com versões anteriores, mas não realiza mais nenhum trabalho de segurança significativo — o TLS está encarregado de toda a carga. Há outra dimensão aqui que é cada vez mais relevante: o roaming. A federação Eduroam, usada por universidades e instituições de pesquisa em toda a Europa e além, opera com RadSec há anos como parte de sua infraestrutura de roaming interinstitucional. Mais recentemente, o padrão OpenRoaming da Wi-Fi Alliance — que permite roaming de WiFi contínuo em locais participantes — exige o RadSec para todo o tráfego da federação. Se você está implantando uma infraestrutura compatível com OpenRoaming, o RadSec não é opcional; é um pré-requisito. A Purple oferece suporte ao OpenRoaming sob sua licença Connect, atuando como um provedor de identidade dentro da federação, e o RadSec é central para o funcionamento dessa estrutura de roaming seguro. Do ponto de vista de conformidade, o RadSec é cada vez mais relevante para o PCI DSS 4.0, que endurece os requisitos em torno da proteção de dados de autenticação em trânsito. Se a sua infraestrutura de WiFi toca ambientes de cartões de pagamento — e no varejo e na hotelaria, isso acontece com frequência —, a lacuna de criptografia no RADIUS tradicional é uma vulnerabilidade prestes a ser descoberta. O GDPR exige de forma semelhante medidas técnicas apropriadas para proteger dados pessoais; credenciais de usuário e metadados de sessão trafegando sem criptografia pela sua rede são difíceis de defender em uma auditoria de proteção de dados. Agora vamos falar sobre arquitetura. Existem dois padrões principais de implantação para o RadSec. O primeiro é o suporte nativo ao RadSec no seu servidor RADIUS e pontos de acesso. O FreeRADIUS 3.0 e superior suporta RadSec nativamente. O Microsoft NPS não suporta RadSec nativamente nas versões atuais, o que é uma limitação significativa para organizações que executam infraestrutura centrada em Windows. O Cisco ISE suporta RadSec. O Aruba ClearPass suporta RadSec. Se o seu servidor RADIUS e o fornecedor do seu ponto de acesso suportam RadSec nativamente, este é o caminho mais limpo — configure certificados TLS em ambas as extremidades, abra a porta TCP 2083 no seu firewall e você estará criptografando o tráfego RADIUS de ponta a ponta. O segundo padrão é um proxy RadSec. Essa é a implantação mais comum na prática, particularmente para organizações com infraestrutura RADIUS legada ou ambientes de múltiplos fornecedores. Um proxy RadSec — o radsecproxy é a implementação de código aberto mais amplamente implantada — fica entre seus pontos de acesso e seu servidor RADIUS. Os pontos de acesso enviam RADIUS padrão sobre UDP para o proxy na rede local. O proxy encerra essa conexão, reencapsula o tráfego RADIUS dentro de um túnel TLS e o encaminha para o servidor RADIUS upstream via TCP 2083. Essa abordagem permite adicionar RadSec a uma infraestrutura existente sem substituir seu servidor RADIUS, e é particularmente útil quando seu servidor RADIUS está hospedado na nuvem ou é acessado pela internet pública. A gestão de certificados é a complexidade operacional que você precisa planejar. Você precisará de uma PKI — Infraestrutura de Chaves Públicas — para emitir e gerenciar os certificados X.509 usados para TLS mútuo. Isso significa uma Autoridade Certificadora, emissão de certificados para cada cliente e servidor RADIUS, e um processo para rotação de certificados antes do vencimento. Certificados que expiram sem que ninguém perceba interromperão a autenticação de todos os usuários da sua rede simultaneamente — e esse é um cenário que você deseja evitar. Automatize a renovação de certificados usando ACME ou a API da sua CA, e configure alertas de monitoramento bem antes das datas de expiração. --- [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ARMADILHAS — aprox. 2 minutos] Deixe-me dar as recomendações práticas. Primeiro: faça uma auditoria antes de implantar. Mapeie cada cliente RADIUS — pontos de acesso, concentradores de VPN, switches executando 802.1X — e cada servidor RADIUS em seu ambiente. Entenda quais deles suportam RadSec nativamente e quais precisarão de um proxy. Essa auditoria normalmente revela dispositivos legados que não suportam TLS de forma alguma, e esses precisam estar no seu cronograma de substituição. Segundo: comece com o tráfego de maior risco. Se você tem tráfego RADIUS atravessando a internet pública — sites remotos, RADIUS hospedado na nuvem, grupos de hotéis com várias propriedades —, essa é sua primeira prioridade. O tráfego RADIUS local em uma VLAN de gerenciamento bem segmentada apresenta menor risco, mas ainda deve estar no cronograma. Terceiro: teste o TLS mútuo exaustivamente antes de entrar em operação. O modo de falha mais comum em implantações RadSec são os erros de validação de certificado — Common Names incompatíveis, certificados intermediários expirados ou clientes que não confiam na CA que assinou o certificado do servidor. Use openssl s_client para testar os handshakes TLS antes de migrar o tráfego de produção. Quarto: não negligencie o monitoramento. O RadSec adiciona uma camada de conexão TCP que o RADIUS tradicional não possui. Falhas de conexão TCP, timeouts de handshake TLS e erros de certificado se manifestarão como falhas de autenticação para seus usuários. Certifique-se de que os logs do seu servidor RADIUS e os logs do seu proxy estejam sendo enviados para o seu SIEM ou plataforma de monitoramento para que você possa distinguir um problema de conectividade RadSec de um problema de política de autenticação. O erro que vejo com mais frequência são as organizações implementando o RadSec no lado do servidor, mas esquecendo de atualizar suas regras de firewall. A porta TCP 2083 precisa estar aberta entre cada cliente RADIUS e o servidor ou proxy RADIUS. Se você está acostumado a gerenciar regras UDP 1812, a TCP 2083 pode passar despercebida no processo de alteração do firewall. --- [PERGUNTAS E RESPOSTAS RÁPIDAS — aprox. 1 minuto] Vou passar rapidamente por algumas perguntas que ouço com frequência. "O RadSec substitui o 802.1X?" Não. O RadSec protege a camada de transporte entre o ponto de acesso e o servidor RADIUS. O 802.1X é a estrutura de autenticação entre o dispositivo cliente e o ponto de acesso. Eles operam em camadas diferentes e são complementares. "O RadSec é compatível com todos os fabricantes de pontos de acesso?" Não universalmente. Cisco, Aruba, Ruckus e Meraki têm níveis variados de suporte ao RadSec — verifique a versão específica do seu firmware. Onde o suporte nativo estiver ausente, um proxy RadSec é a sua solução. "E quanto ao DTLS — RADIUS sobre DTLS?" A RFC 7360 define o RADIUS sobre DTLS, que usa UDP em vez de TCP, preservando algumas das características sem conexão do RADIUS tradicional enquanto adiciona criptografia. Ele é menos amplamente implementado do que o RadSec sobre TLS, mas vale a pena avaliar se a latência for uma preocupação em ambientes de alto rendimento. "Como isso afeta o desempenho do roaming?" A conexão TCP do RadSec é persistente, o que pode, na verdade, melhorar o desempenho do roaming em ambientes federados, reduzindo a sobrecarga de configuração de conexão para solicitações de autenticação subsequentes. --- [RESUMO E PRÓXIMOS PASSOS — aprox. 1 minuto] Para resumir: o RadSec é a resposta madura e baseada em padrões para uma lacuna de segurança real no RADIUS tradicional. Se você opera WiFi corporativo em escala — em vários locais, pela internet ou em ambientes sujeitos ao PCI DSS ou GDPR — a questão não é se deve implementar o RadSec, mas sim quando e como. Seus próximos passos: faça uma auditoria na sua infraestrutura RADIUS esta semana. Identifique seus fluxos de tráfego de maior risco. Verifique a documentação do fabricante do seu servidor RADIUS e dos pontos de acesso para suporte nativo ao RadSec. Se você usa FreeRADIUS, pode ter uma implementação de teste do RadSec rodando em um dia. Se você usa o Microsoft NPS, comece a avaliar um proxy ou um caminho de migração para um servidor compatível com RadSec. A plataforma da Purple foi projetada para se integrar à infraestrutura RADIUS corporativa, suportando fluxos de autenticação seguros para ambientes de WiFi corporativo e de visitantes. Se você quiser entender como o RadSec se adapta à sua implementação específica, a equipe da Purple pode orientá-lo. Obrigado por ouvir. Até a próxima. --- FIM DO ROTEIRO