Sophos Firewall como relé NTP vía NAT

En muchas redes, clientes, servidores, conmutadores, puntos de acceso o dispositivos especiales simplemente deberían utilizar el Gateway-IP como servidor horario. Sin embargo, en este escenario, no hay un servidor NTP interno completo ejecutándose en Sophos Firewall, que a su vez proporciona tiempo a los clientes.

La solución práctica es un relé NTP vía NAT. Los dispositivos envían NTP a la IP del firewall, y Sophos Firewall reenvía estas solicitudes a un servidor horario real externo o interno. El firewall no se convierte en la fuente de tiempo real; traduce y permite el tráfico correspondiente.

Esto es particularmente útil si los dispositivos están configurados permanentemente en Gateway-IP, si se ha reemplazado un entorno UTM anterior o si desea controlar de forma centralizada los objetivos NTP. Para nuevos diseños de DHCP, suele ser más limpio distribuir el servidor de hora correcto directamente a través de la opción DHCP. Los conceptos básicos se pueden encontrar en Sophos Firewall Configurar opciones de DHCP.

⚠️ Importante: El Sophos Firewall no debe proporcionar un servicio NTP abierto a Internet. Las zonas de origen, las redes de origen, los servidores de destino y las reglas de firewall deben restringirse deliberadamente. WAN como Source Zone suele ser incorrecto para este patrón.

¿Qué variante es adecuada?

NTP a través de NAT es un patrón pragmático, pero no siempre es la mejor arquitectura.

Dos variantes son importantes para este artículo:

• Variante A: Los dispositivos internos utilizan el firewall IP como servidor NTP, el firewall reenvía a un servidor NTP externo.
• Variante B: Los dispositivos internos utilizan el firewall IP como servidor NTP, el firewall reenvía a un servidor interno NTP. Además, se debe permitir que el servidor interno NTP se sincronice externamente.

Por lo tanto, la segunda variante necesita dos reglas NAT y dos reglas de firewall. Este es el punto que falta en muchas notas breves sobre este tema.

Requisitos

Antes de la configuración, estos puntos deben quedar claros:

• ¿Qué redes internas pueden utilizar NTP?
• ¿Qué dirección IP utilizan los clientes como destino NTP, por ejemplo Gateway-IP?
• ¿Qué servidor NTP real usar?
• ¿Se debe utilizar un servidor de hora interno o un servicio externo como time.google.com o pool.ntp.org?
• ¿Puede el firewall resolver de manera confiable DNS para objetivos FQDN?
• ¿Está sincronizada correctamente la hora del propio sistema del cortafuegos? La hora correcta es importante para funciones críticas como MFA, autenticación WAF, certificados, registros, correlación VPN y SIEM. Si el firewall tiene una hora incorrecta, primero se debe verificar la hora del sistema antes de redirigir Client-NTP.

Los pasos de este artículo se basan en Sophos Firewall 22.0. Las rutas de menú y los nombres de campos pueden variar ligeramente en versiones SFOS anteriores o posteriores. La configuración pertenece a la interfaz WebAdmin de Sophos Firewall o a una automatización API/CLI cuidadosamente comprobada. En Sophos Central, este conjunto de reglas NAT y firewall normalmente no se gestiona como una configuración NTP relay independiente.

Los ejemplos se describen intencionadamente como una configuración IPv4, porque Sophos también muestra la creación del host en la guía oficial con IP version: IPv4. En entornos IPv6 o dual-stack, este patrón no debe copiarse sin más. Primero hay que aclarar si los clientes realmente necesitan NTP sobre IPv6, qué funciones de firewall y NAT se aplican en la versión SFOS usada y si DHCPv6, Router Advertisements o un servidor horario interno directo son la solución más limpia.

Quick Reference

Para administradores experimentados, la lógica resumida es sencilla: los clientes envían UDP 123 a la IP del firewall o gateway. Una regla DNAT cambia el destino al servidor NTP real, una regla de firewall permite exactamente ese tráfico y Log Viewer confirma después la Firewall Rule ID y la NAT Rule ID.

Servidor NTP externo: una regla DNAT reenvía NTP desde la IP del firewall al objeto FQDN o host del servidor NTP externo. Una regla de firewall permite NTP desde las fuentes internas afectadas hacia WAN. El campo crítico es Original destination: debe apuntar a la IP del firewall o gateway.

