Publicar un servidor mediante DNAT en Sophos Firewall

Con DNAT publicas un servidor interno a través de una dirección IP o puerto público. A continuación, Sophos Firewall reenvía el tráfico entrante al servidor de destino interno. Ejemplos típicos son servidores web, servidores proxy inversos, puertas de enlace VPN u otros servicios en una DMZ.

El artículo explica qué puntos debe comprobar antes y después de una regla DNAT y cómo garantizar la liberación lo más estrictamente posible.

Planificar antes de publicar

Antes de lanzar DNAT, debe quedar claro si el servicio realmente necesita ser accesible al público y qué variante técnica es la más adecuada. Una buena planificación evita puertos abiertos, reglas NAT duplicadas y rutas de retorno difíciles de rastrear.

Requisitos

• Dirección IP pública o interfaz WAN
• Servidor interno con dirección IP fija
• Servicio y puerto conocidos, por ejemplo TCP 443
• Regla de firewall adecuada
• Opcional: IPS, Web Server Protection o Reverse Proxy según el servicio

⚠️ DNAT publica un servicio interno para el mundo exterior. Cada servicio publicado aumenta la superficie de ataque. Sólo debería publicarse lo que sea realmente necesario. Origen, puerto y destino deben ser lo más estrechos posible.

Aclarar de antemano

Antes de configurar el sistema de control, debe responder estas preguntas:

• ¿Qué IP pública o interfaz WAN se utiliza?
• ¿A qué puerto externo debería ser accesible?
• ¿A qué IP interna se reenvía?
• ¿El puerto sigue igual o está traducido?
• ¿Debería permitirse el acceso desde cualquier lugar o sólo desde determinadas redes de origen?
• ¿Es necesario tener en cuenta la NAT de origen o la NAT reflexiva?
• ¿Es necesaria una regla de bucle invertido para los clientes internos que utilizan el FQDN público?
• ¿Se publicará solo un servidor interno o varios servidores con equilibrio de carga?
• ¿Existe ya una regla que utilice el mismo puerto?
• ¿El firewall de Sophos está ubicado directamente en Internet o detrás del enrutador de un proveedor?
• ¿Es necesario abrir reglas adicionales en un grupo de seguridad en la nube?

Esta información evita conflictos posteriores con reglas de firewall o NAT existentes.

Si los términos Original source, Original destination, Translated destination, Translated service, bucle invertido o regla reflexiva aún no están claros, primero debe leer Comprensión de NAT en Sophos Firewall: SNAT, DNAT, MASQ, PAT. Esta página se centra en la publicación específica de un servicio interno.

¿DNAT, WAF, VPN o ZTNA?

No todos los servicios de acceso público deberían publicarse automáticamente a través de DNAT. DNAT es técnicamente simple, pero también muy directo: el firewall reenvía un puerto a un destino interno. Que esto tenga sentido depende del servicio, las fuentes y la necesidad de protección.

• Servicio no HTTP con fuentes claramente definidas: DNAT con restricción estricta de fuentes, registro e IPS.
• Aplicación pública HTTP o HTTPS: primera comprobación Sophos Firewall WAF.
• Acceso de administrador como SSH, RDP o portal de administración interno: Si es posible, VPN, ZTNA o IP de fuente fija en lugar de DNAT abierta.
• Acceso solo para algunos socios o ubicaciones: Prefiere IP de origen, VPN o conexión de sitio a sitio.
• La aplicación debe ser accesible interna y externamente con el mismo nombre: Verifique el DNS dividido o la regla de bucle invertido planificada deliberadamente.

Para aplicaciones web clásicas, WAF suele ser un mejor punto de partida porque se pueden tener en cuenta nombres de host, certificados, rutas, perfiles de protección web y, opcionalmente, autenticación. DNAT sólo debe utilizarse para acceso administrativo en casos excepcionales. Si un servicio interno no necesita ser público, una VPN o una arquitectura ZTNA suelen ser una solución más limpia. Los conceptos básicos de ZTNA existentes están disponibles en Cómo configurar Sophos ZTNA y Crear Sophos ZTNA Gateway.

