Configurar Sophos Firewall Discover Mode con TAP y SPAN

En Discover Mode, Sophos Firewall recibe una copia del tráfico de red mediante una interfaz TAP. El switch replica los puertos o las VLAN seleccionados hacia un puerto SPAN o mirror conectado a un puerto libre de la firewall. La firewall no está en línea y no modifica la ruta de paquetes de producción.

Procedimiento rápido: Garantizar un acceso de administración separado, configurar un puerto SPAN bidireccional en el switch, seleccionar un puerto libre de la firewall, ejecutar system discover-mode tap add PortD en Device Console y comprobar primero la entrada con Packet Capture. Después se revisan Current Activity, los informes y, si es necesario, un Security audit report.

⚠️ Discover Mode es un modo de observación. No se pueden aplicar políticas de seguridad al tráfico de la interfaz TAP, y la firewall no puede bloquearlo ni descartarlo. HTTPS no es compatible con este modo. Por tanto, un informe sin hallazgos no demuestra ni una visibilidad completa ni una protección eficaz.

PortD es un ejemplo en esta guía. Se utiliza el puerto físico que esté realmente libre en el appliance.

Discover Mode en ocho pasos

1. Comprobar un puerto de administración independiente de la firewall y una vía segura de recuperación para la administración.
2. Definir en el switch qué puertos o VLAN se replicarán en ambas direcciones.
3. Conectar un puerto mirror dedicado a un puerto físico libre de la firewall.
4. Guardar el estado inicial en Device Console con system discover-mode tap show.
5. Activar el puerto de ejemplo como TAP con system discover-mode tap add PortD.
6. Comprobar el tipo Discover, physical (TAP) en Network > Interfaces.
7. Generar un flujo de prueba conocido y confirmar sus paquetes en la interfaz TAP.
8. Solo entonces evaluar los informes, la asignación de usuarios y un Security Audit Report.

El switch y la firewall se configuran por separado. Una interfaz TAP visible todavía no demuestra que el switch replique las tramas correctas.

Cuándo es adecuado TAP y cuándo no

Discover Mode es adecuado para un inventario pasivo, una prueba de concepto o un análisis previo a una implantación posterior en línea. Los objetivos habituales son:

• visualizar relaciones de tráfico y aplicaciones activas;
• clasificar categorías web y de aplicaciones dentro de los límites técnicos;
• observar detecciones IPS sin modificar la ruta de datos;
• recopilar informes para planificar posteriormente políticas y segmentación;
• evaluar una nueva firewall en paralelo con la infraestructura existente.

TAP no es la opción correcta si el tráfico ya debe bloquearse, descifrarse, modificarse mediante NAT o controlarse con reglas basadas en usuarios. Para ello se necesita el modo gateway, bridge u otro funcionamiento en línea con reglas de firewall adecuadas.

Discover Mode se puede combinar con los modos gateway, mixed y bridge. En ese caso, las reglas de seguridad se aplican a las interfaces en línea normales, no a la interfaz TAP. Planificar zonas e interfaces de Sophos Firewall explica cómo se relacionan los puertos físicos, las zonas, los bridges y los demás tipos de interfaz.

Topología de ejemplo y valores sustituibles

El ejemplo utiliza estos componentes:

• Switch central: SW-Core-01
• Uplink que se replica: Switch-Port 1, recepción y transmisión
• Destino SPAN: Switch-Port 24
• TAP de la firewall: PortD, libre y sin configuración IP
• Administración de la firewall: PortA - 10.10.10.16/24
• Cliente de prueba: 10.20.30.40

Los nombres y las direcciones son ejemplos. Lo importante es su función: el puerto TAP solo recibe las tramas replicadas. La administración, las actualizaciones, DNS y el envío de informes utilizan otra interfaz configurada normalmente.

El puerto mirror debe ser al menos tan rápido como el tráfico observado. Si varios puertos de origen muy utilizados se replican hacia un puerto de destino más lento, el switch puede descartar paquetes de la copia. La conexión de producción sigue funcionando, pero el informe queda incompleto. Por tanto, TAP no es una captura forense sin pérdidas, y la ausencia de un evento no demuestra que no se haya producido.

Requisitos y límites de seguridad

Antes de la activación deben aclararse estos puntos:

• Un switch administrado admite SPAN o port mirroring.
• Un puerto físico de la firewall está libre y no se utiliza en producción.
• La administración sigue disponible mediante una interfaz separada.
• La firewall tiene acceso a Internet para la clasificación en la nube, las actualizaciones IPS y la generación del Security Audit Report.
• Si el informe debe mostrar usuarios en lugar de solo direcciones IP, hay integrada una fuente de autenticación externa adecuada.
• La finalidad, la conservación y los destinatarios de los datos replicados cumplen los requisitos de privacidad.

