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

RadSec: Como o RADIUS over TLS melhora a segurança da autenticação WiFi Um boletim de inteligência em WiFi corporativo da Purple Tempo estimado de leitura: 10 minutos - - - [INTRODUÇÃO E CONTEXTO - aprox. 1 minuto] Bem-vindo à série de Inteligência em WiFi corporativo da Purple. Sou o seu anfitrião e hoje abordaremos um tema que se encontra exatamente na intersecção entre a segurança de rede e o risco operacional: o RadSec - formalmente definido no RFC 6614 - e por que ele deve estar no planejamento da sua 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 boletim é para você. Vamos cobrir 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 comuns que pegam as equipes de surpresa. Sem teoria apenas por teoria - apenas a informação necessária para você tomar uma decisão neste trimestre. Vamos começar. - - - [IMERSÃO TÉCNICA - 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 age como um cliente RADIUS, encaminhando as solicitações de autenticação para um servidor RADIUS, que valida as credenciais em relação ao 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 serve de base para 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 é orientado a não conexão, o que significa que não há handshake, não há estado de sessão e, o mais crítico, não há criptografia nativa. A única proteção entre seu ponto de acesso e 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 invasores na sua VLAN de gerenciamento ou qualquer ponto entre um ponto de acesso remoto e um servidor RADIUS hospedado na nuvem - eles podem potencialmente capturar as 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 todas as lojas enviando tráfego 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 real.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 atual recomendada, fornecendo sigilo de encaminhamento e eliminando uma série de vulnerabilidades de criptografia 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 vê apenas registros TLS criptografados. O segredo compartilhado ainda está presente para compatibilidade com versões anteriores, mas não está mais realizando nenhum trabalho de segurança significativo - o TLS está carregando o fardo. Há outra dimensão aqui que é cada vez mais relevante: roaming. A federação Eduroam, usada por universidades e instituições de pesquisa em toda a Europa e além, executa o RadSec há anos como parte de sua infraestrutura de roaming interinstitucional. Mais recentemente, o padrão OpenRoaming da Wi-Fi Alliance - que permite roaming WiFi contínuo em locais participantes - exige 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 WiFi toca ambientes de cartões de pagamento - e no varejo e na hospitalidade, isso acontece com frequéncia - a lacuna de criptografia no RADIUS tradicional é uma falha prestes a ser descoberta. Da mesma forma, a GDPR exige medidas técnicas adequadas para proteger dados pessoais; credenciais de usuário e metadados de sessão fluindo sem criptografia pela sua rede são difíceis de defender em uma auditoria de proteção de dados. Agora vamos falar de arquitetura. Existem dois padrões de implantação principais para o RadSec. O primeiro é o suporte nativo ao RadSec em seu servidor RADIUS e pontos de acesso. O FreeRADIUS 3.0 e superior oferece suporte nativo ao RadSec. O Microsoft NPS não oferece suporte nativo ao RadSec nas versões atuais, o que é uma restriçã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 fabricante do seu ponto de acesso suportarem RadSec nativamente, este é o caminho mais limpo - configure certificados TLS em ambas as pontas, abra a porta TCP 2083 em 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, encapsula novamente o tráfego RADIUS dentro de um túnel TLS e o encaminha para o servidor RADIUS de upstream através da porta 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 para a qual você precisa se planejar. Você precisará de uma PKI - Public Key Infrastructure - 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 da expiração. Certificados que expiram sem serem notados interromperão a autenticação de todos os usuários em 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 Autoridade Certificadora, e configure alertas de monitoramento bem antes das datas de expiração. --- [RECOMENDAÇÕES DE IMPLANTAÇÃO E ARMADILHAS - aprox. 2 minutos] Deixe-me apresentar 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 oferecem suporte nativo ao RadSec 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 em 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 hoteleiros 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 minuciosamente antes do início da 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 Autoridade Certificadora 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 na conexão TCP, limites de tempo de handshake TLS excedidos 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 organizações implementando 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 porta TCP 2083 pode passar despercebida no processo de alteração do firewall. - [PERGUNTAS E RESPOSTAS RÁPIDAS - aprox. 1 minuto] Deixe-me passar por algumas perguntas que ouço regularmente. "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 fornecedores de pontos de acesso?" Não universalmente. Cisco, Aruba, Ruckus e Meraki têm níveis variados de suporte ao RadSec - verifique sua versão específica de 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 implantado 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 de roaming?" A conexão TCP do RadSec é persistente, o que pode realmente 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 encerrar: 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 a PCI-DSS ou GDPR - a questão não é se deve implantar 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 fornecedor do seu servidor RADIUS e dos pontos de acesso para ver se há suporte nativo ao RadSec. Se você estiver executando o FreeRADIUS, poderá ter uma implantação de teste do RadSec funcionando em um dia. Se você estiver no 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 empresarial, oferecendo suporte a fluxos de autenticação seguros para ambientes de WiFi corporativo e de visitantes. Se quiser entender como o RadSec se adapta à sua implantação específica, a equipe da Purple pode orientar você. Obrigado por ouvir. Até a próxima. - FIM DO ROTEIRO