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

RadSec: Como o RADIUS sobre TLS Melhora a Segurança da Autenticação WiFi Um Informativo de Inteligência em WiFi para Grandes Empresas da Purple Tempo estimado de leitura: 10 minutos --- [INTRODUÇÃO E CONTEXTO - aprox. 1 minuto] Boas-vindas à série de Inteligência em WiFi para Grandes Empresas da Purple. Sou o seu anfitrião e hoje abordaremos um tópico que está no cruzamento exato entre segurança de rede e risco operacional: RadSec - formalmente definido no RFC 6614 - e por que ele deve estar em seu planejamento de infraestrutura se ainda não estiver. Se você é gerente de TI, arquiteto de rede ou CTO responsável pelo WiFi corporativo de uma rede de hotéis, de um complexo de varejo, de um estádio ou de um campus do setor público, este informativo é para você. Vamos explicar o que o RadSec realmente é, por que o protocolo RADIUS tradicional deixa você exposto, como implantar o RadSec em um ambiente real e as armadilhas que costumam prejudicar as equipes. Sem teoria apenas por teoria - apenas as informações que você precisa para tomar uma decisão neste trimestre. Vamos começar. --- [ANÁLISE TÉCNICA DETALHADA - 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 WiFi corporativa 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 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 na nuvem - e concede ou nega o acesso. Esse é o modelo de autenticação 802.1X que serve de base para as redes WPA2 e WPA3. 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 é um protocolo sem conexão, o que significa que não há handshake, não há estado de sessão e, o mais importante, não há criptografia nativa. A única proteção entre o seu ponto de acesso e o servidor RADIUS é um segredo compartilhado - basicamente 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 - ele pode 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 uma rede de hotéis que oferece WiFi para visitantes em 200 propriedades, ou uma rede de varejo com pontos de acesso em cada loja direcionando o 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 recomendada atualmente, 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 verá 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á assumindo 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 na Europa e fora dela, 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 de WiFi contínuo em locais participantes - exige o RadSec para todo o tráfego da federação. Se você estiver implantando uma infraestrutura compatível com OpenRoaming, o RadSec não é opcional; é um pré-requisito. O Purple suporta o 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 sobre a 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 hotelaria, isso acontece com frequência - a lacuna de criptografia no RADIUS tradicional é um problema prestes a acontecer. O GDPR exige de forma semelhante medidas técnicas adequadas para proteger dados pessoais; credenciais de usuário e metadados de sessão trafegando sem criptografia em 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 em seu servidor RADIUS e pontos de acesso. O FreeRADIUS 3.0 e superior suporta o RadSec nativamente. O Microsoft NPS não suporta o RadSec nativamente 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 o 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. Esta é 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 - 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 sobre 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 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ê quer evitar. Automatize a renovação de certificados usando ACME ou a API da sua AC, e configure alertas de monitoramento bem antes das datas de expiração. --- [RECOMENDAÇÕES DE IMPLANTAÇÃ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 VPN, switches fazendo 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 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 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 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 AC 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, limites de tempo 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 implantando 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 responder rapidamente a 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 sua versão específica de firmware. Onde o suporte nativo está 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 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 inclusive melhorar o desempenho de 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 corporativa 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 em 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 do ponto de acesso para suporte nativo ao RadSec. Se você estiver executando o FreeRADIUS, poderá ter uma implantação de teste do RadSec funcionando em um dia. Se 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 com a infraestrutura RADIUS corporativa, suportando fluxos de autenticação seguros para ambientes de WiFi corporativo e de convidados. Se você 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