Sophos Firewall como relay NTP: encaminhar NTP via NAT

Quando os dispositivos internos precisam de usar o IP do gateway como destino NTP, o Sophos Firewall pode encaminhar os seus pedidos para um servidor de hora através de NAT. A definição em Administration > Time sincroniza apenas o relógio do firewall; não disponibiliza um serviço de servidor NTP aos clientes.

A solução documentada pela Sophos é um relay NTP via NAT. Os dispositivos enviam NTP para o IP do firewall, que traduz o destino e a origem e encaminha os pacotes para um servidor de hora real, externo ou interno. O firewall não se torna assim a fonte de tempo. Separadamente, atua como cliente NTP para sincronizar o próprio relógio.

Isto é particularmente útil se os dispositivos estiverem permanentemente configurados para o IP do gateway, se um ambiente UTM anterior tiver sido substituído ou se for necessário controlar centralmente os destinos NTP. Para novas conceções DHCP, geralmente é mais fácil distribuir o servidor de hora correto diretamente através da opção DHCP. Os princípios básicos podem ser encontrados em Configurar opções DHCP no Sophos Firewall.

⚠️ Importante: O Sophos Firewall não deve fornecer um serviço NTP aberto para a Internet. Zonas de origem, redes de origem, servidores de destino e regras de firewall devem ser deliberadamente restringidas. WAN como Source Zone é geralmente incorreto para esse padrão.

Qual variante é adequada?

NTP via NAT é um padrão pragmático, mas nem sempre a melhor arquitetura.

Duas variantes são importantes para este artigo:

• Variante A: Dispositivos internos usam o IP do firewall como servidor NTP, o firewall encaminha para um servidor NTP externo.
• Variante B: Dispositivos internos utilizam o IP do firewall como servidor NTP, o firewall encaminha para um servidor NTP interno. Além disso, o servidor interno NTP deve ter permissão para sincronizar externamente.

A segunda variante tem, por isso, dois caminhos de dados separados. Se a sincronização externa do servidor de hora interno já estiver devidamente autorizada e traduzida, verifica-se e reutiliza-se o par de regras existente; não são necessárias regras adicionais idênticas.

Requisitos

Antes da configuração, estes pontos devem estar claros:

• Quais redes internas podem usar NTP?
• Que endereço IP os clientes usam como destino NTP, por exemplo o IP do gateway?
• Que servidor NTP real se pretende utilizar?
• Deve ser usado um servidor de hora interno ou um serviço externo como time.google.com ou pool.ntp.org?
• O firewall pode resolver DNS de forma fiável para destinos FQDN?
• A hora do sistema do próprio firewall está sincronizada corretamente?

Um exemplo IPv4 coerente torna clara a correspondência:

• net_Internet-LAN: 10.10.11.0/24, entrada dos clientes em Port2, na zona da rede interna de clientes.
• host_internal-firewall-ip: host 10.10.11.1, o IP do firewall utilizado por estes clientes.
• host_Google-NTP: FQDN time.google.com para a variante A e, se necessário, como fonte de tempo externa do servidor interno.
• NTP_Server_Internal: host 192.168.20.10, acessível através de Port3, na zona DMZ, para a variante B.

Estes endereços privados, nomes de objetos e interfaces são exemplos e devem ser substituídos pelos valores reais. Selecionam-se apenas as redes que precisam do relay e as respetivas interfaces de entrada; para IOT_NET, acrescenta-se, se necessário, uma regra própria igualmente restrita. Os objetos de rede e de host são criados em Hosts and services > IP host. Se existirem vários IPs de gateway, as redes de origem, entradas e endereços de destino correspondentes têm de ser coerentes. Antes de qualquer alteração, registam-se as regras NAT e de firewall existentes, a sua ordem e a fonte de tempo dos clientes; o servidor de hora real tem de estar acessível e aceitar pedidos do endereço do firewall utilizado por MASQ.