Si el firewall está detrás de un enrutador

DNAT también funciona si el firewall de Sophos no tiene directamente la dirección IP pública, sino que está detrás de un enrutador NAT del proveedor.

En este caso se necesitan dos redirecciones:

1. En el enrutador del proveedor, el puerto público se reenvía a la IP WAN de Sophos Firewall.
2. En el firewall de Sophos, el puerto se reenvía al servidor interno mediante DNAT.

Muchos enrutadores de proveedores ofrecen reenvío de puertos clásico o una función como Host expuesto o Host DMZ. Con una función de host expuesta, muchos o todos los puertos entrantes suelen reenviarse al firewall. Esto puede ser práctico, pero debe asegurarse cuidadosamente porque el control real recaerá exclusivamente en el firewall de Sophos.

Si no hay una IP pública fija, puedes usar DynDNS. Sophos Firewall puede configurar DNS dinámico para que un nombre DNS siempre apunte a la IP pública actual. Sigue siendo importante: el reenvío de puertos en el enrutador del proveedor debe apuntar al firewall de Sophos.

El mismo principio se aplica en entornos de nube. Con Azure, la regla DNAT en Sophos Firewall por sí sola no es suficiente. Además, se deben abrir las reglas de entrada apropiadas en el grupo de seguridad de red; de lo contrario, el tráfico no llegará al firewall en absoluto.

Configurar DNAT y regla de firewall

Una publicación de servidor siempre consta de dos partes: la regla NAT traduce el destino o puerto, la regla de firewall permite y controla el tráfico.

¿Asistente de acceso al servidor o regla DNAT manual?

Sophos Firewall ofrece dos formas de publicar servidores:

• ****Asistente de acceso al servidor (DNAT): estuche estándar rápido para un solo lanzamiento. crea múltiples reglas automáticamente y las coloca en la parte superior de la base de reglas.
• Regla DNAT manual: entornos más complejos con alias IP, PAT, equilibrio de carga, fuentes especiales o diseño de reglas deliberado. Cada campo debe configurarlo y probarlo usted mismo.

El asistente puede resultar útil porque no sólo crea una regla DNAT entrante, sino que, según la selección, también crea una regla de bucle invertido, una regla SNAT reflexiva y la regla de firewall adecuada. Esto ahorra tiempo, pero no sustituye a la comprobación de las reglas creadas.

Después de utilizar el asistente siempre debes comprobar:

• ¿Están las reglas de NAT y firewall en la posición correcta?
• ¿La fuente es realmente tan estrecha como estaba previsto o todavía está en Any?
• ¿Se creó una regla de bucle invertido a pesar de que el DNS dividido sería una solución más limpia?
• ¿Se creó una regla reflexiva que no es necesaria para el tráfico saliente del servidor?
• ¿Coincide la regla del firewall con la zona de destino después de NAT y el objeto de destino público antes de NAT?

Para entornos productivos, una regla DNAT nombrada manualmente y colocada deliberadamente suele ser más fácil de entender. El asistente es bueno para un inicio rápido, pero las reglas creadas pertenecen a la misma revisión que las reglas creadas manualmente.

Crear regla DNAT

Un ejemplo típico de DNAT:

• Fuente original: Any o redes de origen definidas
• Destino original: WAN-IP o interfaz WAN
• Servicio original: HTTPS
• Destino traducido: servidor interno
• Servicio traducido: puerto de destino interno o sin cambios

Procedimiento:

1. Abra Reglas y políticas.
2. Cambie al área Reglas NAT.
3. Seleccione Agregar regla NAT > Nueva regla NAT.
4. Definir fuente original, destino y servicio.
5. Establezca el Destino traducido en el servidor interno.
6. Opcionalmente, configure el Servicio traducido.
7. Verifique conscientemente la interfaz de entrada y salida.
8. Guarde y active la regla.

