Mitigando Vulnerabilidades RADIUS: Um Guia de Fortalecimento de Segurança
Este guia fornece uma referência abrangente e prática para gestores de TI, arquitetos de rede e CTOs responsáveis pela infraestrutura de WiFi empresarial em ambientes de hotelaria, retalho, eventos e setor público. Abrange toda a superfície de ataque das implementações de servidores RADIUS - desde vulnerabilidades de colisão MD5 e segredos partilhados fracos até transporte UDP não encriptado e métodos EAP mal configurados - e apresenta um roteiro de fortalecimento prioritário alinhado com os requisitos IEEE 802.1X, PCI DSS e GDPR. As organizações que implementarem estas recomendações reduzirão materialmente a sua exposição a ataques de rede baseados em credenciais, cumprirão as obrigações de conformidade e construirão uma postura de segurança defensável para a sua infraestrutura de WiFi de convidados e corporativa.
Ouça este guia
Ver transcrição do podcast
Resumo Executivo
O RADIUS (Remote Authentication Dial-In User Service) continua a ser o protocolo principal para controlo de acesso à rede em implementações de WiFi empresariais, servindo de base para a autenticação IEEE 802.1X em hotéis, espaços de retalho, estádios, centros de conferências e edifícios do setor público. No entanto, a arquitetura do RADIUS remonta à década de 1990 e várias das suas decisões de design fundamentais - dependência de hash MD5, transporte UDP sem encriptação nativa e segredos partilhados estáticos - tornaram-se riscos significativos no ambiente de ameaças atual.
Em julho de 2024, a vulnerabilidade BlastRADIUS (CVE-2024-3596) demonstrou que um atacante em modo man-in-the-middle pode forjar respostas Access-Accept do RADIUS, explorando fraquezas de integridade do MD5 em pacotes Access-Request. A vulnerabilidade afeta todas as principais implementações de RADIUS, incluindo FreeRADIUS, Cisco ISE e Microsoft NPS. As implementações sem patch continuam em risco.
Este guia fornece um roteiro de reforço de segurança priorizado que abrange a gestão de patches, higiene de segredos partilhados, seleção do método EAP, implementação de RadSec, autenticação multifator para acesso administrativo e integração com SIEM para deteção de anomalias. Foi escrito para profissionais de TI que precisam de tomar decisões defensáveis neste trimestre, e não no próximo ano.
Análise Técnica Detalhada
Como o RADIUS funciona e onde é fraco
O RADIUS opera como um protocolo cliente-servidor entre um servidor de acesso à rede (NAS) - tipicamente um ponto de acesso WiFi, switch ou concentrador VPN - e um servidor RADIUS, que valida as credenciais num repositório de identidades de backend, como o Active Directory ou LDAP. A troca de autenticação segue o modelo de pedido-desafio-resposta definido na norma RFC 2865, sendo a faturação gerida separadamente ao abrigo da norma RFC 2866.
O protocolo transmite pacotes de autenticação através de UDP, utilizando a porta 1812 para autenticação e a 1813 para faturação. O segredo partilhado - a chave pré-partilhada configurada tanto no NAS como no servidor RADIUS - é utilizado para gerar o campo Response Authenticator e para encriptar o atributo User-Password através de uma cifra XOR baseada em MD5. Isto não é encriptação no sentido moderno; é uma ofuscação que depende inteiramente do segredo e da força do segredo partilhado.
As cinco principais categorias de vulnerabilidade numa implementação típica de RADIUS são as seguintes.
Vulnerabilidades de colisão de MD5 e integridade. O ataque BlastRADIUS (CVE-2024-3596) explora a falta de proteção de integridade nos pacotes Access-Request. Dado que muitas configurações não incluem o atributo Message-Authenticator do NAS por padrão, um atacante numa posição de man-in-the-middle pode injetar atributos manipulados antes que o pacote chegue ao servidor RADIUS. Utilizando uma técnica de colisão de prefixo escolhido em MD5, o atacante pode manipular o pacote de forma a que o servidor RADIUS calcule um Response Authenticator válido para o pacote modificado, retornando um Access-Accept para um pedido que deveria ter sido rejeitado. A mitigação passa por impor o atributo Message-Authenticator em todos os pacotes Access-Request, o que fornece proteção de integridade HMAC-MD5 sobre todo o pacote. Isto requer alterações de configuração tanto no NAS como no servidor RADIUS, e não apenas uma correção no servidor.
Segredos partilhados fracos ou estáticos. O segredo partilhado é a âncora criptográfica do intercâmbio RADIUS. Se o segredo for curto, adivinhável ou nunca for rodado, um atacante que capture o tráfego RADIUS (alcançável através de ARP spoofing ou de um dispositivo de rede comprometido) pode decifrar o atributo User-Password por força bruta em modo offline. As diretrizes do NIST SP 800-63B sobre segredos memorizados aplicam-se aqui: os segredos devem ter pelo menos 20 caracteres, ser gerados aleatoriamente e guardados num sistema de gestão de segredos. Para redes de grande dimensão com dezenas ou centenas de dispositivos NAS, a rotação manual é operacionalmente inviável; a automação através do HashiCorp Vault ou de um gestor de segredos semelhante é a abordagem correta.
Transporte UDP não encriptado. O RADIUS padrão sobre UDP não oferece confidencialidade na camada de transporte. O atributo User-Password é ofuscado mas não encriptado. Todos os outros atributos - incluindo nomes de utilizador, IPs de NAS e metadados de sessão - viajam em texto simples. O RadSec (RADIUS sobre TLS), definido no RFC 6614 e atualizado no RFC 7360, resolve este problema ao envolver o protocolo RADIUS num túnel TLS sobre a porta TCP 2083, estabelecendo uma sessão TLS 1.2 ou TLS 1.3. O RadSec fornece autenticação mútua de certificados entre o NAS e o servidor RADIUS, encriptação total da carga útil e proteção contra ataques de repetição. É o transporte correto para qualquer tráfego RADIUS que atravesse um limite de rede não confiável.
Seleção do método EAP. O Extensible Authentication Protocol (EAP) define os métodos de autenticação interna utilizados no âmbito do 802.1X. O EAP-MD5 foi descontinuado e deve ser removido de todas as implementações imediatamente - não fornece autenticação mútua nem resistência a ataques de recolha de credenciais. O PEAP (Protected EAP) e o EAP-TTLS estabelecem um túnel TLS utilizando um certificado de servidor antes de transmitir as credenciais, fornecendo autenticação mútua e protegendo o método interno contra escuta ativa. O EAP-TLS elimina totalmente as palavras-passe, exigindo certificados X.509 tanto no servidor como no cliente. É imune a phishing e a ataques de força bruta, sendo o método recomendado para ambientes de alta segurança. Registo e monitorização insuficientes. O registo de RADIUS regista todos os eventos de autenticação - sucesso, falha, início de sessão, fim de sessão. Estes dados são operacionalmente valiosos para o planeamento de capacidade e comercialmente valiosos para WiFi Analytics , mas são também uma fonte crítica de telemetria de segurança. Picos de falhas de autenticação, autenticações a partir de endereços MAC desconhecidos e padrões de acesso fora de horas são todos detetáveis a partir dos registos de RADIUS. A maioria das organizações não integra estes dados num SIEM, e as que o fazem raramente configuram limiares de alerta.
O ataque BlastRADIUS em detalhe
O BlastRADIUS foi divulgado em julho de 2024 por investigadores da Universidade de Boston e da UC San Diego. O ataque requer uma posição de "man-in-the-middle" entre o NAS e o servidor RADIUS - realizável através de envenenamento de ARP num segmento de rede partilhado, um router comprometido ou um insider malicioso com acesso à rede.
O ataque processa-se da seguinte forma: o atacante intercepta um pacote Access-Request do NAS. Como o pacote carece do atributo Message-Authenticator (o padrão em muitas configurações), o atacante está livre para modificar a lista de atributos do pacote. Utilizando uma colisão de prefixo escolhido MD5, o atacante constrói um pacote modificado para o qual o servidor RADIUS calculará o mesmo Response Authenticator que o original. O servidor, portanto, devolve um Access-Accept para um pedido contendo atributos controlados pelo atacante - incluindo um Service-Type de Administrative que autoriza acesso total à rede.
O ataque é eficaz contra implementações PEAP e EAP-TTLS que utilizam MSCHAPv2 como o método interno. Não afeta implementações EAP-TLS, onde a autenticação mútua baseada em certificados fornece proteção de integridade que o MD5 não consegue subverter.
Para organizações que executam tanto Guest WiFi como 802.1X corporativo, a instância de RADIUS da rede de convidados também deve ser corrigida, mesmo que utilize bypass de autenticação MAC em vez de EAP. A higiene de segredos partilhados e o requisito de Message-Authenticator aplicam-se igualmente.
Guia de Implementação
Fase 1: Correção imediata (semanas 1-2)
A aplicação de patches vem primeiro. O FreeRADIUS 3.2.5 e 3.0.27 contêm as correções para o BlastRADIUS e impõem o Message-Authenticator por predefinição. O Cisco ISE 3.1 Patch 8, 3.2 Patch 4 e 3.3 Patch 1 resolvem a vulnerabilidade. A Microsoft lançou o KB5040434 para Windows Server 2022 NPS em julho de 2024. Verifique as suas versões atuais e aplique as correções na sua próxima janela de alteração programada.
Ao mesmo tempo, audite o firmware dos seus dispositivos NAS. A imposição do Message-Authenticator só é eficaz se o NAS também enviar o atributo. Verifique os avisos dos fornecedores de pontos de acesso e switches - Aruba, Ruckus, Cisco e Juniper lançaram atualizações de firmware para o BlastRADIUS. Se estiver a utilizar hardware Ruckus, o guia de ponto de acesso wireless Ruckus fornece o contexto relevante para a gestão do firmware.
Para a resolução de problemas de autenticação 802.1X no Windows 11 que possam surgir após a aplicação de patches, a causa mais comum é o servidor NPS rejeitar ligações de clientes que não incluem o Message-Authenticator - um comportamento de segurança correto que pode exigir a reconfiguração do suplicante em clientes Windows mais antigos.
Fase 2: Higiene do segredo partilhado (semanas 2 a 4)
Exporte a lista completa de clientes NAS registados nos seus servidores RADIUS. Para cada entrada, registe o comprimento do segredo partilhado e a data da última alteração. Qualquer segredo com menos de 20 caracteres, ou inalterado há mais de 24 meses, deve ser rodado imediatamente.
Para novos segredos, utilize um gerador criptograficamente aleatório - openssl rand -base64 32 produz uma string base64 de 44 caracteres ideal para utilizar como segredo partilhado RADIUS. Armazene todos os segredos num sistema de gestão de segredos. Implemente um calendário de rotação: anualmente para dispositivos NAS de baixo risco, a cada seis meses para dispositivos NAS no âmbito do PCI-DSS.
Fase 3: Racionalização do método EAP (meses 1 a 2)
Audite os métodos EAP que os seus servidores RADIUS permitem. Desative o EAP-MD5. Se estiver a utilizar PEAP-MSCHAPv2, verifique se todos os suplicantes impõem a validação do certificado do servidor - um suplicante mal configurado que aceita qualquer certificado de servidor é vulnerável a ataques de servidores RADIUS falsos. Para ambientes no âmbito do PCI-DSS, recomenda-se o EAP-TLS. Se não tiver uma infraestrutura de certificados existente, inicie o planeamento da PKI.
Para a segurança de redes WiFi de convidados , note que as redes de convidados utilizam tipicamente a autenticação por Captive Portal em vez de 802.1X, pelo que o reforço do método EAP se aplica principalmente a SSIDs corporativos e de funcionários.
Fase 4: Implantação do RadSec (meses 2 a 3)
Identifique todos os caminhos de tráfego RADIUS que cruzam um limite de rede não confiável. Os cenários comuns incluem um servidor RADIUS central a servir hotéis remotos através da Internet; dispositivos NAS locais a aceder a um serviço RADIUS na nuvem; e cadeias de proxy RADIUS onde o tráfego atravessa vários domínios de rede.
Para cada caminho identificado, configure o RadSec. No FreeRADIUS, isto significa ativar o listener tls na porta 2083 e configurar TLS mútuo com certificados da sua PKI. No Cisco ISE, o RadSec é configurado em Administration > Network Devices. Garanta o TLS 1.2 como mínimo; desative explicitamente o TLS 1.0 e 1.1.
Fase 5: Autenticação multifator para acesso administrativo (meses 2 a 3)
A interface de gestão de um servidor RADIUS é um alvo de alto valor. Um atacante que comprometa o servidor RADIUS pode modificar a política de autenticação, extrair segredos partilhados e redirecionar fluxos de autenticação. Force a MFA nos acessos administrativos de todos os servidores RADIUS e respetivos sistemas operativos subjacentes. Restrinja o acesso de gestão a uma VLAN de gestão out-of-band dedicada. Implemente o controlo de acessos baseado em funções: os engenheiros de rede não devem ter os mesmos privilégios que os administradores de segurança.
Fase 6: Integração com SIEM e alertas (meses 3-4)
Configure os seus servidores RADIUS para reencaminhar os registos (logs) de accounting para o seu SIEM em tempo real. Defina os seguintes limiares de alerta de referência:
| Alerta | Limiar | Gravidade |
|---|---|---|
| Múltiplas falhas de autenticação a partir de um único endereço MAC | >5 em 60 segundos | Alta |
| Pico na taxa de Access-Reject | 200% acima da referência de 7 dias | Média |
| Autenticação a partir de um novo endereço MAC num SSID corporativo | Primeira ocorrência | Média |
| Certificado do servidor RADIUS próximo do fim da validade | 90 / 30 / 7 dias | Alta / Crítica / Crítica |
| Erros de incompatibilidade de segredo partilhado | Qualquer ocorrência | Alta |
Melhores Práticas
As recomendações seguintes sintetizam o consenso entre a IEEE 802.1X, NIST SP 800-63B, PCI DSS v4.0 e avisos de segurança de fornecedores.
Gestão de certificados. Qualquer implementação que utilize EAP-TLS ou RadSec possui certificados X.509 no seu caminho de autenticação. A expiração de certificados é a causa singular mais comum de falhas de autenticação súbitas e totais em implementações de WiFi corporativas. Implemente a gestão automatizada do ciclo de vida dos certificados. Defina alertas de monitorização para 90, 30 e 7 dias antes da expiração. Para certificados de servidores RADIUS, utilize chaves RSA de no mínimo 2048 bits ou ECDSA de 256 bits, e algoritmos de assinatura SHA-256 ou superiores. Não utilize SHA-1.
Segmentação de rede. Os servidores RADIUS devem estar localizados num segmento de gestão dedicado, isolado das redes de convidados e corporativas gerais. O acesso às portas RADIUS (UDP 1812, 1813 e TCP 2083 para RadSec) deve ser restringido por ACL de firewall aos endereços IP específicos dos dispositivos NAS registados. Não permita qualquer acesso direto à internet para as portas RADIUS.
Redundância e alta disponibilidade. Um único servidor RADIUS representa um ponto único de falha para toda a sua infraestrutura de controlo de acessos à rede. Implemente pelo menos dois servidores RADIUS numa configuração ativo-passivo ou ativo-ativo. Para implementações em Hotelaria com requisitos de conectividade de convidados 24/7, a inatividade do servidor RADIUS traduz-se diretamente em inatividade do WiFi de convidados - um risco reputacional e comercial.WPA3 and 802.1X. O WPA3-Enterprise no modo de segurança de 192 bits, exigido para implementações governamentais e de alta segurança, exige AES-256-GCMP para encriptação de dados e HMAC-SHA-384 para autenticação. Para a maioria das implementações empresariais, o WPA3-Enterprise com segurança padrão de 128 bits já é uma melhoria significativa em relação ao WPA2-Enterprise, particularmente quando combinado com EAP-TLS. Os ambientes de Retalho que lidam com pagamentos com cartão devem tratar a adoção do WPA3-Enterprise como uma medida de redução de risco PCI-DSS.
Cadência de patches do fabricante. Subscreva os avisos de segurança do fabricante do seu servidor RADIUS e dos fabricantes dos seus dispositivos NAS. O FreeRADIUS, Cisco, Microsoft, Aruba e Ruckus publicam notificações de CVE. Introduza estas informações no seu programa de gestão de vulnerabilidades com SLAs definidos: vulnerabilidades críticas (CVSS ≥ 9.0) corrigidas em 72 horas; vulnerabilidades de gravidade elevada (CVSS 7.0-8.9) em 14 dias.
Resolução de Problemas e Mitigação de Riscos
Modos de falha comuns
Falhas de autenticação após a aplicação de patches. Após a aplicação de patches BlastRADIUS, alguns dispositivos NAS podem falhar na autenticação se o seu firmware não suportar o Message-Authenticator. Sintoma: um aumento repentino nas respostas Access-Reject sem alteração nas credenciais do utilizador. Diagnóstico: ative o registo de depuração RADIUS e verifique se existem erros do tipo "Message-Authenticator exigido mas não presente". Resolução: atualize o firmware do NAS ou, como medida temporária, configure o servidor RADIUS para aceitar pedidos sem Message-Authenticator de IPs de NAS específicos enquanto as atualizações de firmware são agendadas.
Falhas de validação de certificado no EAP-TLS. Sintoma: os clientes recebem "falha na autenticação" sem o correspondente Access-Reject no registo do RADIUS. Diagnóstico: verifique a cadeia de certificados do servidor RADIUS - a CA emissora é de confiança do suplicante do cliente? O certificado do servidor está dentro do seu período de validade? Resolução: garanta que a cadeia completa de certificados (folha + intermédio + raiz) está configurada no servidor RADIUS. Distribua os certificados da CA raiz para os dispositivos clientes através de MDM ou Política de Grupo.
Falhas no handshake TLS do RadSec. Sintoma: os dispositivos NAS não conseguem estabelecer ligações RadSec após uma alteração de configuração. Diagnóstico: verifique a compatibilidade da versão do TLS - o firmware do NAS mais antigo pode não suportar o TLS 1.2. Verifique a autenticação mútua de certificados - ambas as partes devem confiar na CA uma da outra. Resolução: verifique o suporte da versão TLS nas notas de lançamento do firmware do NAS; garanta que os certificados do dispositivo NAS são emitidos pela mesma CA em que o servidor RADIUS confia.
Incompatibilidade de segredo partilhado. Sintoma: todas as autenticações de um NAS específico falham com erros de "autenticador inválido". Diagnóstico: uma incompatibilidade do segredo partilhado entre a configuração do NAS e a entrada de cliente do servidor RADIUS. Resolução: introduza novamente o segredo partilhado em ambos os lados, verificando se existem espaços em branco no final ou problemas de codificação de caracteres. Copie e cole a partir do seu gestor de segredos para evitar erros de transcrição.
Registo de riscos
| Risco | Probabilidade | Impacto | Controlos de mitigação |
|---|---|---|---|
| Exploração BlastRADIUS | Alta (se não corrigido) | Crítica | Correção + aplicação de Message-Authenticator |
| Brute-force de segredo partilhado | Média | Alta | Segredos aleatórios de 32 caracteres, rotação anual |
| Servidor RADIUS fraudulento | Média | Alta | Autenticação mútua EAP-TLS, certificate pinning |
| Expiração de certificado do servidor RADIUS | Alta | Crítica | Monitorização automatizada, alertas com 90 dias de antecedência |
| Credential stuffing via 802.1X | Média | Alta | Política de bloqueio de conta, alertas SIEM |
| Compromisso de servidor RADIUS | Baixa | Crítica | MFA no acesso de administrador, segmentação de rede |
ROI e Impacto no Negócio
Quantificar o risco
O caso financeiro para a robustez de RADIUS é mais claro quando comparado com os custos de uma violação. O custo médio de uma violação de dados no Reino Unido em 2024 foi de £3,58 milhões, cobrindo multas regulatórias, remediação, custos legais e danos à reputação. Para organizações no âmbito do PCI-DSS - efetivamente todos os operadores de Retail e Hospitality que aceitam pagamentos com cartão através de WiFi - uma violação de controlo de acesso à rede que exponha dados de titulares de cartões desencadeia uma investigação forense obrigatória, potenciais multas das marcas de cartões e a possível suspensão dos direitos de processamento de cartões.
Para organizações de Healthcare , uma violação de GDPR que envolva dados de pacientes acedidos através de um servidor RADIUS comprometido acarreta multas de até 4% da faturação anual global ao abrigo do Artigo 83(5). O histórico de aplicação do ICO demonstra que as falhas de segurança de rede são tratadas como negligência, e não como infortúnio técnico.
Referências de custos de implementação
As seguintes estimativas de custos pressupõem uma rede corporativa de 500 dispositivos:
| Atividade de robustez | Custo estimado | Cronograma |
|---|---|---|
| Correção (FreeRADIUS / NPS / ISE) | Apenas mão de obra interna | 1 a 2 semanas |
| Auditoria e rotação de segredo partilhado | Mão de obra interna + licença de gestor de segredos (~£2.000/ano) | 2 a 4 semanas |
| Implantação de PKI EAP-TLS | £15.000 - £30.000 (ferramentas + serviços profissionais) | 2 a 3 meses |
| Implementação de RadSec | Mão de obra interna + custos de certificado (~£1.500) | 4 a 6 semanas |
| Integração SIEM e alertas | Depende do SIEM existente; £0 - £10.000 | 4 a 8 semanas |
O investimento total de robustez para uma média empresa é de aproximadamente £20.000 - £45.000. Contra a base de custo de violação de £3,58 milhões, o ROI ajustado ao risco é convincente mesmo sob suposições conservadoras de probabilidade de violação.
Benefícios operacionais além da segurança
Uma infraestrutura RADIUS robusta também traz dividendos operacionais. Uma autenticação fiável e bem monitorizada reduz os pedidos de suporte técnico relacionados com a conectividade WiFi. Os dados de contabilização RADIUS, quando integrados com WiFi Analytics , fornecem visibilidade ao nível da sessão sobre padrões de utilização da rede, tempos de permanência e tipos de dispositivos - dados com valor comercial direto para operadores de locais em ambientes de Hospitality e Transport . Para organizações do setor público e de Saúde , um programa documentado de hardening de RADIUS fornece evidências de controlos técnicos para as avaliações Cyber Essentials Plus, ISO 27001 e NHS DSPT - reduzindo o esforço de auditoria e demonstrando a devida diligência perante os reguladores.
Definições Principais
RADIUS (Remote Authentication Dial-In User Service)
Um protocolo cliente-servidor definido no RFC 2865 que fornece autenticação, autorização e contabilidade (AAA) centralizadas para acesso à rede. Os servidores RADIUS validam as credenciais enviadas pelos dispositivos de rede (NAS) contra um repositório de identidade backend, como o Active Directory ou LDAP.
As equipas de IT encontram o RADIUS como o backend de autenticação para WiFi 802.1X, autenticação de portas com fios, acesso VPN e gestão de dispositivos de rede. É o protocolo que decide quem entra na rede.
IEEE 802.1X
Uma norma IEEE para controlo de acesso à rede baseado em portas que define o encapsulamento de EAP sobre LAN (EAPOL). Fornece uma estrutura de autenticação para redes com e sem fios, exigindo que os dispositivos se autentiquem antes de lhes ser concedido acesso à rede.
O 802.1X é a norma que faz a autenticação de WiFi empresarial funcionar. Quando um funcionário se liga a um SSID corporativo e lhe são pedidas credenciais, o 802.1X é a estrutura que orquestra essa troca, com o RADIUS como backend.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
Um método EAP que utiliza certificados X.509 para autenticação mútua entre o cliente e o servidor RADIUS. Ambas as partes devem apresentar certificados válidos, eliminando totalmente as palavras-passe da troca de autenticação.
O EAP-TLS é o padrão de excelência para autenticação WiFi empresarial. É imune a phishing de credenciais e a ataques de força bruta. O requisito operacional é uma infraestrutura PKI para emitir e gerir certificados de cliente.
RadSec (RADIUS over TLS)
Um protocolo definido no RFC 6614 que encapsula pacotes RADIUS dentro de uma sessão TLS sobre a porta TCP 2083. Fornece encriptação na camada de transporte, autenticação mútua de certificados e proteção contra repetição para tráfego RADIUS.
O RadSec é obrigatório para qualquer tráfego RADIUS que atravesse uma fronteira de rede não confiável - ligações WAN, ligações à internet ou infraestrutura de rede partilhada. É a substituição correta para o RADIUS padrão sobre UDP em implementações multi-site.
BlastRADIUS (CVE-2024-3596)
Um ataque man-in-the-middle revelado em julho de 2024 que explora a ausência de proteção de integridade nos pacotes RADIUS Access-Request. Utilizando técnicas de colisão de prefixo escolhido MD5, um atacante pode forjar uma resposta Access-Accept, concedendo acesso à rede a um utilizador não autenticado.
O BlastRADIUS afeta todas as principais implementações de RADIUS, incluindo FreeRADIUS, Cisco ISE e Microsoft NPS. As organizações que não aplicaram as correções lançadas em julho de 2024 continuam expostas a este ataque.
Message-Authenticator
Um atributo RADIUS (Atributo 80) que fornece proteção de integridade HMAC-MD5 sobre todo o pacote RADIUS. Quando presente num Access-Request, previne o ataque de modificação de pacotes utilizado no BlastRADIUS.
A imposição do Message-Authenticator em todos os pacotes Access-Request é a principal mitigação para o BlastRADIUS. Deve ser configurado tanto no servidor RADIUS (para exigir o atributo) como no dispositivo NAS (para incluir o atributo nos pedidos).
NAS (Network Access Server)
Na terminologia RADIUS, o NAS é o dispositivo de rede - normalmente um ponto de acesso WiFi, switch ou concentrador VPN - que atua como o cliente RADIUS. Intercetar pedidos de ligação de dispositivos finais e encaminha os pedidos de autenticação para o servidor RADIUS.
Os dispositivos NAS são os clientes RADIUS numa implementação. Os segredos partilhados são configurados por NAS. A mitigação do BlastRADIUS requer atualizações de firmware nos dispositivos NAS, bem como correções no servidor RADIUS.
PEAP (Protected Extensible Authentication Protocol)
Um método EAP que estabelece um túnel TLS utilizando um certificado do lado do servidor antes de transmitir o método de autenticação interno (normalmente MSCHAPv2). Fornece autenticação mútua e protege as credenciais contra a interceção de dados.
O PEAP-MSCHAPv2 é o método de autenticação WiFi empresarial mais amplamente implementado. Está em conformidade com o PCI DSS e é operacionalmente mais simples do que o EAP-TLS porque não requer certificados de cliente. No entanto, é vulnerável a ataques de servidores RADIUS falsos se a validação de certificados do lado do cliente não for imposta.
Segredo Partilhado
Uma chave pré-partilhada configurada tanto no servidor RADIUS como em cada dispositivo NAS. É utilizada para gerar o campo Response Authenticator e para ofuscar o atributo User-Password. Não é uma palavra-passe para utilizadores finais - é uma credencial de autenticação de servidor para servidor.
Segredos partilhados fracos ou estáticos são uma das vulnerabilidades RADIUS mais comuns. Um atacante que capture tráfego RADIUS pode realizar um ataque de força bruta offline contra um segredo partilhado fraco. O comprimento mínimo recomendado é de 32 carateres, gerados aleatoriamente.
PCI DSS (Payment Card Industry Data Security Standard)
Um conjunto de normas de segurança exigidas pelas principais redes de cartões (Visa, Mastercard, Amex) para organizações que processam, armazenam ou transmitem dados de titulares de cartões. A Versão 4.0, em vigor a partir de março de 2024, inclui requisitos específicos para controlo de acesso à rede e autenticação forte.
As organizações de retalho e hotelaria com terminais de pagamento ligados por WiFi estão no âmbito do PCI DSS. As vulnerabilidades do servidor RADIUS que possam permitir o acesso não autorizado à rede a ambientes de dados de titulares de cartões constituem um risco direto de conformidade.
Exemplos Práticos
Um grupo hoteleiro de 350 quartos com 12 propriedades utiliza um servidor RADIUS centralizado alojado no centro de dados da sua sede. Cada propriedade liga-se através de uma WAN MPLS partilhada. Uma auditoria de segurança assinalou que o tráfego RADIUS não é encriptado na WAN, os segredos partilhados são strings de 8 caracteres definidas durante a implementação inicial há cinco anos, e o servidor RADIUS está a executar o FreeRADIUS 3.0.21. O grupo processa pagamentos com cartão através de terminais POS ligados por WiFi nos seus restaurantes e spas. Qual é a prioridade de remediação e a sequência de implementação?
A sequência de remediação deve ser ordenada pela gravidade do risco e velocidade de implementação. Passo 1 (imediato, em 72 horas): Atualizar o FreeRADIUS para 3.2.5 ou 3.0.27. Isto aborda o BlastRADIUS e força o Message-Authenticator por predefinição. Simultaneamente, verifique as versões de firmware dos pontos de acesso em todas as 12 propriedades e agende atualizações de firmware para quaisquer dispositivos NAS que não suportem Message-Authenticator. Passo 2 (semana 1–2): Rodar todos os segredos partilhados. Gerar segredos aleatórios de 32 caracteres usando openssl rand -base64 32 para cada um dos 12 registos NAS das propriedades. Armazenar no HashiCorp Vault ou equivalente. Documentar a data de rotação. Passo 3 (mês 1–2): Implementar RadSec no caminho WAN. Configurar o servidor FreeRADIUS para aceitar ligações RadSec em TCP 2083. Emitir certificados TLS de uma CA interna para os dispositivos NAS de cada propriedade. Atualizar as regras de firewall para permitir TCP 2083 das gamas de IP NAS das propriedades para o servidor RADIUS. Desativar UDP 1812/1813 das interfaces voltadas para a WAN assim que o RadSec for confirmado como operacional. Passo 4 (mês 2–3): Para o SSID de WiFi do POS no âmbito do PCI DSS, migrar de PEAP-MSCHAPv2 para EAP-TLS. Implementar uma PKI interna (Microsoft ADCS ou motor HashiCorp Vault PKI). Emitir certificados de cliente para terminais POS via MDM. Atualizar a política RADIUS para exigir EAP-TLS para o SSID do POS. Passo 5 (mês 3): Integrar os registos de contabilidade RADIUS no SIEM. Configurar alertas para picos de falha de autenticação e expiração de certificados.
Uma cadeia de retalho regional com 45 lojas utiliza WPA2-Personal (chave pré-partilhada) para o WiFi dos funcionários e uma rede aberta para o WiFi dos clientes. O diretor de IT pretende migrar o WiFi dos funcionários para autenticação 802.1X utilizando o Microsoft NPS como servidor RADIUS, integrado com o Active Directory. As lojas têm uma mistura de pontos de acesso Aruba e Cisco. A cadeia está no âmbito do PCI DSS. Que arquitetura devem implementar e quais são as principais decisões de configuração?
A arquitetura recomendada é o 802.1X com PEAP-MSCHAPv2 como o método EAP inicial, com um plano de transição documentado para EAP-TLS. O servidor NPS deve ser implementado num par redundante (primário + secundário) no data centre central, com configuração de proxy RADIUS nos pontos de acesso para failover automático. Decisões de configuração: (1) Política de Rede NPS: crie uma política correspondente ao SSID dos funcionários com PEAP-MSCHAPv2, exigindo a filiação num grupo de segurança de AD (por exemplo, 'WiFi-Staff-Access'). Defina o limite de tempo da sessão para 8 horas para forçar a reautenticação. (2) Certificado: implemente um certificado de servidor NPS a partir de uma CA de ADCS interna da Microsoft. Distribua o certificado CA raiz para todos os dispositivos dos funcionários através de Política de Grupo (Windows) e MDM (iOS/Android). (3) Configuração do suplicante: configure os dispositivos Windows através de Política de Grupo (Configuração do Computador > Definições do Windows > Definições de Segurança > Políticas de Rede Sem Fios). Para dispositivos iOS e Android, utilize um perfil de MDM. Force a validação do certificado do servidor - não permita que os utilizadores aceitem certificados arbitrários. (4) Configuração do ponto de acesso: no Aruba, configure o servidor RADIUS em Autenticação > Servidores. Defina o segredo partilhado como uma string aleatória de 32 caracteres. Ative o RadSec se o firmware da Aruba o suportar (AOS 8.9+). No Cisco, configure em Segurança > AAA > RADIUS. (5) Registo do NPS: ative o registo de contabilidade do NPS para uma base de dados SQL Server. Configure um período de retenção de registos de, no mínimo, 90 dias para conformidade com o PCI DSS. (6) Pós-migração: desative o WPA2-Personal no SSID dos funcionários. Mantenha-o apenas como um SSID de emergência com uma PSK complexa guardada no gestor de segredos, para utilização apenas quando o NPS estiver indisponível.
Perguntas de Prática
Q1. A sua organização gere um servidor FreeRADIUS 3.0.21 que suporta autenticação 802.1X para 800 dispositivos de funcionários num campus de local único. O servidor RADIUS está na mesma VLAN de gestão que todos os pontos de acesso. Um teste de intrusão identificou que os pontos de acesso estão a enviar pacotes Access-Request sem o atributo Message-Authenticator. A equipa de segurança quer impor o Message-Authenticator de imediato, mas a equipa de operações de rede está preocupada com a interrupção da autenticação para os 800 utilizadores. Como deve sequenciar a correção para minimizar a interrupção do serviço?
Dica: Considere a diferença entre o servidor RADIUS exigir o Message-Authenticator e os dispositivos NAS enviarem-no. Estas são duas alterações de configuração distintas com perfis de risco diferentes.
Ver resposta modelo
A sequência correta é: (1) Primeiro, atualize o FreeRADIUS para a versão 3.2.5. Esta versão impõe o Message-Authenticator por predefinição, mas inclui um modo de compatibilidade que regista um aviso em vez de rejeitar pacotes sem o atributo. Isto permite aplicar a correção sem interromper imediatamente a autenticação. (2) Audite as versões de firmware dos pontos de acesso. Identifique quais os modelos e versões de firmware que suportam o Message-Authenticator em pacotes Access-Request. (3) Atualize o firmware dos pontos de acesso em lotes, começando com um grupo piloto de 50 dispositivos. Verifique se a autenticação continua a funcionar após cada lote. (4) Assim que confirmar que todos os pontos de acesso estão a enviar o Message-Authenticator, ative a imposição estrita no servidor FreeRADIUS (require_message_authenticator = yes no ficheiro clients.conf). (5) Monitorize os registos do RADIUS para identificar quaisquer avisos restantes de 'Message-Authenticator em falta', o que indicaria dispositivos NAS que não receberam a atualização de firmware. O princípio fundamental é que pode atualizar o servidor primeiro sem interromper o serviço, pois o modo de compatibilidade permite um período de transição. A imposição de rejeição estrita no servidor deve ser o último passo, após a atualização de todos os dispositivos NAS.
Q2. O operador de um centro de conferências gere um único servidor RADIUS que suporta tanto o SSID corporativo dos funcionários (802.1X com PEAP-MSCHAPv2) como o WiFi de convidados de eventos (Captive Portal com MAC Authentication Bypass). O gestor de TI pergunta se a instância RADIUS do WiFi de convidados necessita de ser protegida com o mesmo nível de exigência que a instância RADIUS corporativa, uma vez que os convidados não se autenticam com credenciais corporativas. Qual é a sua recomendação?
Dica: Considere os vetores de ataque que se aplicam ao MAC Authentication Bypass em comparação com a autenticação baseada em EAP, e o risco de movimento lateral entre as instâncias RADIUS de convidados e corporativa.
Ver resposta modelo
A instância RADIUS do WiFi de convidados requer endurecimento, mas os controlos específicos diferem da instância corporativa. O patch BlastRADIUS aplica-se de igual forma — a vulnerabilidade afeta o servidor RADIUS independentemente do método de autenticação utilizado pelos clientes. A higiene do segredo partilhado aplica-se de igual forma — um segredo partilhado fraco entre o controlador do Captive Portal de convidados e o servidor RADIUS é explorável independentemente de o EAP estar em utilização. O principal risco adicional é o servidor RADIUS partilhado: se os pedidos de autenticação do SSID de convidados e corporativo forem tratados pelo mesmo processo do servidor RADIUS, uma vulnerabilidade no caminho do RADIUS de convidados poderá ser utilizada para pivotar para a política de autenticação corporativa. A arquitetura recomendada consiste em executar instâncias RADIUS separadas (ou, no mínimo, servidores virtuais separados no FreeRADIUS) para autenticação de convidados e corporativa, com segredos partilhados separados e conjuntos de políticas separados. Isto proporciona isolamento de modo a que um comprometimento do caminho do RADIUS de convidados não exponha as credenciais corporativas. Para a instância de convidados especificamente: aplicar o patch para o BlastRADIUS, rodar os segredos partilhados e garantir que a instância RADIUS de convidados não tem acesso ao Active Directory corporativo. Os requisitos de EAP-TLS e RadSec são menos relevantes para uma implementação de Captive Portal, mas o RadSec deve continuar a ser considerado se o controlador do Captive Portal estiver num segmento de rede diferente do servidor RADIUS.
Q3. Uma fundação de saúde planeia migrar o seu WiFi clínico de WPA2-Personal para autenticação 802.1X. A fundação tem 1200 dispositivos clínicos, incluindo portáteis Windows, tablets iOS e dispositivos portáteis Android. O CISO deseja o EAP-TLS como estado-alvo. O diretor de TI está preocupado com a complexidade de implementação da PKI e propõe o PEAP-MSCHAPv2 como uma solução permanente. Como aconselha o CISO e o diretor de TI, e qual é o caminho de implementação recomendado?
Dica: Considere o modelo de ameaças específico para um ambiente de saúde — quais são as consequências de um comprometimento de credenciais e como é que o EAP-TLS aborda riscos que o PEAP-MSCHAPv2 não aborda?
Ver resposta modelo
O instinto do CISO está correto, mas a preocupação do diretor de TI é válida. O conselho recomendado é: implementar o PEAP-MSCHAPv2 agora como uma posição provisória, com um roteiro comprometido de 12 meses para o EAP-TLS. A justificação para não aceitar o PEAP-MSCHAPv2 como uma solução permanente na saúde é: (1) O PEAP-MSCHAPv2 é vulnerável a ataques de servidores RADIUS falsos se a validação de certificados do lado do cliente não for imposta. Num ambiente de saúde onde a equipa clínica pode ligar dispositivos pessoais, impor a configuração do suplicante de forma consistente em 1200 dispositivos é um desafio operacional. (2) As credenciais MSCHAPv2, se capturadas através de um ataque RADIUS falso, podem ser decifradas offline utilizando ferramentas como o hashcat. Num contexto de saúde, essas credenciais provavelmente também fornecem acesso a sistemas clínicos. (3) As avaliações do NHS DSPT e CQC esperam cada vez mais controlos de autenticação fortes para o acesso à rede clínica. O EAP-TLS fornece uma posição de prova de auditoria mais forte. O caminho de implementação: Meses 1-2: Implementar PEAP-MSCHAPv2 com validação de certificado de servidor imposta através de perfis MDM em todos os 1200 dispositivos. Meses 3-6: Implementar o Microsoft ADCS como infraestrutura PKI. Registar dispositivos Windows através de registo automático de Política de Grupo. Meses 6-9: Registar dispositivos iOS e Android através de perfis de certificado MDM. Meses 9-12: Migrar a política de SSID clínica de PEAP para EAP-TLS. Reter o PEAP como recurso de contingência para quaisquer dispositivos que falhem o registo de certificado, com monitorização melhorada. Para saber mais sobre a arquitetura de segurança de redes clínicas, o WiFi in Hospitals guide fornece um contexto de implementação relevante.
Continue a ler esta série
Cisco Meraki e guest WiFi: configuração do captive portal com a Purple
Como os pontos de acesso Cisco Meraki e os dispositivos das gamas MX e Z-series funcionam com o guest WiFi da Purple: autenticação web externa, RADIUS e um walled garden, com um link para o guia de configuração passo a passo da Purple para a configuração exata.
Alcatel-Lucent OmniAccess Stellar and guest WiFi: captive portal setup with Purple
How Alcatel-Lucent OmniAccess Stellar access points, managed from OmniVista Cirrus, work with Purple guest WiFi: an external captive portal, RADIUS and a walled garden, with a link to Purple's step-by-step setup guide for the exact configuration.
Mikrotik RouterOS e guest WiFi: configuração do captive portal com a Purple
Como o guest WiFi na nuvem da Purple se integra com dispositivos MikroTik com RouterOS, utilizando o Hotspot integrado e o RADIUS, e onde encontrar os passos exatos de configuração.