A hora correta é importante para funções críticas de tempo, como MFA, autenticação WAF, certificados, logs, correlação VPN e SIEM. Se o próprio firewall tiver hora incorreta, a hora do sistema deve ser verificada primeiro antes de redirecionar o Client-NTP.

Os passos seguintes baseiam-se na documentação oficial do Sophos Firewall 22.0 (fontes verificadas em 17.10.2026). Não foi realizado qualquer teste num equipamento para esta instrução. As definições NTP do firewall não podem ser sincronizadas pelo Sophos Fusion (anteriormente Sophos Central); são geridas no WebAdmin, por CLI ou API. Os passos de NAT e firewall abaixo usam o WebAdmin.

Os exemplos usam intencionalmente uma configuração IPv4, com IP version: IPv4 selecionado ao criar o host. Em ambientes IPv6 ou dual-stack, este padrão não deve ser simplesmente copiado. Primeiro é necessário esclarecer se os clientes precisam realmente de NTP via IPv6, que funções de firewall e NAT se aplicam na versão SFOS usada e se DHCPv6, Router Advertisements ou um servidor de hora interno direto são a solução mais adequada.

Quick Reference

Para administradores experientes, a lógica curta é simples: os clientes enviam UDP 123 para o IP do firewall ou gateway. Uma regra DNAT altera o destino para o servidor NTP real, uma regra de firewall permite exatamente esse tráfego e o Log Viewer confirma depois o Firewall Rule ID e o NAT Rule ID.

Servidor NTP externo: uma regra DNAT encaminha NTP do IP do firewall para o objeto FQDN ou host do servidor NTP externo. Uma regra de firewall permite NTP das fontes internas afetadas em direção a WAN. No exemplo geral de relay, a Sophos deixa Original destination como Any. Para o relay através do IP do gateway aqui descrito, limitar o campo ao IP exato do firewall usado pelos clientes. Assim, pedidos NTP diretos destinados a outros servidores não são redirecionados silenciosamente.

Servidor NTP interno: são necessários dois fluxos. Primeiro, o servidor NTP interno deve poder sincronizar externamente via SNAT/MASQ. Depois, uma regra DNAT encaminha pedidos de clientes do IP do firewall para o servidor NTP interno. Ambos os pares de regras devem ser verificados separadamente no Log Viewer.

Na primeira implementação, a posição da regra deve ser deliberadamente alta, normalmente Top ou acima de regras LAN-to-WAN e NAT gerais. Depois, a posição pode ser integrada no conceito de regras existente, desde que o Log Viewer e Packet Capture continuem a mostrar que a regra esperada é a primeira a corresponder.

host_internal-firewall-ip contém o endereço IP LAN interno do Sophos Firewall, aqui 10.10.11.1. Os clientes usam este endereço como servidor NTP. Substitui o exemplo pelo IP LAN interno do firewall da tua rede de clientes e adapta net_Internet-LAN (10.10.11.0/24), a interface de entrada e a zona de origem. Aqui a entrada é Port2 com a zona da rede interna de clientes; Port1 pertence à DMZ e não é usado. Ambas as regras usam o serviço predefinido NTP; não é necessário um serviço adicional apenas UDP. Este exemplo de configuração não comprova um teste real bem-sucedido. Seleciona a zona atribuída à rede de clientes no teu ambiente; «zona LAN interna» é uma descrição, não um nome de zona obrigatório.

Em Hosts and services > IP host > Add, cria os dois objetos IPv4 seguintes e guarda cada um com Save. Reutiliza objetos existentes adequados, se disponíveis.

Variante A: Utilizar um servidor NTP externo

Esta variante é adequada se os clientes usarem o IP do firewall como servidor NTP e não houver um servidor de hora interno próprio. O firewall traduz o destino do pedido NTP para um servidor de hora externo, por exemplo time.google.com ou um servidor de hora de fornecedor escolhido deliberadamente.

O Google Public NTP (time.google.com) utiliza leap smear. Não o misture com fontes de tempo sem leap smear.

Criar um host FQDN para servidor NTP externo