Si solo es necesario acceder a unas pocas direcciones IP de fuentes externas, la fuente original no debe ser Any, sino que debe limitarse a estas fuentes.

Para recursos compartidos de producción, un objeto host para la IP pública suele ser más limpio que seleccionar directamente una interfaz WAN. El objeto sigue siendo rastreable si las interfaces, las direcciones de alias o los detalles del proveedor cambian más adelante.

Comprender el original y traducirlo correctamente.

Cuando se trata de reglas NAT, la distinción entre Original y Traducido es importante.

• Fuente/destino/servicio original describe el tráfico que llega a Sophos Firewall.
• Fuente/destino/servicio traducido describe el tráfico que sale de Sophos Firewall después de la traducción.

Para una regla DNAT entrante, esto significa:

• Destino original es la dirección IP o WAN pública del firewall.
• Servicio original es el puerto externo al que se dirige el cliente.
• Destino traducido (DNAT) es el servidor interno.
• Servicio traducido (PAT) es el puerto interno en el servidor de destino si el puerto se va a traducir.
• Fuente traducida (SNAT) generalmente permanece en Original con reglas DNAT normales.

Reenvío de puertos y PAT

El reenvío de puertos es técnicamente un servicio de traducción. En Sophos Firewall, se utiliza el servicio traducido (PAT) para esto.

Ejemplo:

• Externo: TCP 20120
• Interno: TCP 22

El cliente externo se conecta en el puerto 20120, pero el firewall de Sophos reenvía internamente en el puerto SSH 22. Esto puede resultar útil, pero no reemplaza las restricciones de acceso. Cambiar el puerto externo puede reducir algo de ruido de fondo, pero no hace que el servicio sea seguro.

Importante: El protocolo debe seguir siendo el mismo. TCP se puede traducir a otro puerto TCP y UDP a otro puerto UDP. TCP a UDP no es una traducción de puerto válida.

Si se publica HTTPS, también debe comprobar si hay conflictos con WebAdmin o el Portal de usuario de Sophos Firewall. De forma predeterminada, la consola de administración usa el puerto HTTPS 4444, el portal de usuario usa el puerto HTTPS 443. En caso de superposiciones, se deben separar claramente los puertos propios del firewall o los servicios publicados.

Planificar la IP de origen y la ruta de regreso conscientemente

Para una publicación DNAT normal, Fuente traducida (SNAT) debe permanecer en su mayor parte en Original. Luego, el servidor interno ve la IP de origen externa real. Esto es importante para los registros del servidor, los límites de velocidad, los mecanismos de protección tipo Fail2Ban, los registros de aplicaciones, la evaluación de WAF o proxy inverso y el posterior análisis de incidentes.

Es posible que aún sea necesario SNAT al firewall o una dirección interna si la ruta de retorno no pasa por el firewall de Sophos. Esto es posible, por ejemplo, si el servidor publicado utiliza una puerta de enlace predeterminada diferente, se encuentra en un segmento de enrutamiento externo o tiene una situación de enrutamiento asimétrico.

La decisión debe tomarse conscientemente:

• La fuente sigue siendo Original: El servidor ve una IP externa real. La ruta de retorno debe pasar limpiamente a través del firewall.
• La fuente está traducida a través de SNAT: La ruta de regreso es más fácil de controlar. El servidor solo ve el firewall o la IP SNAT, la IP real del cliente se pierde en el registro del servidor.

Si un servicio sólo funciona con SNAT, no deberías quedarte con él y dejar el tema de lado. Es mejor comprobar primero si se puede corregir la puerta de enlace, la ruta, la VLAN, el firewall del servidor o el diseño de enrutamiento. SNAT puede ser una solución alternativa legítima, pero dificulta el análisis posterior.

