Configurar y probar NetFlow en Sophos Firewall

Con NetFlow, Sophos Firewall envía metadatos de conexión a un Flow Collector externo. Esto permite analizar a lo largo del tiempo las relaciones de comunicación, el volumen de tráfico y las conexiones sospechosas. El requisito más importante se pasa por alto con facilidad: solo se exporta el tráfico de reglas de firewall que tengan activado Log firewall traffic.

El procedimiento resumido es el siguiente:

1. Preparar en el Collector un listener NetFlow v5, por ejemplo en UDP 2055.
2. Añadir el Collector en System > Administration > Netflow.
3. Activar Log firewall traffic en la regla de firewall afectada.
4. Generar un flujo de prueba claramente documentado.
5. Comprobar por separado el transporte con Packet Capture y el contenido en el Collector.

Para obtener un resultado fiable deben coincidir tres elementos: los campos de la versión 5, la regla de firewall que realmente se aplica y la ruta de red al Collector.

Cuándo es NetFlow la herramienta adecuada

NetFlow es adecuado cuando un Collector debe almacenar Flow Records de conexiones procesadas por reglas con el registro activado y analizarlos a lo largo del tiempo. Las preguntas típicas son: ¿qué direcciones de origen y destino se comunican entre sí, qué puertos utilizan y cuántos paquetes o bytes pertenecen al flujo?

Otras herramientas responden a otras preguntas:

• Monitoreo sFlow muestrea tráfico y contadores de interfaz de determinadas interfaces de hardware. Resulta especialmente adecuado para patrones de tráfico y supervisión de capacidad.
• Syslog a un SIEM transporta eventos de registro de firewall, VPN, IPS y otros con campos específicos del producto.
• Monitoreo de hardware SNMP supervisa hardware, interfaces, temperatura, ventiladores o fuentes de alimentación.
• Central Firewall Reporting ofrece informes, búsqueda y retención propios de Sophos en Sophos Fusion (antes Sophos Central).
• Packet Capture sigue siendo más preciso para una ruta de paquetes concreta, NAT o errores de conexión.

NetFlow no sustituye estas herramientas. A menudo el Collector muestra un flujo sospechoso y Log Viewer o Packet Capture explica después qué regla, decisión NAT o función de seguridad intervino.

Qué muestra NetFlow v5 y qué no

SFOS 22 y SFOS 23 documentan NetFlow Version 5 y la posibilidad de exportar todos los parámetros de v5. Esta capacidad documentada no confirma que todos los campos contengan valores significativos en cada flujo; para comprobarlo hay que revisar los registros recibidos. Un registro v5 puede contener, entre otros, estos valores:

• dirección IPv4 de origen y destino;
• puerto de origen y destino, además del protocolo IP;
• contadores de paquetes y bytes;
• hora inicial y final del flujo;
• interfaz de entrada y salida como ifIndex;
• TCP flags, ToS e información de AS y prefijos.

En cambio, NetFlow v5 no contiene campos nativos para nombre de usuario, Firewall Rule ID, URL, aplicación o contenido de paquetes. Un Collector puede correlacionar las direcciones IP con otras fuentes de datos, pero esta información no procede directamente del registro v5.

La ayuda de Sophos también describe el objetivo de identificar protocolos, políticas, interfaces y usuarios que consumen mucho ancho de banda. Los protocolos y los índices de interfaz se pueden analizar a partir de los registros v5; la asociación con una política o un usuario requiere datos adicionales de registros o inventario. Sophos menciona PRTG y Open Source Data Analyzer como ejemplos para el análisis de informes, no como una lista exhaustiva de compatibilidad.

En SFOS, la dirección del Collector puede introducirse como dirección IPv4, dirección IPv6 o FQDN. Esto no cambia el formato de exportación: el firewall sigue enviando NetFlow v5. Este formato no tiene campos para direcciones IPv6 de origen y destino. Por tanto, una dirección IPv6 del Collector solo afecta al transporte hacia él; no permite representar el tráfico útil IPv6 como flujos IPv6 nativos.

