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 Purple Enterprise WiFi. Boas-vindas. Se você é responsável pela segurança de rede de um grupo hoteleiro, de uma rede de varejo, de um estádio ou de uma organização do setor público, este informativo é para você. Nos próximos dez minutos, vamos abordar a autenticação PEAP - o que ela realmente é, como funciona nos bastidores, onde se encaixa em sua arquitetura de segurança e, principalmente, quando é a escolha certa e quando você deve procurar algo mais robusto. Vamos começar. Seção um: Contexto e por que isso importa agora. A maioria das implantações de WiFi empresarial hoje ainda depende de um de dois modelos de autenticação. Ou você tem uma chave pré-compartilhada - uma única senha compartilhada por toda a organização - ou você 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. A razão pela 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 laptop, cada telefone, cada tablet. Para uma organização com quinhentos funcionários e uma política de BYOD, isso representava 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 nome 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 empresarial 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: Mergulho técnico profundo. Vamos detalhar 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 - que é o dispositivo cliente, seja um laptop, 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 é 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 armazenamento 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 relação ao seu armazenamento de identidade, que pode ser o Active Directory, LDAP ou um provedor de identidade em nuvem. Se as credenciais forem válidas, o servidor RADIUS envia uma mensagem Access-Accept de volta através do autenticador, e o cliente recebe acesso à rede. 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 de 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 criar um ponto de acesso invasor, 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 solicitante: impor a validação do certificado do servidor, fixar a CA esperada e especificar o nome comum 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 AP invasor descrito acima - ele pode tentar recuperar a senha em texto não criptografado offline. A força da sua política de senhas, portanto, 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. Essas 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 suplicante. Este é o item de configuração mais importante de todos. No Windows, essa é 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 AP invasores, independentemente de quão bem o restante 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 ignorarão os avisos de certificado clicando neles. Eles configurarão incorretamente o campo CA. Distribua seus perfis de rede sem fio via Microsoft Intune, Jamf ou Diretiva de Grupo. Isso garante uma configuração de suplicante consistente e em conformidade com as políticas em todo o seu parque tecnológico. Número três: use 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 isso, mas vale a pena verificar - principalmente em implantações locais mais antigas. Número quatro: integre com seu provedor de identidade. O PEAP-MSCHAPv2 autentica em relação a um repositório de credenciais. Esse repositório deve ser o seu provedor de identidade autoritativo - Active Directory, Azure AD via extensão NPS ou um serviço RADIUS em nuvem com integração LDAP. Isso significa que, quando um funcionário sai, a desativação de sua conta revoga imediatamente o acesso dele 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 corporativo. 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 gerencia a autenticação de Captive Portal, captura de dados e análise de dados sem exigir infraestrutura RADIUS no SSID de convidados. Mantenha seu SSID corporativo em 802.1X com PEAP, e seu SSID de convidados em uma rede separada e isolada com a integração apropriada. Número seis: planeje a rotação de certificados. O certificado do seu servidor RADIUS vai expirar. Quando isso acontecer, cada cliente que tiver fixado esse certificado falhará na autenticação até que o novo certificado seja distribuído. Inclua 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 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 forçada, levando à vulnerabilidade de AP invasor; certificados de servidor RADIUS que expiram sem aviso, causando falhas de autenticação generalizadas; 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 através 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 ser integrados 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 mais rígidos em relação aos controles de acesso à rede - revise os requisitos relevantes com seu QSA. Devo migrar do PEAP para o EAP-TLS? Se você tem 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 ambiente misto com dispositivos pessoais, hardware legado ou cobertura limitada de MDM, o PEAP-MSCHAPv2 com configuração rigorosa continua sendo apropriado. Esta é uma decisão baseada em riscos, não uma escolha binária. E sobre o WPA3-Enterprise? O WPA3-Enterprise exige o modo de segurança de 192 bits para ambientes de alta segurança, mas ainda oferece suporte a métodos EAP, incluindo 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 as credenciais internas - normalmente MSCHAPv2 - dentro de um túnel TLS. É o método EAP 802.1X mais amplamente implantado porque elimina a necessidade de certificados de cliente, ao mesmo tempo em que fornece uma autenticação forte de servidor. Sua principal vulnerabilidade são os ataques de APs maliciosos facilitados 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 retaguarda 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, indústrias regulamentadas ou organizações com infraestrutura PKI madura, o EAP-TLS fornece uma segurança significativamente mais forte e deve ser a arquitetura de destino. 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 o Purple, que fornecem 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 do 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 do Purple.