Al realizar la prueba, siempre debe verificar qué IP de origen ve realmente el servidor. Si en lugar de la IP del cliente externo solo aparece la IP del firewall, se debe documentar claramente si esto es intencionado.

Verifique la regla del firewall

Una regla NAT por sí sola no permite el tráfico automáticamente. Además, se requiere una regla de firewall adecuada.

Con DNAT, la vista en la regla del firewall es inusual porque el firewall debe conocer simultáneamente el acceso original desde el exterior y el destino interno traducido.

La regla general más importante:

⚠️ Con DNAT, la regla de firewall usa la zona de destino después de NAT, pero la red de destino antes de NAT.

Asignación típica:

• Zona de origen: Principalmente WAN cuando el acceso proviene de Internet.

• Redes y dispositivos de origen: Lo más limitado posible, por ejemplo, IP individuales, redes, países o grupos.

• Zonas de destino: Zona del servidor interno por DNAT, por ejemplo DMZ o SERVER.

• Redes de destino: Dirección de destino pública u objeto de host WAN de Original destination.

• Servicios: Servicio externo desde Original service, es decir, el puerto al que acceden los clientes desde el exterior.

• Perfiles de seguridad: Dependiendo del servicio, IPS, escaneo de malware, política web u otra verificación adecuada

• Registro: Habilitar para servicios publicados

Sin una regla de firewall adecuada, el tráfico se rechaza a pesar de la DNAT.

Este punto es una fuente común de error: si ingresa el servidor interno como red de destino, aunque la regla espera el objeto WAN público, la regla no coincide. La lógica exacta se explica con más detalle en el artículo Comprensión de NAT en Sophos Firewall: SNAT, DNAT, MASQ, PAT.

El orden también se aplica a las reglas NAT. Sophos comprueba las reglas NAT de arriba a abajo y utiliza la primera regla coincidente. Por lo tanto, una regla NAT anterior que sea demasiado general puede impedir que la regla DNAT específica entre en vigor.

Opciones NAT avanzadas

Estas opciones solo se vuelven relevantes cuando los clientes internos usan nombres públicos, las rutas de retorno deben traducirse específicamente o están involucrados varios servidores de destino.

Reglas NAT de bucle invertido, reflexivas y vinculadas

Sophos Firewall ofrece varias opciones NAT que se confunden fácilmente:

• Regla de bucle invertido: ayuda cuando los clientes internos deben llegar a un servidor interno a través de la IP pública o el nombre DNS público.
• Regla reflexiva: crea una regla SNAT que refleja una regla DNAT para que el tráfico de retorno o ciertas direcciones opuestas se traduzcan adecuadamente.
• Regla NAT vinculada: creada a partir de una regla de firewall y es una regla SNAT vinculada. Una regla NAT vinculada no es lo mismo que una regla DNAT entrante para un servidor publicado.

Para las publicaciones de servidor clásicas, lo más claro suele ser una regla DNAT independiente más una regla de firewall adecuada. Las reglas NAT vinculadas pueden resultar útiles si una regla de firewall requiere directamente una traducción SNAT especial. Sin embargo, en entornos generales, las reglas NAT independientes y con nombres claros tienden a ser más fáciles de entender y mantener.

Importante: Las reglas de bucle invertido y reflexivas se derivan de la regla DNAT original. Si la regla DNAT original se cambia posteriormente, se deben verificar las reglas derivadas por separado. De lo contrario, puede suceder que el acceso externo se haya ajustado correctamente, pero el acceso de loopback interno o el tráfico saliente del servidor continúen funcionando según la lógica anterior.

Equilibrio de carga y control de estado

Cuando se publican varios servidores internos detrás de una IP pública, DNAT también se puede utilizar para equilibrio de carga o conmutación por error.

Los métodos posibles son, por ejemplo:

• Round Robin
• Primero vivo
• Aleatorio
• IP fija
• Uno a uno