Nota sobre la API: La referencia Configure Netflow de SFOS 23 documenta para NetflowServer los tipos de datos IPADDRESS y DOMAIN y un máximo de 255 caracteres. La referencia de SFOS 22 incluye además STRING y no indica una longitud máxima para este campo. Se trata de una diferencia en los metadatos documentados de la API, no de una prueba de aceptación ilimitada en SFOS 22 ni de valores que ahora se rechacen en SFOS 23. Tampoco permite deducir una validación en WebAdmin ni un comportamiento verificado en ejecución.

Preparar el Collector y la ruta de red

Antes de configurar el firewall, el Collector necesita un listener NetFlow v5 activo. Sophos utiliza de forma predeterminada UDP 2055; se puede utilizar otro puerto UDP válido si el firewall y el Collector se configuran de manera idéntica. Se pueden registrar hasta cinco servidores NetFlow.

El ejemplo utiliza:

• Nombre del Collector: flow-collector-primary
• Dirección del Collector: 192.0.2.50
• Transporte: UDP
• Puerto del Collector: 2055
• Regla de prueba: LAN_Test_to_WAN_HTTPS

192.0.2.50 es una dirección reservada para documentación y no se puede utilizar como Collector real. En el ejemplo solo muestra qué campo se debe completar. Se introduce la dirección IP real o el FQDN del Collector en el que se ejecuta el listener v5 y al que el firewall puede llegar por la ruta de red prevista. Antes deben aclararse estos puntos:

• El Collector es compatible con NetFlow v5 y escucha realmente en UDP 2055.
• El firewall dispone de una ruta al Collector; si se utiliza un FQDN, también debe funcionar DNS.
• Los componentes intermedios y el Host Firewall del Collector permiten el puerto UDP.
• El Collector asigna la dirección de origen utilizada realmente al firewall correcto.
• Se han definido la finalidad, los derechos de acceso y el período de retención de los datos de flujo.

La exportación NetFlow es tráfico de sistema generado por el firewall. Una regla de firewall de cliente no controla esta exportación. Son relevantes la ruta del tráfico de sistema, el routing, DNS si se utiliza un FQDN y los filtros entre el firewall y el Collector.

⚠️ Las referencias de NetFlow revisadas no describen ajustes de TLS o autenticación ni constituyen un inventario exhaustivo de las opciones disponibles. Los datos de flujo pueden revelar direcciones internas, interlocutores, puertos, horarios y volúmenes. Por eso, el Collector debería ser accesible a través de una red de administración fiable o una ruta VPN protegida.

Ejemplo: preparar PRTG como Collector

En PRTG, la Probe recibe los flujos, no necesariamente el servidor web central. El siguiente ejemplo presupone que ya existe una Probe local o remota. El sensor NetFlow v5 no admite una Probe de clúster; en PRTG Hosted Monitor se necesita una Probe remota para este sensor.

1. Añadir un sensor NetFlow v5 en la Probe prevista.
2. Introducir 2055 en Receive Packets on UDP Port.
3. En Receive Packets on IP Address, seleccionar la dirección real de la Probe que se introducirá en SFOS como destino del Collector.
4. En Sender IP Address, introducir la dirección de origen de exportación del firewall que se haya observado realmente. Si el campo se deja vacío, se aceptan datos de cualquier emisor en ese puerto, por lo que no es una alternativa permanente adecuada a una asignación correcta.
5. Para la primera prueba, dejar vacíos Include Filter y Exclude Filter para que ningún filtro del Collector oculte el flujo de referencia. Permitir la recepción en el host de la Probe únicamente desde los exportadores necesarios.

Después de la prueba de exportación, comparar Top Talkers, Top Connections y Top Protocols con los valores de prueba anotados. Si llegan paquetes UDP al host de la Probe, pero no aparecen resultados del análisis, comprobar primero la dirección de recepción, el filtro de emisor y los filtros Include/Exclude. El estado Unknown puede aparecer una vez transcurrido Active Flow Timeout (Minutes) sin nuevos datos de flujo. Por sí solo, no demuestra un error del firewall; aquí no se prescribe para SFOS ningún tiempo de espera de exportación no confirmado.