Las tramas replicadas pueden revelar direcciones internas, consultas DNS, protocolos sin cifrar y relaciones de comunicación. Por ello, las capturas de paquetes y los informes solo se conservan durante el tiempo necesario y se transfieren de forma protegida.

Entender correctamente Port Affinity

Para determinadas plataformas, la guía de Sophos recomienda vincular la interfaz TAP a una CPU con bind-with antes de activarla. Los appliances XGS no necesitan Port Affinity manual porque el procesamiento se distribuye automáticamente entre los núcleos de CPU.

En otros appliances y plataformas virtuales, una asignación de CPU adecuada depende del hardware, el adaptador y la carga. No se debe copiar un valor de CPU de un ejemplo ajeno. Si la plataforma necesita una asignación manual, se planifica antes del despliegue de TAP con la guía correspondiente del dispositivo o de soporte. Un comando genérico set port-affinity no forma parte del procedimiento rápido normal.

En una firewall virtual también hay que garantizar que el hipervisor, el vSwitch y el adaptador de red virtual entreguen realmente las tramas replicadas a la máquina virtual. El estado del adaptador de red virtual por sí solo no lo confirma; la prueba de paquetes en SFOS es decisiva.

Preparar SPAN o port mirroring en el switch

La configuración exacta depende del fabricante. Como mínimo, se definen estos valores en el switch:

1. Source: el puerto físico que se observará o las VLAN previstas.
2. Direction: recepción y transmisión para que ambas direcciones sean visibles.
3. Destination: el puerto dedicado conectado a PortD de la firewall.
4. Session status: activado.

El puerto de destino no se utiliza al mismo tiempo como puerto access o trunk normal para endpoints. Tampoco se conecta el puerto de administración de la firewall al puerto mirror. De lo contrario se mezclan las rutas de administración y observación, o el switch crea un diseño de capa 2 inesperado.

Antes de configurar la firewall, conviene documentar qué VLAN y direcciones replica realmente el switch. En uplinks grandes, el piloto empieza mejor con una sola VLAN de prueba o un puerto claramente limitado en lugar de todo el tráfico del core.

Activar la interfaz TAP en Sophos Firewall

En Network > Interfaces, el puerto elegido debe tener la zona None y no debe tener configuración IP ni dependencias de producción. No se debe liberar un puerto en uso solo para la prueba: esto puede interrumpir interface hosts, DHCP, routing, reglas u otros servicios.

Después de iniciar sesión por SSH en Sophos Firewall, se abre Option 4: Device Console. Primero se consulta el estado actual:

system discover-mode tap show

A continuación se activa el puerto de ejemplo previsto y se vuelve a comprobar:

system discover-mode tap add PortD
system discover-mode tap show

Sophos documenta el mensaje Discover Interface added successfully para una activación correcta. Después, el puerto aparece en Network > Interfaces como Discover, physical (TAP).

El comando no configura SPAN en el switch. Si el puerto muestra el estado correcto en SFOS pero no recibe tráfico, se comprueba primero el lado del switch en vez de crear una regla de firewall por sospecha.

Comprobar el tráfico y los informes

1. Realizar una prueba de paquetes controlada

En el cliente de prueba 10.20.30.40 se genera una prueba clara de DNS o HTTP sin cifrar. En Diagnostics > Packet capture se utiliza un filtro BPF limitado:

host 10.20.30.40

La captura debe mostrar paquetes con In interface PortD. Con replicación bidireccional aparecen la solicitud y la respuesta. Una Firewall Rule ID o un estado Forwarded no es un criterio de éxito en la ruta TAP pasiva, porque SFOS no reenvía este tráfico ni le aplica una política de seguridad.

Packet Capture en Sophos Firewall WebAdmin explica el uso, los filtros y los límites de exportación. La captura se detiene después de la prueba y solo conserva el intervalo necesario.

2. Comprobar la visibilidad en su contexto

Tras confirmar los paquetes, se revisan Current activities y los informes locales adecuados. Las expectativas deben corresponder al protocolo:

• las direcciones de origen y destino visibles coinciden con la prueba;
• solo cabe esperar una categoría de aplicación o web cuando SFOS puede clasificar el tráfico;
• una detección IPS es una observación, no un bloqueo;
• los usuarios solo aparecen si la fuente de identidad funciona y la asignación es correcta;
• el contenido HTTPS no es compatible con Discover Mode.

La fuente externa de usuarios se prueba por separado. Para Active Directory sirve conectar Active Directory con Sophos Firewall. De lo contrario, la ausencia de un nombre de usuario no significa automáticamente que falte el tráfico TAP.

3. Generar un Security Audit Report

En Reports > Show report settings > Report scheduling > Add se selecciona el tipo Security audit report. Los destinatarios y la organización se introducen de forma consciente, y después se comprueban por separado el transporte de correo y el contenido del informe.

