Sophos Firewall: Bloquear países e IPs maliciosas

Una vez que los servicios son accesibles desde Internet, generalmente se observa rápidamente tráfico no deseado: escaneos de puertos, intentos de inicio de sesión, redes de bots conocidas o accesos desde países de los que no se esperan usuarios. En Sophos Firewall, se pueden bloquear estas fuentes en varios niveles.

Este artículo explica dos variantes típicas:

• Bloquear países o redes de origen con una regla de firewall
• Traducir fuentes no deseadas al vacío con una regla Black Hole DNAT

Además, recomendamos Sophos Firewall Threat Feeds, para que las IPs, dominios o URLs maliciosas conocidas puedan ser bloqueadas automáticamente.

Orientación

Antes de bloquear fuentes, debe quedar claro qué tráfico se quiere tratar: servicios publicados, servicios locales del firewall, tráfico saliente de clientes o tráfico WAF. El método adecuado depende exactamente de eso.

¿Qué método es adecuado en cada caso?

• Regla de firewall con Drop: Bloquea tráfico según Source Country, Source Network o Source Host. Encaja para bloqueos de países, redes individuales o listas de IPs maliciosas mantenidas manualmente.
• Black Hole DNAT: Redirige tráfico no deseado a una IP interna inexistente. Es útil cuando se quiere interceptar temprano tráfico hacia servicios publicados.
• WAF Blocked countries: Se aplica a servidores web publicados mediante WAF. Los países se bloquean directamente en la regla WAF.
• Local service ACL exception rule: Controla servicios locales del firewall como WebAdmin, User Portal, VPN Portal o SSH. Es el lugar correcto cuando se debe proteger el propio firewall.
• Threat Feeds: Usan listas dinámicas de fuentes maliciosas conocidas. Encajan para botnets, escáneres, infraestructura de malware y direcciones IP de atacantes conocidas.

El método adecuado depende de dónde se procesa técnicamente el tráfico. Las reglas de firewall no siempre se aplican al tráfico que va a una dirección alojada utilizada en WAF. En tales casos, una regla de país WAF o una regla Black Hole DNAT a menudo son más adecuadas.

Entrante, saliente o firewall local

Antes de una regla de bloqueo, debe quedar claro qué tipo de tráfico se refiere. De lo contrario, se bloquea en el lugar equivocado y luego uno se pregunta por qué el ataque sigue siendo visible o por qué el tráfico legítimo falla.

• Entrante a servidor publicado: Redirección de puertos a RDP, HTTPS, SMTP o aplicación propia. Orden DNAT, regla WAF, regla de firewall, IPS y registro
• Entrante al propio firewall: WebAdmin, User Portal, VPN Portal, SSH, Ping o DNS en el firewall. Device Access y Local Service ACL Exception Rules
• Saliente de clientes internos: Los clientes se comunican con destinos sospechosos en Internet. Regla de firewall, Threat Feeds, Web Protection, DNS Protection y registro
• Servidor web a través de WAF: Aplicación web pública detrás de Web Server Protection. Regla WAF, Blocked countries, autenticación, MFA y registros WAF

Esta separación es importante porque una regla de país en Rules and policies > Firewall rules no asegura automáticamente todas las superficies de ataque del firewall. Para servidores publicados, generalmente la cadena NAT y WAF es prioritaria. Para portales de administración, primero cuenta si el servicio de firewall local es accesible desde la zona. Para el tráfico saliente de clientes, Threat Feeds, Web Protection y DNS Protection a menudo son las herramientas más limpias.

No confundir con Device Access

El bloqueo de países y Black Hole DNAT protegen principalmente el tráfico que se procesa a través de reglas de firewall o NAT. Los servicios locales de Sophos Firewall son otro caso. Estos incluyen, por ejemplo, WebAdmin, SSH, User Portal, VPN Portal, DNS, Ping y, en parte, también servicios de acceso remoto.

Para estos servicios locales, primero es relevante Administration > Device access. Allí se decide desde qué zonas un servicio es accesible en principio. Si se desea permitir el acceso solo para direcciones IP de administración individuales, países o fuentes de soporte, Local service ACL exception rules es el punto de control correcto. El procedimiento se describe en Asegurar el acceso a Sophos Firewall: Configurar correctamente Device Access.

