Utilizar correctamente IP hosts, servicios y grupos en Sophos Firewall

Los IP hosts y servicios asignan nombres comprensibles a direcciones, redes y puertos. Así, una regla de firewall muestra directamente qué origen puede comunicarse con qué destino y servicio.

La decisión importante es el alcance adecuado: una dirección se crea como IP, una subred como Network, un bloque consecutivo de direcciones como IP range y una pequeña colección de direcciones individuales como IP list. En TCP y UDP, un servicio suele describir el Destination Port fijo; el Source Port dinámico se mantiene sin cambios.

Para una regla nueva, el camino más corto y seguro parte del objeto de host más pequeño que resulte adecuado, pasa por un servicio existente o propio y termina en una regla de firewall de alcance limitado. Los casos especiales, como System Hosts, MAC Hosts y grupos reutilizables, se abordan después. Antes de cualquier modificación posterior, Object Usage muestra qué reglas y políticas dependen del objeto.

Elegir el objeto de host adecuado

En Hosts and services > IP host hay cuatro tipos disponibles:

• IP: exactamente una dirección IPv4 o IPv6, por ejemplo un servidor, una impresora o un sistema de administración.
• Network: una subred completa con su máscara, por ejemplo 198.51.100.0/24.
• IP range: un rango consecutivo, por ejemplo desde 203.0.113.10 hasta 203.0.113.20.
• IP list: varias direcciones individuales no consecutivas. Una lista admite como máximo 800 direcciones IP y no puede pertenecer a una IP Host Group. La ayuda actual de SFOS 22 contiene la frase «For IP list, use only class B IP addresses.» Como Sophos no explica esta formulación obsoleta basada en clases de red, no debe interpretarse como compatibilidad con listas IPv4 o IPv6 arbitrarias.

Un FQDN Host es más adecuado cuando cambia la dirección de destino y existe un nombre DNS estable. La resolución, los comodines y los límites se explican en Utilizar correctamente FQDN Hosts y Wildcard FQDN.

Como regla general, debe utilizarse el objeto estable más pequeño que describa por completo el tráfico necesario. Un objeto del tipo IP solo cubre una dirección y es demasiado limitado para una subred completa; una red /24 sería innecesariamente amplia para un único servidor.

Crear un IP host paso a paso

El siguiente ejemplo representa un único servidor de prueba:

1. Abrir Hosts and services > IP host y seleccionar Add.
2. Introducir host_test_web como Name.
3. Establecer IP version en IPv4.
4. Seleccionar IP como Type.
5. Introducir 192.0.2.10 en IP address.
6. Guardar con Save.

Las siguientes direcciones de 192.0.2.0/24, 198.51.100.0/24 y 203.0.113.0/24 están reservadas para ejemplos de documentación. En una configuración productiva deben sustituirse todos los nombres, direcciones y tamaños de red por los valores de la red real.

Network, range e IP list

Los campos cambian según el tipo seleccionado:

• Network: net_test_branch con 198.51.100.0 y /24 representa toda la red de prueba. Debe introducirse la dirección de red, no la dirección de la puerta de enlace.
• IP range: range_test_admins desde 203.0.113.10 hasta 203.0.113.20 representa un bloque consecutivo.
• IP list: en list_test_hosts solo deben introducirse, separadas por comas, direcciones del entorno propio que se hayan verificado. Dada la ambigüedad de la indicación sobre la clase B en la ayuda actual, la lista concreta debe crearse en la versión de SFOS utilizada y validarse con una regla de prueba. Es apropiada para unas pocas direcciones individuales fijas, no para indicadores de compromiso que cambian continuamente.

Para direcciones IP, dominios o URLs maliciosos que se mantienen de forma dinámica, la función adecuada son los Threat Feeds en Sophos Firewall. Una IP list manual no se actualiza automáticamente.

IP Host Groups