Si desea que el firewall detecte si un servidor de destino está disponible, se debe configurar una comprobación de estado. Sin una verificación de estado, el firewall también puede reenviar tráfico a un servidor al que no se puede acceder.

Cobertura y puesta en marcha

Un servicio publicado forma inmediatamente parte de la superficie de ataque pública. Es por eso que el acceso cerrado, el registro, los perfiles de seguridad y una reversión clara son parte de la puesta en marcha.

Planificar la puesta en marcha y la reversión

Una publicación de DNAT debe tratarse como un pequeño cambio de producción. Tan pronto como la regla esté activa, se podrá acceder al servicio desde Internet. Por lo tanto, antes de la entrada en funcionamiento, debe quedar claro qué regla se activará, cómo se probará el acceso y cómo volver atrás si hay problemas.

Verifique antes de entrar en funcionamiento:

• Haga una copia de seguridad de la configuración actual del firewall o al menos documente las reglas de NAT y firewall afectadas.
• Verifique las reglas NAT existentes para la misma IP pública, puerto externo e interfaz WAN.
• HAga coincidir el enrutador del proveedor, el grupo de seguridad de la nube o las reglas de firewall ascendentes con la configuración de Sophos.
• Considere DNS TTL cuando un nombre de host apunta a la dirección publicada.
• Prepare una fuente de prueba fuera de su propia LAN, por ejemplo, un teléfono móvil, una ubicación externa o una prueba de puerto en línea controlado.
• Establezca las ubicaciones de registro esperadas: Visor de registros, ID de regla NAT, ID de regla de firewall, captura de paquetes y registro del servidor.
• Defina criterios de reversión, por ejemplo, acceso a un servicio incorrecto, servidor que no responde, error de certificado, perfil de seguridad que bloquea el tráfico legítimo o IP de origen inesperada en el servidor.

Una reversión simple generalmente implica deshabilitar la nueva regla DNAT y la regla de firewall correspondiente. Si se reemplazó una publicación antigua, debe quedar claro si la regla anterior se puede reactivar o si primero se debe restablecer el reenvío de puertos del proveedor, el DNS o la supervisión.

Para servicios críticos, no debes cambiar varias cosas al mismo tiempo. Si el DNS, el enrutador del proveedor, la regla NAT, la regla del firewall y la configuración del servidor se ajustan al mismo tiempo, es difícil atribuir un error más adelante. Es mejor un proceso breve con pasos claros: preparar, activar, probar externamente, verificar registros, verificar servidores, documentar resultados.

Restringir el acceso lo más estrechamente posible

No todos los servicios publicados tienen que ser accesibles desde todo Internet. Si es posible, el acceso debe ser limitado.

Restricciones útiles:

• Permitir únicamente direcciones IP de fuente única.
• Solo permita hosts FQDN conocidos cuando el otro lado use IP dinámicas.
• Sólo permitir ciertos países.
• Bloquear explícitamente ciertos países.
• Permitir el acceso solo a través de VPN.
• Utilizar una solución ZTNA en lugar de publicación directa.

Por lo general, DNAT no es la mejor solución para servicios administrativos como SSH, RDP o portales de administración internos. Si no es necesario que el acceso sea público, VPN o ZTNA casi siempre son una mejor opción.

Mejorar la seguridad

Para los servicios publicados debes consultar:

• ¿Está el servidor parcheado actualmente?
• ¿Existe una opción WAF o proxy inverso?
• ¿IPS está activo en la regla del firewall?
• ¿Están abiertos sólo los puertos necesarios?
• ¿Está registrado el servicio?
• ¿Existen restricciones de IP geográfica, fuente de amenazas o IP de origen?
• ¿Es posible MFA si es un portal?

Para aplicaciones web, Web Server Protection / WAF también puede resultar útil en lugar de DNAT puro.

Bots y fuentes de amenazas

