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

RadSec: Como o RADIUS over TLS Melhora a Segurança da Autenticação WiFi Uma Sessão de Informação de Inteligência sobre WiFi de Nível Corporativo da Purple Duração aproximada: 10 minutos - - - [INTRODUÇÃO E CONTEXTO — aprox. 1 minuto] Bem-vindo à série de Inteligência sobre WiFi da Purple para empresas. Eu sou o seu anfitrião e hoje vamos abordar um tema que se situa exatamente na intersecção entre a segurança de rede e o risco operacional: o RadSec - formalmente definido no RFC 6614 - e o motivo pelo qual deve constar no roteiro da sua infraestrutura, caso ainda não conste. Se é um gestor de TI, arquiteto de rede ou CTO responsável pelo WiFi corporativo num grupo hoteleiro, numa rede de retalho, num estádio ou num campus do setor público, esta sessão de informação é para si. Vamos abordar o que é realmente o RadSec, porque é que o protocolo RADIUS tradicional o deixa exposto, como implementar o RadSec num ambiente real e as armadilhas que costumam apanhar as equipas de surpresa. Nada de teoria pela teoria - apenas a informação de que necessita para tomar uma decisão neste trimestre. Vamos a isso. - - - [ANÁLISE TÉCNICA DETALHADA — aprox. 5 minutos] Então, comecemos pelo 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 utilizador ou dispositivo se liga ao seu WiFi corporativo ou de convidados, o ponto de acesso funciona como um cliente RADIUS, encaminhando os pedidos de autenticação para um servidor RADIUS, que valida as credenciais em relação ao seu diretório - Active Directory, LDAP ou um fornecedor de identidade na nuvem - e concede ou nega o acesso. Este é o modelo de autenticação 802.1X que serve de base às redes WPA2 e WPA3. O problema é que o RADIUS tradicional foi concebido para uma era diferente. É executado através de UDP - User Datagram Protocol - nas portas 1812 e 1813. O UDP é um protocolo sem ligação, o que significa que não há handshake, não há estado de sessão e, fundamentalmente, não há encriptação nativa. A única proteção entre o seu ponto de acesso e o seu servidor RADIUS é um segredo partilhado - essencialmente uma palavra-passe - utilizado para ofuscar a palavra-passe do utilizador em trânsito através de hashing MD5. O MD5, como a maioria de vós saberá, está criptograficamente quebrado. Está quebrado há anos. O que é que isto significa na prática? Significa que em qualquer segmento de rede onde um atacante possa intercetar o tráfego RADIUS - o que inclui comutadores comprometidos, dispositivos não autorizados na sua VLAN de gestão ou qualquer ponto entre um ponto de acesso remoto e um servidor RADIUS alojado na nuvem - este pode potencialmente capturar trocas de autenticação, tentar ataques de dicionário offline contra o segredo partilhado e, em algumas configurações, expor totalmente as credenciais do utilizador. Para um grupo hoteleiro que disponibiliza WiFi para convidados em 200 propriedades, ou uma cadeia de retalho com pontos de acesso em cada loja a ligarem-se a um servidor RADIUS central através da internet pública, este não é um risco teórico. É uma superfície de ataque real.Isto é 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, utiliza TCP na porta 2083. Em vez de um segredo partilhado e MD5, utiliza autenticação TLS mútua com certificados X.509. Tanto o cliente RADIUS como o servidor RADIUS apresentam certificados, verificam a identidade um do outro e estabelecem uma sessão encriptada antes de qualquer dado de autenticação ser trocado. O TLS 1.3 é a versão recomendada atualmente, fornecendo segredo de encaminhamento e eliminando uma série de vulnerabilidades de cifra legadas. O efeito prático é significativo. Os dados de credenciais, atributos de utilizador e tokens de sessão são encriptados de ponta a ponta entre o ponto de acesso - ou um proxy RadSec - e o servidor RADIUS. Um atacante que intersete o tráfego na rede vê apenas registos TLS encriptados. O segredo partilhado ainda está presente para compatibilidade com versões anteriores, mas já não realiza nenhum trabalho de segurança significativo - o TLS está a carregar o peso. Existe outra dimensão aqui que é cada vez mais relevante: o roaming. A federação Eduroam, utilizada por universidades e instituições de investigação em toda a Europa e não só, executa o RadSec há anos como parte da sua infraestrutura de roaming interinstitucional. Mais recentemente, o padrão OpenRoaming da Wi-Fi Alliance - que permite um roaming de WiFi contínuo em locais aderentes - exige o RadSec para todo o tráfego da federação. Se está a implementar uma infraestrutura compatível com OpenRoaming, o RadSec não é opcional; é um pré-requisito. A Purple suporta OpenRoaming ao abrigo da sua licença Purple Connect, agindo como um fornecedor de identidade dentro da federação, e o RadSec é central para o funcionamento desta rede de roaming segura. Do ponto de vista da conformidade, o RadSec é cada vez mais relevante para o PCI-DSS 4.0, que reforça os requisitos em torno da proteção de dados de autenticação em trânsito. Se a sua infraestrutura de WiFi toca em ambientes de cartões de pagamento - e no retalho e hotelaria, toca frequentemente - a lacuna de encriptação no RADIUS tradicional é uma falha prestes a ser identificada. O GDPR exige igualmente medidas técnicas adequadas para proteger os dados pessoais; as credenciais de utilizador e os metadados de sessão que fluem sem encriptação pela sua rede são difíceis de defender numa auditoria de proteção de dados. Agora vamos falar de arquitetura. Existem dois padrões principais de implementação para o RadSec. O primeiro é o suporte nativo de 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 constitui uma limitação significativa para organizações que executam infraestruturas centradas 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 ambos RadSec nativamente, este é o caminho mais limpo - configure os certificados TLS em ambas as extremidades, abra a porta TCP 2083 na sua firewall e passará a encriptar o tráfego RADIUS de ponta a ponta. O segundo padrão é um proxy RadSec. Esta é a implementaçã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 instalada - posiciona-se entre os seus pontos de acesso e o seu servidor RADIUS. Os pontos de acesso enviam RADIUS padrão sobre UDP para o proxy na rede local. O proxy termina essa ligação, reenvelopa o tráfego RADIUS dentro de um túnel TLS e encaminha-o para o servidor RADIUS a montante sobre TCP 2083. Esta abordagem permite-lhe adicionar RadSec a uma infraestrutura existente sem substituir o seu servidor RADIUS, e é particularmente útil quando o seu servidor RADIUS está alojado na cloud ou é acedido através da internet pública. A gestão de certificados é a complexidade operacional que precisa de planear. Irá precisar de uma PKI - Public Key Infrastructure - para emitir e gerir os certificados X.509 utilizados para TLS mútuo. Isso significa uma Autoridade de Certificação, emissão de certificados para cada cliente e servidor RADIUS, e um processo para rotação de certificados antes da expiração. Certificados que expirem sem serem notados irão interromper a autenticação de todos os utilizadores na sua rede em simultâneo - e esse é um cenário que deseja evitar. Automatize a renovação de certificados utilizando ACME ou a API da sua CA, e configure alertas de monitorização com bastante antecedência em relação às datas de expiração. --- [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS - aprox. 2 minutos] Deixe-me dar-lhe as recomendações práticas. Primeiro: faça uma auditoria antes de implementar. Mapeie cada cliente RADIUS - pontos de acesso, concentradores VPN, switches que utilizam 802.1X - e cada servidor RADIUS no seu ambiente. Perceba quais suportam RadSec nativamente e quais precisarão de um proxy. Esta auditoria normalmente revela dispositivos legados que não suportam de todo TLS, e esses precisam de estar no seu plano de substituição. Segundo: comece com o tráfego de maior risco. Se tem tráfego RADIUS a atravessar a internet pública - locais remotos, RADIUS alojado na cloud, grupos de hotéis com várias propriedades - essa é a sua primeira prioridade. O tráfego RADIUS local numa VLAN de gestão bem segmentada apresenta menor risco, mas deve continuar a constar no seu plano de evolução. Terceiro: teste o TLS mútuo exaustivamente antes do lançamento. O modo de falha mais comum em implementações RadSec são os erros de validação de certificados - Common Names incompatíveis, certificados intermediários expirados ou clientes que não confiam na CA que assinou o certificado do servidor. Utilize openssl s_client para testar os handshakes TLS antes de transferir o tráfego de produção. Quarto: não descure a monitorização. O RadSec adiciona uma camada de ligação TCP que o RADIUS tradicional não possui. Falhas de ligação TCP, tempos limite de handshake TLS e erros de certificado manifestar-se-ão como falhas de autenticação para os seus utilizadores. Certifique-se de que os registos do seu servidor RADIUS e os registos do seu proxy estão a alimentar o seu SIEM ou plataforma de monitorização, para que consiga distinguir um problema de conectividade RadSec de um problema de política de autenticação. O erro que vejo com mais frequência é as organizações implementarem RadSec no lado do servidor, mas esquecerem-se de atualizar as regras de firewall. A porta TCP 2083 precisa de estar aberta entre cada cliente RADIUS e o servidor ou proxy RADIUS. Se está habituado a gerir regras UDP 1812, a porta TCP 2083 pode passar despercebida no processo de alteração da firewall. - [PERGUNTAS E RESPOSTAS RÁPIDAS - aprox. 1 minuto] Vou responder rapidamente a algumas perguntas que oiç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 do cliente e o ponto de acesso. Operam em camadas diferentes e são complementares. "O RadSec é suportado por todos os fabricantes de pontos de acesso?" Não universalmente. Cisco, Aruba, Ruckus e Meraki têm todos níveis variados de suporte RadSec - verifique a 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 over DTLS?" O RFC 7360 define RADIUS over DTLS, que utiliza UDP em vez de TCP, preservando algumas das características sem ligação do RADIUS tradicional enquanto adiciona encriptação. É menos implementado do que o RadSec sobre TLS, mas vale a pena avaliar se a latência for uma preocupação em ambientes de elevado rendimento. "Como é que isto afeta o desempenho do roaming?" A ligação TCP do RadSec é persistente, o que pode realmente melhorar o desempenho do roaming em ambientes federados, reduzindo a sobrecarga de configuração da ligação para pedidos de autenticação subsequentes. - [RESUMO E PRÓXIMOS PASSOS - aprox. 1 minuto] Para concluir: o RadSec é a resposta madura e baseada em normas para uma lacuna de segurança real no RADIUS tradicional. Se gere WiFi empresarial em escala - em vários locais, através da Internet ou em ambientes sujeitos a PCI DSS ou GDPR - a questão não é se deve implementar o RadSec, mas sim quando e como. Os seus próximos passos: faça uma auditoria à sua infraestrutura RADIUS esta semana. Identifique os 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 RadSec nativo. Se estiver a utilizar FreeRADIUS, pode ter uma implementação RadSec de teste a funcionar num 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 concebida para se integrar com a infraestrutura RADIUS empresarial, suportando fluxos de autenticação seguros tanto para ambientes WiFi corporativos como de convidados. Se quiser compreender como o RadSec se enquadra na sua implementação específica, a equipa da Purple pode orientá-lo no processo. Obrigado por ouvir. Até à próxima. - FIM DO GUIÃO