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:
- Verificar a fonte de autenticação e o grupo autorizado.
- Autorizar o Captive Portal para a zona dos clientes em Administration > Device access.
- Se for utilizado um servidor DNS externo, criar uma regra DNS restrita sem associação a utilizadores.
- Criar uma regra de utilizador com Match known users e Use web authentication for unknown users.
- Em Authentication > Web authentication, definir HTTPS, a página de destino e o logout.
- 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.
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
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.
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.
Numa configuração de produção, são importantes as seguintes decisões:
- Use insecure HTTP instead of HTTPS permanece desativado. O HTTP transmitiria as credenciais sem encriptação e não funciona com Entra ID SSO.
- 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 é mais adequado quando a sessão deve terminar após um período de inatividade definido.
- 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 pessoais, o login pode ser menos intrusivo. Cada opção deve ser testada com suspensão, mudança de WLAN e logout manual. Estas opções locais de sign-out não se aplicam ao Entra ID SSO.
Depois da seleção, guarde com Apply.
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. Por isso, deve verificar-se sempre através do FQDN se o DNS e o certificado funcionam em conjunto.
As definições encontram-se em Administration > Admin and user settings > Admin console and end-user interaction. Em Redirect users, seleciona-se Firewall’s configured hostname ou A different hostname; no exemplo, introduz-se login.example.com. Em Certificate, seleciona-se o certificado que abrange esse nome. A seleção do certificado não afeta apenas o Captive Portal, mas também outros portais locais da firewall. Antes de uma alteração, deve testar-se também o WebAdmin, o User Portal e o VPN Portal.
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.
- Verificar se o cliente recebeu um endereço de
10.30.40.0/24, a gateway prevista e o servidor DNS correto. - Abrir diretamente
https://10.30.40.1:8090para testar a acessibilidade do portal independentemente de um redirecionamento automático do browser. É esperado um aviso de nome se o certificado contiver apenaslogin.example.com. Em seguida, abrir o URL FQDN para validar o DNS e o certificado. - 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.
- 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.
- Em Current activities > Live users, verificar o nome do utilizador, o IP do cliente e o tipo de autenticação.
- Testar uma página autorizada e, deliberadamente, um destino ou serviço não autorizado.
- 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. - Com um utilizador fora de
BYOD_Internet, verificar que o login não concede acesso através desta regra. - 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; 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, a janela do portal aberta, a suspensão, as mudanças de rede e a inatividade. 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.