En Hosts and services > IP host group pueden agruparse hosts con el mismo propósito funcional. Por ejemplo, un grupo puede contener todos los sistemas de administración permitidos y utilizarse después en varias reglas.

Además de los Custom IP Hosts, también pueden pertenecer a un grupo los hosts predeterminados de interfaces, Cellular WAN e internet. La pertenencia a un grupo es independiente de la posibilidad de editar el objeto: un host de sistema que no puede editarse directamente no queda automáticamente excluido de los grupos. Sin embargo, los hosts de sistema dinámicos de VPN Remote Access siguen excluidos.

Hay tres límites importantes:

• Los hosts IPv4 e IPv6 no pueden estar en la misma IP Host Group.
• Un host normal puede pertenecer a varios grupos.
• Un objeto del tipo IP list no puede añadirse a una IP Host Group.

Para crear un pequeño grupo de prueba IPv4 con el host_test_web creado anteriormente:

1. Abrir Hosts and services > IP host group y seleccionar Add.
2. Introducir grp_test_servers como Name; adaptar el nombre al propósito del grupo.
3. Establecer IP version en IPv4, de acuerdo con el host de prueba existente.
4. Seleccionar host_test_web mediante Add new item. Los miembros adicionales deben compartir el mismo propósito y la misma versión IP.
5. Guardar con Save.

Después, volver a abrir el grupo y comprobar su versión IP y sus miembros. Si un host deseado no aparece en la selección, revisar primero su versión IP y su tipo; no eludir la exclusión de una IP list o de un host de sistema VPN Remote Access con un objeto sustituto innecesariamente amplio.

Los grupos deben tener un significado común. Un grupo que mezcle servidores, clientes y excepciones temporales puede ahorrar clics, pero después dificulta comprender por qué una regla permite el acceso.

Entender los hosts de sistema e interfaz

La lista de IP hosts muestra las interfaces físicas, incluidos los módulos FleXi-Port adicionales, así como las interfaces virtuales creadas por el usuario. En Address details figuran la dirección y la máscara de red de Network > Interfaces. Si aparece un valor inesperado, comparar primero esta configuración de interfaz con lo que se muestra; el objeto de host mantenido automáticamente no es el lugar donde cambiar la dirección.

SFOS crea automáticamente varios objetos de host. Estos objetos no deben recrearse como Custom Hosts normales ni modificarse en el lugar equivocado:

• Los Interface Hosts siguen la configuración IP de Network > Interfaces y se modifican allí. Zonas e interfaces en Sophos Firewall explica la relación entre conexión, zona y regla.
• Si el diseño del proveedor y de la red exige vincular localmente una dirección adicional a una interfaz física, debe configurarse como IP alias en la interfaz física. Si un campo NAT no ofrece el Interface Host correspondiente, debe crearse además un Custom IP Host con esa dirección y un nombre claro. Usar el mismo nombre es solo una convención útil, no un requisito técnico.
• ##WWAN1 se crea cuando se activa Cellular WAN, utiliza la dirección IP de la interfaz WWAN y se mantiene dinámicamente.
• ##ALL_SSLVPN_RW, ##ALL_SSLVPN_RW6, ##ALL_IPSEC_RW y ##ALL_RW representan hosts dinámicos de Remote Access.
• ##ALL_SSLVPN_RW contiene las direcciones IP asignadas por el firewall a las conexiones VPN SSL de acceso remoto establecidas con Sophos Connect. ##ALL_IPSEC_RW contiene las direcciones asignadas a las conexiones IPsec correspondientes. ##ALL_RW reúne las direcciones asignadas a ambos tipos de conexión; SFOS las añade dinámicamente cuando se establecen las conexiones.
• Otros System Hosts no pueden modificarse ni eliminarse como objetos propios.

Los hosts dinámicos de Remote Access no pueden añadirse a otra IP Host Group. Los Physical Interface Hosts no están disponibles en determinados campos NAT, entre ellos Translated source y Translated destination. En ese caso puede ser necesario crear un IP host propio con la misma dirección. Su nombre debe mostrar claramente la relación con la interfaz para que no parezca una dirección independiente.