⚠️ Una regla de bloqueo de países no reemplaza una configuración limpia de Device Access. Si WebAdmin, User Portal, VPN Portal o SSH son demasiado accesibles, el propio firewall sigue siendo una superficie de ataque. El bloqueo de países puede reducir el riesgo, pero no reemplaza el endurecimiento básico del acceso.

Para servicios locales especialmente sensibles, WAN no debería activarse de forma amplia en Local service ACL. Es mejor una exception rule que solo permita las fuentes esperadas o bloquee países no deseados. Para WebAdmin, una IP fija de administración o una VPN de gestión suele ser más limpio que un filtro de países, porque Geo-IP no es una verdadera verificación de identidad.

Planificar reglas de bloqueo

Las reglas de bloqueo deben planificarse para no interrumpir tráfico legítimo por error.

Bloquear países con una regla de firewall

Para el bloqueo general de países, se puede crear una regla de firewall con Drop.

Ruta de menú:

Rules and policies > Firewall rules

Campos recomendados:

• Rule name: Nombre descriptivo, por ejemplo, BLOCK_COUNTRY_PANAMA
• Rule position: Top
• Action: Drop
• Source zones: Any
• Source networks and devices: País, grupo de países, lista de IPs o grupo de hosts
• During scheduled time: All the time
• Destination zones: Any
• Destination networks: Any
• Services: Any o un servicio definido

Para el bloqueo de países, es importante que las zonas de origen y destino no se establezcan demasiado estrechamente. Si solo se ingresa WAN como zona de origen, es posible que la regla no se aplique a todas las rutas de tráfico relevantes.

Los países y grupos de países se usan como objetos en Hosts and services. Para varios países, una Country host group es más clara que muchos países individuales directamente en cada regla. Las listas de IPs maliciosas pertenecen a objetos IP host o IP host group adecuados. Hay que conocer los límites: las listas IP host no están pensadas para feeds dinámicos arbitrariamente grandes. Para infraestructura atacante que cambia continuamente, los Threat Feeds son más mantenibles.

El bloqueo de países también debe entenderse como un control de mejor esfuerzo. Los datos de Geo-IP pueden ser incorrectos, los usuarios viajan, los atacantes usan proxies o sistemas comprometidos en países permitidos, y los servicios en la nube utilizan infraestructura distribuida globalmente. Por lo tanto, una regla de país nunca debe ser la única medida de protección.

Cuándo no bloquear demasiado ampliamente

Una regla de bloqueo se crea rápidamente, pero puede generar efectos secundarios difíciles de rastrear más tarde. Se debe tener especial cuidado si las aplicaciones productivas dependen de plataformas externas, CDNs, proveedores de pagos, servicios en la nube, proveedores de monitoreo o socios de soporte.

Antes de un bloqueo amplio de países o IPs, se debe aclarar:

• ¿Hay usuarios, socios o proveedores de servicios en los países afectados?
• ¿Una aplicación utiliza infraestructura de nube o CDN con direcciones de origen cambiantes?
• ¿Se activan actualizaciones, webhooks, monitoreo, copias de seguridad o accesos de soporte a través de servicios externos?
• ¿Existe una forma de registrar primero o probar la regla por un tiempo limitado?
• ¿Está claro quién verifica los falsos positivos y cómo se libera una excepción?

Para servicios de Internet con autenticación real de usuarios, las reglas de países a menudo son solo una medida adicional. MFA, reglas de firewall estrictas, sistemas de destino actualizados, IPS, protección WAF, registro y Threat Feeds siguen siendo más importantes que una lista de bloqueo lo más larga posible.

Planificar Allowlist antes que Blocklist

Para servicios críticos, una Allowlist a menudo es más limpia que una Blocklist cada vez más larga. Si un servicio solo debe ser accesible desde socios fijos, sucursales, sistemas de monitoreo o ubicaciones de administración, primero se deben permitir estas fuentes y bloquear el resto. Esto reduce el esfuerzo de mantenimiento y evita tener que bloquear reactivamente cada nueva IP de escáner individualmente.

Una Allowlist es especialmente adecuada para:

• Accesos de administración a servicios de gestión publicados
• Interfaces B2B con direcciones IP de socios conocidas
• Monitoreo, copias de seguridad, webhooks o puntos finales de API con sistemas de origen fijos
• Accesos de soporte temporales con ticket, fecha de vencimiento y revisión

