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.

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.

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

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 mantiene dinámicamente para la interfaz Cellular WAN.
• ##ALL_SSLVPN_RW, ##ALL_SSLVPN_RW6, ##ALL_IPSEC_RW y ##ALL_RW representan hosts dinámicos de Remote Access.
• 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 usa el firewall como puerta de enlace, 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.

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.

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.

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.

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.