Para los hosts internos de la subred del alias, SFOS debe ser la puerta de enlace predeterminada. Si un dispositivo situado aguas arriba actúa como puerta de enlace para el tráfico de Sophos Firewall, necesita una dirección IP de cada subred de alias afectada. Tras sustituir un firewall, las entradas ARP obsoletas de los dispositivos aguas arriba pueden hacer que la IP alias quede inaccesible temporalmente. En ese caso, primero hay que revisar y actualizar su caché ARP, no ampliar innecesariamente la regla NAT.

Para las rutas SD-WAN de salida a internet, Sophos también recomienda usar Internet IPv4 group o los hosts predeterminados incluidos como destino en lugar de Any. De este modo, la ruta queda limitada a destinos IPv4 públicos y no arrastra tráfico interno al mismo camino solo porque el objeto de destino sea demasiado amplio.

A diferencia de los hosts de sistema no editables, los hosts de internet predeterminados pueden modificarse y eliminarse. Antes de hacerlo, actualizar Object Usage como se describe más abajo y revisar las reglas y rutas SD-WAN dependientes. Esta excepción se aplica a los hosts de internet, no a los hosts de sistema dinámicos VPN/WWAN; las direcciones de interfaz siguen modificándose en Network > Interfaces.

Usar MAC hosts para dispositivos visibles directamente

Un MAC host describe un dispositivo en la capa 2 y puede contener una sola dirección o una lista. Solo es adecuado cuando el firewall ve la dirección MAC de origen real. Detrás de un router, una VPN o NAT, normalmente ve la MAC del siguiente salto y no la del cliente original. Por eso, un IP host o una red suele ser el objeto más estable para reglas enrutadas.

En Hosts and services > MAC host > Add, se asigna al objeto un nombre descriptivo y se elige MAC address o MAC list. La dirección puede escribirse con dos puntos, como 00:16:76:49:33:CE, o con guiones, como 00-16-76-49-33-CE; las entradas múltiples se separan con comas. Una MAC list admite como máximo 1000 direcciones MAC.

Un MAC host no es una identidad de dispositivo. Una dirección MAC puede copiarse o falsificarse y puede cambiar con estaciones de acoplamiento, máquinas virtuales o direcciones Wi-Fi privadas. El objeto sirve como criterio de coincidencia restrictivo en un segmento controlado, pero no como única autenticación o límite de seguridad.

Ejemplo: bloquear un flujo no web por su MAC de origen

Este ejemplo para SFOS 22/23 bloquea un nuevo flujo IPv4 TCP de iPerf3 desde un dispositivo de prueba LAN visible directamente hacia un servidor de prueba WAN controlado. No es un procedimiento para bloquear todo el acceso a internet: HTTP/HTTPS y Web Exceptions quedan fuera de esta prueba. Primero, comprobar con Packet Capture en la interfaz de entrada la MAC de origen real del dispositivo. Si solo se ve un router aguas arriba, esta regla no es adecuada; un puerto LAN de un switch no demuestra por sí solo visibilidad de capa 2. Antes del cambio, comprobar la accesibilidad del servidor WAN y del puerto TCP 5201. Debe ejecutar realmente iPerf3, no un servicio web.

