Configurar e testar o Sophos Firewall Captive Portal

O Captive Portal autentica utilizadores que já estão ligados a uma rede LAN ou WLAN. Em seguida, o Sophos Firewall pode associar o respetivo tráfego a uma identidade e aplicar regras a utilizadores ou grupos específicos.

O essencial é a interação entre os componentes: o portal cria a associação do utilizador, mas não concede por si só acesso à internet. Para isso, é necessária também uma regra de firewall adequada. O DNS, o routing, o NAT e a segmentação da rede têm de funcionar de forma independente.

O processo completo resume-se a seis passos:

1. Verificar a fonte de autenticação e o grupo autorizado.
2. Autorizar o Captive Portal para a zona dos clientes em Administration > Device access.
3. Se for utilizado um servidor DNS externo, criar uma regra DNS restrita sem associação a utilizadores.
4. Criar uma regra de utilizador com Match known users e Use web authentication for unknown users.
5. Em Authentication > Web authentication, definir HTTPS, a página de destino e o logout.
6. Verificar o login através da porta 8090, o utilizador em Live users e a Rule ID no Log Viewer.

O que o Captive Portal faz — e o que não faz

O Captive Portal é adequado para dispositivos BYOD, clientes não geridos ou redes onde não está disponível a identificação transparente dos utilizadores. O utilizador abre uma página web, é redirecionado para o login e fica depois associado ao respetivo endereço IP de origem na firewall. A firewall pode usar esta identidade como critério de correspondência.

Outros portais e métodos de autenticação resolvem tarefas diferentes:

• Um Wireless Hotspot destina-se ao acesso de convidados através de voucher, palavra-passe diária ou termos de utilização. O processo completo encontra-se em Configurar um Hotspot no Sophos Firewall.
• Um Guest user é uma conta local temporária para o Captive Portal. Criar e gerir utilizadores convidados em segurança explica grupo, validade, entrega de credenciais, autorregisto e limpeza.
• O VPN Portal faz parte do Remote Access. O Captive Portal não cria um túnel VPN e não deve ser utilizado como portal de login público.
• STAS, AD SSO ou SATC identificam, sempre que possível, os utilizadores sem login no browser. Nestes ambientes, o Captive Portal pode servir de alternativa para dispositivos onde a identificação transparente não funciona.
• Para um login Microsoft, aplica-se o procedimento separado Captive Portal com Microsoft Entra ID SSO.

A visão geral dos portais Sophos ajuda quando ainda não é clara a diferença entre User Portal, VPN Portal, WebAdmin e Captive Portal.

⚠️ O Captive Portal não substitui a segmentação. Uma rede BYOD ou de convidados permanece numa zona ou VLAN própria e recebe acesso apenas aos destinos e serviços realmente necessários. O login melhora a associação do utilizador, mas não torna automaticamente segura uma rede demasiado abrangente.

Pré-requisitos e exemplo

Antes da configuração, devem estar definidos os seguintes pontos:

• Uma fonte de autenticação local ou externa funciona. No caso do Active Directory, a ligação ao servidor e o grupo já foram verificados; a configuração é explicada em Ligar o Active Directory ao Sophos Firewall.
• São conhecidos a zona dos clientes, a rede de origem e o grupo de utilizadores autorizado.
• O cliente recebe um endereço IP correto, uma gateway e servidores DNS funcionais.
• Para o nome produtivo do portal existe um registo DNS e um certificado aceite pelos clientes.
• Uma regra MASQ/SNAT existente e o routing abrangem o tráfego de internet que será posteriormente autorizado.
• Estão disponíveis um utilizador de teste autorizado e outro não autorizado para a validação.

O exemplo utiliza:

