Como Configurar a Autenticação WiFi 802.1X: Um Guia Passo a Passo

Como Configurar a Autenticação WiFi 802.1X: Um Guia Passo a Passo Um Podcast da Purple Enterprise WiFi Intelligence [INTRODUÇÃO — aproximadamente 1 minuto] Bem-vindo de volta. Falo hoje como arquiteto sénior de soluções e, se está a ouvir isto, é provável que esteja a enfrentar um projeto de segurança de rede que envolve a autenticação 802.1X - seja porque a sua equipa de conformidade o sinalizou, a sua seguradora perguntou sobre isso, ou simplesmente herdou uma rede que funciona com uma PSK partilhada e sabe que isso já não é suficiente. Por isso, vamos directos ao assunto. O 802.1X é o padrão IEEE para controlo de acesso à rede baseado em portas. É a espinha dorsal da segurança WiFi empresarial - o mecanismo que garante que cada dispositivo que se liga à sua rede foi positivamente identificado e autorizado antes de receber um único byte de tráfego. Isto não é opcional para organizações que lidam com dados de cartões de pagamento sob o PCI-DSS, não é opcional para ambientes de saúde sob o GDPR e os padrões de segurança de dados do NHS e, francamente, para qualquer organização que execute mais do que um punhado de pontos de acesso, é a arquitetura correta. Nos próximos dez minutos, vou guiá-lo através da arquitetura técnica, da configuração RADIUS, da implementação de certificados e dos cenários do mundo real onde isto se torna complicado. Vamos a isso. [MERGULHO TÉCNICO PROFUNDO — aproximadamente 5 minutos] Certo, então a estrutura do 802.1X tem três componentes. Tem o Supplicant - que é o dispositivo cliente, o portátil, o telemóvel, o sensor IoT. Tem o Authenticator - que é o seu ponto de acesso ou o seu comutador de rede, por vezes chamado de NAS, o Network Access Server. E tem o Authentication Server - quase universalmente um servidor RADIUS em implementações empresariais. Eis como funciona o handshake. Quando um dispositivo tenta ligar-se a um SSID protegido por 802.1X, o ponto de acesso não se limita a deixá-lo entrar. Em vez disso, abre o que se chama uma porta controlada - um canal limitado que apenas passa tráfego EAP, o Extensible Authentication Protocol. O AP envia um EAP-Request Identity para o dispositivo. O dispositivo responde com a sua identidade. O AP encaminha então isso para o servidor RADIUS, encapsulado num pacote RADIUS Access-Request. O servidor RADIUS executa a autenticação - verificando as credenciais no Active Directory, num repositório de certificados ou em qualquer backend de identidade que tenha configurado - e envia de volta um Access-Accept ou um Access-Reject. Apenas mediante um Accept é que o AP abre a porta de dados completa e atribui o dispositivo à VLAN apropriada. Agora, o método EAP que escolher aqui importa enormemente. Existem cinco que irá encontrar em implementações empresariais.O EAP-TLS é o padrão de excelência. Tanto o cliente como o servidor apresentam certificados X.509. Não há palavras-passe envolvidas. É a opção mais segura e a exigida para os níveis mais elevados de conformidade PCI-DSS. O senão é que precisa de uma PKI completa - uma Infraestrutura de Chaves Públicas - para emitir e gerir certificados de cliente. Isso significa uma Autoridade de Certificação, gestão do ciclo de vida dos certificados e um mecanismo para enviar os certificados para todos os dispositivos. Para organizações com o Microsoft Active Directory e Active Directory Certificate Services, isto é muito viável. Para organizações sem essa infraestrutura, representa um investimento significativo. O PEAP-MSCHAPv2 é o método mais amplamente implementado na prática. Cria um túnel TLS utilizando apenas um certificado do lado do servidor e, em seguida, transmite as credenciais de nome de utilizador e palavra-passe dentro desse túnel. É compatível com praticamente todos os dispositivos por predefinição, integra-se diretamente com o Active Directory através do NPS no Windows Server e não requer certificados de cliente. A desvantagem é que é vulnerável a ataques de recolha de credenciais se os utilizadores forem induzidos a ligar-se a um AP não autorizado - porque o cliente não valida o certificado do servidor por predefinição. Deve impor a validação do certificado do servidor nos seus perfis de suplicante. O EAP-TTLS é semelhante ao PEAP, mas mais flexível no método de autenticação interno. É comum em ambientes Linux e onde necessita de suportar sistemas de autenticação legados. O EAP-FAST foi desenvolvido pela Cisco como resposta às fraquezas do LEAP. Utiliza Protected Access Credentials em vez de certificados. É relevante principalmente se estiver num ambiente maioritariamente Cisco ou a lidar com dispositivos legados que não conseguem suportar os outros. O EAP-SIM e o EAP-AKA são utilizados em implementações de nível de operador - pense em OpenRoaming ou Passpoint - onde a autenticação está associada a um cartão SIM ou USIM. Estes são cada vez mais relevantes para redes WiFi de locais públicos onde deseja uma integração segura e contínua sem um Captive Portal. Agora vamos falar sobre a configuração RADIUS. Quer esteja a implementar o Microsoft NPS, FreeRADIUS, Cisco ISE ou Aruba ClearPass, os passos de configuração principais são os mesmos. Primeiro, define os seus clientes RADIUS - estes são os seus pontos de acesso ou controladores de LAN sem fios. Cada cliente é registado com o seu endereço IP e um segredo partilhado. Esse segredo partilhado é utilizado para autenticar as mensagens RADIUS entre o AP e o servidor. Utilize um mínimo de 22 carateres, gerados aleatoriamente e únicos por dispositivo NAS. Segundo, configura a sua política de rede. É aqui que define quem tem acesso a quê. Em termos de NPS, está a criar uma Política de Rede que corresponde a condições - pertença a grupos no Active Directory, tipo de dispositivo, hora do dia - e atribui atributos - VLAN ID, tempo limite da sessão, limites de largura de banda. O atributo RADIUS que mais utilizará é a atribuição de VLAN, especificamente o Tunnel-Type definido como VLAN, o Tunnel-Medium-Type definido como 802 e o Tunnel-Private-Group-ID definido com o número da sua VLAN. Terceiro, configura a sua política de pedido de ligação. Isto indica ao NPS como processar os pedidos RADIUS recebidos - se deve autenticar localmente ou reencaminhar para outro servidor RADIUS. Numa implementação distribuída, poderá ter um servidor RADIUS central com proxies NPS em cada local. No que diz respeito aos certificados, para PEAP e EAP-TLS, o seu servidor RADIUS necessita de um certificado de servidor fidedigno para os seus clientes. O caminho mais simples é utilizar um certificado de uma CA pública - DigiCert, Sectigo, Let's Encrypt - porque esses certificados raiz já são fidedignos para todos os principais sistemas operativos. Se estiver a utilizar uma CA interna, precisa de enviar o certificado raiz para todos os dispositivos cliente através de Política de Grupo ou da sua plataforma de MDM. Especificamente para EAP-TLS, também necessita de certificados de cliente. Num ambiente Active Directory, utilizaria o ADCS com inscrição automática através de Política de Grupo para enviar certificados para dispositivos associados ao domínio. Para dispositivos BYOD, utilizaria o seu MDM - Intune, Jamf, VMware Workspace ONE - para enviar tanto o certificado como o perfil de WiFi. Do lado do ponto de acesso, a configuração é simples. Cria um novo SSID, define a segurança para WPA2-Enterprise ou WPA3-Enterprise, aponta o servidor de autenticação RADIUS para o IP do seu NPS na porta UDP 1812, define o servidor de faturação RADIUS na porta UDP 1813, introduz o segredo partilhado e ativa a atribuição dinâmica de VLAN se a estiver a utilizar. A maioria das plataformas de AP empresariais - Cisco Meraki, Aruba, Ruckus, Extreme - tem uma GUI para isto que demora cerca de dez minutos a configurar assim que o seu servidor RADIUS estiver pronto. [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS - aproximadamente 2 minutos] Muito bem, vamos falar sobre onde as implementações costumam falhar, porque é aqui que eu justifico os meus honorários de consultoria. O ponto de falha mais comum é a validação de certificados. Já vi organizações a implementar o PEAP-MSCHAPv2 corretamente no lado do servidor, mas a deixar os perfis de suplicante do cliente configurados para aceitar qualquer certificado. Isso compromete totalmente o modelo de segurança. Cada perfil de suplicante - quer seja enviado via Política de Grupo ou MDM - tem de especificar a CA raiz fidedigna e o nome de servidor esperado. Sem isso, fica vulnerável a ataques de evil twin. O segundo problema comum é a gestão do segredo partilhado RADIUS. Já vi redes de produção em funcionamento com o segredo partilhado definido como "radius" ou o predefinido do fornecedor. Estes segredos são as chaves da sua infraestrutura de autenticação. Gere-os aleatoriamente, guarde-os num gestor de segredos e rode-os de forma programada. Terceiro: configuração incorreta de VLAN. A atribuição dinâmica de VLAN é poderosa - permite colocar dispositivos de funcionários na VLAN corporativa, prestadores de serviços numa VLAN restrita e dispositivos IoT numa VLAN isolada, tudo a partir do mesmo SSID. Mas se os atributos RADIUS não estiverem configurados corretamente, ou se as portas trunk do switch não estiverem a transportar as VLANs corretas, os dispositivos não se conseguirão ligar ou irão parar ao segmento errado. Teste isto exaustivamente num laboratório antes de avançar para a produção. Quarto: redundância. O seu servidor RADIUS é agora uma peça crítica de infraestrutura. Se ele falhar, ninguém se liga. Precisa, no mínimo, de um servidor RADIUS primário e secundário configurado em cada AP. Em grandes implementações, considere clusters de proxy RADIUS com monitorização de integridade. Quinto, e isto é específico para ambientes de hotelaria e retalho: separação entre convidados e corporativo. O seu SSID corporativo 802.1X e o seu SSID de WiFi de convidados devem ser completamente separados - VLANs diferentes, políticas de firewall diferentes, DNS diferente. Uma plataforma como a Purple gere o lado dos convidados com o seu próprio captive portal e camada de analítica, enquanto a sua infraestrutura 802.1X gere o lado corporativo. Estes são sistemas complementares, não concorrentes. [PERGUNTAS E RESPOSTAS RÁPIDAS - aproximadamente 1 minuto] Vou responder rapidamente às perguntas que recebo com mais frequência. Posso executar 802.1X numa plataforma de AP gerida na nuvem? Sim - Meraki, Aruba Central e Ruckus Cloud suportam. Configura os detalhes do servidor RADIUS no painel de controlo na nuvem, e os APs tratam do proxy EAP. Preciso do Active Directory? Não. O FreeRADIUS pode autenticar contra LDAP, bases de dados SQL, ficheiros simples ou até APIs REST. Mas a integração AD via NPS é, de longe, o caminho empresarial mais comum. E quanto aos dispositivos IoT que não suportam 802.1X? Use MAC Authentication Bypass - MAB - como alternativa. O endereço MAC do dispositivo é enviado para o RADIUS como o nome de utilizador e a palavra-passe. Não é tão seguro como o EAP, mas permite registar dispositivos IoT mantendo-os numa VLAN restrita. O 802.1X funciona com WPA3? Sim. O WPA3-Enterprise é essencialmente WPA3 com autenticação 802.1X. Adiciona uma encriptação mais forte - 192 bits no modo de alta segurança - e é o padrão recomendado para novas implementações. [RESUMO E PRÓXIMOS PASSOS - aproximadamente 1 minuto] Portanto, para resumir: o 802.1X não é um extra opcional. Para qualquer organização que lide com dados sensíveis, processe pagamentos ou opere num ambiente regulado, é a base para a segurança de WiFi empresarial. A arquitetura está bem estabelecida, as ferramentas são maduras e o caminho de implementação é claro. Comece pela seleção do seu método EAP - PEAP-MSCHAPv2 se precisar de vitórias rápidas e ampla compatibilidade, EAP-TLS se tiver a infraestrutura PKI e precisar de uma postura de segurança mais robusta. Configure o seu servidor RADIUS e garanta a redundância antes de tocar num único AP. Implemente os seus perfis de suplicante via Group Policy ou MDM antes de entrar em funcionamento. E mantenha o seu WiFi de convidados completamente separado - use uma plataforma concebida especificamente para essa camada. Se opera num ambiente de múltiplos locais - hotéis, cadeias de retalho, estádios - a complexidade aumenta com o número de locais, mas a arquitetura não muda. A chave é o RADIUS centralizado com redundância local por site, e um perfil de suplicante consistente implementado via MDM em toda a sua frota de dispositivos. Obrigado por ouvir. O guia escrito completo, os diagramas de arquitetura e as listas de verificação de configuração estão disponíveis em purple.ai. Se está a planear uma implementação 802.1X e deseja discutir as especificidades do seu ambiente, contacte diretamente a equipa Purple.