Programar informes de Sophos Firewall y enviarlos por correo electrónico explica los límites de Send test mail, Generate now, privacidad, idioma y comportamiento de HA. Un correo de prueba correcto solo demuestra la ruta de correo. Únicamente un informe generado con datos plausibles confirma la ruta completa.

HA y modos de funcionamiento mixtos

Discover Mode solo admite HA active-passive. HA active-active no es posible cuando una de las firewalls funciona en Discover Mode.

No se puede crear un clúster active-passive mientras la interfaz TAP esté activa. Para configurar HA, se desactiva el puerto TAP en ambos appliances, se crea HA y después se vuelve a activar la interfaz TAP por separado en los dos dispositivos. Sophos también indica que la interfaz TAP permanece activa en el appliance pasivo.

Por ello, el cableado, la replicación del switch y la recepción de datos se vuelven a comprobar después de un cambio de rol planificado. No se da por hecho que un periodo de informe existente o una observación TAP continúe sin interrupción en el otro nodo. Configurar HA en Sophos Firewall explica los roles, la sincronización y el comportamiento local de los nodos.

El límite también queda claro en un diseño mixto gateway o bridge: las interfaces normales pueden reenviar y proteger el tráfico. La interfaz TAP solo recibe la copia replicada.

Solucionar problemas por síntoma

La interfaz TAP no muestra ningún paquete

1. Comprobar el puerto configurado con system discover-mode tap show.
2. En Network > Interfaces, comprobar el tipo Discover, physical (TAP) y el enlace físico.
3. Comparar el destino del switch, los puertos de origen o las VLAN y la dirección de replicación.
4. Repetir un flujo de prueba conocido sin un filtro de captura demasiado limitado.
5. En una VM, comprobar si la ruta de red virtual entrega a la firewall las tramas ajenas replicadas.

Una regla de firewall no es la solución, porque el tráfico TAP no se reenvía mediante el motor de reglas normal.

Solo es visible una dirección

A menudo, la fuente mirror del switch está configurada solo como RX o TX. La sesión se cambia a both, es decir, ambas direcciones, y se repite la misma prueba. Con routing asimétrico, la ruta de retorno también puede utilizar otro uplink físico que no se replica.

Los paquetes son visibles, pero los informes están vacíos o incompletos

Primero se comprueban el intervalo, el tipo de informe, el acceso a Internet, el estado de patrones y los protocolos realmente replicados. HTTPS no es compatible con Discover Mode. Un destino SPAN sobrecargado también puede perder copias sin afectar al tráfico de producción.

Si faltan usuarios, se continúa con la fuente de autenticación. Si solo falla el envío por correo, primero se revisan las notificaciones por correo electrónico. No se reinician servicios de informes por sospecha ni se borran datos locales de informes como primer paso.

Un informe muestra riesgos, pero no se bloquea nada

Es el comportamiento esperado. Discover Mode evalúa una copia. Un hallazgo solo se convierte en una futura política en línea, segmentación u otra medida de protección tras una revisión técnica. La firewall TAP no puede detener posteriormente el flujo original observado.

Deshacer Discover Mode de forma segura

Antes de deshacer la configuración se guardan los informes, intervalos y hallazgos necesarios. Después:

1. Desactivar la sesión SPAN en el switch para que no lleguen más copias.
2. Eliminar el puerto de ejemplo en Device Console:

system discover-mode tap delete PortD
system discover-mode tap show

3. En Network > Interfaces, comprobar que el puerto ya no aparece como Discover, physical (TAP).
4. Eliminar de forma controlada las programaciones de Security Audit que ya no se necesiten.
5. Volver a utilizar normalmente el puerto de destino del switch solo después de una comprobación documentada.
6. Si el puerto de la firewall se utilizará en producción, planificar y probar su zona, IP, dependencias y reglas como un cambio independiente.

No se debe mezclar la reversión de TAP con una migración improvisada en línea. Los modos gateway o bridge cambian el routing, las reglas y el riesgo de interrupción, y requieren un plan de migración separado.

Lista de comprobación

• El acceso de administración separado funciona.
• El puerto TAP es físico, está libre y no se utiliza para otro fin.
• La fuente, la dirección y el destino SPAN están documentados.
• El destino mirror no está sobrecargado.
• system discover-mode tap show muestra el puerto esperado.
• Packet Capture ve un flujo de prueba conocido en ambas direcciones.
• Los informes solo se evalúan dentro de la visibilidad compatible.
• HTTPS y la ausencia de enforcement están documentados.
• La asignación de usuarios se probó por separado si era necesaria.
• Los destinatarios y la conservación de informes están aprobados.
• Los límites de HA o VM se probaron en el entorno real.
• La reversión y la posterior migración en línea son cambios separados.

Preguntas frecuentes