Servidor NTP interno: se necesitan dos movimientos. Primero, el servidor NTP interno debe poder sincronizarse hacia fuera mediante SNAT/MASQ. Segundo, una regla DNAT reenvía las solicitudes de clientes desde la IP del firewall al servidor NTP interno. Ambos pares de reglas deben comprobarse por separado en Log Viewer.

Para la primera implementación, la posición de la regla debe ponerse deliberadamente alta, normalmente Top o por encima de reglas LAN-to-WAN y NAT generales. Después se puede integrar la posición en el concepto de reglas existente, siempre que Log Viewer y Packet Capture sigan mostrando que la regla esperada coincide primero.

Variante A: Usar servidor NTP externo

Esta variante es adecuada si los clientes deben utilizar el cortafuegos IP como servidor NTP y no hay un servidor horario interno propio. El firewall traduce la solicitud NTP a un servidor horario externo, por ejemplo 1.sophos.pool.ntp.org, time.google.com o un servidor horario de proveedor elegido deliberadamente.

Crear host FQDN para el servidor externo NTP

La ruta del menú es:

Hosts and services > FQDN host

Procedimiento:

1. Seleccione Add.
2. Asigne Nombre, por ejemplo NTP_1_sophos_pool.
3. Ingrese el servidor externo NTP en FQDN, por ejemplo 1.sophos.pool.ntp.org.
4. Guardar.

Si se utiliza un servidor de hora interno o externo con un IP fijo en lugar de FQDN, un objeto host normal puede tener más sentido. Es importante que el objetivo pueda reconocerse claramente más adelante en la regla NAT y el firewall.

Crear regla NAT para el servidor externo NTP

La regla NAT garantiza que las solicitudes NTP al firewall IP se reescriban en el servidor de hora externo. La ruta del menú es:

Rules and policies > NAT rules

Procedimiento:

1. Seleccione Add NAT rule > New NAT rule.
2. Configure Rule name, por ejemplo DNAT_Client_NTP_to_External.
3. Establezca Rule position en Top o colóquelo por encima de las reglas amplias NAT.
4. Configure Original source en la red interna afectada, por ejemplo LAN_NET o IOT_NET.
5. Configure Original destination en el firewall o Gateway-IP que los clientes usan como servidor NTP.
6. Para Original service, elimine Any y seleccione NTP.
7. Para Translated source (SNAT) seleccione MASQ.
8. Para Translated destination (DNAT), seleccione el host FQDN o el host del servidor externo NTP.
9. Para Inbound interface, seleccione la interfaz interna o las interfaces internas afectadas.
10. Guardar.

    

⚠️ No dejar Original destination abierta: si Original destination no se limita a la IP del firewall o gateway, la regla puede actuar de forma mucho más amplia según el resto del diseño NAT. En ese caso puede reenviar no solo tráfico hacia la IP del firewall, sino también redirigir de forma transparente tráfico NTP de la red. Para un relé controlado, la regla solo debe coincidir cuando los clientes usan realmente la IP del firewall o gateway como destino NTP. En la vista detallada debe prestar especial atención a cuatro puntos: el destino original debe ser realmente el firewall o Gateway-IP, el servicio debe permanecer limitado a NTP o UDP 123, el destino traducido debe apuntar al servidor de hora planificado y SNAT debe coincidir con la ruta de regreso.

Si los conceptos básicos de NAT o los campos DNAT no están claros, Comprender NAT en Sophos Firewall: SNAT, DNAT, MASQ, PAT le ayudará. También explica por qué NAT no reemplaza una versión de firewall.

Permitir regla de firewall para NTP externo

Según la regla NAT, se requiere una regla de firewall adecuada. Esto permite el tráfico NTP desde las redes internas al servidor de destino. La ruta del menú es:

Rules and policies > Firewall rules

Procedimiento:

1. Seleccione Add firewall rule > New firewall rule.
2. Configure Rule name, por ejemplo LAN_to_External_NTP.
3. Establezca Rule position en Top o colóquela por encima de reglas LAN-to-WAN generales si estas coincidirían antes.
4. Active Log firewall traffic.
5. Configure Source zones en las zonas internas, por ejemplo LAN, DMZ o una zona IoT. WAN y Any son incorrectos para este patrón.
6. Configure Source networks and devices en las redes o dispositivos afectados. No es un Any general si solo ciertas redes deben usar NTP.
7. Establezca Destination zones en WAN.
8. Establezca Services en NTP.
9. Establezca Action en Accept.
10. Guardar.

