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, é 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 apenas herdou uma rede que está a funcionar com uma PSK partilhada e sabe que isso já não é suficiente. Então vamos directos ao assunto. O 802.1X é a norma 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 é positivamente identificado e autorizado antes de 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 PCI-DSS, não é opcional para ambientes de saúde sob o GDPR e normas 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 pela arquitetura técnica, pela configuração de RADIUS, pela implementação de certificados e pelos cenários do mundo real onde isto se complica. Vamos a isso. [MERGULHO TÉCNICO PROFUNDO - aproximadamente 5 minutos] Certo, então a estrutura do 802.1X tem três componentes. Tem o Suplicante - que é o dispositivo cliente, o portátil, o telemóvel, o sensor IoT. Tem o Autenticador - que é o seu ponto de acesso ou o seu comutador de rede, por vezes chamado de NAS, o Network Access Server. E tem o Servidor de Autenticação - 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, envolvido 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 importa imenso. 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 o 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 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 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 (Protected Access Credentials) em vez de certificados. É principalmente relevante se estiver num ambiente predominantemente 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 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 redes WiFi de espaços públicos onde deseja um registo seguro e contínuo sem um Captive Portal. Agora vamos falar sobre a configuração do 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 exclusivos 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 - 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 para VLAN, o Tunnel-Medium-Type definido para 802 e o Tunnel-Private-Group-ID definido para o número da sua VLAN. Em terceiro lugar, configure a sua política de pedidos de ligação. Esta política 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 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 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 accounting 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 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 correm mal, porque é aqui que justifico os meus honorários de consultoria. O ponto de falha mais comum é a validação do certificado. Tenho visto organizações a implementar o PEAP-MSCHAPv2 corretamente no lado do servidor, mas a deixar os perfis dos suplicantes dos clientes 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 raiz fidedigna e o nome do servidor esperado. Sem isso, fica vulnerável a ataques evil twin. O segundo problema comum é a gestão do segredo partilhado RADIUS. Já vi redes de produção a funcionar com o segredo partilhado definido como "radius" ou o predefinido do fornecedor. Estes segredos são as chaves para a 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 lançar para 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 estar 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] 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 todos. Configura os detalhes do servidor RADIUS no painel da nuvem e os APs tratam do proxying de EAP. Preciso do Active Directory? Não. O FreeRADIUS pode autenticar face a 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? 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 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] Portanto, para resumir: o 802.1X não é um recurso opcional. Para qualquer organização que lide com dados sensíveis, processe pagamentos ou opere num ambiente regulamentado, é 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 de PKI e precisar do nível 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 Política de Grupo ou MDM antes de entrar em funcionamento. 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 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 de 802.1X e deseja discutir as especificidades do seu ambiente, entre em contacto direto com a equipa da Purple.