1. En Hosts and services > MAC host > Add, introducir mac_test_client como Name, MAC address como Type y 02:00:00:00:00:10 como MAC address, y guardar con Save. El nombre y la dirección unicast administrada localmente son ejemplos; sustituir la dirección por la MAC verificada del dispositivo.
2. Abrir Rules and policies > Firewall rules, seleccionar IPv4 y crear drop_mac_test_wan mediante Add firewall rule > New firewall rule. Establecer Action en Drop y activar Log firewall traffic.
3. Establecer Source zones en LAN, Source networks and devices en mac_test_client y Destination zones en WAN. En Destination networks, seleccionar el IP Host del servidor WAN propio y, en Services, svc_iperf3_tcp; crear este servicio TCP con Destination Port 5201 como se describe en la sección siguiente. Así se limitan el destino y el servicio de prueba no web. Any no es necesario en este ejemplo.
4. Establecer During scheduled time en All the time para un bloqueo permanente; en otro caso, seleccionar el horario adecuado. Colocar la regla por encima de las que permitirían antes el mismo flujo, sin desplazar excepciones intencionadas de mayor prioridad. Top no es un requisito universal. Rule group puede permanecer en None; un grupo no sustituye una posición correcta. Guardar con Save y comprobar el orden real.

Después, iniciar desde el dispositivo de prueba un nuevo intento de conexión TCP de iPerf3 al mismo servidor WAN por el puerto 5201, no una prueba UDP ni de navegador. En Log Viewer, Drop y la Rule ID de esta regla de bloqueo deben corresponder al flujo. Probar el mismo flujo no web desde un segundo dispositivo no bloqueado: debe seguir coincidiendo con la regla Allow prevista. Usar conexiones nuevas en ambas pruebas, no sesiones existentes. Si falta la coincidencia esperada, revisar la MAC de origen en Packet Capture, las zonas, la versión IP, el horario, el alcance de destino/servicio y las reglas anteriores.

Esta comprobación solo demuestra los flujos probados, no un bloqueo general de la web o de internet. IPv6, otras zonas de destino, destinos y servicios quedan fuera y requieren configuración y pruebas propias. Para revertir el cambio, desactivar únicamente la nueva regla de bloqueo y comprobar el estado permitido anterior con un nuevo flujo TCP de iPerf3. El riesgo de suplantación y de identidad descrito arriba se mantiene.

Crear un servicio con el Destination Port correcto

Antes de crear un servicio debe comprobarse si ya existe un servicio estándar adecuado. Un Custom Service es útil cuando una aplicación necesita otro puerto o una combinación especial de protocolos.

El siguiente ejemplo crea el servicio TCP para iPerf3:

1. Abrir Hosts and services > Services y seleccionar Add.
2. Introducir svc_iperf3_tcp como Name.
3. Establecer Type en TCP/UDP y Protocol en TCP.
4. Mantener sin cambios el Source Port predeterminado 1:65535.
5. Introducir 5201 como Destination Port.
6. Guardar con Save.

El cliente suele elegir dinámicamente su Source Port. Si el servicio también lo limitara a 5201, una conexión normal dejaría de coincidir. Por ello, el puerto fijo del servidor pertenece a Destination Port. Un Source Port limitado solo es correcto cuando el protocolo lo exige expresamente y el tráfico real confirma ese comportamiento.

Para una prueba UDP de iPerf3 también se crea svc_iperf3_udp con protocolo UDP y Destination Port 5201. Como iPerf3 sigue utilizando una conexión de control TCP durante la prueba UDP, ambos servicios se agrupan:

1. Abrir Hosts and services > Service group y seleccionar Add.
2. Introducir grp_iperf3 como Name.
3. Seleccionar svc_iperf3_tcp y svc_iperf3_udp.
4. Guardar con Save.

El procedimiento completo de medición se describe en Prueba de velocidad con iPerf3 a través de Sophos Firewall.

Un Service Group puede combinar servicios predeterminados y personalizados, y un servicio puede pertenecer a varios grupos. Los Services y Service Groups no distinguen entre IPv4 e IPv6; la versión IP viene determinada por los objetos host y el contexto de la regla. Los Service Groups predeterminados no se pueden editar ni eliminar, por lo que una combinación propia requiere un grupo nuevo.

Tampoco pueden editarse ni eliminarse los servicios predefinidos ni los que ya se utilizan en Security Policies. En lugar de eludir una dependencia, debe crearse el Custom Service necesario, sustituirse de forma controlada el objeto anterior en las políticas dependientes y comprobarse después la indicación Usage actualizada.