Configurar el Collector NetFlow

1. Abrir System > Administration > Netflow en WebAdmin.
2. Hacer clic en Add.
3. Introducir flow-collector-primary en Server name.
4. Introducir 192.0.2.50 en Netflow server IP/domain.
5. Introducir 2055 en Netflow server port.
6. Guardar con Save.

También se pueden actualizar las entradas de servidores NetFlow existentes. Después de un cambio, repetir la prueba controlada de exportación descrita a continuación: comprobar por separado la regla aplicada, el transporte UDP y la decodificación v5.

La pantalla no dispone de ninguna prueba de conexión documentada. Por tanto, una entrada guardada solo confirma la configuración, no el transporte ni la decodificación en el Collector.

Activar Rule Logging como fuente de datos

NetFlow solo exporta conexiones de reglas de firewall que tengan activado Log firewall traffic. Este ajuste se comprueba en la regla correspondiente en Rules and policies > Firewall rules.

Para la primera prueba debe utilizarse una regla claramente delimitada. En el ejemplo, LAN_Test_to_WAN_HTTPS procesa una prueba HTTPS desde un cliente conocido hacia un destino autorizado. Lo importante no es el nombre de ejemplo, sino que el administrador pueda identificar sin dudas en Log Viewer qué regla procesa realmente el flujo.

Crear correctamente reglas de Sophos Firewall explica cómo estructurar y registrar una regla. Si hay dudas sobre la coincidencia, resulta útil Probar una regla con Log Viewer, Policy Tester y Packet Capture.

Probar la exportación de forma controlada

La prueba separa tres preguntas: ¿se ha aplicado la regla correcta, sale un paquete UDP del firewall y puede el Collector interpretar el contenido como NetFlow v5?

Antes de empezar, definir una ventana de observación finita adecuada al entorno local y anotar su hora de finalización. Las fuentes revisadas no especifican un calendario de exportación de SFOS; la observación de la exportación puede demorarse tras finalizar la conexión. Durante la ventana, vigilar el estado de la captura, el uso del búfer y el procesamiento en el Collector. La captura de WebAdmin tiene un búfer de 2048 KB y se detiene automáticamente cuando se llena, salvo que esté activado Wrap capture buffer once full. Esta opción mantiene la captura, pero sobrescribe los paquetes anteriores. Guardar las pruebas necesarias antes de perderlas y no considerar una captura detenida antes de tiempo o sobrescrita como una observación continua.

1. Comprobar en el Collector si el listener v5 está activo en UDP 2055.
2. Anotar la hora, el cliente de prueba, la dirección de destino, el puerto de destino y la regla de firewall esperada.
3. En Diagnostics > Packet capture, hacer clic en Configure, introducir dst host 192.0.2.50 and dst port 2055 en Enter BPF string, hacer clic en Save e iniciar la captura con Trace On.
4. Generar un único flujo de prueba identificable y acotado desde el cliente, por ejemplo una solicitud HTTPS permitida, y finalizar la conexión cuando sea posible. Anotar su hora de finalización.
5. Comprobar en Log Viewer si se ha aplicado LAN_Test_to_WAN_HTTPS o la Rule ID esperada.
6. Continuar observando hasta la hora de finalización de la ventana y buscar paquetes UDP dirigidos al Collector; después detener la captura con Trace Off.
7. Durante la misma ventana, comprobar si aparece en el Collector un registro v5 con los valores de origen y destino esperados y anotar el resultado. La ausencia de datos en una ventana breve no es concluyente sin conocer los tiempos de exportación; por sí sola no demuestra un fallo de exportación.

Para realizar una comprobación adicional de solo lectura, se puede ejecutar una captura breve en Device Console:

tcpdump 'host 192.0.2.50 and port 2055'

192.0.2.50 y 2055 se sustituyen por el Collector y el puerto reales. La captura se detiene con Ctrl+C. Los paquetes UDP visibles confirman el transporte hasta la interfaz observada, pero todavía no que el Collector decodifique los registros como versión 5.

