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

RadSec: Protegendo o Tráfego de Autenticação RADIUS com TLS. Um Informativo Técnico da Purple. Introdução e Contexto. Bem-vindo a este informativo técnico da Purple. Vou guiar você pelo RadSec — RADIUS sobre TLS — o que é, por que importa agora e como você realmente o implanta. Isso é direcionado diretamente a arquitetos de rede e engenheiros de segurança que já executam o cloud RADIUS hoje ou estão planejando migrar para lá. Se você ainda está executando servidores RADIUS locais com UDP e um segredo compartilhado, este informativo é para você. Vamos contextualizar. O RADIUS tem sido a espinha dorsal da autenticação de rede por mais de trinta anos. Ele sustenta o 802.1X, WPA2-Enterprise, WPA3-Enterprise e praticamente todos os sistemas de Captive Portal em produção hoje. O protocolo em si, definido na RFC 2865, foi projetado em uma época em que a internet era um lugar muito diferente. O tráfego de autenticação entre seus dispositivos NAS — seus pontos de acesso, switches e controladores — e seu servidor RADIUS viajava por UDP, porta 1812 para autenticação, porta 1813 para tarifação. E esse tráfego? Em grande parte não criptografado. A única proteção era um segredo compartilhado usado para ofuscar o atributo de senha do usuário, e mesmo isso tem fraquezas bem documentadas. Durante anos, isso foi aceitável porque o tráfego RADIUS permanecia em redes privadas e controladas. Seus dispositivos NAS e seu servidor RADIUS estavam na mesma LAN ou conectados por meio de um circuito MPLS dedicado. A superfície de ataque era gerenciável. Mas o mundo mudou. Infraestrutura nativa da nuvem, implantações em locais distribuídos, sobreposições de SD-WAN e a mudança para serviços de cloud RADIUS alteraram fundamentalmente o modelo de ameaça. Seu tráfego de autenticação agora está atravessando a internet pública ou, na melhor das hipóteses, uma infraestrutura compartilhada que você não controla totalmente. É aí que entra o RadSec. Deep-Dive Técnico. O RadSec, formalmente definido na RFC 6614, é o RADIUS sobre TLS. O conceito é simples: em vez de enviar pacotes RADIUS sobre UDP, você os encapsula dentro de uma conexão TLS sobre TCP. O resultado é que todo o tráfego de autenticação e tarifação entre seu NAS e seu servidor RADIUS é totalmente criptografado, mutuamente autenticado e protegido por integridade. A RFC 7360 estende isso para DTLS — Datagram TLS sobre UDP — que preserva algumas das características de latência do transporte UDP original enquanto adiciona criptografia. Para a maioria das implantações corporativas, o TLS sobre TCP é a escolha certa. O DTLS vale a pena ser considerado em ambientes de alto rendimento e sensíveis à latência, como grandes implantaçõ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 conexão RadSec, ele abre uma conexão TCP com o servidor RADIUS na porta 2083 e realiza um handshake TLS. Esse handshake é mútuo — tanto o cliente, que é o seu NAS, quanto o servidor apresentam certificados X.509. O certificado do servidor é validado em relação a uma CA confiável. O certificado do cliente identifica o NAS para o servidor RADIUS. Uma vez estabelecida a sessão TLS, os pacotes RADIUS fluem dentro desse túnel criptografado exatamente como fariam sobre UDP, mas agora com total confidencialidade, integridade e proteção contra repetição. Esta é uma mudança significativa em relação ao RADIUS tradicional em três aspectos importantes. Primeiro, o transporte é TCP, não UDP. Isso significa que você obtém uma entrega confiável e ordenada. Pacotes perdidos são retransmitidos automaticamente. Segundo, a autenticação de ambos os endpoints é baseada em certificado, não em segredo compartilhado. Isso elimina toda uma classe de ataques baseados em segredos compartilhados fracos ou comprometidos. Terceiro, todo o pacote RADIUS é criptografado, não apenas o atributo de senha. Isso significa que nomes de usuário, identificadores de sessão e todos os atributos RADIUS são protegidos em trânsito. Do ponto de vista do gerenciamento de certificados, você precisa de uma PKI — uma Infraestrutura de Chaves Públicas — para emitir e gerenciar certificados tanto para o seu servidor RADIUS quanto para os seus dispositivos NAS. Na prática, a maioria dos provedores de cloud RADIUS, incluindo a infraestrutura de autenticação nativa da nuvem da Purple, cuida do gerenciamento de certificados do lado do servidor para você. Sua responsabilidade é provisionar certificados de cliente para seus dispositivos NAS. Para implantações em larga escala, isso normalmente é feito por meio de sua plataforma de gerenciamento de rede ou de um sistema dedicado de gerenciamento de certificados. Os certificados devem usar RSA de 2048 bits ou ECDSA P-256 no mínimo, com um período de validade que equilibre a sobrecarga operacional com a higiene de segurança — doze meses é um padrão razoável. Agora, vamos abordar a comparação com a abordagem alternativa que muitas organizações usam hoje: túneis IPsec ou sobreposições de VPN para proteger o tráfego RADIUS. O IPsec é uma abordagem perfeitamente válida, mas opera em uma camada diferente. Você está criptografando todo o tráfego entre dois endpoints, o que adiciona complexidade — você precisa gerenciar IKE, chaves pré-compartilhadas ou certificados para o próprio túnel, além da sobrecarga operacional de manter o estado do túnel em potencialmente centenas de sites. O RadSec é mais cirúrgico. Ele criptografa especificamente o tráfego do protocolo RADIUS, opera na camada de aplicação e se integra diretamente à sua infraestrutura RADIUS. Para implantações de cloud RADIUS onde você está conectando muitos dispositivos NAS em locais distribuídos a um servidor de nuvem centralizado, o RadSec é arquitetonicamente mais limpo e operacionalmente mais simples. Deixe-me orientar você sobre como é uma implantação multi-site na prática. Você tem um servidor cloud RADIUS — digamos que seja a plataforma da Purple — com um certificado TLS válido de uma CA confiável. Você tem três tipos de locais: um hotel, uma loja de varejo e um centro de convenções. Cada um possui dispositivos NAS — pontos de acesso, switches ou controladores de LAN sem fio. Cada NAS precisa ser configurado com o endereço do servidor RadSec, porta 2083 e um certificado de cliente. O NAS inicia a conexã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 naquele local flui criptografado para o servidor cloud RADIUS. Se a conexão TLS cair — por exemplo, devido a uma interrupção na rede — o NAS a restabelece automaticamente. Esse modelo de conexão persistente é, na verdade, mais eficiente do que o UDP para implantações de alto volume porque você evita a sobrecarga do processamento por pacote. Do lado do firewall, você precisa permitir o tráfego TCP de saída na porta 2083 da sua rede de gerenciamento NAS para o endereço IP ou FQDN do seu servidor RADIUS. Se você estiver executando uma política de saída rígida, também desejará permitir o tráfego de retorno. Isso é mais simples do que gerenciar regras de firewall IPsec, que frequentemente exigem exceções do protocolo ESP e IKE nas portas UDP 500 e 4500. Recomendações de Implementação e Armadilhas. Vamos falar sobre o que realmente dá errado nas implantações do 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. Seu dispositivo NAS precisa confiar na CA que assinou o certificado do servidor RADIUS. Se você estiver usando um provedor de cloud RADIUS com um certificado de uma CA pública bem conhecida — DigiCert, Let's Encrypt, Sectigo — a maioria dos dispositivos NAS modernos confiará nele por padrão. Mas se você estiver usando uma CA interna, precisará enviar o certificado da CA para cada dispositivo NAS. Isso é frequentemente negligenciado durante a implantação inicial e surge como falhas de handshake TLS que parecem problemas de conectividade. A segunda armadilha é a expiração do certificado. Ao contrário dos segredos compartilhados, 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 da sua infraestrutura falharão ao autenticar simultaneamente. Você precisa de gerenciamento do ciclo de vida dos certificados — renovação automatizada sempre que possível e monitoramento com alertas bem antes da expiração. Um aviso prévio de noventa dias é o mínimo; trinta dias é melhor. A terceira questão é 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 doméstico não têm suporte a RadSec. Antes de se comprometer com uma implantação do RadSec, faça uma auditoria em sua infraestrutura de NAS para verificar a compatibilidade. O Cisco IOS-XE 16.x e posterior, Aruba AOS-CX, Ruckus SmartZone e a série Juniper EX têm suporte sólido ao RadSec. Para dispositivos que não suportam RadSec nativamente, um proxy RadSec — uma opção de código aberto como o radsecproxy — pode preencher a lacuna, aceitando RADIUS UDP de dispositivos legados e encaminhando-o por TLS para o servidor cloud RADIUS. A quarta consideração é a persistência da conexão e os keepalives. O RadSec usa conexões TCP persistentes, mas firewalls e dispositivos NAT com políticas de timeout agressivas podem derrubar silenciosamente conexões ociosas. Configure keepalives TCP em suas conexões RadSec — normalmente um intervalo de keepalive de sessenta segundos é suficiente para evitar a desmontagem prematura da conexão. A maioria das implementações de servidores RADIUS e dispositivos NAS suporta essa configuração. Para o Cisco IOS-XE, a configuração do RadSec se parece com isso. Você define um servidor RADIUS com o endereço do seu endpoint cloud RADIUS, 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 como 2083. Em seguida, você faz referência a este servidor na configuração do seu grupo de servidores AAA. Os detalhes variam de acordo com a versão da plataforma, mas a estrutura lógica é consistente entre os fornecedores. Para controladores Aruba executando AOS, você configura o servidor RADIUS com a opção RadSec habilitada, 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 bem documentada. Perguntas e Respostas Rápidas. Deixe-me passar pelas perguntas que mais me fazem sobre o RadSec. O RadSec adiciona latência? O handshake TLS adiciona uma pequena sobrecarga no estabelecimento inicial da conexão — normalmente menos de 100 milissegundos. Uma vez estabelecida a conexão, a sobrecarga por pacote é insignificante. Para a autenticação 802.1X, onde o handshake acontece uma vez por sessão, isso não é uma preocupação significativa. Posso executar o RadSec junto com o RADIUS UDP tradicional? Sim. A maioria dos servidores RADIUS suporta ambos simultaneamente. Durante uma migração, você pode executar o RadSec para os sites que o suportam e voltar para o UDP nos sites legados. Esta é a abordagem de migração recomendada. O RadSec é necessário para a conformidade com o PCI DSS? O PCI DSS versão 4.0 exige que o tráfego de autenticação seja protegido em trânsito. O RadSec é uma das maneiras mais diretas de atender a esse requisito para autenticação baseada em RADIUS. Se você processa pagamentos com cartão em uma rede que usa autenticação RADIUS, o RadSec deve estar no seu roteiro de conformidade. O RadSec funciona com EAP? Sim. O EAP — Extensible Authentication Protocol — é encapsulado dentro do RADIUS, de modo que EAP-TLS, PEAP, EAP-TTLS funcionam de forma transparente sobre o RadSec. A troca EAP em si não é afetada. E quanto à tarifação RADIUS? A RFC 6614 cobre tanto o tráfego de autenticação quanto o de tarifação. Seus dados de tarifação — registros de início, término e atualizações provisórias de sessão — também são criptografados na mesma conexão TLS na porta 2083. Resumo e Próximos Passos. Para resumir: o RadSec é a camada de transporte certa para o RADIUS em qualquer implantação onde o tráfego de autenticação cruza uma infraestrutura que você não controla totalmente. Isso significa cloud RADIUS, implantações multi-site, ambientes SD-WAN e qualquer cenário onde o tráfego RADIUS atravesse a internet pública ou infraestrutura de operadora compartilhada. As principais ações para sua equipe são: primeiro, auditar sua infraestrutura de NAS para compatibilidade com o RadSec e identificar quaisquer dispositivos que precisarão de um proxy. Segundo, entrar em contato com seu provedor de cloud RADIUS — ou avaliar provedores que suportam o RadSec nativamente — e entender a abordagem de gerenciamento de certificados deles. Terceiro, estabelecer um processo de gerenciamento do ciclo de vida dos certificados antes de entrar em produção. Quarto, atualizar suas regras de firewall para permitir a saída TCP 2083 da sua rede de gerenciamento NAS. Quinto, testar sua configuração do RadSec em um ambiente de homologação antes de implantar em produção, prestando atenção especial à validação da cadeia de certificados e à persistência da conexão sob carga. Para organizações que executam a plataforma da Purple para WiFi de convidados e autenticação em locais distribuídos, o RadSec é o transporte recomendado para conectividade com o cloud RADIUS. Ele se alinha com a arquitetura nativa da nuvem da Purple e garante que os dados de autenticação que fluem entre seus locais e a plataforma estejam totalmente protegidos — o que importa tanto para sua postura de segurança quanto para suas obrigações de conformidade sob o GDPR e o PCI DSS. Se você está planejando uma implantação ou deseja discutir sua arquitetura específica, a equipe da Purple é o ponto de partida ideal. Este foi um informativo técnico da Purple sobre o RadSec. Obrigado por ouvir.