Arquitetura de Captive Portal: Segurança, Redirecionamento e Boas Práticas

Fale em inglês britânico com um tom confiante, autoritário e de conversação — como se fosse um consultor de redes sénior a fazer um briefing a um cliente enquanto bebem um café. Ritmo medido, dicção clara, sem pressas. Pausas naturais ocasionais para dar ênfase. Profissional mas não rígido: Bem-vindo ao Purple Technical Briefing. Sou o seu anfitrião e hoje vamos analisar a fundo a arquitetura de captive portal — especificamente o modelo de segurança, a mecânica de redirecionamento e as decisões de design que distinguem uma implementação em conformidade e bem estruturada de outra que lhe causará problemas às três da manhã. [medium pause] Vamos contextualizar a situação. Tem uma rede WiFi para convidados a funcionar numa cadeia de hotéis, numa rede de lojas ou num estádio. Milhares de dispositivos ligam-se todos os dias. Alguns desses dispositivos contêm malware. Alguns desses utilizadores tentarão aceder a conteúdos que não deviam. E a sua equipa jurídica quer a garantia, por escrito, de que recolheu um consentimento válido antes de armazenar um único byte de dados pessoais. [medium pause] Esse é o problema que a arquitetura de captive portal foi concebida para resolver. Vamos analisar como funciona realmente. [medium pause] Secção um. A cadeia de redirecionamento. Quando um dispositivo convidado se liga ao seu SSID de WiFi, obtém um endereço IP de um pool de DHCP numa VLAN de convidados dedicada — vamos chamar-lhe VLAN 20. Os seus dispositivos corporativos estão na VLAN 10. Estas duas VLANs nunca devem encaminhar tráfego entre si. Isso não é negociável do ponto de vista do PCI DSS e, francamente, também do ponto de vista da segurança básica. Neste momento, o dispositivo está ligado, mas ainda não se autenticou. O controlador coloca-o no que chamamos de estado de pré-autenticação. O dispositivo só consegue aceder a uma pequena lista de domínios permitidos — o walled garden. Tudo o resto é interceptado. Aqui está o aspeto engenhoso. Quando o dispositivo tenta carregar uma página web — ou quando o sistema operativo realiza a verificação de deteção de captive portal, o que o iOS faz automaticamente acedendo a captive.apple.com — o resolvedor de DNS no gateway devolve o endereço IP do servidor do captive portal em vez do destino real. O navegador segue esse redirecionamento e vai parar à sua splash page. [medium pause] Trata-se do Layer 3 e do Layer 7 a trabalhar em conjunto. A VLAN trata do isolamento da rede. A interceção de DNS trata do redirecionamento. E o captive portal trata da camada de identidade e consentimento. Três mecanismos distintos, todos a funcionar em sequência. [medium pause] Secção dois. Autenticação e RADIUS. Assim que o convidado interage com a splash page — seja aceitando os termos e condições, inserindo um endereço de e-mail, autenticando-se através de login social ou verificando um código por SMS —, a plataforma precisa de instruir o controlador de rede a abrir a firewall para esse dispositivo específico. É aqui que entra o RADIUS. RADIUS significa Remote Authentication Dial-In User Service. É um protocolo definido no RFC 2865 e é o padrão da indústria para comunicar decisões de autenticação entre um servidor de políticas e um dispositivo de acesso à rede. A Purple funciona como um servidor RADIUS alojado na nuvem. Quando um convidado conclui o fluxo do Captive Portal, a Purple envia uma mensagem RADIUS Access-Accept para o controlador WiFi local - quer seja um Cisco Meraki, um controlador HPE Aruba, um Ruckus SmartZone ou um ponto de acesso Juniper Mist. O controlador recebe essa mensagem e transita o dispositivo do convidado do estado de pré-autenticação para o estado autorizado, abrindo as regras de firewall e concedendo acesso à internet. [medium pause] Existe uma extensão importante do RADIUS que deve conhecer: Change of Authorisation, ou CoA. O CoA permite que o servidor RADIUS envie uma mensagem a meio da sessão para o controlador para revogar ou modificar uma sessão que já está ativa. A Purple utiliza o CoA para impor limites de tempo de sessão, desligar dispositivos que tenham sido sinalizados por violações de políticas e apoiar fluxos de trabalho de direito ao apagamento sob o GDPR - onde um utilizador solicita a eliminação dos seus dados e a Purple pode revogar imediatamente a sua sessão ativa. [medium pause] Secção três. O walled garden. O walled garden é uma lista branca de endereços IP e nomes de domínio que os dispositivos não autenticados podem aceder antes de concluírem o fluxo do Captive Portal. Se errar nisto, a sua splash page não irá carregar. Se errar gravemente, terá criado uma lacuna de segurança. No mínimo, o seu walled garden precisa de incluir o próprio URL do Captive Portal, quaisquer endpoints de CDN que sirvam os recursos do portal e os endpoints de autenticação de quaisquer fornecedores de início de sessão social que esteja a utilizar - Google, Facebook, Microsoft. Se estiver a utilizar a verificação por SMS, terá de incluir na lista branca o endpoint da API do gateway de SMS. Laço que apanha a maioria das implementações são os endereços IP dinâmicos. Os serviços de nuvem nem sempre têm IPs estáticos. Se incluir na lista branca um IP em vez de um domínio, e esse IP for alterado, o seu portal deixa de funcionar. Utilize a inclusão em lista branca baseada em domínio onde o seu controlador a suporte e teste após cada alteração. [medium pause] Secção quatro. Design de segurança. Vamos falar sobre a arquitetura de segurança com mais detalhe, porque é aqui que a maioria das implementações apresenta lacunas. Primeiro: isolamento de clientes. Ative-o. Esta é uma definição no ponto de acesso que impede os dispositivos dos convidados de comunicarem diretamente entre si através do meio sem fios. Sem isso, um dispositivo comprometido na sua rede de convidados pode sondar e atacar outros dispositivos de convidados. É uma correção com uma única caixa de seleção que elimina toda uma classe de ataques peer-to-peer. Segundo: tempos de concessão DHCP. Num local de grande rotação - um centro de transportes, um estádio, uma loja de retalho movimentada - precisa de tempos de concessão curtos. Trinta a sessenta minutos. Se mantiver o valor predefinido de vinte e quatro horas e tiver dez mil dispositivos a ligarem-se num dia de jogo, esgotará o seu pool de endereços IP antes do intervalo. Os novos dispositivos não se irão ligar. A sua equipa de operações receberá reclamações. Mantenha as concessões curtas. Terceiro: encriptação. O seu Captive Portal deve ser servido através de HTTPS com um certificado TLS válido. Se for servido através de HTTP, os browsers modernos irão sinalizá-lo como inseguro, os utilizadores desconfiarão dele e estará a transmitir credenciais em texto simples. Utilize, no mínimo, TLS 1.2; o TLS 1.3 é preferível. A camada de transporte WiFi deve utilizar WPA2-AES ou WPA3 - nunca WEP, nunca TKIP. Quarto: segmentação de VLAN. A sua VLAN de convidados deve estar completamente isolada de qualquer segmento de rede que toque em dados de cartões de pagamento. A versão 4.0 do PCI DSS é explícita quanto a isto. Se a sua rede de convidados conseguir encaminhar para uma sub-rede que contenha um sistema de ponto de venda, toda a sua rede POS estará no âmbito de uma auditoria PCI. Esse é um encargo de conformidade significativo. Segmente corretamente desde o primeiro dia. [medium pause] Secção cinco. GDPR e conformidade de dados. Cada Captive Portal que recolha dados pessoais - e endereço de email, número de telefone e login social contam todos como dados pessoais ao abrigo do GDPR - deve cumprir requisitos específicos. Necessita de uma base jurídica para o processamento. Para o WiFi de convidados, isso é normalmente o consentimento. O consentimento deve ser dado livremente, específico, informado e inequívoco. Caixas pré-selecionadas não contam. Agrupar o consentimento de WiFi com o consentimento de marketing não conta. O modelo de opt-in de escolha consciente da Purple separa o consentimento de acesso à rede do consentimento de marketing, para que os convidados possam aceder à internet sem serem forçados a aceitar emails de marketing. Necessita de documentar que dados recolhe, por que razão os recolhe, onde são armazenados e durante quanto tempo os retém. A Purple é certificada pela norma ISO 27001, em conformidade com o GDPR, em conformidade com o CCPA e com a certificação Cyber Essentials. A plataforma armazena dados em centros de dados conformes com políticas de retenção documentadas. E necessita de um fluxo de trabalho de direito ao apagamento. Se um convidado solicitar a eliminação dos seus dados, deve ser capaz de agir em conformidade no prazo de trinta dias. A plataforma da Purple suporta isto nativamente, e o mecanismo RADIUS CoA que mencionei anteriormente significa que pode revogar sessões ativas ao mesmo tempo. [medium pause] Passemos agora para as recomendações de implementação e os erros que vemos com mais frequência. [medium pause] Erro um: walled gardens mal configurados. A splash page carrega, mas o botão de login social não funciona. Ou a página carrega mas o logótipo não aparece porque o domínio CDN não está na whitelist. Teste o seu walled garden num dispositivo novo sem DNS em cache antes de entrar em produção. Erro dois: PSKs partilhadas. Alguns locais ainda utilizam uma única palavra-passe de WiFi escrita num quadro de giz. Isso não é um Captive Portal - é um segredo partilhado que qualquer pessoa pode fotografar e partilhar. Não lhe fornece dados de identidade, nenhum registo de consentimento e nenhuma capacidade de revogar o acesso individual. Substitua-o por um Captive Portal gerido. Erro três: dimensionamento insuficiente do pool DHCP. Já abordei isto, mas vale a pena repetir. Dimensione o seu pool DHCP para o pico de ligações simultâneas, não para a média de ligações. Num estádio com quarenta mil adeptos, poderá ter vinte mil dispositivos a tentar ligar-se simultaneamente. Planeie em conformidade. Quarto erro: sem limite de tempo de sessão. Sem um limite de tempo de sessão, um dispositivo que se ligou há seis meses e nunca mais voltou ainda mantém um estado de sessão autorizado no seu controlador. Esse é um registo obsoleto que desperdiça recursos e cria ruído de auditoria. Defina limites de tempo de sessão. Trinta minutos de inatividade é um padrão razoável. [medium pause] Perguntas e respostas rápidas. Pergunta: O Captive Portal funciona em todos os dispositivos? Resposta: Os sistemas operativos modernos - iOS, Android, Windows, macOS - têm todos deteção de Captive Portal integrada. Detetam o redirecionamento e apresentam o portal automaticamente. Dispositivos mais antigos podem exigir que o utilizador abra um browser manualmente. A plataforma da Purple lida com ambos os fluxos. Pergunta: Podemos usar um Captive Portal em conjunto com o 802.1X? Resposta: Sim. Muitas implementações empresariais usam 802.1X para dispositivos de funcionários - onde os certificados ou credenciais são autenticados automaticamente - e um Captive Portal para dispositivos de convidados num SSID separado. A Purple integra-se com infraestruturas RADIUS que suportam ambos os fluxos simultaneamente. Pergunta: E quanto ao OpenRoaming? Resposta: O OpenRoaming é um padrão que permite que os dispositivos se liguem ao WiFi automaticamente utilizando autenticação baseada em certificados, contornando totalmente o Captive Portal. A Purple atua como um fornecedor de identidade gratuito para o OpenRoaming sob a licença Connect. É o rumo futuro para uma conectividade de convidados contínua, mas os Captive Portals continuam a ser o padrão atual para captura de dados e gestão de consentimento. [medium pause] Para resumir. Uma implementação de Captive Portal bem arquitetada baseia-se em cinco pilares. Isolamento de VLAN para proteger a sua rede corporativa. Interceção de DNS e redirecionamento HTTPS para apresentar a splash page. Autenticação RADIUS para abrir a firewall após o consentimento. Um walled garden configurado corretamente para garantir que o portal carrega de forma fiável. E o tratamento de dados em conformidade com o GDPR para proteger tanto os seus convidados como a sua organização. A plataforma da Purple lida com todas as cinco camadas em 80.000 locais ativos, com 440 milhões de inícios de sessão processados em 2024 e 99,999% de uptime. Integra-se nativamente com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet - por isso, independentemente do hardware que estiver a utilizar, pode implementar sem necessidade de remover e substituir. Se pretender aprofundar qualquer um destes tópicos - design de SSID, configuração de RADIUS ou fluxos de trabalho de conformidade com o GDPR - visite purple.ai para aceder à biblioteca completa de guias técnicos. Obrigado por ouvir.