• Zona dos clientes: LAN
• Rede dos clientes: 10.30.40.0/24
• Objeto de rede: BYOD_10.30.40.0_24
• IP da firewall na zona dos clientes: 10.30.40.1
• Grupo de utilizadores: BYOD_Internet
• Nome da regra: LAN-BYOD-to-WAN-Captive
• Servidor DNS interno: 10.20.0.53
• Nome do portal: login.example.com

Estes valores não devem ser copiados sem verificação. A zona e a rede têm de corresponder à interface real dos clientes, 10.30.40.1 deve ser substituído pelo IP da firewall nessa interface e o grupo tem de pertencer à fonte de autenticação utilizada. A partir da rede dos clientes, o nome do portal deve resolver exatamente para este endereço alcançável da firewall.

Configurar o Captive Portal passo a passo

1. Selecionar o método de autenticação

Em Authentication > Services, na secção Firewall authentication methods, definem-se as fontes que a firewall consulta durante um login. Pode ser a base de dados local de utilizadores ou um servidor AD, LDAP ou RADIUS previamente configurado. Criar e testar utilizadores locais normais descreve o grupo, a palavra-passe, Local, Sign-in Restriction e o ciclo de vida deste modelo. A ordem é relevante: se existirem vários servidores, o SFOS verifica-os de cima para baixo.

No exemplo, o grupo BYOD_Internet tem de existir na firewall. No caso do Active Directory, deve ser importado previamente. Só depois pode ser selecionado na regra de utilizador e atribuído de forma inequívoca durante o teste.

Uma ligação bem-sucedida ao servidor não é suficiente. Por isso, mais tarde é utilizado um login real no portal para verificar se a palavra-passe, o grupo e a regra de utilizador funcionam em conjunto.

2. Autorizar o Captive Portal para a zona de origem

Em Administration > Device access, na linha Captive portal, ative apenas as zonas a partir das quais os utilizadores devem realmente iniciar sessão. No exemplo, é LAN. Em seguida, guarde com Apply.

O Device Access controla o acesso a um serviço local da firewall. Uma regra LAN-to-WAN normal não substitui esta autorização. Por outro lado, o Captive Portal não deve ser aberto preventivamente para WAN ou para zonas internas não envolvidas. Device Access e Local Service ACL explica também o caso especial do Web Proxy, em que os portais locais podem ficar acessíveis apesar de uma tabela de zonas mais restrita.

Se os clientes utilizarem a própria firewall como resolver DNS, também é necessário autorizar DNS para a respetiva zona na mesma matriz. Com um servidor DNS separado, é necessária a regra de trânsito seguinte.

3. Disponibilizar o DNS antes do login

O browser só consegue abrir login.example.com ou a página originalmente solicitada se o DNS já funcionar antes da autenticação do utilizador. Se o servidor DNS não estiver na firewall, cria-se uma regra própria em Rules and policies > Firewall rules > Add firewall rule > New firewall rule:

• Action: Accept
• Source zones: LAN
• Source networks and devices: BYOD_10.30.40.0_24
• Destination zones: zona do servidor DNS
• Destination networks: objeto host para 10.20.0.53
• Services: DNS
• Log firewall traffic: ativar para a validação

Esta regra não tem associação a utilizadores, porque o cliente ainda não está autenticado. Antes do login, autoriza-se apenas o DNS para o resolver previsto, não tráfego arbitrário. Se o ambiente utilizar vários servidores DNS, os respetivos objetos host são adicionados de forma específica.

A regra DNS deve ser posicionada de modo que o resolver esteja acessível antes do login. No exemplo, fica imediatamente antes da regra de utilizador e acima de qualquer regra mais geral que rejeite ou processe de outra forma o DNS desta rede. Em seguida, guarde com Save.

Acima da tabela de regras, selecione o protocolo aplicável, IPv4 ou IPv6. Se os clientes só alcançarem o resolver através de IPv4, a regra DNS IPv4 é suficiente. Se o DNS também for utilizado através de IPv6, crie uma regra IPv6 igualmente restrita com os objetos de rede e host IPv6 adequados.