Los puertos públicos como HTTP, HTTPS, SSH o RDP están constantemente en el foco de los bots. Tan pronto como se puede acceder a un puerto en Internet, a menudo puede ver rápidamente los intentos de conexión, escaneos, intentos de inicio de sesión o explotar el tráfico en el visor de registros.

Esto no significa automáticamente que el servidor esté comprometido. Pero muestra que el servicio es parte de la superficie de ataque pública. Por lo tanto, recomendamos proteger adicionalmente los servicios publicados con IPS, registros, fuentes específicas y fuentes de amenazas de terceros.

Las fuentes de amenazas proporcionan continuamente al firewall indicadores actuales de compromiso, por ejemplo, direcciones IP o dominios maliciosos. Esto permite que el firewall bloquee atacantes, botnets o escáneres conocidos antes de que lleguen al servicio publicado.

Más: Fuentes de amenazas de Sophos Firewall

Prueba

Después de guardar la regla DNAT:

• Prueba desde una red externa, no desde la misma LAN
• Verifique únicamente el puerto público esperado, no realice escaneos amplios contra direcciones extranjeras
• Verifique en el Visor de registros el ID de la regla de firewall y el ID de la regla NAT.
• Comparar la captura de paquetes con fuente externa, destino público y destino interno
• Verificar los registros del servidor
• Controlar la IP de origen visible en el sistema de destino.

Si la prueba se va a realizar desde la LAN interna a la IP pública, también puede ser necesaria una NAT en horquilla o una solución DNS interna.

Matriz de pruebas para publicaciones DNAT

Una sola prueba de puerto rara vez es suficiente para una publicación DNAT en producción. Es mejor usar una pequeña matriz de pruebas que separe los caminos permitidos y los no deseados. Así no solo se ve si el servicio es accesible, sino también si las restricciones, el registro y la ruta de retorno funcionan correctamente.

Fuentes de prueba útiles:

• Fuente externa permitida: probar la conexión desde datos móviles, una sede externa o una red de partner hacia la IP pública y el puerto externo. En Log Viewer deben aparecer el ID esperado de la regla firewall y el ID de la regla NAT.
• Fuente externa no permitida: si la publicación está limitada a fuentes concretas, una prueba desde una fuente no permitida debe fallar de forma intencionada. Si no falla, la restricción de origen es demasiado amplia.
• Cliente interno con el nombre DNS interno: comprobar si los usuarios internos resuelven directamente a la IP interna del servidor. Suele ser más limpio que loopback NAT.
• Cliente interno con el FQDN público: probarlo solo si este acceso es realmente necesario. Si falla, revisar primero split DNS y no añadir loopback NAT automáticamente.
• Servidor de destino: revisar el log del servidor, firewall local, servicio enlazado, certificado e IP de origen visible. Así se detecta si el servidor ve la IP externa real o una dirección SNAT.
• Monitorización o health check externo: comprobar que la prueba usa la misma URL, el mismo puerto y la misma lógica de origen que la monitorización real.

Después de cada prueba se debe evaluar un único punto: ¿llega el tráfico a Sophos Firewall, coincide la regla NAT esperada, coincide la regla firewall esperada, llega el paquete al servidor y vuelve una respuesta? Si se cambian varias cosas al mismo tiempo, el siguiente error será mucho más difícil de asignar.

Una prueba DNAT limpia compara tres puntos de vista:

• Cliente externo: Conexión a IP pública y puerto externo funciona o se bloquea deliberadamente.
• Cortafuegos de Sophos: El Visor de registros muestra el ID de regla de firewall y el ID de regla NAT esperados.
• Servidor interno: El servicio ve la IP de origen esperada, responde a través de la puerta de enlace correcta y registra el acceso.

Si se examina sólo una de estas perspectivas, los errores típicos no se detectan. Por ejemplo, una prueba de puerto externo exitosa aún no dice si el registro, el IPS, las restricciones de origen o los propietarios del servidor están debidamente documentados.

