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.

Procedimento rápido

1. Verificar se o access point, o controlador ou o proxy RADIUS consegue gerar um accounting start com o nome de utilizador e Framed-IP-Address.
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 access point, controlador Wi-Fi ou network access server.
2. Após a atribuição do endereço, esta infraestrutura gera um accounting start ou encaminha-o através de um proxy RADIUS.
3. A Sophos Firewall recebe o pacote no seu 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.

O envio direto do controlador Wi-Fi para a firewall ou o reencaminhamento do accounting por um servidor RADIUS como o NPS depende do produto. A configuração Sophos não contém um procedimento universal para NPS ou controladores. O pacote que chega realmente à firewall é determinante. Uma indicação do fabricante como «suporta RADIUS Accounting» não basta enquanto o nome de utilizador e o IP do cliente não tiverem sido comprovados 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

No access point, controlador, network access server ou proxy RADIUS, a autenticação e o accounting têm de ser verificados separadamente. Um início de sessão bem-sucedido não prova que o accounting é gerado ou encaminhado para a Sophos Firewall.

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

1. Ativar accounting para o acesso 802.1X ou de rede afetado.
2. Definir o endereço previsto da firewall 10.10.20.1 como destino do accounting.
3. Usar UDP 1813 ou a porta de accounting acordada expressamente entre ambas as partes.
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 o parâmetro radius_accounting_start_delay com um intervalo de 0 a 60 segundos. Não alterar este valor por tentativa: primeiro, um capture tem de demonstrar que o accounting start é gerado antes da atribuição do IP. A configuração Wi-Fi geral é explicada em Configurar Wireless Network na Sophos Firewall.

Para AP6, as notas da versão 1.5.2167 MR5 indicam a correção WIFIX-5189 para um caso em que faltava a framed IP no accounting start e accounting update. Num AP6 com firmware antigo ou desconhecido, atualizar primeiro para firmware atual suportado e voltar a verificar o pacote. A correção não prova automaticamente que todas as combinações de controlador, proxy ou NPS encaminham corretamente os atributos.

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.

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 não cria um servidor RADIUS em Authentication > Servers nem substitui a configuração geral de um servidor RADIUS na Sophos Firewall. O artigo do servidor trata dos pedidos enviados pela firewall para NPS, MFA ou outro servidor RADIUS. O RADIUS SSO trata das mensagens de accounting recebidas.

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 é a porta de accounting configurada.
• 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.

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 o destino de accounting do access point, controlador ou proxy RADIUS, ou restaurar o estado anterior documentado.
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