4. Criar a regra de utilizador

Agora é criada a regra de acesso propriamente dita. No exemplo, recebe os seguintes valores:

• Rule name: LAN-BYOD-to-WAN-Captive
• Action: Accept
• Source zones: LAN
• Source networks and devices: BYOD_10.30.40.0_24
• Destination zones: WAN
• Destination networks: os destinos de internet necessários ou Any
• Services: apenas os serviços necessários
• Match known users: ativado
• Use web authentication for unknown users: ativado
• Users or groups: BYOD_Internet
• Log firewall traffic: ativado

Também aqui, selecione IPv4 ou IPv6 acima da tabela de regras. Numa rede dual-stack, crie uma regra de utilizador separada, com os objetos de rede adequados, para cada família de protocolos efetivamente autorizada; uma regra IPv4 não abrange IPv6.

Match known users torna a identidade num critério de correspondência. Use web authentication for unknown users faz com que um pedido web correspondente de um utilizador ainda não autenticado conduza ao login. O grupo determina quem pode utilizar a regra após uma autenticação bem-sucedida.

No SFOS 22 e 23, Use web authentication for unknown users não é o único mecanismo que desencadeia um login. Se a opção estiver ativada, um pedido web correspondente de um utilizador ainda não autenticado desencadeia a autenticação. Se estiver desativada, esta opção permite inicialmente o pedido sem login; no entanto, uma Web Policy atribuída pode continuar a bloqueá-lo e, assim, desencadear a autenticação web. O fator decisivo é saber se uma Web Policy para utilizadores ou grupos desconhecidos está definida como Block. O processo seguinte depende do AD SSO:

• Com AD SSO, tanto quando a regra desencadeia a autenticação como quando ocorre um Block pela Web Policy para utilizadores desconhecidos: o SFOS tenta primeiro o login transparente. Se este falhar, segue-se o redirecionamento para o Captive Portal. Após um login bem-sucedido, a página é recarregada e a Web Policy do utilizador é novamente avaliada.
• Sem AD SSO, com autenticação desencadeada pela regra: o pedido web correspondente de um utilizador ainda não autenticado é redirecionado diretamente para o Captive Portal.
• Sem AD SSO, apenas com bloqueio pela Web Policy: é apresentada uma página de bloqueio. Esta pode apresentar uma ligação ao Captive Portal; neste caso, não se deve esperar um redirecionamento automático como o desencadeado pela regra.

Perante um login inesperado ou uma página de bloqueio, verificam-se primeiro, em conjunto, a regra que efetivamente correspondeu ao tráfego no Log Viewer, a opção nessa regra, a Web Policy para utilizadores ou grupos desconhecidos e o estado do AD SSO em Authentication > Web authentication. Antes de qualquer alteração, registam-se os valores existentes. A verificação é feita com um cliente piloto sem sessão existente e apenas para o acesso previsto para esse cliente: não se deve remover indiscriminadamente o Block, tornar as regras de utilizador menos restritivas ou alterar globalmente o AD SSO apenas para forçar um redirecionamento. Após o login, verificam-se Current activities > Live users, o utilizador e a Rule ID no Log Viewer, bem como um destino autorizado e outro que deve continuar bloqueado. Se o comportamento for inesperado, repõem-se os valores alterados e repetem-se as mesmas verificações.

Em Services, Any só é adequado se o grupo realmente tiver de receber acesso completo de cliente à internet depois do login. Para um acesso mais restrito, selecionam-se deliberadamente HTTP, HTTPS e outros protocolos necessários. O tráfego que não é web não consegue apresentar uma página de login; o utilizador tem de iniciar primeiro a autenticação num browser ou através do URL direto do portal.

A regra tem de ficar acima de uma regra allow abrangente baseada em IP. Caso contrário, o tráfego é processado antes e nunca chega à regra de utilizador. Depois de verificar a posição, guarde com Save. A avaliação básica é explicada em Planear corretamente as regras de firewall.

