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. Estou falando hoje como arquiteto sênior de soluções e, se você está ouvindo isso, provavelmente está diante de um projeto de segurança de rede que envolve a autenticação 802.1X - seja porque sua equipe de conformidade sinalizou isso, sua seguradora perguntou a respeito ou você acabou de herdar uma rede que está rodando em uma PSK compartilhada e sabe que isso não é mais suficiente. Então vamos direto ao assunto. O 802.1X é o padrão IEEE para controle de acesso à rede baseado em porta. Ele é a espinha dorsal da segurança de WiFi corporativo - o mecanismo que garante que cada dispositivo conectado à sua rede seja positivamente identificado e autorizado antes de transmitir um único byte de tráfego. Isso não é opcional para organizações que lidam com dados de cartões de pagamento sob PCI-DSS, não é opcional para ambientes de saúde sob a GDPR e os padrões de segurança de dados do NHS e, francamente, para qualquer organização que opere mais do que um punhado de pontos de acesso, é a arquitetura correta. Nos próximos dez minutos, vou guiar você pela arquitetura técnica, pela configuração do RADIUS, pela implantação de certificados e pelos cenários do mundo real onde isso se complica. Vamos lá. [IMERSÃO TÉCNICA - aproximadamente 5 minutos] Certo, então o framework do 802.1X possui três componentes. Você tem o Supplicant - que é o dispositivo do cliente, o laptop, o telefone, o sensor de IoT. Você tem o Authenticator - que é o seu ponto de acesso ou o seu switch de rede, às vezes chamado de NAS, o Network Access Server. E você tem o Authentication Server - quase universalmente um servidor RADIUS em implantações corporativas. Aqui está como o handshake funciona. Quando um dispositivo tenta se conectar a um SSID protegido por 802.1X, o ponto de acesso não apenas o deixa entrar. Em vez disso, ele abre o que é chamado de porta controlada - um canal limitado que apenas passa o tráfego EAP, o Extensible Authentication Protocol. O AP envia um EAP-Request Identity para o dispositivo. O dispositivo responde com sua identidade. O AP então encaminha isso para o servidor RADIUS, encapsulado em um pacote RADIUS Access-Request. O servidor RADIUS executa a autenticação - verificando as credenciais no Active Directory, em um repositório de certificados ou em qualquer backend de identidade que você tenha configurado - e envia de volta um Access-Accept ou um Access-Reject. Somente em caso de Accept o AP abre a porta de dados completa e atribui o dispositivo à VLAN apropriada. Agora, o método EAP que você escolhe aqui importa enormemente. Existem cinco que você encontrará em implantações corporativas. O EAP-TLS é o padrão ouro. Tanto o cliente quanto o servidor apresentam certificados X.509. Não há senhas envolvidas. É a opção mais segura e a exigida para os níveis mais altos de conformidade PCI-DSS. O detalhe é que você precisa de uma PKI completa - uma Infraestrutura de Chaves Públicas - para emitir e gerenciar certificados de cliente. Isso significa uma Autoridade Certificadora, gerenciamento do ciclo de vida dos certificados e um mecanismo para enviar os certificados para todos os dispositivos. Para organizações com Microsoft Active Directory e Active Directory Certificate Services, isso é totalmente viável. Para organizações sem essa infraestrutura, representa um investimento significativo. O PEAP-MSCHAPv2 é o método mais amplamente implantado na prática. Ele cria um túnel TLS usando apenas um certificado do lado do servidor e, em seguida, passa as credenciais de usuário e senha dentro desse túnel. É compatível com praticamente qualquer dispositivo de forma nativa, integra-se diretamente com o Active Directory via NPS no Windows Server e não exige certificados de cliente. A desvantagem é que ele é vulnerável a ataques de captura de credenciais caso os usuários sejam induzidos a se conectar a um AP falso - porque o cliente não valida o certificado do servidor por padrão. Você deve impor a validação do certificado do servidor em 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 você precisa oferecer suporte a backends de autenticação legados. O EAP-FAST foi desenvolvido pela Cisco como uma resposta às fraquezas do LEAP. Ele usa credenciais de acesso protegido (Protected Access Credentials) em vez de certificados. É relevante principalmente se você estiver em um ambiente focado em Cisco ou lidando com dispositivos legados que não suportam os outros métodos. O EAP-SIM e o EAP-AKA são usados em implantações de nível de operadora - como OpenRoaming ou Passpoint - onde a autenticação está vinculada a um cartão SIM ou USIM. Estes são cada vez mais relevantes para redes WiFi de locais públicos onde você deseja uma integração segura e contínua sem um Captive Portal. Agora vamos falar sobre a configuração RADIUS. Seja implantando o Microsoft NPS, FreeRADIUS, Cisco ISE ou Aruba ClearPass, as etapas principais de configuração são as mesmas. Primeiro, você define seus clientes RADIUS - que são seus pontos de acesso ou controladores de LAN sem fio. Cada cliente é registrado com seu endereço IP e um segredo compartilhado. Esse segredo compartilhado é usado para autenticar as mensagens RADIUS entre o AP e o servidor. Use um mínimo de 22 caracteres, gerados aleatoriamente e exclusivos por dispositivo NAS. Segundo, você configura sua política de rede. É aqui que você define quem tem acesso a quê. Em termos de NPS, você está criando uma Política de Rede que corresponde a condições - associação a grupos no Active Directory, tipo de dispositivo, hora do dia - e atribui atributos - VLAN ID, tempo limite de sessão, limites de largura de banda. O atributo RADIUS que você mais usará é a atribuição de VLAN, especificamente o Tunnel-Type definido como VLAN, Tunnel-Medium-Type definido como 802 e Tunnel-Private-Group-ID definido como o número da sua VLAN. Em terceiro lugar, você configura sua política de solicitação de conexão. Isso informa ao NPS como lidar com as solicitações RADIUS recebidas - se deve autenticar localmente ou encaminhar para outro servidor RADIUS. Em uma implantação distribuída, você pode ter um servidor RADIUS central com proxies NPS em cada site. No lado do certificado, para PEAP e EAP-TLS, seu servidor RADIUS precisa de um certificado de servidor confiável para seus clientes. O caminho mais simples é usar um certificado de uma CA pública - DigiCert, Sectigo, Let's Encrypt - porque esses certificados raiz já são confiáveis para todos os principais sistemas operacionais. Se você estiver usando uma CA interna, precisará enviar o certificado raiz para todos os dispositivos clientes por meio de Política de Grupo ou de sua plataforma MDM. Especificamente para EAP-TLS, você também precisa de certificados de cliente. Em um ambiente Active Directory, você usaria o ADCS com registro automático via Política de Grupo para enviar certificados a dispositivos ingressados no domínio. Para dispositivos BYOD, você usaria seu MDM - Intune, Jamf, VMware Workspace ONE - para enviar o certificado e o perfil de WiFi. No lado do ponto de acesso, a configuração é simples. Você cria um novo SSID, define a segurança como 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 bilhetagem RADIUS na porta UDP 1813, insere o segredo compartilhado e ativa a atribuição dinâmica de VLAN se estiver usando-a. A maioria das plataformas de AP corporativas - Cisco Meraki, Aruba, Ruckus, Extreme - possui uma interface gráfica para isso que leva cerca de dez minutos quando o seu servidor RADIUS estiver pronto. [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ARMADILHAS - aproximadamente 2 minutos] Certo, vamos falar sobre onde as implantações dão errado, porque é aqui que eu ganho minhas taxas de consultoria. O ponto de falha mais comum é a validação do certificado. Tenho visto organizações implantarem o PEAP-MSCHAPv2 corretamente no lado do servidor e, em seguida, deixarem os perfis do suplicante do cliente configurados para aceitar qualquer certificado. Isso compromete totalmente o modelo de segurança. Cada perfil de suplicante - seja enviado por meio de Política de Grupo ou MDM - deve especificar a CA raiz confiável e o nome do servidor esperado. Sem isso, você estará vulnerável a ataques de evil twin. O segundo problema comum é o gerenciamento do segredo compartilhado do RADIUS. Já vi redes de produção rodando com o segredo compartilhado definido como "radius" ou o padrão do fabricante. Esses segredos são as chaves da sua infraestrutura de autenticação. Gere-os aleatoriamente, armazene-os em um gerenciador de segredos e faça a rotação deles periodicamente. Terceiro: configuração incorreta de VLAN. A atribuição dinâmica de VLAN é poderosa - ela permite colocar dispositivos de funcionários na VLAN corporativa, prestadores de serviços em uma VLAN restrita e dispositivos IoT em uma VLAN isolada, tudo a partir do mesmo SSID. Mas se os atributos RADIUS não estiverem configurados corretamente, ou se as portas de tronco do switch não estiverem transportando as VLANs corretas, os dispositivos falharão ao se conectar ou cairão no segmento errado. Teste isso exaustivamente em um laboratório antes de implantar em produção. Quarto: redundância. O seu servidor RADIUS agora é uma peça crítica de infraestrutura. Se ele cair, ninguém se conecta. Você precisa de, no mínimo, um servidor RADIUS primário e secundário configurado em cada AP. Em grandes implantações, considere clusters proxy RADIUS com monitoramento de status. Quinto, e isto é específico para ambientes de hotelaria e varejo: separação entre rede de convidados e corporativa. 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 o Purple gerencia o lado dos convidados com o seu próprio Captive Portal e camada de análise, enquanto a sua infraestrutura 802.1X gerencia o lado corporativo. Estes são sistemas complementares, não concorrentes. [perguntas e respostas rápidas - aproximadamente 1 minuto] Vou passar pelas perguntas que recebo com mais frequência. Posso executar 802.1X em uma plataforma de AP gerenciada em nuvem? Sim - Meraki, Aruba Central e Ruckus Cloud suportam essa função. Você configura os detalhes do servidor RADIUS no painel da nuvem, e os APs cuidam do proxying de EAP. Preciso de Active Directory? Não. O FreeRADIUS pode autenticar em LDAP, bancos de dados SQL, arquivos planos ou até mesmo APIs REST. Mas a integração com 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 ao RADIUS como nome de usuário e senha. Não é tão seguro quanto o EAP, mas permite integrar dispositivos IoT mantendo-os em uma VLAN restrita. O 802.1X funciona com WPA3? Sim. O WPA3-Enterprise é essencialmente WPA3 com autenticação 802.1X. Ele adiciona uma criptografia mais forte - 192 bits no modo de alta segurança - e é o padrão recomendado para novas implantações. [RESUMO E PRÓXIMOS PASSOS - aproximadamente 1 minuto] Resumindo: o 802.1X não é um recurso opcional. Para qualquer organização que lide com dados confidenciais, processe pagamentos ou opere em um ambiente regulamentado, ele é a base da segurança de WiFi corporativo. A arquitetura está bem estabelecida, as ferramentas são maduras e o caminho de implantação é claro. Comece com a seleção do seu método EAP - PEAP-MSCHAPv2 se você precisa de resultados rápidos e ampla compatibilidade, ou EAP-TLS se você tiver a infraestrutura de PKI e precisar da postura de segurança mais robusta. Configure o seu servidor RADIUS e garanta a redundância antes de tocar em um único AP. Distribua os perfis de suplicante via Diretiva de Grupo ou MDM antes de entrar em operação. E mantenha o seu WiFi de convidados completamente separado - use uma plataforma dedicada para essa camada. Se você opera um ambiente multi-local - hotéis, redes de varejo, 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 distribuído 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 você está planejando uma implantação de 802.1X e quer discutir as especificidades do seu ambiente, entre em contato diretamente com a equipe da Purple.