Solución de problemas y operaciones

Después de la puesta en marcha, no sólo debes comprobar si el servicio es accesible. Son importantes los visores de registros, el ID de la regla NAT, el ID de la regla del firewall, los registros del servidor y las revisiones periódicas de versiones anteriores.

Solución de problemas

Errores comunes:

• Falta la regla del firewall
• IP WAN incorrecta seleccionada
• Falta el reenvío de puertos en el enrutador del proveedor
• Azure Network Security Group bloquea el puerto
• El servicio no se ejecuta internamente.
• La puerta de enlace del servidor no apunta a Sophos Firewall
• La regla NAT está bajo otra que entra en vigor de antemano.
• La regla de firewall utiliza la red de destino incorrecta en DNAT
• El puerto ya está siendo utilizado por otro servicio.
• Falta loopback cuando los clientes internos usan FQDN público
• Falta la verificación de estado o es incorrecta al usar el equilibrio de carga
• Las pruebas se realizan desde la red interna y no externamente
• El servidor de destino responde a través de una puerta de enlace diferente
• Un perfil de seguridad bloquea el tráfico, pero no se busca en el registro correcto

El Visor de registros es el punto de partida más importante para los problemas de DNAT. Allí puede ver si llega tráfico, qué regla de firewall y qué regla NAT se aplican y si el tráfico está permitido o rechazado. Si el resultado no coincide con lo esperado, No se aplica la regla de firewall de Sophos: verifique las causas será de ayuda.

Para una solución de problemas más profunda, no debería simplemente mirar el firewall de Sophos. Si el visor de registros permite el tráfico y la captura de paquetes muestra que los paquetes continúan hacia el servidor, la causa suele estar en el sistema de destino: firewall local, puerta de enlace predeterminada incorrecta, servicio no vinculado, problema de certificado, aplicación escuchando en un puerto diferente o proxy inverso ascendente que no responde como se esperaba.

Una clasificación rápida ayuda a no buscar en el lugar equivocado:

• No aparece ningún hit en Log Viewer: El tráfico no llega al firewall o se está usando la IP WAN incorrecta. Revisar el router del proveedor, Cloud Security Group, IP pública y Packet Capture en WAN.
• Coincide el ID de la regla de firewall, pero falta el ID de la regla NAT: La regla NAT no coincide o está demasiado abajo en el orden. Revisar Original destination, Original service, interfaz entrante y orden NAT.
• Coincide el ID de la regla NAT, pero el servicio no responde: El servidor de destino o la ruta de retorno no son correctos. Revisar firewall del servidor, puerta de enlace predeterminada, routing y Packet Capture hacia el servidor.
• Funciona desde fuera, pero no internamente mediante FQDN: Falta Split DNS o loopback. Revisar la resolución DNS interna y añadir loopback solo de forma consciente.
• Después de cambiar el asistente, solo una parte se comporta incorrectamente: Una regla loopback o reflexive derivada ya no encaja. Revisar individualmente las reglas NAT y de firewall generadas.

Cuando Black Hole DNAT también ayuda

Si un servicio deliberadamente necesita permanecer accesible públicamente, pero ciertas fuentes deben ser interceptadas antes de la publicación real, una regla DNAT de agujero negro por encima de la regla DNAT productiva puede tener sentido. Esto funciona, por ejemplo, para listas de IP malas conocidas, países permanentemente no deseados o fuentes de escaneo recurrentes.

Esta técnica no reemplaza la liberación limpia. La regla productiva DNAT aún debe ser estricta, el registro debe estar activo y el servidor publicado debe mantenerse actualizado. Black Hole DNAT es una capa de bloque adicional antes de un lanzamiento, no la arquitectura de seguridad real.

Black Hole DNAT es particularmente útil en estos casos:

• Las fuentes recurrentes del escáner llegan al mismo servicio publicado: Las fuentes pueden quedar en nada ante la productiva norma DNAT.

• Los países individuales no deberían tener acceso al reenvío de puertos: La regla de bloqueo se puede colocar encima de la regla DNAT real.

• Ya existe un grupo de IP incorrecto mantenido: El grupo se puede utilizar como Original source de la Regla del Agujero Negro.

• Un servicio debe seguir siendo público, pero debería lograr menos tráfico de bots: Se mantiene la regla productiva, las fuentes no deseadas se interceptan de antemano

Black Hole DNAT no es adecuado para servicios de firewall locales como WebAdmin, Portal de usuario, Portal VPN o SSH al propio firewall. Acceso al dispositivo y Reglas de excepción de ACL de servicio local son responsables de esto. Para servidores web a través de WAF, primero debe verificar la regla WAF, los países bloqueados, la autenticación y los registros WAF.

El orden es importante: la regla DNAT del agujero negro debe estar por encima de la regla DNAT productiva. A continuación, debería comprobar en el visor de registros si las fuentes bloqueadas realmente cumplen la regla del agujero negro y si las fuentes permitidas siguen utilizando la regla productiva de NAT y firewall. El procedimiento exacto se puede encontrar en Sophos Firewall: Bloquear países e IP maliciosas.

Verificación operativa

Las reglas de la DNAT deben revisarse periódicamente. Las versiones antiguas son un riesgo de seguridad típico porque los servicios publicados a menudo permanecen accesibles incluso aunque la aplicación haya sido movida, reemplazada hace mucho tiempo o solo se necesite temporalmente.

Para reglas DNAT productivas, se debe documentar al menos lo siguiente:| punto | Por qué es importante |

• Propósito de la liberación: Más adelante debe quedar claro por qué el servicio es de acceso público
• Persona o equipo responsable: Sin propietario, las acciones antiguas rara vez se eliminan
• IP pública y puerto externo: Facilita pruebas, monitoreo y escaneos externos
• Servidor de destino interno y puerto de destino: Importante para migraciones de servidores, equilibrio de carga y cambios de certificados
• Fuentes esperadas: Ayuda a determinar si Any es realmente necesario
• Medidas de protección: IPS, alternativa WAF, MFA, fuentes de amenazas, registros y estado de parches deben ser rastreables
• Fecha de caducidad o fecha de revisión: Las liberaciones temporales necesitan un final claro

Una revisión significativa no consiste simplemente en mirar la regla. Debe verificar externamente si solo están abiertos los puertos esperados, verificar en el visor de registros a qué fuentes acceden realmente y verificar en el servidor de destino si la aplicación aún se mantiene. Si el servicio solo es necesario internamente o para algunos socios, se debe reevaluar VPN, ZTNA, una restricción de IP de origen o una regla WAF.

Al eliminar reglas DNAT antiguas, no debe eliminar simplemente la regla NAT. A menudo se le adjuntan reglas de firewall, objetos de host, objetos de servicio, reglas de loopback, reglas reflexivas, entradas DNS, comprobaciones de monitoreo o reenvío de puertos del proveedor. Es mejor un proceso breve de desmantelamiento:

1. Consulta los últimos accesos en el visor de registros.
2. HAcer que la persona o departamento responsable confirme que el servicio ya no es necesario.
3. Primero desactive la regla NAT y la regla de firewall adecuada.
4. Pruebe externamente si el puerto está cerrado.
5. Verifique los registros de monitoreo y del servidor en busca de errores.
6. Sólo entonces limpie los objetos, las entradas DNS y las reglas del proveedor que ya no sean necesarias.

Si aún se requiere autorización, la revisión debería terminar con una conclusión concreta: dejarlo como está, restringirlo más estrictamente, cambiar a WAF, moverlo detrás de VPN/ZTNA o volver a examinarlo con una fecha de vencimiento.

Preguntas frecuentes