5. Definir HTTPS, redirecionamento e logout

Em Authentication > Web authentication não se ativa a acessibilidade do portal, mas configura-se o respetivo comportamento.

Captive Portal aceita no máximo 50 caracteres tanto para o nome de utilizador como para a palavra-passe. Este limite deve ser testado com uma conta real antes do rollout, sobretudo com diretórios externos e nomes de utilizador gerados automaticamente.

Numa configuração de produção, são importantes as seguintes decisões:

• Show user portal link apresenta na página do Captive Portal uma ligação ao User Portal. Ative-a apenas se os utilizadores precisarem realmente desse portal e este tiver de estar acessível a partir da respetiva zona.
• Use insecure HTTP instead of HTTPS permanece desativado. O HTTP transmitiria as credenciais sem encriptação. Com esta opção, o SFOS 22 não suporta Microsoft Entra ID SSO; no SFOS 23, esta restrição aplica-se ao OpenID Connect SSO no seu conjunto.
• Show web page after sign-in pode redirecionar o utilizador para a página originalmente solicitada ou para uma página interna definida.
• Open web page: In new browser window mantém a página do Captive Portal aberta para logout e keepalives. Se o mesmo separador for substituído, o processo de logout torna-se menos visível para o utilizador.
• When captive portal page is closed or redirected termina a sessão do utilizador quando a firewall deixa de receber keepalives. Isto também pode acontecer após a suspensão do dispositivo ou uma mudança de rede.
• When user is inactive avalia um período e a quantidade de dados transferidos nesse intervalo. O SFOS termina a sessão de um utilizador cujo tráfego fique abaixo do limiar configurado. Escolha o período e a quantidade para que o tráfego normal em segundo plano não mantenha indefinidamente todas as sessões obsoletas.
• Never exige logout manual e pode manter durante mais tempo associações desatualizadas entre utilizadores e endereços IP.

Não existe um timeout universalmente correto. Em dispositivos partilhados e com utilizadores alternados, as sessões mais curtas são mais importantes; em dispositivos atribuídos individualmente, o login pode ser menos intrusivo. Cada opção é testada com suspensão, mudança de WLAN e logout manual. Estas opções locais de sign-out não se aplicam ao Microsoft Entra ID SSO no SFOS 22 nem ao OpenID Connect SSO no seu conjunto no SFOS 23.

Antes da validação final, registam-se a versão do SFOS em utilização e o método de login. As opções locais de sign-out mencionadas não são um mecanismo adequado para evitar fins de sessão inesperados nestes logins SSO; esta exceção não permite concluir que a sessão seja ilimitada nem que exista um timeout específico do IdP. O teste SSO mantém-se em HTTPS com um certificado válido e fidedigno. O HTTP não é ativado, nem sequer para diagnóstico de erros. O login, a associação visível do utilizador e o logout são verificados com uma conta piloto no processo SSO efetivamente utilizado, em vez de se pressupor o efeito das opções locais de sign-out.

Além disso, Authentication > Services > Global settings > Maximum session timeout limita a duração total dos utilizadores autenticados. O SFOS verifica a autorização a cada três minutos; Access Policies, Surfing Quota e o limite de transferência de dados também podem terminar uma sessão. Este valor global afeta mais do que o Captive Portal, pelo que os outros métodos de autenticação devem ser verificados antes de o alterar.

Depois da seleção, guarde com Apply.

A Device Console contém também valores globais para as versões TLS mínimas do Captive Portal, X-Frame-Options e uma string de cifras partilhada com Web Proxy. Verificar em segurança as definições HTTP Proxy explica por que estes valores não são uma lista geral de tuning e como testar e reverter uma alteração com provas do portal e do proxy.