IP, ICMP e ICMPv6

Además de TCP y UDP, un Custom Service puede describir un número de protocolo IP o tipos y códigos ICMP/ICMPv6. Estos tipos están destinados a protocolos que no utilizan un puerto TCP o UDP. Los valores deben proceder de la documentación técnica de la aplicación y no deducirse a partir de una única prueba fallida.

Para un servicio del tipo IP en Hosts and services > Services > Add, asignar un Name adecuado, establecer Type en IP, seleccionar el número de protocolo necesario y guardar con Save. Se trata del número de protocolo IP, no de un puerto de destino TCP/UDP. Después, volver a abrir el servicio y comparar el número con el requisito de la aplicación; al probarlo en una regla de alcance muy limitado, comprobar en Packet Capture el protocolo observado realmente. Si falta la coincidencia esperada, revisar primero el protocolo y el alcance de la regla en lugar de recurrir a Any.

En Hosts and services > Services > Add, un servicio puede contener varias entradas del mismo tipo seleccionado. Para ICMP o ICMPv6, seleccionar primero el par de tipo y código necesario, añadir otros pares con Add y eliminar las entradas innecesarias con Remove. Después, comprobar todas las entradas y guardar con Save. Así se describen varios mensajes ICMP necesarios en un único servicio, sin permitir indiscriminadamente todos los tipos. Los servicios TCP/UDP separados y el Service Group del ejemplo de iPerf3 siguen siendo una alternativa clara cuando se necesita reutilizar los servicios individualmente.

Nota de versión sobre la documentación de la API: En la tabla guardada de la API de Sophos «Add Service / Update Service» para SFOS 22, la columna Mandatory indica No tanto para ICMPType como para ICMPv6Type; para SFOS 23, indica Yes en ambos casos. Son etiquetas de la documentación de la API, no pruebas de un cambio en la GUI ni en el comportamiento en tiempo de ejecución. Se refieren a los campos ICMP/ICMPv6 y no deben interpretarse como una exigencia de añadir ambas familias de protocolos a los servicios TCP/UDP/IP. La página no define una regla condicional que indique cuándo pueden omitirse estos campos; por tanto, estas etiquetas no permiten deducir instrucciones concretas sobre el payload o la validación.

Utilizar objetos en una regla de firewall

Un objeto de host o servicio no permite tráfico por sí solo. Solo se vuelve efectivo como criterio de coincidencia dentro de una regla. Un ejemplo limitado podría ser:

• Source zones: LAN
• Source networks and devices: net_test_branch
• Destination zones: DMZ
• Destination networks: host_test_web
• Services: HTTPS
• Log firewall traffic: activado

Las zonas, direcciones y el servicio se adaptan a la red real. El tráfico de respuesta de una conexión con estado permitida se devuelve automáticamente. Sin embargo, esta regla no permite nuevas conexiones independientes desde la DMZ hacia la LAN. Una regla NAT tampoco concede permisos por sí sola; sigue siendo necesaria una regla de firewall adecuada.

SFOS evalúa las reglas de firewall de arriba abajo y detiene la búsqueda en la primera coincidencia. Por eso, la nueva regla específica debe colocarse por encima de una regla más amplia que, de otro modo, procesaría primero el mismo flujo. Comprender y configurar de forma segura las reglas de Sophos Firewall explica el orden, las funciones de protección y las pruebas.

Después de guardar debe comprobarse un intento real de conexión en el Log Viewer. Los filtros por dirección de prueba, puerto y regla permiten aislar el flujo correcto; en la vista detallada se revisan Rule ID, Source, Destination y Service. Así puede distinguirse entre un objeto mal definido y un tráfico procesado por otra regla. Si una conexión se interrumpe sin que el firewall detecte un evento Destroy, puede faltar la entrada final de la sesión; en ese caso, Packet Capture y Live Connections ofrecen una comprobación más fiable.