Una Blocklist es más adecuada cuando un servicio debe permanecer conscientemente accesible públicamente, pero se deben reducir las fuentes sospechosas. Entonces, la regla debe operarse con registro, fecha de revisión y excepciones claras. Para servidores web publicados a través de WAF, además es relevante Sophos Firewall WAF: Publicar servidores web de forma segura, ya que allí se controlan los países, la autenticación y la protección del servidor web más cerca de la aplicación publicada.

Tratar por separado los filtros de país WAF

En Web Server Protection, la regla WAF tiene campos propios para Allowed client networks, Blocked client networks, Blocked countries y Block IP addresses of unknown country-origin. Estos ajustes pertenecen a la aplicación web publicada y no son lo mismo que una regla firewall Drop normal.

Esto es práctico porque el filtro de países está directamente ligado a la publicación WAF. Al mismo tiempo hay que tener cuidado: Block IP addresses of unknown country-origin puede excluir usuarios legítimos si su dirección IP no puede asignarse claramente. Antes de activarlo, conviene comprobar la propia IP externa con la GeoIP2 Databases Demo. Esta opción solo debería activarse si el efecto se ha probado y el proceso de soporte lo conoce.

Para reglas WAF, los filtros de países son solo un componente. Autenticación, MFA, certificado, Web Server Protection, firmas IPS/WAF, registro y un servidor backend actualizado siguen siendo más importantes que una larga lista de países bloqueados.

Black Hole DNAT y Threat Feeds

En servicios publicados, puede ser útil interceptar fuentes no deseadas antes de la regla DNAT productiva. Para infraestructura atacante dinámica, los Threat Feeds también ayudan.

Black Hole DNAT para fuentes no deseadas

Una regla Black Hole DNAT traduce el tráfico a un destino que no existe en la red. El tráfico, por lo tanto, se pierde y no alcanza el servicio real.

Esto es especialmente útil cuando un servicio se publica mediante DNAT y se desean interceptar ciertas fuentes antes de la redirección de puertos real.

Black Hole DNAT debe usarse de manera específica. Es especialmente adecuado para el tráfico hacia servicios publicados, donde hay una regla DNAT normal debajo. Para el tráfico de clientes salientes general, servicios de firewall locales o servidores web publicados a través de WAF, generalmente una regla de firewall, Device Access o una configuración WAF es el mejor punto de control.

En la regla NAT es importante no confundir la vista original del atacante con el destino ficticio traducido. La regla debe estar en Rules and policies > NAT rules por encima de la regla DNAT de producción. Original source contiene la lista de IP bloqueadas, el país o el grupo de países. Original destination es la dirección WAN pública o el objeto de host WAN al que se dirige el atacante. Translated destination es el host ficticio no enrutado. En este patrón, la traducción de origen y de servicio normalmente permanece en Original.

Después de guardar, hay que comprobar en el Log Viewer si se alcanza la NAT Rule ID esperada. Si la regla DNAT normal sigue coincidiendo, la regla Black Hole está demasiado abajo, la fuente no coincide, o el servicio o destino al que se accede no coincide con el tráfico de prueba.

La regla Black Hole DNAT sigue necesitando una regla firewall adecuada o una ruta de logging para que el hit sea trazable. NAT solo traduce, no es una autorización de acceso independiente. Si más tarde nadie sabe por qué existe el host ficticio o qué fuente se intercepta, esta técnica se convierte rápidamente en carga heredada.

Ejemplo:

• Rule name: BLOCK_BAD_IPS_COUNTRIES
• Rule position: Top
• Original source: Lista de IPs maliciosas, país o grupo de países
• Original destination: IP pública WAN u objeto de host WAN
• Original service: Any o el servicio publicado
• Translated source (SNAT): Original
• Translated destination (DNAT): Host ficticio que no existe
• Translated service (PAT): Original
• Inbound interface: Any
• Outbound interface: Any

El host ficticio debe usar una dirección IP que no exista en la propia red y que no se enrute. Es importante que esta regla esté por encima de las reglas DNAT reales. Las reglas NAT se procesan de arriba a abajo. Si primero coincide la regla DNAT normal, la regla Black Hole DNAT llega demasiado tarde.