O caminho de menu é:

Hosts and services > FQDN host

Procedimento:

1. Selecionar Add.
2. Definir Name, por exemplo host_Google-NTP.
3. Introduzir o servidor NTP externo em FQDN, por exemplo time.google.com.
4. Guardar.

Se um servidor de hora interno ou externo com um IP fixo for usado em vez de FQDN, um objeto de host normal poderá fazer mais sentido. É importante que o destino possa ser claramente reconhecido posteriormente no NAT e na regra de firewall.

Criar regra NAT para o servidor NTP externo

A regra NAT garante que os pedidos NTP ao IP do firewall sejam reescritos para o servidor de hora externo. O caminho de menu é:

Rules and policies > NAT rules

Procedimento:

1. Selecionar Add NAT rule > New NAT rule.
2. Definir Rule name, por exemplo DNAT_Client_NTP_to_External.
3. Definir Rule position como Top ou colocar acima das regras amplas NAT.
4. Configurar Original source para a rede interna afetada, neste exemplo net_Internet-LAN (10.10.11.0/24).
5. Configurar Original destination como host_internal-firewall-ip, neste exemplo 10.10.11.1.
6. Para Original service, remover Any e selecionar NTP.
7. Para Translated source (SNAT) selecionar MASQ.
8. Para Translated destination (DNAT), selecionar o host FQDN ou o host do servidor externo NTP.
9. Para Inbound interface, remover Any e selecionar a entrada real dos clientes, neste exemplo Port2. A Sophos também permite Any, mas a seleção explícita evita correspondências em entradas não pretendidas.
10. Manter Translated service (PAT) em Original para preservar UDP 123. Outbound interface permanece em Any nesta regra DNAT; a rota para o destino traduzido determina a saída.
11. Guardar.

    

⚠️ Não deixar Original destination aberto: se Original destination não for limitado ao IP do firewall ou gateway, a regra pode atuar de forma muito mais ampla, dependendo da restante configuração NAT. Nesse caso, não só o tráfego para o IP do firewall pode ser encaminhado; o tráfego NTP da rede também pode ser redirecionado de forma transparente. Para um relay controlado, a regra só deve corresponder quando os clientes usam realmente o IP do firewall ou gateway como destino NTP. Na visão detalhada deve prestar-se especial atenção a quatro pontos: O destino original deve ser realmente o IP do firewall ou gateway, o serviço deve permanecer limitado a NTP ou UDP 123, o destino traduzido deve apontar para o servidor de hora previsto e SNAT deve corresponder à rota de retorno.

Se os campos básicos de NAT ou DNAT não estiverem claros, Compreender NAT no Sophos Firewall: SNAT, DNAT, MASQ, PAT ajudará. Também explica porque NAT não substitui a permissão concedida por uma regra de firewall.

Permitir regra de firewall para NTP externo

De acordo com a regra NAT, é necessária uma regra de firewall adequada. Isso permite o tráfego NTP das redes internas para o servidor de destino. O caminho de menu é:

Rules and policies > Firewall rules

Procedimento:

1. Selecionar Add firewall rule > New firewall rule.
2. Definir Rule name, por exemplo NTP_LAN_to_Google.
3. Definir Rule position como Top ou colocá-la acima das regras gerais LAN-to-WAN se estas corresponderem antes.
4. Ativar Log firewall traffic.
5. Definir Source zones para as zonas internas, por exemplo a zona LAN interna, DMZ ou uma zona IoT. WAN e Any estão incorretos para esse padrão.
6. Definir Source networks and devices para as redes ou dispositivos afetados. Não é um Any geral se apenas algumas redes usarem NTP.
7. Definir Destination zones como WAN.
8. Definir Destination networks como um objeto host IPv4 para o IP do firewall ou gateway que os clientes usam como destino NTP, por exemplo host_internal-firewall-ip. Se não existir, criá-lo em Hosts and services > IP host > Add, com Type: IP e esse endereço IP exato. Deve corresponder a Original destination na regra DNAT dos clientes, não ao host NTP externo.
9. Definir Services como NTP.
10. Definir Action como Accept.
11. Guardar.