Actualizar Object Usage antes de realizar cambios

Un objeto puede utilizarse en reglas de firewall y NAT, VPN, rutas SD-WAN u otras configuraciones. Antes de modificarlo o eliminarlo deben comprobarse sus dependencias.

La columna Usage de la lista de objetos muestra el número conocido de referencias. Este contador solo se actualiza automáticamente una vez al día. Antes de realizar un cambio:

1. Seleccionar Refresh junto a Usage.
2. Abrir el contador actualizado del objeto afectado.
3. Desplegar las categorías y revisar cada regla o política dependiente.
4. Solo entonces decidir si el objeto puede modificarse, sustituirse o eliminarse.

No todas las dependencias pueden editarse directamente desde la vista Usage. Algunas, como las puertas de enlace WAN y las configuraciones CLI, deben abrirse por separado en el lugar de configuración indicado. Un contador de cero solo es una base fiable después de un Refresh manual.

Encontrar objetos existentes y mantenerlos de forma selectiva

Las listas de Hosts and services > IP host, IP host group, MAC host, Services y Service group permiten buscar por los atributos de los objetos correspondientes. Antes de crear un objeto nuevo, buscar no solo el nombre deseado, sino también los valores de dirección o de protocolo/puerto necesarios, en la medida en que sean aplicables al tipo de objeto. Así puede detectarse un objeto que ya sea adecuado aunque tenga otro nombre. Después de guardar, volver a buscar el objeto y comprobar sus valores o los miembros del grupo, según corresponda.

Los Custom IP Hosts y las IP Host Groups pueden añadirse, editarse y eliminarse; los Service Groups propios también pueden editarse, renombrarse, ampliarse con servicios o eliminarse. Actualizar siempre primero Object Usage. Un cambio en un grupo afecta a todas las reglas que lo utilizan, no solo al caso de uso que se está modificando. Antes del cambio, registrar los valores y miembros existentes; después, comprobar las conexiones afectadas con sesiones nuevas. Si el alcance es incorrecto, revertir el cambio de forma controlada y volver a probar. Las restricciones descritas anteriormente para los System Hosts, los Service Groups predeterminados y los servicios protegidos siguen vigentes.

Gestionar los objetos de forma segura

Evitar errores habituales

• Host en lugar de Network: Una dirección IP individual no incluye automáticamente la subred asociada.
• Dirección de red o máscara incorrecta: En un objeto Network, la dirección de red y el prefijo deben coincidir con la segmentación real.
• Source Port limitado: En conexiones cliente-servidor normales se mantiene 1:65535; se limita el Destination Port.
• Demasiado Any: Un objeto de host preciso pierde su valor de seguridad si el origen o el servicio siguen siendo innecesariamente amplios.
• Objeto de sistema duplicado: SFOS mantiene los hosts de interfaz y Remote Access, por lo que no deben copiarse sin un motivo concreto.
• IP list como Threat Feed: Una IP list permanece estática y no sustituye a indicadores de amenazas actualizados automáticamente.
• Dependencias sin actualizar: Antes de modificar o eliminar un objeto, debe seleccionarse siempre Refresh en Object Usage.

Los prefijos descriptivos como host_, net_, range_, svc_ y grp_ no son un requisito técnico, pero facilitan la búsqueda y la revisión. Más importante que el esquema concreto es mantener nombres, propósitos y ámbitos coherentes en todo el conjunto de reglas.

Mantener un inventario reducido y comprensible

SFOS admite hasta 16 000 hosts entre todos los tipos. Es un límite de la plataforma, no un objetivo de planificación. Para la operación diaria, una base de objetos reducida y comprensible resulta más valiosa que muchas entradas difíciles de distinguir. Los objetos que ya no se necesiten deben sustituirse o eliminarse de forma controlada, y solo después de actualizar y revisar su Usage.