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 de soluções sénior e, se está a ouvir isto, provavelmente está 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 está a funcionar 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 conseguir passar um único byte de tráfego. Isto não é opcional para organizações que lidam com dados de cartões de pagamento sob a norma PCI DSS, não é opcional para ambientes de saúde sob o GDPR e as normas 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 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] Muito bem, a estrutura do 802.1X tem três componentes. Temos o Supplicant — que é o dispositivo cliente, o portátil, o telemóvel, o sensor IoT. Temos o Authenticator — que é o seu ponto de acesso ou o seu switch de rede, por vezes chamado de NAS, o Network Access Server. E temos 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 é chamado de 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 essa informação para o servidor RADIUS, envolvida 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 num Accept é que o AP abre a porta de dados completa e atribui o dispositivo à VLAN apropriada. Agora, o método EAP que escolher aqui é extremamente importante. 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 necessita 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 certificados para todos os dispositivos. Para organizações com Microsoft Active Directory e Active Directory Certificate Services, isto é perfeitamente realizá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, passa as credenciais de utilizador e palavra-passe dentro desse túnel. É compatível com praticamente todos os dispositivos de imediato, 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 ligarem-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 interna. É 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 Credenciais de Acesso Protegido em vez de certificados. É relevante principalmente se estiver num ambiente predominantemente Cisco ou a lidar com dispositivos legados que não suportam os outros. O EAP-SIM e o EAP-AKA são utilizados em implementações de nível de operador — como OpenRoaming ou Passpoint — onde a autenticação está associada a um cartão SIM ou USIM. Estes são cada vez mais relevantes para WiFi em locais públicos onde se pretende uma integração segura e contínua sem um Captive Portal. Agora vamos falar sobre a configuração de RADIUS. Quer esteja a implementar 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 caracteres, 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 — ID de VLAN, limite de tempo da sessão, limites de largura de banda. O atributo RADIUS que mais utilizará é a atribuição de VLAN, especificamente Tunnel-Type definido como VLAN, Tunnel-Medium-Type definido como 802 e Tunnel-Private-Group-ID definido como o seu número de VLAN. Terceiro, configura a sua política de pedido de ligação. Isto indica ao NPS como lidar com 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 de raiz já são fidedignos para todos os principais sistemas operativos. Se estiver a utilizar uma CA interna, terá de enviar o certificado de raiz para todos os dispositivos clientes através de Política de Grupo ou da sua plataforma 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 contabilidade 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 interface gráfica 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 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 e, depois, 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 — deve especificar a CA de 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 do RADIUS. Já vi redes de produção a funcionar com o segredo partilhado definido como "radius" ou com o valor predefinido do fabricante. Estes segredos são as chaves da sua infraestrutura de autenticação. Gere-os de forma aleatória, guarde-os num gestor de segredos e rode-os periodicamente. Terceiro: configuração incorreta de VLAN. A atribuição dinâmica de VLAN é poderosa — permite-lhe 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 de 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 implementações de grande escala, 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 guest WiFi devem ser completamente separados — diferentes VLANs, diferentes políticas de firewall, diferentes DNS. Uma plataforma como a Purple lida com o lado dos convidados com o seu próprio captive portal e camada de analítica, enquanto a sua infraestrutura 802.1X lida com o lado corporativo. Estes são sistemas complementares, não concorrentes. [Q&A RÁPIDO — aproximadamente 1 minuto] Vou responder rapidamente às perguntas que recebo com mais frequência. Posso executar o 802.1X numa plataforma de AP gerida na cloud? Sim — Meraki, Aruba Central e Ruckus Cloud suportam-no. Configura os detalhes do servidor RADIUS no painel da cloud e os APs tratam do proxying 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 com AD via NPS é, de longe, o caminho empresarial mais comum. E quanto aos dispositivos IoT que não suportam 802.1X? Utilize o MAC Authentication Bypass — MAB — como alternativa. O endereço MAC do dispositivo é enviado para o RADIUS como nome de utilizador e palavra-passe. Não é tão seguro como o EAP, mas permite integrar 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] 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 resultados rápidos e ampla compatibilidade, EAP-TLS se tiver a infraestrutura PKI e precisar da postura de segurança mais forte. Configure o seu servidor RADIUS e garanta a redundância antes de tocar num único AP. Distribua os perfis de suplicante via Group Policy ou MDM antes de entrar em produção. E mantenha o seu guest WiFi completamente separado — utilize uma plataforma concebida especificamente para essa camada. Se opera num ambiente multi-espaço — hotéis, cadeias de retalho, estádios — a complexidade aumenta com o número de locais, mas a arquitetura não muda. A chave é um RADIUS centralizado com redundância local por site, e um perfil de suplicante consistente distribuído por 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, entre em contacto diretamente com a equipa da Purple.