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 Uma Apresentação de Informação sobre WiFi da Purple Enterprise Duração aproximada: 10 minutos - - - [INTRODUÇÃO E CONTEXTO - aprox. 1 minuto] Bem-vindo à série de Informação sobre WiFi da Purple Enterprise. Sou o seu anfitrião e hoje vamos abordar um tema que se situa exatamente na interseçã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 empresarial numa cadeia de hotéis, numa rede de retalho, num estádio ou num campus do setor público, esta apresentação é para si. Vamos abordar 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 necessita para tomar uma decisão neste trimestre. Vamos a isto. - - - [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 de 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 em relação ao 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 serve de base às redes WPA2-Enterprise e WPA3-Enterprise. O problema é que o RADIUS tradicional foi concebido para uma era diferente. É executado em UDP - User Datagram Protocol - nas portas 1812 e 1813. O UDP é 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 saberá, está criptograficamente quebrado. Está quebrado há anos. O que significa isto na prática? Significa que em qualquer segmento de rede onde um atacante consiga intercetar tráfego RADIUS - e isso 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 para uma cadeia de retalho com pontos de acesso em cada loja a ligarem-se de volta 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 no RFC 6614 e atualizado pelo 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, proporcionando forward secrecy 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 ponto a ponto entre o ponto de acesso - ou um proxy RadSec - e o servidor RADIUS. Um atacante que intersete o tráfego na rede apenas vê 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 assume essa carga. 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 um roaming 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 sob a sua licença Connect, funcionando como um fornecedor de identidade dentro da federação, e o RadSec é central para o funcionamento desse tecido de roaming seguro. Do ponto de vista da conformidade, o RadSec é cada vez mais relevante para a 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 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 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 ao RadSec no seu servidor RADIUS e pontos de acesso. O FreeRADIUS 3.0 e superior suporta RadSec nativamente. O NPS da Microsoft não suporta RadSec nativamente nas versões atuais, o que é uma limitação significativa para organizações que executam infraestruturas baseadas 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 estará a encriptar o tráfego RADIUS ponto a ponto. 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 adotada - 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, 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á necessitar 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 aviso irão interromper 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 AC, e defina 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: audite antes de implementar. Mapeie cada cliente RADIUS - pontos de acesso, concentradores VPN, switches que fazem 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 TLS de todo, 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 - localizações remotas, 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 um risco menor, mas deve continuar a constar no plano. Terceiro: teste o TLS mútuo minuciosamente antes de entrar em produção. O modo de falha mais comum em implementações RadSec são erros de validação de certificados - nomes comuns incompatíveis, certificados intermédios expirados ou clientes que não confiam na AC 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 tem. Falhas de ligação TCP, tempos de 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 ser enviados para 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. 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 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 níveis variados de suporte RadSec - verifique a sua versão de firmware específica. Nos casos em que o suporte nativo está ausente, um proxy RadSec é a sua solução. "E quanto ao DTLS - RADIUS sobre DTLS?" O RFC 7360 define 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 elevado débito. "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 de ligação para pedidos de autenticação subsequentes. - [RESUMO E PRÓXIMOS PASSOS - aprox. 1 minuto] Para resumir: 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 múltiplos locais, através da internet ou em ambientes sujeitos a PCI-DSS ou GDPR - a questão não é se deve implementar RadSec, é 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 RadSec. Se utiliza FreeRADIUS, pode ter uma implementação de teste do RadSec a funcionar num dia. Se utiliza 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 de WiFi corporativo como de convidados. Se quiser compreender como o RadSec se enquadra na sua implementação específica, a equipa da Purple pode orientá-lo. Obrigado por ouvir. Até à próxima. - FIM DO GUIÃO