Configurar RADIUS SSO com accounting na Sophos Firewall

O RADIUS SSO inicia a sessão de um utilizador na Sophos Firewall sem um captive portal adicional. O utilizador já se autenticou numa rede sem fios, num network access server ou noutro sistema RADIUS. Em seguida, a firewall recebe um pacote de accounting RADIUS com o nome de utilizador e o IP do cliente e pode usar esta associação em regras baseadas em utilizadores.

O ponto decisivo não é apenas um início de sessão 802.1X bem-sucedido. A firewall tem de receber um Accounting-Start utilizável exatamente do remetente configurado. Para Wi-Fi SSO, a Sophos utiliza o Framed-IP-Address deste pacote inicial. Se faltar o IP do cliente, a firewall poderá conhecer o nome de utilizador, mas não consegue associá-lo ao tráfego.

⚠️ RADIUS SSO não é o mesmo que Enable accounting no objeto do servidor RADIUS. Em Authentication > Servers, Enable accounting significa que a firewall envia accounting para um servidor RADIUS. Em Authentication > Services > SSO using RADIUS accounting request, a firewall recebe accounting de um cliente RADIUS e cria uma associação utilizador-IP.

O procedimento atual da Sophos confirma este fluxo para access points APX geridos pelo SFOS. Não constitui uma aprovação geral para AP6 nem para qualquer controlador de terceiros. Noutra plataforma, confirmar com o fabricante e, se necessário, com a Sophos Support que o mesmo caminho de proxy e atributos é suportado antes do rollout em produção. Um pacote de teste tecnicamente adequado não alarga, por si só, o âmbito de suporte documentado.

Procedimento rápido

1. Para o fluxo oficialmente documentado, usar APX com 802.1X e configurar o servidor de accounting RADIUS como proxy para a firewall.
2. Definir o remetente real, o endereço de destino da firewall, a porta UDP 1813 e um shared secret forte.
3. Em Authentication > Services > SSO using RADIUS accounting request, introduzir o IP do remetente e o shared secret.
4. Em Administration > Device access, permitir o serviço RADIUS SSO apenas para este remetente e o endereço correto da firewall.
5. Preparar uma regra de utilizador estritamente limitada com Match known users e logging.
6. Ligar um cliente real e verificar o pacote de accounting na firewall.
7. Em Current activities > Live users, verificar o tipo de cliente RADIUS SSO, o utilizador e o IP correto do cliente.
8. Só depois testar tráfego permitido e deliberadamente não permitido com o Firewall Rule ID esperado.

Quando o RADIUS SSO é adequado

O RADIUS SSO é especialmente adequado para redes Wi-Fi 802.1X ou sistemas de acesso à rede onde a autenticação já ocorre fora da firewall. A firewall pode então reconhecer o utilizador sem um segundo início de sessão no navegador.

O procedimento exige uma relação inequívoca entre o utilizador e um endereço IPv4. Os requisitos típicos são:

• O cliente recebe um endereço IPv4 que a Sophos Firewall também vê como origem do tráfego.
• O remetente do accounting conhece o nome de utilizador e este IP do cliente.
• O accounting start chega diretamente a um endereço da firewall sem uma alteração inesperada de NAT de origem.
• O remetente RADIUS consegue fornecer Framed-IP-Address no pacote inicial.
• Os objetos de utilizador ou grupo e a respetiva regra de firewall já foram planeados.

O RADIUS SSO não substitui o STAS na Sophos Firewall quando os eventos de início de sessão do Windows no Active Directory são a fonte de identidade. Também não distingue vários utilizadores por trás do mesmo IP RDS ou Citrix. Consoante o tráfego, são mais adequados o SATC para Remote Desktop Services ou o AD SSO por ligação através do direct web proxy.

Quando interromper o procedimento

Não ativar em produção enquanto algum destes pontos estiver em aberto:

• O pacote de accounting não contém um nome de utilizador ou Framed-IP-Address.
• O endereço indicado no pacote difere do IP de origem que a firewall vê mais tarde no tráfego útil.
• Vários utilizadores partilham o mesmo IP de cliente.
• O remetente real ou o endereço de destino da firewall não é inequívoco devido a NAT, HA ou routing.
• O cliente RADIUS apenas consegue usar uma rede inteira não fidedigna em vez de um endereço de origem fixo.
• A estratégia de regras para utilizadores desconhecidos ou que já terminaram sessão não está esclarecida.

Compreender o caminho do accounting

Na autenticação RADIUS clássica, a firewall envia um Access-Request para o servidor RADIUS. Com RADIUS SSO, a direção é inversa:

1. Um cliente autentica-se no APX gerido pelo SFOS através do servidor RADIUS selecionado em Wireless > Wireless settings.
2. O APX envia o accounting para esse servidor através da firewall. O servidor também está configurado como proxy de accounting e reencaminha a mensagem para a firewall.
3. A Sophos Firewall recebe o pacote reencaminhado no serviço RADIUS SSO.
4. Se o IP do remetente corresponder a RADIUS client IPv4 e o shared secret estiver correto, a firewall processa a mensagem.
5. O nome de utilizador e Framed-IP-Address aparecem associados em Live users.
6. Só o tráfego útil subsequente pode corresponder a uma regra com Match known users.

No fluxo APX oficial, o servidor RADIUS é simultaneamente o destino da autenticação e do accounting e o proxy que reencaminha os pacotes de accounting APX para a firewall. Por isso, o NPS requer uma configuração de proxy RADIUS adequada. Para RADIUS client IPv4, conta o IP de origem do pacote reencaminhado. Uma indicação geral como «suporta RADIUS Accounting» não comprova o suporte desta arquitetura nem a presença do nome de utilizador e IP do cliente no accounting start.

Exemplo completo

Este guia usa os seguintes valores de exemplo:

• Remetente RADIUS ou de accounting: 10.10.20.15
• Endereço da firewall para RADIUS SSO: 10.10.20.1
• Cliente Wi-Fi: 10.30.40.50
• Porta de destino do accounting: UDP 1813
• Utilizador: EXAMPLE\alex.muster
• Regra de utilizador: RADIUS-SSO-WiFi-Out

Os endereços pertencem a redes privadas de exemplo e devem ser substituídos pelas redes reais de gestão, servidores e clientes. Em RADIUS client IPv4, não se introduz automaticamente o IP do servidor de autenticação, mas o IP de origem realmente visível no packet capture da firewall.

Preparar o sistema remoto

Na arquitetura APX oficialmente documentada, verificar separadamente a autenticação, o accounting para o servidor RADIUS e o caminho de retorno do proxy para a firewall. Um início de sessão 802.1X bem-sucedido não prova que o servidor RADIUS reencaminha accounting para a Sophos Firewall.

Preparar o sistema remoto, no mínimo, da seguinte forma:

1. Configurar o APX e a rede Wi-Fi 802.1X em Wireless e selecionar o servidor RADIUS em Wireless > Wireless settings.
2. Ativar accounting no servidor RADIUS e configurá-lo como proxy para o endereço da firewall 10.10.20.1.
3. Usar UDP 1813 no reencaminhamento para a firewall.
4. Configurar um shared secret próprio e forte para este caminho.
5. Enviar o accounting start apenas quando o IP do cliente for conhecido.
6. Garantir que o nome de utilizador e Framed-IP-Address estão incluídos.
7. Documentar o IP de origem, o routing e qualquer tradução NAT para a interface da firewall.

Um accounting stop ou update pode melhorar a manutenção da sessão em alguns produtos. Contudo, a ajuda pública da Sophos refere explicitamente o IP do accounting start como base de início de sessão para Wi-Fi SSO. Por isso, um update posterior não pode substituir um pacote inicial completo como critério de sucesso.