Em exemplos oficiais ou simplificados, Source networks and devices aparece por vezes como Any. Num laboratório é prático, mas em produção raramente é a melhor escolha. É mais adequado usar um objeto de rede concreto como net_Internet-LAN, IOT_NET ou um pequeno grupo de hosts, para que fique claro que dispositivos podem usar este encaminhamento NTP.

No DNAT de entrada, a Sophos determina primeiro o destino traduzido. Destination zones usa a zona desse destino, aqui WAN; Destination networks, por outro lado, usa o destino original, aqui o IP do firewall ou gateway. O servidor de hora real permanece apenas em Translated destination (DNAT). O exemplo NTP geral da Sophos não especifica Destination networks; esta distinção segue os exemplos explícitos de DNAT e loopback. Após uma alteração, iniciar uma nova sessão NTP a partir do cliente: as sessões existentes não são reavaliadas com as regras NAT alteradas. Antes de validar a configuração, verificar Firewall Rule ID, NAT Rule ID e o caminho dos pacotes de entrada e encaminhados como descrito na secção de testes; a configuração por si só não comprova uma sincronização bem-sucedida.

O registo do tráfego desta regra é útil durante a implementação. Após o teste, pode verificar-se no Log Viewer de que rede de clientes veio o pedido, qual Firewall Rule ID foi utilizado e se o NAT Rule ID esperado também está visível. Se nenhum ID de regra ou uma regra incorreta aparecer, a ordem ou correspondência da regra é mais importante do que a própria configuração NTP.

Para estrutura de regras, sequência, Services e registo de tráfego, Compreender e configurar corretamente as regras Sophos Firewall também é adequado.

Variante B: Utilizar um servidor NTP interno

Esta variante é adequada se um controlador de domínio interno, servidor de hora Linux ou outro sistema interno for a fonte de horário para clientes, mas os clientes continuarem a usar o IP do firewall como servidor NTP.

Verificam-se aqui dois caminhos de dados com os respetivos pares de regras; as regras existentes adequadas podem ser reutilizadas:

Criar um host para servidor interno NTP

O caminho de menu é:

Hosts and services > IP host

Procedimento:

1. Selecionar Add.
2. Definir Name, por exemplo NTP_Server_Internal.
3. Definir IP version como IPv4 se IPv4 for usado.
4. Definir Type como IP.
5. Introduzir o IP address do servidor NTP interno, neste exemplo 192.168.20.10.
6. Guardar.

Par de regras 1: servidor NTP interno sincroniza externamente

Primeiro, o próprio servidor NTP interno tem de conseguir aceder a um servidor de hora externo, caso ainda não esteja sincronizado por outra via. A fonte de tempo a montante configurada tem de ser o servidor de hora real, e não o IP do gateway utilizado como relay. Os pedidos só podem ser encaminhados de volta para o próprio servidor se o seu tráfego também corresponder a uma regra DNAT de relay que tenha esse servidor como destino traduzido. No exemplo acima, a rede de origem e a interface de entrada impedem essa correspondência com a regra DNAT dos clientes; o IP do gateway escolhido incorretamente poderá então não fornecer uma hora utilizável.

Regra NAT:

1. Abrir Rules and policies > NAT rules.
2. Selecionar Add NAT rule > New NAT rule.
3. Definir Rule name, por exemplo SNAT_Internal_NTP_to_WAN.
4. Definir Rule position como Top ou colocá-la adequadamente acima de regras NAT amplas.
5. Em Original source, selecionar o objeto host NTP_Server_Internal criado anteriormente.
6. Configurar Original destination como a fonte de tempo externa prevista, neste exemplo host_Google-NTP.
7. Para Original service, remover Any e selecionar NTP.
8. Para Translated source (SNAT), selecionar MASQ; Translated destination (DNAT) e Translated service (PAT) permanecem em Original.
9. Configurar Inbound interface como a entrada do servidor interno, neste exemplo Port3; limitar Outbound interface à interface WAN efetivamente utilizada. Se existirem várias ligações WAN, têm de ser consideradas todas as saídas previstas.
10. Guardar.