El host ficticio no debe elegirse al azar. Es recomendable una dirección de una red de documentación o ficticia interna no utilizada, que no se enrute y que no se planifique para sistemas reales más adelante. La regla debe describir claramente por qué existe este host, para que no se elimine accidentalmente o se use de manera productiva.

Por qué el orden es crucial

En las reglas NAT, gana la primera regla que coincide. Por lo tanto, una regla Black Hole DNAT debe estar muy arriba, generalmente en la parte superior de la tabla de reglas NAT.

Orden de ejemplo:

1. Black Hole DNAT para lista de IPs maliciosas y países bloqueados
2. Reglas DNAT específicas para servicios publicados
3. Reglas SNAT especiales
4. Regla MASQ general para tráfico saliente

En las reglas de firewall se aplica el mismo principio: las reglas de bloqueo específicas están por encima de las reglas de permiso generales. De lo contrario, puede suceder que el tráfico ya haya sido permitido antes de que se verifique la regla de caída.

No dejar la fuente innecesariamente en Any

Para servicios publicados, se debe restringir la fuente tanto como sea posible.

Fuentes razonables pueden ser:

• Direcciones IP públicas individuales
• Redes de socios o sucursales
• Países desde los que se espera el acceso
• Hosts FQDN o grupos de hosts DNS, si es apropiado
• Grupos de hosts mantenidos con direcciones IP de administración permitidas

Any solo es razonable si el servicio realmente debe ser accesible en todo el mundo. Entonces, se deben activar medidas de protección adicionales: registro, IPS, MFA donde sea posible, autenticación fuerte, sistemas de destino actualizados y Threat Feeds.

IPv6 debe planificarse por separado. Una regla de país IPv4 no demuestra que la misma aplicación también esté protegida mediante IPv6. En entornos dual-stack se necesitan reglas IPv6 adecuadas, logging y una ruta de prueba. Si IPv6 no se usa en producción, debe desactivarse, bloquearse o introducirse documentadamente.

Usar Threat Feeds adicionalmente

Las listas manuales y las reglas de países son estáticas. Sin embargo, la infraestructura de los atacantes cambia constantemente. Por eso recomendamos además Sophos Firewall Threat Feeds.

Threat Feeds ayudan especialmente con:

• Direcciones IP de escáneres conocidas
• Redes de bots
• Infraestructura de malware
• Hosts comprometidos
• Listas de IPs maliciosas mantenidas dinámicamente

Así, no es necesario mantener manualmente cada IP individual. El firewall puede bloquear fuentes malas conocidas antes de que lleguen al servicio publicado.

Pruebas y operación

Después del cambio, se deben revisar conscientemente los contadores, logs y rutas de acceso esperadas.

Operación y revisión de listas de bloqueo

Las listas de bloqueo solo son útiles si permanecen comprensibles en operación. Por lo tanto, una regla de país o una lista de IPs maliciosas no debe simplemente crecer indefinidamente sin que alguien verifique los aciertos, excepciones y efectos secundarios.

Para cada lista de bloqueo manual, se debe documentar:

• por qué se bloqueó la fuente
• si es un bloqueo temporal o permanente
• quién mantiene la lista
• cuándo se revisará nuevamente la regla
• qué servicios o reglas DNAT están afectados
• cómo se libera un falso positivo

Especialmente en redes de nube, CDN, hosting o soporte, se debe tener cuidado. Una dirección IP individual puede pertenecer a otro cliente más tarde, un rango de CDN puede contener servicios legítimos, y un proveedor de servicios externo puede cambiar su IP de salida. Si se bloquea un acceso legítimo, no se debe desactivar inmediatamente toda la regla. Es mejor una excepción estrecha con motivo, ticket y fecha de revisión.

Para servidores publicados, además se debe verificar si la lista de bloqueo realmente se aplica antes de la regla DNAT productiva. La verificación operativa en Publicar servidores mediante DNAT en Sophos Firewall ayuda a evaluar conjuntamente servicios publicados, reglas NAT y registro. Si las fuentes bloqueadas pasan por una regla de firewall, Probar regla de firewall con Log Viewer, Policy Test y Packet Capture es el camino de prueba adecuado.

