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

RadSec: Como o RADIUS sobre TLS Melhora a Segurança da Autenticação WiFi Um Briefing de Inteligência em WiFi Empresarial da Purple Tempo de execução aproximado: 10 minutos --- [INTRODUÇÃO & CONTEXTO — aprox. 1 minuto] Bem-vindo à série de Inteligência em WiFi Empresarial da Purple. Sou o vosso anfitrião e hoje vamos abordar um tema que se situa precisamente na interseção da segurança de rede e do risco operacional: o RadSec — formalmente definido na RFC 6614 — e por que razão deve constar no vosso roteiro de infraestrutura, caso ainda não conste. Se é um gestor de TI, arquiteto de rede ou CTO responsável pelo WiFi empresarial de um grupo hoteleiro, de uma rede de retalho, de um estádio ou de um campus do setor público, este briefing é para si. Vamos cobrir o que é realmente o RadSec, por que razão o protocolo RADIUS tradicional o deixa exposto, como implementar o RadSec num ambiente real e as armadilhas que costumam surpreender as equipas. Sem teoria apenas por teoria — apenas a informação de que precisa para tomar uma decisão este 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 empresarial desde a década de 1990. Quando um utilizador ou dispositivo se liga ao seu WiFi corporativo ou de convidados, o ponto de acesso atua como um cliente RADIUS, encaminhando os pedidos de autenticação para um servidor RADIUS, que valida as credenciais no seu diretório — Active Directory, LDAP ou um fornecedor de identidade na nuvem — e concede ou recusa 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 concebido para uma era diferente. É executado sobre UDP — User Datagram Protocol — nas portas 1812 and 1813. O UDP é sem ligação, o que significa que não há handshake, não há estado de sessão e, crucialmente, 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 utilizando 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 — e isso inclui switches 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 — eles podem 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 enviar dados para um servidor RADIUS central através da internet pública, este não é um risco teórico. É uma superfície de ataque ativa. É exatamente isto que o RadSec resolve. O RadSec — definido na RFC 6614 e atualizado pela RFC 7360 — encapsula 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 atualmente recomendada, fornecendo segredo de encaminhamento e eliminando uma série de vulnerabilidades de cifras 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 intercete o tráfego no cabo vê apenas registos TLS encriptados. O segredo partilhado ainda está presente para compatibilidade retroativa, mas já não realiza qualquer trabalho de segurança significativo — o TLS encarrega-se disso. Há 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ó, utiliza RadSec há anos como parte da sua infraestrutura de roaming interinstitucional. Mais recentemente, o padrão OpenRoaming da Wi-Fi Alliance — que permite o roaming WiFi contínuo em locais participantes — exige o RadSec para todo o tráfego da federação. Se está a implementar infraestrutura compatível com OpenRoaming, o RadSec não é opcional; é um pré-requisito. A Purple suporta o OpenRoaming sob a sua licença Connect, atuando como um fornecedor de identidade dentro da federação, e o RadSec é central para o funcionamento dessa estrutura de roaming seguro. Do ponto de vista da conformidade, o RadSec é cada vez mais relevante para o PCI DSS 4.0, que aperta os requisitos em torno da proteção de dados de autenticação em trânsito. Se a sua infraestrutura WiFi toca em ambientes de cartões de pagamento — e no retalho e hotelaria, isso acontece frequentemente —, a lacuna de encriptação no RADIUS tradicional é uma falha à espera de ser detetada. O GDPR exige igualmente medidas técnicas adequadas para proteger os dados pessoais; credenciais de utilizador e metadados de sessão a fluir 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 a 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 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 RadSec nativamente, este é o caminho mais limpo — configure certificados TLS em ambas as extremidades, abra a porta TCP 2083 na sua firewall e estará 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 infraestruturas RADIUS legadas ou ambientes de vários fabricantes. Um proxy RadSec — o radsecproxy é a implementação de código aberto mais amplamente utilizada — situa-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, volta a encapsular 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, sendo particularmente útil quando o seu servidor RADIUS está alojado na nuvem 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 o 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 que ninguém note irão quebrar a autenticação de todos os utilizadores na sua rede em simultâneo — e esse é um cenário que vai querer 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 & ARMADILHAS — aprox. 2 minutos] Deixe-me dar-lhe as recomendações práticas. Primeiro: audite antes de implementar. Mapeie cada cliente RADIUS — pontos de acesso, concentradores VPN, switches a fazer 802.1X — e cada servidor RADIUS no seu ambiente. Compreenda quais suportam RadSec nativamente e quais precisarão de um proxy. Esta auditoria normalmente revela dispositivos legados que não suportam TLS de todo, e esses devem constar no seu plano de substituição. Segundo: comece pelo tráfego de maior risco. Se tem tráfego RADIUS a atravessar a internet pública — locais remotos, RADIUS alojado na nuvem, grupos hoteleiros 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 ainda assim constar no plano de trabalhos. Terceiro: teste o TLS mútuo exaustivamente antes de entrar em produção. O modo de falha mais comum em implementações RadSec são os erros de validação de certificados — Common Names incompatíveis, certificados intermédios expirados ou clientes que não confiam na CA que assinou o certificado do servidor. Utilize o comando openssl s_client para testar os handshakes TLS antes de migrar 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 tem. Falhas de ligação TCP, tempos limite de handshake TLS e erros de certificado irão manifestar-se 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 possa distinguir um problema de conectividade RadSec de um problema de política de autenticação. A armadilha que vejo com mais frequência são as organizações que implementam o RadSec no lado do servidor mas se esquecem de atualizar as suas 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 facilmente ser esquecida no processo de alteração da firewall. --- [PERGUNTAS E RESPOSTAS RÁPIDAS — aprox. 1 minuto] Deixe-me passar por 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. A Cisco, Aruba, Ruckus e Meraki têm todos níveis variados de suporte a 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 sobre DTLS?" A RFC 7360 define o RADIUS sobre DTLS, que utiliza UDP em vez de TCP, preservando algumas das características sem ligação do RADIUS tradicional ao mesmo tempo que adiciona encriptação. É 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 é que isto afeta o desempenho do roaming?" A ligação TCP do RadSec é persistente, o que pode, na verdade, melhorar o desempenho do roaming em ambientes federados, reduzindo a sobrecarga de estabelecimento de ligação para pedidos de autenticação subsequentes. --- [RESUMO & PRÓXIMOS PASSOS — aprox. 1 minuto] Para concluir: o RadSec é a resposta madura e baseada em padrões para uma lacuna de segurança real no RADIUS tradicional. Se gere WiFi empresarial em grande 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: audite a sua infraestrutura RADIUS esta semana. Identifique os seus fluxos de tráfego de maior risco. Verifique a documentação do seu servidor RADIUS e do fabricante do ponto de acesso para suporte nativo a RadSec. Se utiliza o FreeRADIUS, pode ter uma implementação de teste do RadSec a funcionar num dia. Se utiliza 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 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 nos ouvir. Até à próxima. --- FIM DO GUIÃO