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 WiFi empresarial 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 em comparação com quando deve procurar algo mais robusto. Vamos a isso. Secção um: Contexto e porque é que isto é importante agora. A maioria das implementações de WiFi empresarial atuais ainda depende de um de dois modelos de autenticação. Ou tem uma chave pré-partilhada - uma única palavra-passe partilhada em 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 todos os dispositivos - todos os portáteis, todos os telemóveis, todos os tablets. Para uma organização com quinhentos funcionários e uma política de BYOD, isso representava 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 através de TLS, com credenciais de utilizador e palavra-passe do lado do cliente. Sem necessidade de certificados de cliente. Esse compromisso tornou o PEAP a norma de facto para a autenticação WiFi empresarial ao longo das décadas de 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 através de 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, quer 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 imediato. Em vez disso, inicia uma troca EAP através da rede local - isto é o EAPOL, EAP sobre LAN. O autenticador reencaminha 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 identidade na nuvem. Se as credenciais forem válidas, o servidor RADIUS envia uma mensagem Access-Accept de volta através do autenticador, e é concedido ao cliente o acesso à rede. 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. Esse é o principal valor acrescentado 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 AC - 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 AC esperada e especificar o common name do servidor. Isto não é negociável em qualquer implementação séria. Segundo: o MSCHAPv2 é um protocolo antigo com fragilidades conhecidas. A investigação de 2012 de Moxie Marlinspike demonstrou que os pares de desafio-resposta do MSCHAPv2 podem ser decifrados offline com poder computacional suficiente. Se um atacante capturar a troca de autenticação interna - por exemplo, através do ataque de ponto de acesso fictício descrito acima - ele pode tentar recuperar a palavra-passe em texto simples 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 cada dispositivo. Para organizações com uma implementação madura de MDM 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 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: imponha a validação do certificado do servidor em todos os suplicantes. Este é o item de configuração mais importante de todos. No Windows, esta é a caixa de seleção "Validar certificado do servidor" no perfil da rede sem fios. No iOS e Android, é o campo de 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 do quão bem tudo o resto esteja configurado. Número dois: implemente através de MDM ou GPO, não por configuração manual. A configuração manual pelos utilizadores finais não é fiável. Os utilizadores irão ignorar os avisos de certificado. Irã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. Isto garante uma configuração de suplicante consistente e em conformidade com as políticas em todo o seu parque informático. Número três: utilize o TLS 1.2 como limite 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 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 de referência - Active Directory, Azure AD através da extensão NPS, ou um serviço cloud RADIUS com integração LDAP. Isto significa que, quando um funcionário sai, a desativação da sua conta revoga imediatamente o seu acesso à WiFi. Sem segredos partilhados para rodar, sem desprovisionamento manual. Número cinco: considere a sua rede de convidados separadamente. O PEAP é um método de autenticação empresarial. Para a WiFi de convidados - onde está a acolher visitantes, clientes ou participantes de eventos - precisa de uma abordagem diferente. Plataformas como a Purple fornecem uma camada de WiFi de convidados desenvolvida especificamente para o efeito que gere a autenticação em Captive Portal, a recolha de dados e a análise analítica 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 o acolhimento adequado. Número seis: planeie a rotação de certificados. O certificado do seu servidor RADIUS irá expirar. Quando isso acontecer, todos os clientes que tenham associado esse certificado falharão 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: validação de certificado não imposta, levando a vulnerabilidade a 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 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-lhe fazer o proxy da autenticação PEAP através do Azure AD, ativando a autenticação multifator no seu WiFi. Alternativamente, serviços de RADIUS na nuvem como 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 precisa de garantir que a validação do certificado do servidor é imposta, que o TLS 1.2 ou superior está em uso e que o servidor RADIUS está devidamente segmentado. O PCI-DSS 4.0 aperta 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 limitada de MDM, 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 um 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 - tipicamente MSCHAPv2 - dentro de um túnel TLS. É o método 802.1X EAP mais amplamente implementado porque elimina a necessidade de certificados de cliente, ao mesmo tempo que fornece 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 wireless impostos por MDM, pinning de CA e validação do nome do servidor. Para a maioria das implementações de WiFi empresarial - 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 regulamentadas ou organizações com uma infraestrutura PKI madura, o EAP-TLS fornece uma segurança significativamente mais forte e deve ser a arquitetura-alvo. Se também estiver a executar WiFi para convidados juntamente com a sua rede corporativa - e a maioria de vós está - lembre-se de que o PEAP não é a ferramenta certa para a integração de convidados. Analise plataformas como a Purple, que fornecem autenticação de WiFi para convidados concebida especificamente para o efeito com análises, captura de dados e integração de marketing, mantendo o tráfego de convidados e o tráfego corporativo 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 de WiFi empresarial. Os links estão nas notas do programa. Obrigado por ouvir. Esta foi uma Apresentação de Informação de WiFi Empresarial da Purple.