Una prueba correcta solo está completa cuando coinciden la regla aplicada, el transporte UDP y la decodificación v5. Así también queda claro en qué punto se produce un error.

Delimitar flujos ausentes o incompletos

No hay paquetes UDP hacia la dirección del Collector

Comprobar la dirección y el puerto del Collector en System > Administration > Netflow. Después, comprobar DNS si se utiliza un FQDN, la ruta, la interfaz de salida y los filtros de los componentes intermedios. El Host Firewall del Collector también debe aceptar UDP 2055.

Si al mismo tiempo se modifican otras reglas o rutas, el resultado apenas puede atribuirse. Por eso, se debe empezar con una regla conocida y registrada y un único flujo de prueba.

Llegan paquetes UDP, pero el Collector no muestra nada

El listener debe procesar expresamente NetFlow v5. Una entrada configurada solo para NetFlow v9, IPFIX o sFlow puede recibir los paquetes UDP y aun así no mostrar flujos utilizables. Comprobar los registros del Collector, el parser y la dirección de origen esperada.

En este caso, Packet Capture solo demuestra el transporte. La decodificación correcta debe ser visible en el propio Collector.

Solo se ve una parte de las conexiones

Primero se comprueba qué regla de firewall procesa realmente el tráfico ausente y si allí está activado Log firewall traffic. Otra regla puede aplicarse antes de lo esperado. Además, la pérdida de paquetes UDP puede causar vacíos.

NetFlow v5 tiene limitaciones técnicas. La ausencia de nombres de usuario, Rule IDs, URLs o nombres de aplicaciones no es un error de exportación. El formato tampoco puede representar tráfico útil IPv6 con direcciones IPv6 de origen y destino nativas; una dirección IPv6 del Collector no cambia esta limitación.

La dirección de origen es inesperada

Las referencias de NetFlow revisadas no describen un ajuste específico para la dirección de origen de exportación. Una Packet Capture de duración limitada muestra la dirección utilizada realmente cuando se observan paquetes de exportación. Compararla con la asignación y los filtros de entrada del Collector; si difiere de la prevista, comprobar después la ruta y la interfaz de salida.

HA Failover o cambio de firmware

Las referencias revisadas no establecen garantías de exportación NetFlow sin interrupciones ni duplicados durante un Failover HA. Realizar el Failover únicamente como ejercicio operativo planificado y autorizado. Antes, en funcionamiento normal, y después, utilizar la misma prueba acotada para comprobar la recepción de registros, los huecos o duplicados, la dirección de origen y la asignación al firewall correcto.

Después de cambios de firmware, routing, DNS, Collector o reglas se repite la misma prueba documentada. Un flujo de referencia breve es más fiable que suponer que una entrada NetFlow guardada sigue funcionando.

Operación y privacidad

Como los registros de firewall, los datos NetFlow necesitan un responsable y una retención definida. La operación debe cubrir como mínimo estos puntos:

• supervisar la recepción en el Collector por firewall y alertar sobre fallos;
• documentar las direcciones de origen, la asignación de interfaces y la sincronización horaria;
• limitar el acceso a los metadatos de comunicación internos;
• definir la retención y el borrado en el Collector;
• volver a probar después de cambios de routing, HA, firmware o Rule Logging;
• verificar los flujos sospechosos con Log Viewer o Packet Capture.

NetFlow muestra relaciones a lo largo del tiempo, pero no demuestra la causa de una conexión bloqueada o lenta. Para una sesión concreta siguen siendo decisivos Rule ID, NAT ID, la ruta de paquetes y las funciones de seguridad implicadas.

Revertir el cambio

Para detener la exportación, eliminar el servidor correspondiente en System > Administration > Netflow. A continuación, usar el mismo filtro limitado de Packet Capture para confirmar que ya no se envían paquetes UDP a ese Collector. Log firewall traffic solo debe volver a su estado anterior: desactivarlo no solo detiene NetFlow para esa regla, sino que también impide nuevas entradas en el registro del firewall.

Preguntas frecuentes