Em instalações APX geridas pelo SFOS, a temporização DHCP pode ser relevante. A Sophos documenta radius_accounting_start_delay entre 0 e 60 segundos. O exemplo oficial para a Device Console define 30 segundos:

system wireless-controller global radius_accounting_start_delay 30

30 é um exemplo ajustável, não um valor predefinido universal. Antes da alteração, executar system wireless-controller global show e registar o valor atual. Alterar o parâmetro apenas se um capture mostrar que o accounting start é gerado antes da atribuição do IP. Para rollback, executar o comando de definição com o valor registado. Se esse valor era 0 (sem atraso), o comando exato é system wireless-controller global radius_accounting_start_delay 0. As fontes oficiais não indicam um valor predefinido universal; não se deve presumir nenhum quando o valor anterior é desconhecido. A Sophos também indica use_tunneled_reply para FreeRADIUS; esta opção pertence ao servidor FreeRADIUS e não deve ser aplicada ao NPS sem confirmação. A configuração Wi-Fi geral é explicada em Configurar Wireless Network na Sophos Firewall.

As notas de versão do AP6 incluem WIFIX-5189, um problema resolvido relativo à framed IP em pacotes de accounting. Contudo, o procedimento RADIUS SSO limita o fluxo descrito a APX. A correção do AP6 não comprova, portanto, que esta configuração é suportada.

Configurar RADIUS SSO na Sophos Firewall

Introduzir o remetente e o shared secret

O caminho de menu é:

Authentication > Services > SSO using RADIUS accounting request

Procedimento:

1. Em RADIUS client IPv4, adicionar o IP do remetente 10.10.20.15 esperado no capture.
2. Introduzir o Shared secret acordado para este caminho.
3. Adicionar outros remetentes apenas como entradas próprias e documentadas.
4. Selecionar Apply.

Nesta secção, o SFOS 22 disponibiliza apenas RADIUS client IPv4 e Shared secret; não existe uma definição de porta separada. Apenas os pacotes provenientes dos endereços IPv4 configurados são considerados para RADIUS SSO. Uma rede inteira ou um endereço de origem arbitrário não é uma alternativa sensata a um planeamento ausente do remetente.

Esta configuração do recetor não cria, por si só, um servidor RADIUS em Authentication > Servers. O fluxo APX oficial exige, ainda assim, que o servidor RADIUS externo seja adicionado nesse local e selecionado em Wireless > Wireless settings; a configuração geral de um servidor RADIUS na Sophos Firewall explica essa parte. A autenticação e accounting de saída e as mensagens RADIUS SSO reencaminhadas continuam a ser caminhos separados.

Permitir Device Access de forma restrita

O RADIUS SSO é um serviço local da firewall. Uma regra LAN-to-WAN ou WiFi-to-WAN normal não abre este caminho de receção.

Em Administration > Device access existem duas opções corretas:

• Se a zona do remetente for pequena e totalmente fidedigna, ativar RADIUS SSO na matriz de zonas.
• Se apenas estiver previsto um sistema remoto fixo, manter o acesso da zona desativado e criar uma Accept Local service ACL exception rule específica para o IP do remetente, o endereço utilizado da firewall e o serviço RADIUS SSO.

Uma exceção accept adicional não restringe uma autorização de zona já ativa. Para uma exceção verdadeiramente restrita, RADIUS SSO deve permanecer desativado na zona afetada. O procedimento completo é explicado em Device Access e Local Service ACL.

Preparar a regra de utilizador

Não é necessária uma regra de produção ampla para o primeiro teste. Uma regra limitada fornece resultados mais claros:

1. Em Rules and policies > Firewall rules, criar uma regra acima das regras WiFi ou LAN mais gerais.
2. Limitar Source Zone e Source Network à rede real de clientes.
3. Selecionar apenas o utilizador piloto ou um grupo piloto preparado.
4. Ativar Match known users.
5. Permitir apenas um serviço de teste inofensivo ou um destino claramente definido.
6. Ativar Log firewall traffic.
7. Definir uma segunda combinação de utilizador ou destino deliberadamente não permitida para o teste negativo.