Regra de firewall:

1. Abrir Rules and policies > Firewall rules.
2. Selecionar Add firewall rule > New firewall rule.
3. Definir Rule name, por exemplo Internal_NTP_to_WAN.
4. Ativar Log firewall traffic.
5. Configurar Source zones como a zona do servidor NTP interno, neste exemplo DMZ.
6. Definir Source networks and devices como NTP_Server_Internal.
7. Definir Destination zones como WAN.
8. Definir Destination networks como a mesma fonte de tempo externa da regra SNAT, neste exemplo host_Google-NTP. Não existe DNAT neste caminho; o destino original e o destino real são idênticos.
9. Definir Services como NTP e Action como Accept.
10. Colocar a regra acima das regras gerais que, de outro modo, corresponderiam primeiro e guardar.

Par de regras 2: Encaminhar clientes para o servidor NTP interno através do IP do firewall

O encaminhamento real é então construído: os clientes enviam NTP para o IP do firewall, o firewall encaminha para o servidor NTP interno.

Regra NAT:

1. Abrir Rules and policies > NAT rules.
2. Selecionar Add NAT rule > New NAT rule.
3. Definir Rule name, por exemplo DNAT_Client_NTP_to_Internal.
4. Definir Rule position como Top ou colocá-la acima de regras NAT gerais.
5. Configurar Original source para as redes internas dos clientes afetados, neste exemplo net_Internet-LAN.
6. Configurar Original destination para o IP do firewall ou gateway que os clientes usam como destino NTP, neste exemplo host_internal-firewall-ip.
7. Para Original service, remover Any e selecionar NTP.
8. Para Translated source (SNAT), selecionar MASQ.
9. Para Translated destination (DNAT) selecionar NTP_Server_Internal.
10. Em Inbound interface, selecionar as interfaces internas dos clientes afetados, neste exemplo Port2.
11. Manter Translated service (PAT) em Original; Outbound interface permanece em Any nesta regra DNAT.
12. Guardar.

Também aqui Original destination é decisivo: a regra deve traduzir apenas pedidos NTP dirigidos ao IP do firewall ou gateway. Se este campo permanecer demasiado amplo, o firewall também pode capturar pedidos NTP que os clientes queriam enviar diretamente para outro servidor de hora.

Regra de firewall:

1. Abrir Rules and policies > Firewall rules.
2. Selecionar Add firewall rule > New firewall rule.
3. Definir Rule name, por exemplo LAN_to_Internal_NTP.
4. Ativar Log firewall traffic.
5. Configurar Source zones para as zonas clientes internas. Evitar WAN e Any.
6. Configurar Source networks and devices para as redes de clientes afetadas.
7. Configurar Destination zones para a zona do servidor NTP interno, por exemplo a zona LAN interna ou DMZ.
8. Definir Destination networks como o objeto host IPv4 do IP do firewall ou gateway originalmente contactado, por exemplo host_internal-firewall-ip, tal como em Original destination da regra DNAT dos clientes. Não selecionar NTP_Server_Internal; esse host permanece em Translated destination (DNAT).
9. Definir Services como NTP.
10. Definir Action como Accept. Colocar a regra acima das regras gerais que, de outro modo, corresponderiam primeiro e guardar.

Também aqui, Destination zones corresponde ao destino interno traduzido, enquanto Destination networks contém o IP original do firewall ou gateway. Verificar separadamente uma nova sessão do cliente, os IDs das regras e o caminho dos pacotes para este par de regras. MASQ garante que as respostas regressem através do firewall, mas oculta o IP original do cliente ao servidor NTP interno. Se o servidor precisar dos endereços dos clientes para registo ou controlo de acesso, planear acesso direto com uma rota de retorno adequada em vez deste padrão de relay.