En ejemplos oficiales o simplificados se ve a veces Any en Source networks and devices. En un laboratorio es cómodo, pero en producción rara vez es la mejor opción. Es más limpio usar un objeto de red concreto como LAN_NET, IOT_NET o un pequeño grupo de hosts, para que quede claro qué dispositivos pueden usar este reenvío NTP.

La regla está limitada principalmente a través de Source Zone, Source Network, servicio, posición de regla y destino NAT. Si también se va a utilizar Destination networks, debe verificar el efecto en Log Viewer, porque las reglas DNAT pueden cambiar la dirección de destino visible en el análisis.

Iniciar sesión en esta regla es útil para la introducción. Después de la prueba, debería poder ver en Log Viewer de qué red de cliente proviene la solicitud, qué Firewall Rule ID se utilizó y si el NAT Rule ID esperado también es visible. Si no aparece ningún ID de regla o aparece una regla incorrecta, el orden o la coincidencia de la regla es más importante que la configuración NTP en sí.

Para estructura de reglas, secuencia, Services y registro, también sirve Comprender y configurar correctamente las reglas Sophos Firewall.

Variante B: Usar servidor interno NTP

Esta variante es adecuada si un controlador de dominio interno, un servidor de hora Linux u otro sistema interno va a ser la fuente de hora para los clientes, pero los clientes continúan usando el firewall IP como servidor NTP.

Aquí se necesitan dos pares de reglas:

Crear host para el servidor interno NTP

La ruta del menú es:

Hosts and services

Procedimiento:

1. Seleccione Add.
2. Establezca Nombre, por ejemplo NTP_Server_Internal.
3. Establezca IP version en IPv4 si se utiliza IPv4.
4. Establezca Type en IP.
5. Ingrese IP address del servidor interno NTP.
6. Guardar.

Par de reglas 1: el servidor NTP interno se sincroniza externamente

Primero, el servidor interno NTP debe poder comunicarse con un servidor de hora externo si aún no está sincronizado en otro lugar.

Regla NAT:

1. Abra Rules and policies > NAT rules.
2. Seleccione Add NAT rule > New NAT rule.
3. Configure Rule name, por ejemplo SNAT_Internal_NTP_to_WAN.
4. Establezca Rule position en Top o colóquela de forma adecuada por encima de reglas NAT amplias.
5. Configure Original source para alojar NTP_Server_Internal.
6. Para Original service, elimine Any y seleccione NTP.
7. Para Translated source (SNAT) seleccione MASQ.
8. Guardar.

Regla del cortafuegos:

1. Abra Rules and policies > Firewall rules.
2. Seleccione Add firewall rule > New firewall rule.
3. Configure Rule name, por ejemplo Internal_NTP_to_WAN.
4. Active Log firewall traffic.
5. Configure Source zones en la zona del servidor interno NTP, por ejemplo LAN.
6. Establezca Source networks and devices en NTP_Server_Internal.
7. Establezca Destination zones en WAN.
8. Establezca Services en NTP.
9. Guardar.

Par de reglas 2: guiar a los clientes al servidor interno NTP a través del firewall-IP

Luego se crea el reenvío real: los clientes envían NTP al firewall-IP, el firewall reenvía al servidor interno NTP.

Regla NAT:

1. Abra Rules and policies > NAT rules.
2. Seleccione Add NAT rule > New NAT rule.
3. Configure Rule name, por ejemplo DNAT_Client_NTP_to_Internal.
4. Establezca Rule position en Top o colóquela por encima de reglas NAT generales.
5. Configure Original source en las redes de clientes internas afectadas.
6. Configure Original destination en el firewall o Gateway-IP que los clientes usan como destino NTP.
7. Para Original service, elimine Any y seleccione NTP.
8. Para Translated source (SNAT), seleccione MASQ.
9. Para Translated destination (DNAT) seleccione NTP_Server_Internal.
10. Guardar.