Em Captive portal appearance podem personalizar-se o logótipo, os textos e as cores. Se for utilizado Custom HTML em vez do layout predefinido, o marcador <div id="__loginbox"></div> e o bloco request-url indicado pela Sophos com o respetivo script de redirecionamento têm de continuar funcionais. Por isso, o HTML, CSS ou JavaScript próprio deve ser testado primeiro com Preview e depois com uma conta piloto. Um portal visualmente correto não é um sucesso se o template interromper o início de sessão, o redirecionamento ou o fim de sessão; Reset to default permite anular a personalização.

<div id="__loginbox"></div>
<div id="request-url" style="display:none;">{url}</div>
<script>
var redirect_url = document.getElementById("request-url").innerHTML;
</script>

A parte do script deve ser colocada imediatamente antes de </body>.

6. Verificar o nome do portal e o certificado

O URL direto de diagnóstico é:

https://<Firewall-IP>:8090

No exemplo, pode abrir-se primeiro https://10.30.40.1:8090. Para produção, https://login.example.com:8090 é mais claro, desde que o nome resolva para a firewall e esteja incluído no certificado.

O endereço IP serve apenas para testar a acessibilidade. Se o certificado selecionado abranger apenas login.example.com, o browser apresenta, como esperado, um aviso de incompatibilidade de nome ao abrir 10.30.40.1. Não introduza credenciais depois de ignorar este aviso. Por isso, deve verificar-se sempre através do FQDN se o DNS e o certificado funcionam em conjunto.

Aceda a Administration > Admin and user settings. Antes da alteração, registe o valor atual de Redirect users e o Certificate selecionado. Em Admin console and end-user interaction, sob Redirect users, selecione depois Firewall’s configured hostname ou A different hostname; no exemplo, introduza login.example.com. Em Certificate, selecione o certificado que abrange esse nome. Utilize Check settings para testar o redirecionamento antes do rollout. A seleção do certificado não afeta apenas o Captive Portal, mas também outros portais locais da firewall. Depois da alteração, deve testar-se também o WebAdmin, o User Portal e o VPN Portal.

Se algum destes testes falhar, volte a selecionar o valor de redirecionamento registado e o certificado anterior e guarde com Apply. Em seguida, volte a testar o redirecionamento e os portais.

Um certificado publicamente fidedigno evita avisos em dispositivos não geridos. Com uma CA interna ou assinada pela firewall, a CA tem de estar instalada como fidedigna em todos os clientes. O nome do certificado, a cadeia completa e a atribuição segura são explicados em Gerir certificados no Sophos Firewall.

Testar completamente o login e a regra de utilizador

A validação começa com um cliente sem uma sessão existente. Em Current activities > Live users, pode terminar-se uma sessão de teste antiga, se necessário.

1. Verificar se o cliente recebeu um endereço de 10.30.40.0/24, a gateway prevista e o servidor DNS correto.
2. Abrir diretamente https://10.30.40.1:8090 para testar a acessibilidade do portal independentemente de um redirecionamento automático do browser. É esperado um aviso de nome se o certificado contiver apenas login.example.com. Em seguida, abrir o URL FQDN para validar o DNS e o certificado.
3. Sem uma sessão existente, abrir uma página HTTP normal e verificar o redirecionamento para o Captive Portal. Uma página HTTPS com comportamento HSTS guardado não é um teste fiável para este efeito.
4. Iniciar sessão com um utilizador autorizado. Se o Sophos MFA local estiver ativado, o token OTP tem de ser registado previamente no User Portal. A configuração é descrita em Ativar MFA no Sophos Firewall.
5. Em Current activities > Live users, verificar o nome do utilizador, o IP do cliente e o tipo de autenticação.
6. Testar uma página autorizada e, deliberadamente, um destino ou serviço não autorizado.
7. No Log Viewer, filtrar pelo IP do cliente. A entrada tem de mostrar o utilizador esperado e a Rule ID de LAN-BYOD-to-WAN-Captive.
8. Com um utilizador fora de BYOD_Internet, verificar que o login não concede acesso através desta regra.
9. Provocar o logout, a suspensão ou uma mudança de rede e verificar quando o utilizador desaparece de Live users.