Se o próprio servidor NTP interno for um controlador de domínio, deve definir-se o âmbito com especial cuidado. Nem toda rede cliente precisa aceder diretamente todos os controladores de domínio. NTP pode ser permitido sem abrir acessos igualmente amplos ao controlador de domínio.

Operações, segurança e testes

Enquadrar IPS e funcionalidades de segurança

NTP é tecnicamente um pequeno serviço UDP, mas UDP 123 também se torna relevante na prática para abuso, configuração incorreta ou destinos externos indesejados. Se uma licença de proteção de rede estiver disponível, uma política IPS adequada na regra de firewall poderá fazer sentido.

Para NTP, uma configuração restrita é mais importante do que aplicar o maior número possível de funcionalidades de segurança:

• Source Zone apenas interna: evita que o firewall atue como um relé NTP público.
• Redes de origem concretas: limita NTP a clientes, servidores ou dispositivos que realmente precisam desse encaminhamento.
• Definir Destination Server: limita o tráfego que corresponde a esta regra de relay ao servidor de hora definido e facilita a análise dos logs.
• Serviço somente NTP: evita uma regra UDP muito ampla.
• Ativar registo: mostra em Log Viewer se Firewall Rule ID e NAT Rule ID funcionam conforme esperado.

O IPS deve, portanto, ser visto como um controlo adicional e não como um substituto para uma regra bem definida. Se a regra NTP permitir apenas algumas redes internas para um servidor de hora definido, o ganho de segurança mais importante já é alcançado através do âmbito e da rastreabilidade. Quando um grande número de redes, dispositivos pouco claros ou áreas de IoT/OT estão envolvidos, uma política de IPS direcionada torna-se mais interessante.

Se o IPS for utilizado nesta regra NTP, a política IPS atribuída deve incluir explicitamente assinaturas relacionadas com NTP (IPS patterns). Assim, a proteção adicional centra-se em ataques contra serviços NTP; descrever uma política como geralmente adequada não substitui a seleção dessas assinaturas.

⚠️ O IPS requer uma licença de proteção de rede adequada. Se o IPS estiver ativado numa regra muito utilizada, os logs e o desempenho deverão ser monitorizados. Para o encaminhamento NTP simples, a delimitação adequada do âmbito é mais importante do que uma combinação desnecessariamente ampla de funcionalidades de segurança.

Se uma política IPS dedicada for usada para esse fim, ela não deverá ser copiada para todas as redes internas. Faz mais sentido ter uma regra pequena com uma origem clara, um destino NTP definido, registo ativo e controlo subsequente no Log Viewer.

As outras funcionalidades de segurança devem ser avaliadas com prudência para NTP. Para este serviço UDP simples, Web Filtering, TLS Inspection, Application Control ou Malware Scan geralmente não ajudam com a função NTP real. Se tais perfis estiverem ativos numa regra coletiva, deve-se verificar se NTP estaria melhor colocado numa regra própria e restrita.

Distribuir NTP de forma adequada com DHCP

Se os clientes receberem a sua configuração de rede via DHCP, deve verificar-se se um encaminhamento NAT é mesmo necessário. Para muitos ambientes, é mais fácil distribuir o servidor NTP desejado diretamente via DHCP.

Se existir um controlador de domínio ou servidor de hora central, a opção DHCP 42 pode apontar diretamente para esse servidor, desde que o cliente em questão suporte e utilize efetivamente esta opção. Os membros de um domínio podem, em alternativa, seguir a hierarquia de tempo do domínio; por isso, verifica-se no cliente qual é a fonte de tempo efetiva. NAT é particularmente útil se os dispositivos já usam o IP do gateway ou são difíceis de reconfigurar. Para opções especiais de DHCP, Configurar opções DHCP no Sophos Firewall é um começo melhor.

Configurar o firewall separadamente como cliente NTP

O encaminhamento NTP dos clientes não equivale a configurar a hora do sistema do Sophos Firewall. Em Administration > Time, o SFOS 22.0 disponibiliza três opções:

Configuração atual inalterada do relógio do firewall: Use pre-defined NTP server, Europe/Zurich. É independente do relay dos clientes e não comprova sincronização bem-sucedida; Sync now e Apply não foram utilizados.

• Use predefined NTP server é a predefinição. O firewall utiliza NTPv3 e 0.sophos.pool.ntp.org.
• Use custom NTP server aceita endereços IPv4, IPv6 ou DNS; são verificados até dez servidores pela ordem apresentada.
• Do not use NTP server define a data e a hora manualmente e não é recomendado para a operação normal.

Depois de selecionar um servidor, pode selecionar-se Sync now e, em seguida, Apply. Após Sync now, Current time só é atualizado quando se recarrega o WebAdmin. O fuso horário é definido na mesma página, de acordo com a localização.

⚠️ Impacto na VPN: segundo a Sophos, alterar os servidores de hora NTP volta a estabelecer todas as ligações IPsec. Planear uma janela de manutenção.

Verificar os dois fluxos separadamente:

• Hora do sistema de firewall: relevante para Log Viewer, certificados, MFA, VPN, autenticação WAF, relatórios, Syslog e análise de suporte.
• Cliente-NTP via NAT: Dispositivos na rede interna recebem tempo através do IP do gateway ou de um endereço NTP redirecionado.

Se o próprio firewall tiver uma hora ou fuso horário incorreto, as entradas de log poderão ser difíceis de correlacionar, as verificações de certificados poderão falhar ou a autenticação baseada em tempo, como TOTP/MFA, poderá causar problemas. Nesse caso, a hora do sistema do firewall e o acesso do firewall NTP devem ser corrigidos primeiro. Só então faz sentido validar o cliente NTP via NAT.

Para ambientes SIEM ou Syslog, este ponto é particularmente importante: o firewall pode encaminhar corretamente o tráfego NTP e ainda enviar marcas temporais incorretas para um SIEM se a sua própria hora ou fuso horário estiver incorreto.

Para encaminhamento de log, Enviar Sophos Firewall Syslog para SIEM é adequado. Para problemas MFA, Ativar MFA para WebAdmin, VPN Portal e Remote Access no Sophos Firewall também deve ser incluído.

Testar NTP e isolar erros

Após guardar, não basta verificar se a regra existe. O que é crucial é se um cliente pode realmente sincronizar NTP e se as regras NAT e de firewall esperadas correspondem ao tráfego.

O teste começa da mesma forma para ambas as variantes: Um cliente da rede afetada usa o IP do firewall ou gateway como servidor NTP. Uma sincronização de horário é então acionada ou uma breve espera é realizada até que o cliente envie NTP.

Abrir o Log viewer no canto superior direito do WebAdmin. No módulo Firewall, utilizar Add filter para filtrar por regra, endereço IP ou porta; em alternativa, a pesquisa livre encontra 123, o endereço do cliente ou o nome da regra. Os registos de sessão podem não aparecer imediatamente: o firewall regista a sessão no evento interno Destroy. Com UDP, pode ser necessário esperar pelo fim da sessão; UDP não tem o encerramento de ligação de TCP.

Com a variante A deve estar visível:

• O cliente vem da rede interna esperada.
• A regra de firewall NTP para NTP externo corresponde ao tráfego.
• A regra DNAT para a fonte de tempo externa corresponde ao tráfego.
• O destino é o servidor NTP externo previsto.

Duas coisas devem ser verificadas para a variante B:

• O servidor NTP interno tem permissão para enviar NTP externamente.
• Os clientes são encaminhados via DNAT do IP do firewall para o servidor interno NTP.

Se o Log Viewer não mostrar claramente qual a regra que corresponde, utiliza-se Diagnostics > Packet capture. Em Configure, a expressão BPF port 123 limita a captura ao NTP. Depois de ativar Packet capture, o pacote de entrada deve mostrar o IP do cliente, o IP do firewall e UDP 123; o pacote encaminhado mostra o destino traduzido. NAT ID e Rule ID têm de corresponder às regras criadas. Incoming e Forwarded confirmam o caminho; Consumed indica um pacote destinado ao próprio firewall, enquanto Violation e Reason explicam um descarte.

