O que é autenticação PEAP? Como o PEAP protege seu WiFi

O que é a autenticação PEAP? Como o PEAP protege o seu WiFi. Um informativo de inteligência de WiFi corporativo da Purple. Bem-vindo. Se você é responsável pela segurança de rede em um grupo hoteleiro, uma rede de varejo, um estádio ou uma organização do setor público, este informativo é para você. Nos próximos dez minutos, abordaremos a autenticação PEAP — o que ela realmente é, como funciona nos bastidores, onde se encaixa na sua arquitetura de segurança e, fundamentalmente, quando é a escolha certa versus quando você deve buscar algo mais robusto. Vamos começar. Seção um: Contexto e por que isso importa agora. A maioria das implantações de WiFi corporativo hoje ainda depende de um dos dois modelos de autenticação. Ou você tem uma chave pré-compartilhada — uma única senha compartilhada por toda a organização — ou tem o 802.1X, que é o padrão IEEE para controle de acesso à rede baseado em porta. O PEAP está firmemente no campo do 802.1X e é, de longe, o método EAP mais amplamente implantado em ambientes corporativos e institucionais globalmente. O motivo pelo qual o PEAP se tornou tão dominante é simples: ele resolveu um problema operacional real. Antes do PEAP, implantar a autenticação de WiFi baseada em certificado significava emitir certificados de cliente para cada dispositivo — cada notebook, cada telefone, cada tablet. Para uma organização com quinhentos funcionários e uma política de BYOD, isso representa uma dor de cabeça de implantação de PKI para a qual a maioria das equipes de TI simplesmente não tinha orçamento ou tempo. O PEAP ofereceu um caminho intermediário: autenticação forte do lado do servidor via TLS, com credenciais de usuário e senha do lado do cliente. Sem a necessidade de certificados de cliente. Esse compromisso tornou o PEAP o padrão de fato para autenticação de WiFi corporativo ao longo dos anos 2000 e 2010, e ele continua extremamente comum hoje. Compreender sua arquitetura — e suas limitações — é essencial para qualquer pessoa que tome decisões de infraestrutura em 2024 e nos anos seguintes. Seção dois: Detalhamento técnico. Vamos acompanhar exatamente o que acontece quando um dispositivo se autentica via PEAP. O processo tem duas fases distintas, e compreender ambas é fundamental. Os três atores nessa troca são: o solicitante (supplicant) — que é o dispositivo cliente, seja um notebook, um smartphone ou um terminal IoT; o autenticador — normalmente o ponto de acesso sem fio ou o controlador de LAN sem fio; e o servidor de autenticação — quase sempre um servidor RADIUS, como o Microsoft NPS, FreeRADIUS ou um serviço RADIUS hospedado na nuvem. A fase um é o estabelecimento do túnel TLS. Quando o solicitante tenta se conectar, o autenticador não concede acesso imediatamente. Em vez disso, ele inicia uma troca EAP pela rede local — isso é o EAPOL, EAP sobre LAN. O autenticador encaminha isso para o servidor RADIUS, que apresenta seu certificado TLS do lado do servidor para o cliente. O cliente valida esse certificado em seu repositório de certificados confiáveis. Se a validação for bem-sucedida, um túnel TLS é estabelecido entre o cliente e o servidor RADIUS. Esse túnel é criptografado — normalmente TLS 1.2 ou 1.3 em implantações modernas. A fase dois é a autenticação interna. Dentro desse túnel criptografado, as credenciais reais são trocadas. Na implantação mais comum — PEAP-MSCHAPv2 — o cliente envia um nome de usuário e senha usando o Microsoft Challenge Handshake Authentication Protocol versão 2. O servidor RADIUS valida essas credenciais em seu repositório de identidade, que pode ser o Active Directory, LDAP ou um provedor de identidade em 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 invasor que monitore passivamente o canal sem fio não consegue ver as credenciais em trânsito. Essa é a proposta de valor central do PEAP. Agora, onde o PEAP-MSCHAPv2 falha? Existem dois problemas significativos que qualquer arquiteto preocupado com segurança precisa entender. Primeiro: validação do certificado do servidor. O PEAP exige apenas que o servidor apresente um certificado — ele não exige que o cliente apresente um. Isso 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 invasor pode configurar um ponto de acesso invasor (rogue AP), apresentar um certificado fraudulento e interceptar o handshake MSCHAPv2. Ferramentas como o hostapd-wpe tornaram esse ataque trivialmente acessível. A mitigação é 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. Isso é inegociável em qualquer implantação séria. Segundo: o MSCHAPv2 é um protocolo antigo com fraquezas conhecidas. A pesquisa de 2012 de Moxie Marlinspike demonstrou que pares de desafio-resposta MSCHAPv2 podem ser quebrados offline com capacidade computacional suficiente. Se um invasor capturar a troca de autenticação interna — por exemplo, através do ataque de rogue AP descrito acima — ele poderá tentar recuperar a senha em texto simples offline. Portanto, a força da sua política de senhas afeta diretamente a sua exposição. Senhas longas, complexas e geradas aleatoriamente reduzem significativamente esse risco. Compare isso com o EAP-TLS, onde tanto o servidor quanto o cliente apresentam certificados. Não há senhas para roubar. A superfície de ataque é drasticamente reduzida. A contrapartida é a complexidade operacional: você precisa de uma PKI, precisa emitir e gerenciar certificados de cliente e precisa de um mecanismo para distribuí-los para cada dispositivo. Para organizações com uma implantação de MDM madura e uma PKI bem gerenciada, o EAP-TLS é o padrão ouro. Para todas as outras, o PEAP-MSCHAPv2 com configuração rigorosa continua sendo uma escolha defensável e prática. Seção três: Recomendações de implementação e armadilhas. Deixe-me dar as orientações práticas de implantação. Estas são as coisas que separam uma implantação PEAP segura de uma vulnerável. Número um: force a validação do certificado do servidor em cada solicitante. 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 fio. No iOS e Android, é o campo de certificado CA na configuração EAP. Se isso não estiver configurado, sua implantação PEAP estará vulnerável a ataques de rogue AP, independentemente de quão bem todo o resto esteja configurado. Número dois: implante via MDM ou GPO, não por configuração manual. A configuração manual pelos usuários finais não é confiável. Os usuários vão ignorar os avisos de certificado clicando neles. Eles vão configurar incorretamente o campo CA. Envie seus perfis de rede sem fio via Microsoft Intune, Jamf ou Diretiva de Grupo. Isso garante uma configuração de solicitante consistente e em conformidade com as políticas em toda a sua infraestrutura. Número três: use o TLS 1.2 como requisito mínimo em seu servidor RADIUS. Desative o TLS 1.0 e 1.1. A maioria das implementações modernas de RADIUS suporta isso, mas vale a pena verificar — especialmente em implantações locais mais antigas. Número quatro: integre com seu provedor de identidade. O PEAP-MSCHAPv2 autentica em um repositório de credenciais. Esse repositório deve ser seu provedor de identidade autoritativo — Active Directory, Azure AD via extensão NPS ou um serviço de RADIUS em nuvem com integração LDAP. Isso significa que, quando um funcionário sai, a desativação de sua conta revoga imediatamente seu acesso ao WiFi. Sem segredos compartilhados para rotacionar, sem desprovisionamento manual. Número cinco: considere sua rede de convidados separadamente. O PEAP é um método de autenticação empresarial. Para WiFi de convidados — onde você está integrando visitantes, clientes ou participantes de eventos — você precisa de uma abordagem diferente. Plataformas como a Purple oferecem uma camada de WiFi de convidados desenvolvida sob medida que lida com a autenticação de Captive Portal, captura de dados e análises sem exigir infraestrutura RADIUS no SSID de convidados. Mantenha seu SSID empresarial no 802.1X com PEAP e seu SSID de convidados em uma rede separada e isolada com a integração adequada. Número seis: planeje a rotação de certificados. O certificado do seu servidor RADIUS vai expirar. Quando isso acontecer, todos os clientes que fixaram esse certificado falharão na autenticação até que o novo certificado seja distribuído. Inclua a renovação de certificados em seu calendário operacional — pelo menos 90 dias antes do vencimento — e teste o processo de rotação em um ambiente de homologação antes de implantá-lo em produção. Os modos de falha mais comuns que vejo em campo são: validação de certificado não aplicada, levando à vulnerabilidade de rogue AP; certificados de servidor RADIUS que expiram sem aviso, causando falhas generalizadas de autenticação; e 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 planejamento adequado. Seção quatro: Perguntas rápidas. O PEAP pode funcionar com provedores de identidade em nuvem como o Azure AD? Sim. A extensão NPS da Microsoft para Azure AD MFA permite que você faça o proxy da autenticação PEAP por meio do Azure AD, habilitando a autenticação multifator em seu WiFi. Como alternativa, serviços de RADIUS em nuvem como Cisco ISE, Aruba ClearPass ou JumpCloud RADIUS podem se integrar diretamente com o Azure AD ou Okta. O PEAP está em conformidade com o PCI DSS? O PEAP-MSCHAPv2 pode ser usado em ambientes PCI DSS, mas você precisa garantir que a validação do certificado do servidor seja aplicada, que o TLS 1.2 ou superior esteja em uso e que o servidor RADIUS esteja devidamente segmentado. O PCI DSS 4.0 torna os requisitos de controle de acesso à rede mais rígidos — revise os requisitos relevantes com seu QSA. Devo migrar do PEAP para o EAP-TLS? Se você tiver uma implantação de MDM madura e capacidade operacional para gerenciar uma PKI, sim — o EAP-TLS é a escolha mais forte. Se você estiver gerenciando um parque misto com dispositivos pessoais, hardware legado ou cobertura de MDM limitada, o PEAP-MSCHAPv2 com configuração rigorosa continua sendo apropriado. Esta é uma decisão baseada em riscos, 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 ainda suporta métodos EAP, incluindo o PEAP. O WPA3 melhora a criptografia over-the-air, mas não altera a troca de autenticação EAP em si. Seçã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 implantado porque elimina a necessidade de certificados de cliente, ao mesmo tempo em que fornece uma autenticação de servidor forte. Sua principal vulnerabilidade são os ataques de AP invasores (rogue AP) possibilitados por suplicantes mal configurados que não validam o certificado do servidor. Mitigue isso por meio de perfis sem fio aplicados por MDM, pinning de CA e validação de nome de servidor. Para a maioria das implantações de WiFi corporativo — escritórios corporativos, redes de back-of-house de hotéis, redes de funcionários de varejo — o PEAP-MSCHAPv2 com a configuração correta é uma escolha sólida e defensável. Para ambientes de alta segurança, setores regulamentados ou organizações com infraestrutura de PKI madura, o EAP-TLS oferece uma segurança significativamente mais forte e deve ser a arquitetura-alvo. Se você também opera WiFi para convidados junto com sua rede corporativa — e a maioria de vocês opera —, lembre-se de que o PEAP não é a ferramenta certa para a integração de convidados. Conheça plataformas como a Purple, que oferecem autenticação de WiFi para convidados desenvolvida sob medida com análises, captura de dados e integração de marketing, mantendo o tráfego de convidados e corporativo devidamente separados e sua postura de conformidade intacta. Para leituras adicionais, confira os guias da Purple sobre arquitetura de servidor RADIUS e autenticação de WiFi corporativo. Os links estão nas notas do programa. Obrigado por ouvir. Este foi um Informativo de Inteligência de WiFi Corporativo da Purple.