O RADIUS SSO fornece uma identidade, não uma autorização geral de rede. Criar regras de firewall na Sophos Firewall explica como utilizadores, grupos, serviços e logging funcionam em conjunto.

Validar RADIUS SSO de forma controlada

1. Comprovar o pacote de accounting na firewall

Em Diagnostics > Packet capture, definir um filtro para o IP do remetente 10.10.20.15, o endereço da firewall 10.10.20.1 e UDP 1813. Em seguida, voltar a ligar exatamente um cliente piloto.

O capture tem de confirmar, no mínimo:

• O IP de origem é o RADIUS client IPv4 configurado.
• O destino é o endereço previsto da firewall.
• A porta de destino é UDP 1813.
• Aparece um accounting start para o utilizador piloto.
• Framed-IP-Address corresponde ao IP atual do cliente 10.30.40.50.

O RADIUS accounting contém dados de identidade e sessão que podem estar visíveis no pacote. Tratar os ficheiros capture como logs de autenticação, guardá-los apenas por pouco tempo e não os partilhar sem proteção. A utilização geral é descrita em Packet Capture na Sophos Firewall.

2. Verificar Live User

Em Current activities > Live users, o utilizador, o IP do cliente e o tipo de cliente têm de coincidir. Para este procedimento, espera-se RADIUS SSO como tipo de cliente.

Um utilizador visível com o IP errado não é um sucesso parcial. As regras de utilizador correspondem depois à origem real do tráfego, não à associação Wi-Fi pretendida.

3. Correlacionar o log de autenticação

Em Log Viewer, procurar o utilizador piloto e a hora do incidente. Para a análise detalhada, access_server.log é relevante porque a Sophos processa aí a autenticação, autorização e accounting dos utilizadores.

Em HA, cada nó guarda apenas os logs do tráfego que processou. Verificar o nó que recebeu o accounting no momento do teste. Verificar serviços e logs da Sophos Firewall através da CLI explica como ler e guardar access_server.log sem reiniciar o serviço de forma descontrolada.

4. Executar testes positivo e negativo

Com o cliente piloto, testar separadamente quatro aspetos:

1. Um destino permitido corresponde ao Firewall Rule ID esperado e mostra o utilizador correto.
2. Um destino deliberadamente não permitido permanece bloqueado.
3. Um utilizador não atribuído não recebe o acesso piloto.
4. Após uma nova ligação ou roaming controlado, a associação de utilizador, IP e regra permanece correta.

O teste tem de usar tráfego útil real. Uma entrada Live User, por si só, não comprova a correspondência de regras, o routing ou o caminho de retorno. Testar regras de firewall de forma fiável descreve o procedimento repetível.

Delimitar erros por sintoma

Nenhum pacote de accounting chega à firewall

Verificar primeiro o IP de destino, a porta UDP, o routing e a configuração do sistema remoto. Depois, controlar Device Access ou a Local Service ACL Exception Rule. Um início de sessão RADIUS bem-sucedido no NPS ou na rede Wi-Fi não comprova que existe o caminho separado de accounting para a firewall.

Se o pacote chegar com outro IP de origem, investigar exatamente essa causa. Não permitir precipitadamente uma rede inteira como cliente RADIUS. Com NAT ou HA, documentar e permitir de forma específica o endereço estável do remetente que é realmente visível.

O accounting chega, mas Live Users permanece vazio

Verificar em conjunto o shared secret, o IP do remetente e o conteúdo do pacote. O accounting start, o nome de utilizador e Framed-IP-Address são especialmente importantes. Se faltar o IP do cliente, corrigir primeiro o access point, o controlador ou o proxy RADIUS. Reiniciar um serviço da firewall não cria um atributo em falta.

