O que é a Autenticação PEAP? Como o PEAP Protege o Seu WiFi

O que é a Autenticação PEAP? Como o PEAP Protege o Seu WiFi. Um Briefing de Inteligência de WiFi de Empresa da Purple. Bem-vindo. Se é responsável pela segurança de rede num grupo hoteleiro, numa rede de retalho, num estádio ou numa organização do setor público, este briefing é para si. Nos próximos dez minutos, vamos abordar a autenticação PEAP — o que realmente é, como funciona nos bastidores, onde se enquadra na sua arquitetura de segurança e, fundamentalmente, quando é a escolha certa versus quando deve procurar algo mais forte. Vamos a isso. Secção um: Contexto e por que razão isto é importante agora. A maioria das implementações de WiFi empresarial hoje em dia ainda depende de um de dois modelos de autenticação. Ou tem uma chave pré-partilhada — uma única palavra-passe partilhada por toda a organização — ou tem o 802.1X, que é a norma IEEE para controlo de acesso à rede baseado em portas. O PEAP situa-se firmemente no campo do 802.1X e é, de longe, o método EAP mais amplamente implementado em ambientes corporativos e institucionais a nível global. A razão pela qual o PEAP se tornou tão dominante é simples: resolveu um problema operacional real. Antes do PEAP, implementar a autenticação WiFi baseada em certificados significava emitir certificados de cliente para cada dispositivo — cada portátil, cada telemóvel, cada tablet. Para uma organização com quinhentos funcionários e uma política de BYOD, isso representa uma dor de cabeça de implementação de PKI para a qual a maioria das equipas de TI simplesmente não tinha orçamento ou tempo. O PEAP ofereceu um caminho intermédio: autenticação forte do lado do servidor via TLS, com credenciais de utilizador e palavra-passe do lado do cliente. Sem necessidade de certificados de cliente. Esse compromisso tornou o PEAP o padrão de facto para a autenticação WiFi empresarial ao longo dos anos 2000 e 2010, e continua a ser extremamente comum hoje em dia. Compreender a sua arquitetura — e as suas limitações — é essencial para qualquer pessoa que tome decisões de infraestrutura em 2024 e nos anos seguintes. Secção dois: Análise técnica aprofundada. Vamos analisar exatamente o que acontece quando um dispositivo se autentica via PEAP. O processo tem duas fases distintas, e compreender ambas é fundamental. Os três intervenientes nesta troca são: o suplicante — que é o dispositivo cliente, seja um portátil, um smartphone ou um terminal IoT; o autenticador — normalmente o ponto de acesso sem fios ou o controlador de LAN sem fios; e o servidor de autenticação — quase sempre um servidor RADIUS, como o Microsoft NPS, FreeRADIUS ou um serviço RADIUS alojado na nuvem. A fase um é o estabelecimento do túnel TLS. Quando o suplicante tenta ligar-se, o autenticador não concede acesso imediatamente. Em vez disso, inicia uma troca EAP através da rede local — isto é EAPOL, EAP sobre LAN. O autenticador encaminha isto para o servidor RADIUS, que apresenta o seu certificado TLS do lado do servidor ao cliente. O cliente valida esse certificado em relação ao seu repositório de certificados fidedignos. Se a validação for bem-sucedida, é estabelecido um túnel TLS entre o cliente e o servidor RADIUS. Este túnel é encriptado — normalmente TLS 1.2 ou 1.3 em implementações modernas. A fase dois é a autenticação interna. Dentro desse túnel encriptado, as credenciais reais são trocadas. Na implementação mais comum — PEAP-MSCHAPv2 — o cliente envia um nome de utilizador e palavra-passe utilizando o Microsoft Challenge Handshake Authentication Protocol versão 2. O servidor RADIUS valida essas credenciais no seu repositório de identidades, que pode ser o Active Directory, LDAP ou um fornecedor de identidades na nuvem. Se as credenciais forem validadas, o servidor RADIUS envia uma mensagem Access-Accept de volta através do autenticador, e o acesso à rede é concedido ao cliente. A principal propriedade de segurança aqui é que a troca MSCHAPv2 ocorre dentro do túnel TLS. Um atacante que monitorize passivamente o canal sem fios não consegue ver as credenciais em trânsito. Essa é a proposta de valor central do PEAP. Agora, onde é que o PEAP-MSCHAPv2 falha? Existem dois problemas significativos que qualquer arquiteto preocupado com a segurança precisa de compreender. Primeiro: a validação do certificado do servidor. O PEAP apenas exige que o servidor apresente um certificado — não exige que o cliente apresente um. Isto cria um vetor de ataque amplamente documentado. Se um dispositivo cliente estiver mal configurado para aceitar qualquer certificado — ou para aceitar certificados de qualquer CA — um atacante pode criar um ponto de acesso fictício, apresentar um certificado fraudulento e intercetar o handshake MSCHAPv2. Ferramentas como o hostapd-wpe tornaram este ataque trivialmente acessível. A mitigação passa por uma configuração rigorosa do suplicante: impor a validação do certificado do servidor, fixar a CA esperada e especificar o Common Name do servidor. Isto é inegociável em qualquer implementação séria. Segundo: o MSCHAPv2 é um protocolo antigo com vulnerabilidades conhecidas. A investigação de 2012 de Moxie Marlinspike demonstrou que os pares de desafio-resposta do MSCHAPv2 podem ser decifrados offline com capacidade computacional suficiente. Se um atacante conseguir capturar a troca de autenticação interna — por exemplo, através do ataque de ponto de acesso fictício descrito acima — pode tentar recuperar a palavra-passe em texto limpo offline. A força da sua política de palavras-passe afeta, portanto, diretamente a sua exposição. Palavras-passe longas, complexas e geradas aleatoriamente reduzem significativamente este risco. Compare isto com o EAP-TLS, onde tanto o servidor como o cliente apresentam certificados. Não existem palavras-passe para roubar. A superfície de ataque é drasticamente reduzida. O compromisso é a complexidade operacional: precisa de uma PKI, precisa de emitir e gerir certificados de cliente, e precisa de um mecanismo para os distribuir por todos os dispositivos. Para organizações com uma implementação de MDM madura e uma PKI bem gerida, o EAP-TLS é o padrão de excelência. Para todas as outras, o PEAP-MSCHAPv2 com uma configuração rigorosa continua a ser uma escolha defensável e prática. Secção três: Recomendações de implementação e armadilhas. Deixe-me dar-lhe as orientações práticas de implementação. Estas são as coisas que separam uma implementação PEAP segura de uma vulnerável. Número um: force a validação do certificado do servidor em cada suplicante. Este é o item de configuração mais importante de todos. No Windows, esta é a caixa de seleção "Validar certificado do servidor" no perfil de rede sem fios. No iOS e Android, é o campo do certificado CA na configuração EAP. Se isto não estiver configurado, a sua implementação PEAP estará vulnerável a ataques de rogue AP, independentemente de quão bem tudo o resto esteja configurado. Número dois: implemente via MDM ou GPO, não por configuração manual. A configuração manual por parte dos utilizadores finais não é fiável. Os utilizadores vão ignorar os avisos de certificado. Vão configurar incorretamente o campo CA. Distribua os seus perfis de rede sem fios através do Microsoft Intune, Jamf ou Política de Grupo (GPO). Isto garante uma configuração do suplicante consistente e em conformidade com as políticas em toda a sua infraestrutura. Número três: utilize o TLS 1.2 como requisito mínimo no seu servidor RADIUS. Desative o TLS 1.0 e 1.1. A maioria das implementações RADIUS modernas suporta isto, mas vale a pena verificar — particularmente em implementações locais (on-premises) mais antigas. Número quatro: integre com o seu fornecedor de identidade. O PEAP-MSCHAPv2 autentica contra um repositório de credenciais. Esse repositório deve ser o seu fornecedor de identidade autoritativo — Active Directory, Azure AD via extensão NPS ou um serviço RADIUS na nuvem com integração LDAP. Isto significa que, quando um colaborador sai da empresa, a desativação da sua conta revoga imediatamente o seu acesso ao WiFi. Sem segredos partilhados para rodar, sem desaprovisionamento manual. Número cinco: considere a sua rede de convidados separadamente. O PEAP é um método de autenticação empresarial. Para o WiFi de convidados — onde está a integrar visitantes, clientes ou participantes de eventos — precisa de uma abordagem diferente. Plataformas como a Purple fornecem uma camada de WiFi de convidados concebida especificamente para o efeito, que gere a autenticação do Captive Portal, a recolha de dados e a análise de dados sem necessitar de infraestrutura RADIUS no SSID de convidados. Mantenha o seu SSID empresarial em 802.1X com PEAP, e o seu SSID de convidados numa rede separada e isolada com a integração adequada. Número seis: planeie a rotação de certificados. O certificado do seu servidor RADIUS vai expirar. Quando isso acontecer, todos os clientes que fixaram esse certificado vão falhar a autenticação até que o novo certificado seja distribuído. Integre a renovação de certificados no seu calendário operacional — pelo menos 90 dias antes da expiração — e teste o processo de rotação num ambiente de testes antes de o implementar em produção. Os modos de falha mais comuns que vejo no terreno são: a validação de certificado não ser forçada, levando à vulnerabilidade de rogue AP; certificados de servidor RADIUS que expiram sem aviso, causando falhas generalizadas de autenticação; e a autenticação interna MSCHAPv2 exposta porque o servidor RADIUS está acessível a partir do segmento de rede errado. Todos os três são evitáveis com um planeamento adequado. Secção quatro: Perguntas rápidas. O PEAP pode funcionar com fornecedores de identidade na nuvem como o Azure AD? Sim. A extensão NPS da Microsoft para Azure AD MFA permite fazer o proxy da autenticação PEAP através do Azure AD, ativando a autenticação multifator no seu WiFi. Alternativamente, os serviços de RADIUS na nuvem como o Cisco ISE, Aruba ClearPass ou JumpCloud RADIUS podem integrar-se diretamente com o Azure AD ou Okta. O PEAP está em conformidade com o PCI DSS? O PEAP-MSCHAPv2 pode ser utilizado em ambientes PCI DSS, mas é necessário garantir que a validação do certificado do servidor é aplicada, que o TLS 1.2 ou superior está em uso e que o servidor RADIUS está devidamente segmentado. O PCI DSS 4.0 reforça os requisitos em torno dos controlos de acesso à rede — reveja os requisitos relevantes com o seu QSA. Devo migrar do PEAP para o EAP-TLS? Se tiver uma implementação de MDM madura e a capacidade operacional para gerir uma PKI, sim — o EAP-TLS é a escolha mais forte. Se estiver a gerir um parque misto com dispositivos pessoais, hardware antigo ou cobertura de MDM limitada, o PEAP-MSCHAPv2 com uma configuração rigorosa continua a ser adequado. Esta é uma decisão baseada no risco, não uma escolha binária. E quanto ao WPA3-Enterprise? O WPA3-Enterprise exige o modo de segurança de 192 bits para ambientes de alta segurança, mas continua a suportar métodos EAP, incluindo o PEAP. O WPA3 melhora a encriptação over-the-air, mas não altera a troca de autenticação EAP em si. Secção cinco: Resumo e próximos passos. Para resumir: o PEAP é um protocolo de autenticação de duas fases que envolve credenciais internas — normalmente MSCHAPv2 — dentro de um túnel TLS. É o método 802.1X EAP mais amplamente implementado porque elimina a necessidade de certificados de cliente, continuando a fornecer uma autenticação de servidor forte. A sua principal vulnerabilidade são os ataques de AP falsos (rogue AP), possibilitados por suplicantes mal configurados que não validam o certificado do servidor. Mitigue isto através de perfis sem fios impostos por MDM, pinning de CA e validação do nome do servidor. Para a maioria das implementações de WiFi empresariais — escritórios corporativos, redes de back-of-house de hotéis, redes de funcionários de retalho — o PEAP-MSCHAPv2 com a configuração correta é uma escolha sólida e defensável. Para ambientes de alta segurança, indústrias reguladas ou organizações com infraestrutura PKI madura, o EAP-TLS fornece uma segurança significativamente mais forte e deve ser a arquitetura-alvo. Se também estiver a disponibilizar WiFi para convidados em paralelo com a sua rede empresarial — e a maioria de vós está — lembre-se de que o PEAP não é a ferramenta certa para o registo de convidados. Analise plataformas como a Purple, que fornecem autenticação de WiFi para convidados concebida especificamente para o efeito, com análise de dados, captura de dados e integração de marketing, mantendo o tráfego de convidados e empresarial devidamente separados e a sua postura de conformidade intacta. Para leituras adicionais, consulte os guias da Purple sobre arquitetura de servidores RADIUS e autenticação WiFi empresarial. Os links estão nas notas do programa. Obrigado por ouvir. Este foi um Purple Enterprise WiFi Intelligence Briefing.