Aquí también Original destination es decisivo: la regla solo debe traducir solicitudes NTP dirigidas a la IP del firewall o gateway. Si este campo queda demasiado amplio, el firewall también puede capturar solicitudes NTP que los clientes querían enviar directamente a otro servidor horario.

Regla del cortafuegos:

1. Abra Rules and policies > Firewall rules.
2. Seleccione Add firewall rule > New firewall rule.
3. Configure Rule name, por ejemplo LAN_to_Internal_NTP.
4. Active Log firewall traffic.
5. Establezca Source zones en las zonas de cliente interno. Evite WAN y Any.
6. Configure Source networks and devices en las redes de clientes afectadas.
7. Configure Destination zones en la zona del servidor interno NTP, por ejemplo LAN o DMZ.
8. Establezca Services en NTP.
9. Guardar. Si también se configura una Red de destino, debe probar específicamente si la regla del firewall continúa coincidiendo de acuerdo con DNAT. Para la aceptación inicial, la red de origen, la zona de destino, el servicio, la regla NAT y Log Viewer suelen ser los puntos de control más claros.

Si el servidor interno NTP es un controlador de dominio, debe tener especial cuidado en el alcance. No todas las redes de clientes tienen que llegar directamente a todos los controladores de dominio. Se puede permitir NTP sin abrir accesos de controlador de dominio igualmente amplios.

Operaciones, seguridad y pruebas

Clasificar IPS y características de seguridad

NTP es técnicamente un pequeño servicio UDP, pero UDP 123 también se vuelve relevante en la práctica en caso de abuso, mala configuración u objetivos externos no deseados. Si hay disponible una licencia de Protección de red, puede tener sentido una política IPS adecuada en la regla del firewall.

Más importante que tantas características de seguridad como sea posible con el NTP es un diseño ajustado:

• Source Zone solo interno: evita que el firewall actúe como un relé público NTP.
• Redes de origen específicamente: limita NTP a clientes, servidores o dispositivos que realmente necesitan este reenvío.
• Establecer Destination Server: evita servidores de hora externos y hace que los registros sean evaluables.
• Servicio solo NTP: evita una regla UDP demasiado amplia.
• Activar registro: muestra en Log Viewer si Firewall Rule ID y NAT Rule ID funcionan como se esperaba.

Por lo tanto, el IPS debe verse como un control adicional, no como un reemplazo de una regla limpia. Si la regla NTP solo permite unas pocas redes internas a un servidor de hora definido, la ganancia de seguridad más importante ya se logra a través del alcance y la trazabilidad. Cuando están involucradas una gran cantidad de redes, dispositivos poco claros o áreas de IoT/OT, una política de IPS dirigida se vuelve más interesante.

⚠️ IPS requiere una licencia de protección de red adecuada. Si IPS está habilitado en una regla muy utilizada, se deben monitorear los registros y el rendimiento. Para el reenvío NTP simple, un alcance limpio es más importante que una combinación de funciones de seguridad innecesariamente amplia.

Si se utiliza una política IPS dedicada para este propósito, no se debe copiar de forma generalizada a todas las redes internas. Tiene más sentido tener una pequeña regla con un origen claro, un destino NTP definido, registro activo y control posterior en el Log Viewer.

Otras características de seguridad deben tratarse deliberadamente con cautela con NTP. Para este sencillo servicio UDP, Web Filtering, TLS Inspection, Application Control o Malware Scan normalmente no ayudan con la función NTP real. Si dichos perfiles están activos en una regla colectiva, se debe verificar si NTP estaría mejor ubicado en su propia regla pequeña.

Distribuya NTP limpiamente con DHCP

Si los clientes reciben su configuración de red a través de DHCP, debería comprobar si es necesario un reenvío NAT. Para muchos entornos, es más limpio distribuir el servidor NTP deseado directamente a través de DHCP.

Si hay un controlador de dominio o un servidor de hora central, la opción DHCP 42 puede apuntar directamente a este servidor. NAT es particularmente útil si los dispositivos ya usan el Gateway-IP o son difíciles de reconfigurar. Para las opciones especiales de DHCP, Sophos Firewall Configurar opciones de DHCP es un mejor comienzo.

Verifique la hora del sistema de firewall por separado

La redirección del cliente NTP no es la misma que la hora del sistema Sophos Firewall. Ambos deben comprobarse por separado:

• Hora del sistema de firewall: relevante para autenticación Log Viewer, certificados, MFA, VPN, WAF, informes, Syslog y análisis de soporte.
• Cliente-NTP vía NAT: Los dispositivos en la red interna reciben la hora a través de Gateway-IP o una dirección NTP redirigida.

Si el propio firewall tiene una hora o zona horaria incorrecta, las entradas de registro pueden ser difíciles de correlacionar, las comprobaciones de certificados pueden fallar o la autenticación basada en tiempo como TOTP/MFA puede causar problemas. Luego, primero se deben corregir la hora del sistema del firewall y el acceso al firewall NTP. Sólo entonces tiene sentido validar el cliente NTP a través de NAT.

Para entornos SIEM o Syslog, este punto es particularmente importante: el firewall puede enrutar correctamente el tráfico NTP y aun así enviar marcas de tiempo incorrectas a un SIEM si su propia hora o zona horaria es incorrecta.

Para el reenvío de registros, Enviar Sophos Firewall Syslog a SIEM es adecuado. Para problemas de MFA, también se debe incluir MFA para Sophos Firewall WebAdmin, VPN Habilitar portal y acceso remoto.

Pruebe NTP y aísle los errores

Después de guardar, no sólo debes comprobar si la regla existe. Lo que es crucial es si un cliente realmente puede sincronizar NTP y si se cumple el NAT esperado y la regla de firewall.

La prueba comienza igual para ambas variantes: un cliente de la red afectada utiliza el firewall o Gateway-IP como servidor NTP. A continuación se activa una sincronización horaria o se realiza una breve espera hasta que el cliente envía NTP.

En Log Viewer filtras por servicio NTP o UDP 123.

Con la variante A debería ser visible:

• El cliente proviene de la red interna esperada.
• La regla de firewall NTP para accesos externos NTP.
• La regla DNAT coincide con la fuente de hora externa.
• El objetivo es el servidor externo NTP planificado.

Se deben comprobar dos cosas para la variante B:

• El servidor interno NTP puede enviar NTP externamente.
• Los clientes se enrutan a través de DNAT desde el firewall-IP al servidor interno NTP. Si Log Viewer no muestra claramente qué regla se aplica, Diagnostics > Captura de paquetes le ayudará. Allí debería comprobar si los paquetes del cliente a UDP 123 llegan al cortafuegos y si los paquetes continúan hasta el servidor horario externo o interno esperado.

Si no hay registros visibles, la solicitud no se puede enviar al cliente en absoluto, la regla del firewall no se registra o el tráfico toma una ruta diferente. Probar la regla de firewall con Log Viewer, Policy Test y Packet Capture es adecuada para la verificación sistemática.

Para problemas NTP específicos del firewall, el registro del cliente NTP también es relevante. La descripción general del registro se encuentra en Solución de problemas Sophos Firewall: Services y registros.

Breve aceptación

Antes de una finalización productiva, cinco puntos deben ser correctos:

1. Los clientes realmente usan el firewall o Gateway-IP como servidor NTP.
2. Las reglas NTP solo permiten las redes de origen internas previstas.
3. Los Firewall Rule ID y NAT Rule ID esperados son visibles en el Log Viewer.
4. La hora del sistema de firewall es correcta por separado.
5. Después de DHCP, VLAN, NAT o cambios de reglas, NTP se probará nuevamente.

Errores típicos

• WAN permitido como Source Zone: El firewall puede actuar involuntariamente como un relé NTP abierto. Limite las zonas de origen a zonas internas.
• Any para origen y destino: La regla es difícil de controlar. Defina las redes de origen y los servidores de destino específicamente.
• Regla NAT presente, pero no hay regla de firewall: El tráfico se traduce pero no se permite. Verifique Log Viewer para conocer el ID de regla y el ID de NAT.
• Regla de firewall sin registro: El análisis de errores se vuelve innecesariamente difícil. Active Log firewall traffic al menos durante la prueba.
• El destino FQDN no se resuelve: No se alcanza el destino DNAT. Verifique la resolución DNS del firewall.
• El cliente utiliza otro servidor NTP: La regla nunca se cumple. Verifique la configuración del cliente o la opción DHCP.
• El servidor de hora no responde: El cliente permanece sin sincronizar. Verifique el servidor de destino, el enrutamiento y UDP 123.

Preguntas frecuentes