Numa rede dual-stack, o teste é realizado separadamente para IPv4 e IPv6. O SFOS mantém as duas associações de utilizador em separado e ambas as variantes exigem regras de firewall adequadas; por isso, um teste IPv4 bem-sucedido ainda não confirma que o acesso IPv6 funciona.

Diagnosticar de forma dirigida os erros típicos

O portal não aparece

Começar por abrir o URL direto na porta 8090. Se não estiver acessível, verificar a zona de origem e Captive portal em Device Access, o IP do cliente, o mapeamento da zona, o DNS e o FQDN do portal.

Se o URL direto estiver acessível, mas o login automático não aparecer, o tráfego é frequentemente processado primeiro por uma regra mais geral ou falta a opção Use web authentication for unknown users. Além disso, apenas um pedido web correspondente consegue iniciar o login no browser. As aplicações que não utilizam a web não mostram uma página do Captive Portal.

O login é rejeitado

Em Authentication > Services, verificar a fonte de autenticação e a ordem. Em seguida, verificar a ligação ao servidor, a palavra-passe, o grupo de utilizadores, a quota e, no caso de MFA local, se o registo OTP foi concluído. Os horários recorrentes permitidos ou bloqueados são verificados separadamente com Access Time para utilizadores e grupos. O procedimento de Surfing Quota e Network Traffic Quota mostra se, em vez disso, foi esgotado o tempo de Internet ou o volume de dados consumido.

Se o erro não estiver claramente no portal, Resolver sistematicamente erros de autenticação na Sophos Firewall separa a acessibilidade, seleção do serviço, Live Users, Main Group e percurso posterior do tráfego.

Para tentativas de login clássicas, é relevante o ficheiro access_server.log. O ficheiro oauth_sso_captive.log só é necessário para o processo SSO com Microsoft Entra ID. Logs de serviços do Sophos Firewall explica como ler os ficheiros sem reiniciar serviços prematuramente.

Login bem-sucedido, mas sem acesso

Um login bem-sucedido confirma apenas a autenticação. Depois, a zona dos clientes, a rede de origem, o grupo, os destinos, os serviços, a posição da regra, o NAT e o routing têm de corresponder à regra de utilizador. O Log Viewer mostra qual Rule ID processa efetivamente o tráfego. Para uma verificação sistemática, consulte Porque não corresponde uma regra do Sophos Firewall.

O utilizador é desligado inesperadamente

Verificar a opção de sign-out selecionada e os respetivos limiares de tempo e dados, a janela do portal aberta, a suspensão, as mudanças de rede e a inatividade. Verificar também Maximum session timeout em Authentication > Services > Global settings, bem como Access Time, Surfing Quota e Network Traffic Quota. Com When captive portal page is closed or redirected, a associação termina depois de deixarem de chegar keepalives; isto não tem de ser visível exatamente no momento em que a janela é fechada.

O login só aparece após cerca de dois minutos

Se o STAS for utilizado na mesma rede, a respetiva fase de aprendizagem pode atrasar o redirecionamento. Nesse caso, verificar primeiro o estado do STAS e os clientes não autenticados. O processo geral do Captive Portal não altera nenhum valor CLI global para este efeito; as relações são explicadas no artigo sobre STAS.

Vários utilizadores partilham o mesmo IP de origem

O Captive Portal associa, por princípio, a identidade do utilizador a um endereço IP do cliente. Por isso, os endereços IP registados em Multi-user hosts para Per-Connection AD SSO através do Direct Web Proxy não podem utilizar o Captive Portal. Per-Connection AD SSO para hosts multiutilizador explica o procedimento adequado e a regra separada sem Match known users para o restante tráfego.

Perguntas frequentes