RadSec: Protegendo o Tráfego de Autenticação RADIUS com TLS

RadSec: Proteger o Tráfego de Autenticação RADIUS com TLS. Um Briefing Técnico da Purple. Introdução e Contexto. Bem-vindo a este briefing técnico da Purple. Vou orientá-lo sobre o RadSec — RADIUS sobre TLS — o que é, por que razão é importante neste momento e como o implementar na prática. Este briefing destina-se especificamente a arquitetos de rede e engenheiros de segurança que já utilizam RADIUS na nuvem ou que planeiam migrar para lá. Se ainda utiliza servidores RADIUS locais com UDP e um segredo partilhado, este briefing é para si. Vamos enquadrar o cenário. O RADIUS tem sido a espinha dorsal da autenticação de rede há mais de trinta anos. Sustenta o 802.1X, WPA2-Enterprise, WPA3-Enterprise e praticamente todos os sistemas de Captive Portal em produção atualmente. O protocolo em si, definido no RFC 2865, foi concebido numa era em que a internet era um local muito diferente. O tráfego de autenticação entre os seus dispositivos NAS — os seus pontos de acesso, switches e controladores — e o seu servidor RADIUS viajava através de UDP, porta 1812 para autenticação, porta 1813 para contabilidade (accounting). E esse tráfego? Em grande parte não encriptado. A única proteção era um segredo partilhado utilizado para ofuscar o atributo da palavra-passe do utilizador, e mesmo esse tem fraquezas amplamente documentadas. Durante anos, isto foi aceitável porque o tráfego RADIUS permanecia em redes privadas e controladas. Os seus dispositivos NAS e o seu servidor RADIUS estavam na mesma LAN ou ligados através de um circuito MPLS dedicado. A superfície de ataque era gerível. Mas o mundo mudou. A infraestrutura nativa da nuvem, as implementações em locais distribuídos, as sobreposições de SD-WAN e a transição para serviços RADIUS na nuvem alteraram fundamentalmente o modelo de ameaças. O seu tráfego de autenticação atravessa agora a internet pública ou, na melhor das hipóteses, uma infraestrutura partilhada que não controla totalmente. É aí que entra o RadSec. Mergulho Técnico Profundo. O RadSec, formalmente definido no RFC 6614, é RADIUS sobre TLS. O conceito é simples: em vez de enviar pacotes RADIUS através de UDP, encapsula-os dentro de uma ligação TLS sobre TCP. O resultado é que todo o tráfego de autenticação e contabilidade entre o seu NAS e o seu servidor RADIUS é totalmente encriptado, mutuamente autenticado e protegido na sua integridade. O RFC 7360 estende isto ao DTLS — Datagram TLS sobre UDP — que preserva algumas das características de latência do transporte UDP original, ao mesmo tempo que adiciona encriptação. Para a maioria das implementações empresariais, o TLS sobre TCP é a escolha certa. Vale a pena considerar o DTLS em ambientes de elevado rendimento e sensíveis à latência, como grandes implementações em estádios. Vamos falar sobre a mecânica. O RadSec opera na porta TCP 2083, que é a porta atribuída pela IANA para este protocolo. Quando um dispositivo NAS inicia uma ligação RadSec, abre uma ligação TCP para o servidor RADIUS na porta 2083 e realiza um handshake TLS. Este handshake é mútuo — tanto o cliente, que é o seu NAS, como o servidor apresentam certificados X.509. O certificado do servidor é validado contra uma CA fidedigna. O certificado do cliente identifica o NAS perante o servidor RADIUS. Assim que a sessão TLS é estabelecida, os pacotes RADIUS fluem dentro desse túnel encriptado exatamente como fariam sobre UDP, mas agora com total confidencialidade, integridade e proteção contra ataques de repetição. Isto representa um desvio significativo em relação ao RADIUS tradicional em três aspetos importantes. Primeiro, o transporte é TCP, não UDP. Isto significa que obtém uma entrega fiável e ordenada. Os pacotes perdidos são retransmitidos automaticamente. Segundo, a autenticação de ambos os endpoints é baseada em certificados, não em segredos partilhados. Isto elimina toda uma classe de ataques baseados em segredos partilhados fracos ou comprometidos. Terceiro, todo o pacote RADIUS é encriptado, não apenas o atributo de palavra-passe. Isso significa que os nomes de utilizador, identificadores de sessão e todos os atributos RADIUS estão protegidos em trânsito. Do ponto de vista da gestão de certificados, precisa de uma PKI — uma Infraestrutura de Chaves Públicas — para emitir e gerir certificados tanto para o seu servidor RADIUS como para os seus dispositivos NAS. Na prática, a maioria dos fornecedores de RADIUS na nuvem, incluindo a infraestrutura de autenticação nativa na nuvem da Purple, trata da gestão de certificados do lado do servidor por si. A sua responsabilidade é o aprovisionamento de certificados de cliente para os seus dispositivos NAS. Para implementações em grande escala, isto é normalmente gerido através da sua plataforma de gestão de rede ou de um sistema de gestão de certificados dedicado. Os certificados devem utilizar RSA de 2048 bits ou ECDSA P-256 como requisito mínimo, com um período de validade que equilibre a sobrecarga operacional com a higiene de segurança — doze meses é um valor padrão razoável. Agora, vamos abordar a comparação com a abordagem alternativa que muitas organizações utilizam hoje: túneis IPsec ou sobreposições de VPN para proteger o tráfego RADIUS. O IPsec é uma abordagem perfeitamente válida, mas opera numa camada diferente. Está a encriptar todo o tráfego entre dois endpoints, o que adiciona complexidade — precisa de gerir IKE, chaves pré-partilhadas ou certificados para o próprio túnel, e a sobrecarga operacional de manter o estado do túnel em potencialmente centenas de locais. O RadSec é mais cirúrgico. Encripta especificamente o tráfego do protocolo RADIUS, opera na camada de aplicação e integra-se diretamente com a sua infraestrutura RADIUS. Para implementações de RADIUS na nuvem onde está a ligar muitos dispositivos NAS em locais distribuídos a um servidor centralizado na nuvem, o RadSec é arquitetonicamente mais limpo e operacionalmente mais simples. Deixe-me explicar como funciona uma implementação multi-site na prática. Tem um servidor RADIUS na cloud — digamos que é a plataforma da Purple — com um certificado TLS válido de uma CA fidedigna. Tem três tipos de espaços: um hotel, uma loja de retalho e um centro de conferências. Cada um tem dispositivos NAS — pontos de acesso, switches ou controladores de LAN sem fios. Cada dispositivo NAS precisa de ser configurado com o endereço do servidor RadSec, porta 2083, e um certificado de cliente. O NAS inicia a ligação TLS, o handshake mútuo é concluído e, a partir desse momento, todo o tráfego de autenticação 802.1X para convidados e funcionários nesse espaço flui encriptado para o servidor RADIUS na cloud. Se a ligação TLS cair — por exemplo, devido a uma interrupção de rede — o NAS restabelece-a automaticamente. Este modelo de ligação persistente é, na verdade, mais eficiente do que o UDP para implementações de grande volume, porque evita a sobrecarga do processamento por pacote. Do lado da firewall, precisa de permitir TCP de saída na porta 2083 da sua rede de gestão NAS para o endereço IP ou FQDN do seu servidor RADIUS. Se estiver a aplicar uma política de saída rigorosa, também vai querer permitir o tráfego de retorno. Isto é mais simples do que gerir regras de firewall IPsec, que frequentemente requerem exceções de protocolo ESP e IKE em UDP 500 e 4500. Recomendações de Implementação e Erros Comuns. Vamos falar sobre o que realmente corre mal nas implementações RadSec, porque existem alguns modos de falha consistentes que vejo nas organizações. O primeiro e mais comum problema são as falhas de validação da cadeia de certificados. O seu dispositivo NAS precisa de confiar na CA que assinou o certificado do servidor RADIUS. Se estiver a utilizar um fornecedor de RADIUS na cloud com um certificado de uma CA pública bem conhecida — DigiCert, Let's Encrypt, Sectigo — a maioria dos dispositivos NAS modernos confiará nele de imediato. Mas se estiver a utilizar uma CA interna, precisa de enviar o certificado da CA para todos os dispositivos NAS. Isto é frequentemente descurado durante a implementação inicial e surge como falhas de handshake TLS que parecem problemas de conectividade. O segundo erro comum é a expiração do certificado. Ao contrário dos segredos partilhados, que não expiram, os certificados têm um período de validade definido. Se o certificado do seu servidor RADIUS expirar, todos os dispositivos NAS na sua infraestrutura falharão a autenticação em simultâneo. Precisa de uma gestão do ciclo de vida dos certificados — renovação automatizada sempre que possível, e monitorização com alertas bem antes da expiração. Um aviso de noventa dias é o mínimo; trinta dias é melhor. O terceiro problema é a compatibilidade do dispositivo NAS. Nem todos os dispositivos NAS suportam RadSec nativamente. Versões mais antigas do Cisco iOS, alguns controladores Aruba legados e certos pontos de acesso de nível de consumo não têm suporte para RadSec. Antes de se comprometer com uma implementação de RadSec, audite o seu parque de NAS para verificar a compatibilidade. O Cisco iOS-XE 16.x e posterior, o Aruba AOS-CX, o Ruckus SmartZone e a série Juniper EX têm todos um suporte sólido para RadSec. Para dispositivos que não suportam RadSec nativamente, um proxy RadSec — uma opção de código aberto como o radsecproxy — pode colmatar a lacuna, aceitando UDP RADIUS de dispositivos legados e encaminhando-o através de TLS para o servidor RADIUS na nuvem. A quarta consideração é a persistência da ligação e os keepalives. O RadSec utiliza ligações TCP persistentes, mas as firewalls e os dispositivos NAT com políticas de timeout agressivas podem derrubar silenciosamente as ligações inativas. Configure os keepalives TCP nas suas ligações RadSec — normalmente, um intervalo de keepalive de sessenta segundos é suficiente para evitar o encerramento prematuro da ligação. A maioria das implementações de servidores RADIUS e dispositivos NAS suporta esta configuração. Para o Cisco iOS-XE, a configuração do RadSec é semelhante a esta. Define um servidor RADIUS com o endereço do seu endpoint RADIUS na nuvem, especifica o TLS como transporte, faz referência ao seu trustpoint — que é o repositório de certificados no dispositivo — e define a porta de destino para 2083. Em seguida, faz referência a este servidor na configuração do seu grupo de servidores AAA. Os detalhes variam consoante a versão da plataforma, mas a estrutura lógica é consistente entre os diferentes fabricantes. Para os controladores Aruba que executam o AOS, configura o servidor RADIUS com a opção RadSec ativada, especifica o certificado CA para validação do servidor e, opcionalmente, configura um certificado de cliente para TLS mútuo. A implementação da Aruba é madura e está bem documentada. Perguntas e Respostas Rápidas. Vou abordar as perguntas que me fazem com mais frequência sobre o RadSec. O RadSec adiciona latência? O handshake TLS adiciona uma pequena sobrecarga no estabelecimento inicial da ligação — normalmente inferior a 100 milissegundos. Uma vez estabelecida a ligação, a sobrecarga por pacote é insignificante. Para a autenticação 802.1X, em que o handshake ocorre uma vez por sessão, esta não é uma preocupação relevante. Posso executar o RadSec em conjunto com o RADIUS UDP tradicional? Sim. A maioria dos servidores RADIUS suporta ambos em simultâneo. Durante uma migração, pode executar o RadSec para os locais que o suportam e recorrer ao UDP para os locais legados. Esta é a abordagem de migração recomendada. O RadSec é obrigatório para a conformidade com o PCI DSS? A versão 4.0 do PCI DSS exige que o tráfego de autenticação seja protegido em trânsito. O RadSec é uma das formas mais diretas de satisfazer este requisito para a autenticação baseada em RADIUS. Se processa pagamentos com cartão numa rede que utiliza autenticação RADIUS, o RadSec deve fazer parte do seu plano de conformidade. O RadSec funciona com EAP? Sim. O EAP — Extensible Authentication Protocol — é encapsulado dentro do RADIUS, pelo que o EAP-TLS, PEAP, EAP-TTLS funcionam todos de forma transparente sobre RadSec. A troca de EAP em si não é afetada. E quanto à monitorização de acessos (accounting) RADIUS? O RFC 6614 abrange tanto o tráfego de autenticação como o de accounting. Os seus dados de accounting — registos de início, fim e atualizações provisórias de sessão — também são encriptados através da mesma ligação TLS na porta 2083. Resumo e Próximos Passos. Para resumir: o RadSec é a camada de transporte correta para RADIUS em qualquer implementação onde o tráfego de autenticação atravesse infraestruturas que não controla totalmente. Isso significa RADIUS na nuvem, implementações multi-site, ambientes SD-WAN e qualquer cenário onde o tráfego RADIUS atravesse a internet pública ou infraestruturas de operadores partilhadas. As principais ações para a sua equipa são: primeiro, auditar o seu parque de NAS para verificar a compatibilidade com RadSec e identificar quaisquer dispositivos que necessitem de um proxy. Segundo, contactar o seu fornecedor de RADIUS na nuvem — ou avaliar fornecedores que suportem RadSec nativamente — e compreender a sua abordagem de gestão de certificados. Terceiro, estabelecer um processo de gestão do ciclo de vida dos certificados antes de entrar em produção. Quarto, atualizar as suas regras de firewall para permitir TCP 2083 de saída a partir da sua rede de gestão de NAS. Quinto, testar a sua configuração RadSec num ambiente de testes antes de a implementar em produção, prestando especial atenção à validação da cadeia de certificados e à persistência da ligação sob carga. Para organizações que utilizam a plataforma da Purple para WiFi de convidados e autenticação em locais distribuídos, o RadSec é o transporte recomendado para a conectividade RADIUS na nuvem. Alinha-se com a arquitetura cloud-native da Purple e garante que os dados de autenticação que fluem entre os seus locais e a plataforma estão totalmente protegidos — o que é fundamental tanto para a sua postura de segurança como para as suas obrigações de conformidade ao abrigo do GDPR e PCI DSS. Se está a planear uma implementação ou deseja discutir a sua arquitetura específica, a equipa da Purple é o ponto de partida ideal. Esta foi uma apresentação técnica da Purple sobre RadSec. Obrigado por ouvir.