Só quando o pacote estiver completo e access_server.log continuar sem processar o evento se devem guardar a hora, o capture, o CTR e os logs do nó para o Sophos Support. Não eliminar a base de dados de autenticação nem limpar Live Users por tentativa.

O utilizador aparece com o IP errado

Isto indica frequentemente uma mensagem de accounting demasiado precoce, uma associação DHCP antiga, roaming ou um caminho NAT diferente. Desligar o cliente, registar a lease atual e capturar uma única nova ligação. É decisivo o IP no novo accounting start.

Em wireless gerido pelo SFOS, alterar radius_accounting_start_delay apenas após esta prova e documentando o valor anterior. Access points ou controladores de terceiros usam os seus próprios mecanismos de accounting e DHCP; um parâmetro wireless da Sophos não altera estes dispositivos.

Live User está correto, mas a regra não corresponde

Nesse caso, o caminho de accounting está mais avançado do que a policy. Verificar Source Zone, Source Network, utilizador ou grupo, Match known users, ordem das regras, Firewall Rule ID e IP real do tráfego. Se corresponder a regra #0 ou uma regra geral, corrigir a policy em vez de alterar o shared secret.

O utilizador permanece visível após terminar a sessão

Verificar primeiro se o sistema remoto envia um accounting stop e se este pacote se refere à mesma sessão e associação de utilizador. Depois, correlacionar Live User, o tráfego atual do cliente e access_server.log. Uma desconexão manual pode limpar temporariamente o estado, mas não comprova que o processo automático está correto.

Após reiniciar a firewall, a Sophos indica que os clientes APX têm de desligar e voltar a ligar para que um novo accounting start restaure o início de sessão. Se Show captive portal to unknown users estiver ativo na regra de utilizador, o portal pode aparecer inicialmente; no fluxo APX documentado, o início de sessão transparente ocorre após o atraso de accounting configurado, sem voltar a introduzir credenciais.

Segurança, HA e operação

O RADIUS accounting utiliza UDP e não protege o transporte como TLS. O shared secret autentica o caminho RADIUS, mas não encripta todos os atributos de identidade e sessão. O accounting deve, por isso, permanecer numa rede fidedigna de gestão ou servidores e não atravessar redes externas sem proteção.

Em operação, aplicam-se estes limites:

• Usar um shared secret próprio e forte e um responsável documentado para cada remetente.
• Permitir RADIUS SSO apenas a partir das zonas necessárias e, se possível, apenas de hosts fixos.
• Tratar ficheiros capture, logs RADIUS e access_server.log como dados operacionais pessoais.
• Terminar alterações a DHCP, controlador Wi-Fi, NPS, proxy RADIUS ou NAT com um novo teste end-to-end.
• Em HA, não prometer a preservação ininterrupta da associação de utilizador. Após um failover planeado, verificar um novo accounting start, Live User e tráfego real no nó que o processa.
• Tratar utilizadores desconhecidos ou associações em falta com uma regra predefinida segura, não com uma regra allow ampla.

Rollback

O rollback é efetuado numa ordem que não deixa o serviço de accounting aberto nem concede acesso involuntário aos utilizadores:

1. Restaurar a estratégia anterior de autenticação e regras para a rede piloto.
2. Desativar a regra piloto e efetuar um teste negativo com um utilizador desconhecido.
3. Remover do servidor RADIUS o destino de reencaminhamento do proxy para a firewall ou repor o estado anterior documentado do proxy. Não remover o destino de accounting do APX se o servidor RADIUS continuar a ser necessário para a autenticação e o accounting Wi-Fi.
4. Remover o remetente em SSO using RADIUS accounting request.
5. Retirar a exceção ACL de RADIUS SSO ou a autorização temporária de zona.
6. Voltar a verificar Live Users, Firewall Rule ID e o tráfego normal do cliente.

Documentar na alteração a configuração original, a responsabilidade pelo shared secret e o retorno testado ao método anterior de identificação de utilizadores. Eliminar apenas uma entrada Live User não constitui um rollback completo.

FAQ