Una revisión sensata no solo consiste en mirar la regla. Se debe verificar en el Log Viewer si la regla todavía coincide, qué fuentes están afectadas y si los aciertos corresponden al riesgo esperado. Para una evaluación a largo plazo, Central Firewall Reporting o Enviar Syslog de Sophos Firewall a SIEM son mejores que los registros locales solos.

Procedimiento de prueba después del cambio

Después de una nueva regla de bloqueo, no solo se debe verificar si desaparece el acceso no deseado. También es importante si el tráfico deseado sigue funcionando y si el firewall registra el acierto de manera comprensible.

Procedimiento práctico:

1. Crear la regla con un nombre descriptivo, registro y descripción detallada.
2. Si es posible, probar primero con una lista de fuentes pequeña o un solo país.
3. Verificar el bloqueo esperado desde una fuente externa adecuada.
4. Filtrar en el Log Viewer por Source, Destination, Service, Firewall Rule ID y NAT Rule ID.
5. Probar un acceso legítimo desde una fuente permitida.
6. En servidores publicados, verificar si la regla DNAT productiva sigue aplicándose a fuentes permitidas.
7. Documentar la fecha de revisión y el propietario de la regla.

Si no es posible una prueba limpia desde el exterior, al menos se debe monitorear el cambio con Log Viewer, Packet Capture y una ventana de mantenimiento estrecha. Una regla de bloqueo sin aciertos visibles y sin propietario es difícil de distinguir de un legado después de algunos meses.

Troubleshooting

Si falta el resultado esperado, conviene revisar paso a paso los logs, el rule matching y el comportamiento de las policies.

Errores típicos

• Black Hole DNAT está debajo de la regla DNAT normal: La regla DNAT normal coincide primero, la regla de bloqueo no se aplica
• El destino ficticio sí existe en la red: El tráfico termina inesperadamente en un sistema real
• La fuente se mantiene de manera diferente en NAT y en la regla de firewall: Las reglas se vuelven difíciles de entender y se desincronizan
• El bloqueo de países se usa como única medida de protección: Los bots de países permitidos pueden seguir atacando
• WAF y DNAT se mezclan: Una regla firewall Drop no protege automáticamente cada publicación WAF. Revisar WAF Blocked countries por separado.
• Los servicios locales del firewall se protegen con reglas firewall normales: Para WebAdmin, User Portal, VPN Portal y SSH, revisar primero Device Access y Local Service ACL.
• Se olvida IPv6: Una regla IPv4 no bloquea una ruta IPv6.
• Los bloqueos temporales de IP nunca se revisan: Las entradas antiguas bloquean accesos legítimos más tarde o generan complejidad innecesaria
• Se bloquean rangos de nube o CDN demasiado amplios: Las aplicaciones comerciales, actualizaciones o proveedores externos pueden fallar
• El registro está desactivado: En el Log Viewer no está claro qué regla se aplicó

Solución de problemas

Si una regla de bloqueo no se aplica, se debe verificar en este orden:

1. ¿Está la regla NAT o de firewall realmente por encima de las reglas de permiso?
2. ¿Coincide la IP de origen con la lista de IPs maliciosas o el país elegido?
3. ¿El tráfico se procesa a través de una regla WAF, regla DNAT o regla de firewall?
4. ¿Está activo el registro en la regla de firewall afectada?
5. ¿El Log Viewer muestra la Firewall Rule ID o NAT Rule ID esperada?
6. ¿Se ve el tráfico en Diagnostics > Packet capture?
7. ¿Existe una excepción más reciente, grupo de hosts o exclusión de Threat Feed que influya en el bloqueo esperado?
8. ¿Se dejó un bloqueo temporal después de un incidente de forma permanente?

Para el análisis, también ayudan La regla de firewall no se aplica: Verificar orden, coincidencia y registros, Usar la herramienta Packet Capture en WebAdmin y Entender NAT en Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Si el tráfico bloqueado realmente pertenece a un servidor publicado, también se debe verificar la regla DNAT productiva: ¿Está realmente la regla Black Hole DNAT por encima, se alcanza la misma dirección de destino pública y el servicio es idéntico o se elige conscientemente más amplio? Para la publicación completa, Publicar servidores mediante DNAT en Sophos Firewall es adecuado.

FAQ