Como Configurar 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, é provável que tenha em mãos um projeto de segurança de rede que envolve a autenticação 802.1X - seja porque a sua equipa de conformidade levantou a questão, 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. Então, vamos diretos 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 todos os dispositivos que se ligam à sua rede foram positivamente identificados e autorizados antes de conseguirem transmitir 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 ao abrigo do GDPR e das normas de segurança de dados do NHS e, francamente, para qualquer organização que utilize mais do que um punhado de pontos de acesso, é a arquitetura correta. Nos próximos dez minutos, vou guiá-lo pela arquitetura técnica, pela configuração do RADIUS, pela implementação de certificados e pelos cenários do mundo real onde isto se torna complicado. Vamos a isso. [ANÁLISE TÉCNICA DETALHADA - aproximadamente 5 minutos] Muito bem, o ecossistema 802.1X tem três componentes. Temos o Suplicante - que é o dispositivo cliente, o portátil, o telemóvel, o sensor IoT. Temos o Autenticador - que é o seu ponto de acesso ou o seu switch de rede, por vezes chamado de NAS, o Network Access Server. E temos o Servidor de Autenticação - que é quase universalmente um servidor RADIUS em implementações empresariais. É assim que 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 permitir a entrada. Em vez disso, abre o que se chama uma porta controlada - um canal limitado que apenas transmite 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 resposta 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 base de identidades 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 é extremamente importante. Existem cinco que irá encontrar em implementações empresariais. O EAP-TLS é o padrão de ouro. 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 certificados para todos os dispositivos. Para organizações com Microsoft Active Directory e Active Directory Certificate Services, isto é perfeitamente exequí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 nome 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 via 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 interno. É comum em ambientes Linux e onde necessita de suportar backends 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 maioritariamente 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 operadora - 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 o WiFi de locais públicos onde pretende uma integração contínua e segura sem um Captive Portal. Agora vamos falar sobre a configuração de RADIUS. Quer esteja a implementar o Microsoft NPS, o FreeRADIUS, o Cisco ISE ou o 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 - associação a grupos no Active Directory, tipo de dispositivo, hora do dia - e atribui atributos - ID de VLAN, tempo limite de sessão, limites de largura de banda. O atributo RADIUS que mais utilizará é a atribuição de VLAN, especificamente o Tunnel-Type definido para VLAN, o Tunnel-Medium-Type definido para 802 e o Tunnel-Private-Group-ID definido para 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 confiável 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 confiáveis para todos os principais sistemas operativos. Se estiver a utilizar uma CA interna, precisa de distribuir o certificado raiz para todos os dispositivos cliente através de Política de Grupo ou da sua plataforma MDM. Especificamente para EAP-TLS, também precisa de certificados de cliente. Num ambiente Active Directory, utilizaria o ADCS com inscrição automática através de Política de Grupo para distribuir certificados para dispositivos associados ao domínio. Para dispositivos BYOD, utilizaria o seu MDM - Intune, Jamf, VMware Workspace ONE - para distribuir 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, caso a esteja 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 eu justifico os meus honorários de consultoria. O ponto de falha mais comum é a validação de certificados. Já vi organizações implementarem o PEAP-MSCHAPv2 corretamente do lado do servidor e, em seguida, deixarem os perfis do suplicante cliente configurados para aceitar qualquer certificado. Isso compromete totalmente o modelo de segurança. Cada perfil de suplicante - quer seja distribuído através de Política de Grupo ou MDM - deve especificar a CA raiz confiável e o nome do servidor esperado. Sem isso, fica vulnerável a ataques de evil twin. O segundo problema comum é a gestão de segredos partilhados RADIUS. Já vi redes de produção a funcionar com o segredo partilhado definido como "radius" ou com o valor 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 irão falhar a ligação ou parar ao segmento errado. Teste isto exaustivamente num laboratório antes de implementar em 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 de, no mínimo, 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 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 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. Trata-se de sistemas complementares e não concorrentes. [PERGUNTAS E RESPOSTAS RÁPIDAS - aproximadamente 1 minuto] Permita-me passar pelas perguntas que recebo com mais frequência. Posso executar 802.1X numa plataforma de AP gerida na nuvem? Sim - a Meraki, a Aruba Central e a Ruckus Cloud suportam todas essa funcionalidade. Configura os detalhes do servidor RADIUS no painel da 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 de 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 o nome de utilizador e a palavra-passe. Não é tão seguro como o EAP, mas permite-lhe 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 - de 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 do 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 de uma compatibilidade ampla, EAP-TLS se tiver a infraestrutura de PKI e precisar de uma postura de segurança mais robusta. Configure o seu servidor RADIUS e garanta a sua redundância antes de tocar num único AP. Envie os seus perfis de suplicante via Política de Grupo ou MDM antes de entrar em produção. E mantenha o seu WiFi de convidados 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 local, e um perfil de suplicante consistente enviado 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 de 802.1X e deseja discutir as especificidades do seu ambiente, entre em contacto direto com a equipa da Purple.