Um encaminhamento bem-sucedido, por si só, não confirma a sincronização da hora. O estado NTP no cliente também tem de mostrar uma resposta válida e um estado sincronizado; na variante B, verifica-se igualmente o estado de sincronização do servidor de hora interno. Na captura de pacotes, espera-se uma resposta do servidor de hora real e, no caminho de regresso ao cliente, o IP do gateway contactado como endereço de origem. Se faltar a resposta, verificam-se primeiro a acessibilidade, o caminho de retorno e o controlo de acesso do servidor de hora para o endereço MASQ.

Como teste negativo, um cliente de uma rede interna não autorizada envia um novo pedido NTP ao IP do gateway. A regra DNAT dos clientes criada e a autorização associada não podem corresponder a esse pedido. Se o pedido for encaminhado mesmo assim, procura-se uma regra NAT ou de firewall anterior ou mais abrangente. Um pedido de um cliente autorizado diretamente a outro endereço NTP também não pode ser redirecionado por esta regra DNAT do IP do gateway. A restante política de firewall determina se o NTP direto é permitido ou bloqueado; este relay, por si só, não impõe uma fonte de tempo central para todo o tráfego.

Se nenhum log estiver visível, o cliente pode não estar a enviar o pedido, a regra do firewall não estará a registar ou o tráfego seguirá um caminho diferente. Teste a regra de firewall com Log Viewer, Policy Test e Packet Capture é adequado para a verificação sistemática.

Para problemas NTP específicos do firewall, o log do cliente NTP também é relevante. A visão geral do log está em Resolução de problemas no Sophos Firewall: serviços e logs.

Verificação final breve

Antes da conclusão produtiva, cinco pontos devem estar corretos:

1. Os clientes realmente usam o IP do firewall ou gateway como servidor NTP.
2. As regras NTP permitem apenas as redes de origem internas pretendidas.
3. Os Firewall Rule ID e NAT Rule ID esperados estão visíveis no Log Viewer.
4. A hora do sistema do firewall está correta separadamente.
5. Após DHCP, VLAN, NAT ou alterações de regras, NTP será testado novamente.

Erros típicos

• WAN permitido como Source Zone: O firewall pode agir involuntariamente como um relé NTP aberto. Limitar as zonas de origem às zonas internas.
• Any para origem e destino: A regra é difícil de controlar. Definir redes de origem e servidores de destino especificamente.
• Regra NAT presente, mas nenhuma regra de firewall: O tráfego é traduzido, mas não é permitido. Verificar Log Viewer para ID de regra e ID NAT.
• Regra de firewall sem registo: A análise de erros torna-se desnecessariamente difícil. Ativar Log firewall traffic pelo menos durante o teste.
• O destino FQDN não é resolvido: O destino DNAT não foi alcançado. Verificar a resolução DNS do firewall.
• O cliente usa outro servidor NTP: A regra nunca corresponde ao tráfego. Verificar a configuração do cliente ou a opção DHCP.
• O servidor de hora não responde: O cliente permanece não sincronizado. Verificar o servidor de destino, o encaminhamento e o UDP 123.

Reversão

Se o relay causar problemas, desativar primeiro a nova regra DNAT dos clientes e iniciar um novo teste NTP; depois desativar a regra de firewall associada. Na variante B, remover as regras SNAT e de firewall para WAN do servidor interno apenas se já não forem necessárias para a sua própria sincronização. Eliminar regras e objetos host criados exclusivamente para este relay só depois de confirmar que já não existem correspondências nem dependências. Por fim, fornecer aos clientes um servidor NTP diretamente acessível, por exemplo através da opção DHCP 42; caso contrário, perderão a sua fonte de tempo.

Perguntas frequentes