Configurar Sophos Firewall Mail Protection en modo MTA

Sophos Firewall puede aceptar, analizar y reenviar tráfico SMTP en modo MTA hacia el servidor de correo interno o el siguiente mailhop. El firewall no es entonces solo una apertura de puerto para TCP 25, sino un Mail Transfer Agent activo con routing, análisis de spam y malware, cuarentena, spool y logs de correo.

Hoy recomendamos Mail Protection en el firewall sobre todo para escenarios on-premises o híbridos planificados de forma consciente, por ejemplo cuando un Exchange local u otro servidor de correo interno debe protegerse directamente a través del firewall. Para Microsoft 365, Google Workspace y muchos entornos modernos de correo cloud, Sophos Central Email u otro cloud mail gateway suele ser la arquitectura más limpia, porque MX, cuarentena, headers, TLS, SPF/DKIM/DMARC y soporte quedan más cerca del servicio de correo real.

Si se usa Mail Protection en modo MTA, el artículo debe cubrir más que una explicación de la función: MX record, regla MTA automática, SMTP route and scan Policy, permisos de relay, TLS, verificación de destinatarios, spool, cuarentena y logs deben encajar. De lo contrario, el firewall puede rechazar emails legítimos, retrasar correo o quedar accesible accidentalmente como relay.

Cuándo tiene sentido Mail Protection en el firewall

Mail Protection en Sophos Firewall tiene sentido sobre todo cuando el tráfico SMTP debe pasar deliberadamente por el firewall y este debe hacer más que simplemente reenviar el puerto 25.

Escenarios típicos:

• Los emails entrantes deben aceptarse y analizarse primero en el firewall.
• Un servidor de correo interno no debe ser accesible directamente desde Internet.
• El análisis de spam, malware, tipos de archivo o contenido debe aplicarse antes de la entrega.
• Los emails salientes deben enviarse de forma controlada a través del firewall o de un smarthost.
• La cuarentena, el mail spool y los logs SMTP deben poder rastrearse en el firewall.

No toda configuración de correo debería pasar por el firewall. Si Sophos Central Email, Microsoft Defender for Office 365 u otro cloud mail gateway ya gestiona todo el mailflow, no se debería intercalar además Mail Protection en el firewall sin documentar exactamente el flujo de correo. Las pasarelas duplicadas generan rápidamente responsabilidades poco claras en cuarentena, cabeceras, SPF/DKIM/DMARC, TLS y troubleshooting.

Diferenciar modo MTA, Legacy mode y SMTP Relay

En Sophos Firewall hay que separar claramente tres cosas:

• MTA mode: El firewall acepta correo, lo analiza y lo entrega. Mailflow SMTP entrante o saliente con policies.
• Legacy mode: procesamiento de correo antiguo basado en proxy. Entornos existentes que se migran o se mantienen deliberadamente.
• SMTP Relay como servicio local: sistemas internos envían a través del firewall. Impresoras, escáneres, aplicaciones o sistemas de monitoring.

El MTA mode es el modo objetivo normal para escenarios modernos de Mail Protection en el firewall. El servicio local SMTP Relay, en cambio, es un tema de Device Access. Solo debería ser accesible desde redes internas definidas. Una autorización demasiado amplia puede favorecer el abuso del relay. El endurecimiento de servicios locales se describe en Proteger el acceso a Sophos Firewall: configurar correctamente Device Access.

Requisitos

Antes de la configuración deben aclararse estos puntos:

• Sophos Firewall con Email Protection válida o bundle adecuado.
• No todos los modelos admiten MTA mode. XGS 87/87w y XGS 88/88w son appliances sin soporte de MTA mode.
• Se conocen la zona DNS pública y el registro MX.
• El servidor de correo interno, el puerto de destino y la ruta de entrega están documentados.
• Está definida la dirección IP pública o dirección WAN para el tráfico SMTP entrante.
• El firewall puede enrutar y alcanzar el servidor de correo interno.
• El acceso DNS saliente del firewall funciona.
• La estrategia TLS y de certificados deseada está aclarada.
• El proceso de cuarentena y liberación está definido organizativamente.

Antes de cambiar el mailflow debería planificarse una ventana de mantenimiento. Una prueba con registros MX productivos sin plan de fallback es arriesgada, porque los emails entrantes pueden retrasarse o rechazarse rápidamente según el remitente.

Definir la arquitectura objetivo

Primero debe decidirse qué dirección debe procesar el firewall.

Mailflow entrante

En el mailflow entrante, los registros MX externos apuntan a la dirección pública en la que Sophos Firewall acepta SMTP. El firewall analiza el mensaje y lo reenvía al servidor de correo interno.

Flujo típico:

1. El remitente externo se conecta por SMTP a la dirección MX pública.
2. Sophos Firewall acepta la conexión en MTA mode.
3. Mail Protection comprueba remitente, destinatario, spam, malware, adjuntos y policy.
4. El firewall entrega el email al servidor de correo interno.
5. El servidor de correo interno entrega al buzón o procesa el mensaje.

Es importante que el servidor de correo interno no siga siendo accesible también sin filtrar desde Internet. Si en paralelo una regla DNAT todavía apunta directamente al servidor de correo, parte del tráfico puede saltarse Mail Protection. Para publicaciones normales de servidores, Publicar un servidor mediante DNAT es la base adecuada, pero en MTA mode el propio firewall es el punto de aceptación SMTP.

Mailflow saliente

En el mailflow saliente, el servidor de correo interno envía a través de Sophos Firewall. El firewall puede analizar mensajes, reenviarlos a un smarthost o entregarlos directamente, según la configuración.

Aclarar antes:

• ¿Puede la IP pública del firewall enviar emails directamente?
• ¿SPF, DKIM y DMARC son correctos para la ruta de envío elegida?
• ¿Se necesita un smarthost del proveedor?
• ¿Debe limitarse el tráfico SMTP saliente a sistemas internos concretos?
• ¿Dónde se monitorizan los mensajes rechazados o retrasados?

Para el tráfico de correo saliente debería utilizarse una estructura propia y trazable de reglas y policies. Una regla general LAN to WAN sin restricción clara suele ser demasiado amplia para servidores de correo. Los fundamentos sobre orden de reglas y perfiles de seguridad están en Comprender y construir correctamente reglas de Sophos Firewall.

Preparar cambio MX y pruebas externas

Un cambio de Mail Protection solo se vuelve crítico cuando los remitentes externos usan realmente la nueva ruta. Por eso deben comprobarse registro MX, DNS TTL, accesibilidad externa y rollback antes del cambio productivo.

Antes del cambio:

• Documentar registro MX actual, prioridad y TTL.
• Reducir el DNS TTL con antelación si puede ser necesario un fallback rápido.
• Distinguir claramente la ruta de correo antigua y la nueva dirección de Sophos Firewall.
• Identificar antiguas reglas DNAT directas al servidor de correo.
• Definir destinatarios y remitentes de prueba.
• Definir plan de fallback: MX antiguo, regla DNAT antigua o smarthost temporal.
• Preparar monitoring de spool, cuarentena y queue del servidor de correo.

Comprobaciones externas útiles desde un sistema fuera de la propia red:

dig MX example.com
dig A mail.example.com
nc -vz mail.example.com 25
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com

Los comandos no sustituyen una prueba completa de mailflow, pero muestran rápidamente si DNS, puerto 25 y STARTTLS son básicamente accesibles. example.com y mail.example.com deben sustituirse por el dominio real y el host de correo real.

Después del cambio se debe enviar de inmediato un email de prueba entrante y documentar toda la ruta:

• ¿Conexión visible en Log Viewer?
• ¿Entrada presente en smtpd_main.log?
• ¿Verificación del destinatario correcta?
• ¿Entrega al servidor de correo interno realizada?
• ¿Mensaje recibido en el buzón?
• ¿Sin entrega directa paralela que pase por alto el MTA?

Si el firewall acepta emails pero no los entrega, no debería revertirse inmediatamente el MX. Primero hay que aclarar si se trata de un problema interno de routing, DNS, TLS o servidor de correo. Pero si remitentes externos no pueden conectarse al firewall o se rechazan ampliamente emails legítimos, un fallback rápido a la ruta de correo anterior suele ser más sensato que experimentar durante más tiempo en la ruta MX productiva.

Activar MTA mode

Los ajustes básicos se encuentran en:

Email > General settings

Para esta guía debe estar activo MTA mode. Si el firewall aún funciona en Legacy Mode, se cambia con Switch to MTA mode.

Después de activarlo, Sophos Firewall crea automáticamente una regla de firewall para SMTP/SMTPS llamada Auto added firewall policy for MTA. Esta regla debe permanecer visible y estar bastante arriba en la base de reglas. Una regla MTA no debe tratarse como una regla LAN-to-WAN normal ni moverse hacia abajo de forma incidental, porque entonces el tráfico SMTP entrante puede dejar de entrar en el flujo MTA esperado.

Después se revisan los ajustes básicos:

1. En SMTP settings, definir el SMTP hostname. Es el hostname que el firewall usa en contextos HELO y banner para mensajes generados por el sistema. No introduzca a ciegas el nombre interno del servidor de correo si el nombre público de correo es distinto.
2. Activar Reject based on IP reputation si las conexiones SMTP entrantes deben rechazarse según mala reputación del remitente.
3. En SMTP TLS configuration, seleccionar un certificado público confiable adecuado si SMTP TLS debe presentarse correctamente a través del firewall.
4. Activar Disable legacy TLS protocols, salvo que existan sistemas antiguos documentados que lo impidan.
5. Activar Scan outgoing mails si los mensajes salientes del servidor de correo también deben analizarse a través del firewall.

En entornos existentes, no cambiar simplemente entre Legacy mode y MTA mode sin probar el mailflow. El procesamiento, los logs y la lógica de policy son diferentes. Antes de una migración deben documentarse la configuración actual del firewall, los registros MX, los conectores del servidor de correo y los ajustes de relay.

Configurar routing SMTP y dominios

Para emails entrantes, el firewall debe saber qué dominios debe aceptar y dónde debe entregarlos.

Crear Address Group para dominios de correo

Primero se crea una Address Group para los dominios de correo protegidos:

1. Abrir Email > Address group.
2. Hacer clic en Add.
3. Comprobar que Group type esté en Email address/domain.
4. Mantener Type en Manual si los dominios se administran manualmente.
5. En Email address/domain, introducir el dominio, por ejemplo example.com, y añadirlo.
6. Hacer clic en Save.

Aquí se trata de dominios, no de direcciones de destinatario individuales. Según la configuración, direcciones existentes o migradas pueden seguir funcionando, pero en las SMTP route and scan Policies actuales ya no deberían planificarse como nuevas entradas individuales. Para un estado objetivo limpio conviene trabajar con dominios y una verificación de destinatarios adecuada.

Crear SMTP route and scan Policy

La policy MTA propiamente dicha se crea en:

Email > Policies and exceptions > Add a policy > SMTP route and scan

Flujo típico para correo entrante hacia un servidor interno:

1. Definir un Name claro, por ejemplo Inbound example.com to Exchange.
2. En Protected domain, seleccionar la Address Group creada previamente.
3. Definir Route by:
   • Static host: para direcciones IP fijas de servidores de correo internos.
   • DNS host: para un nombre DNS como mailserver.example.com.
   • MX: si el firewall debe entregar según MX records.
4. Con Static host, seleccionar el servidor de correo interno en Host list. Los IP hosts se crean, si hace falta, en Hosts and services > IP host.
5. Poner Global action en Accept si el dominio debe aceptarse y revisarse según la policy.
6. Activar Spam protection y decidir conscientemente si el spam se advierte, se pone en cuarentena, se descarta o se entrega sin acción.
7. Activar Malware protection. Para Zero-Day Protection con Single-Antivirus-Scan debe usarse Sophos como motor primario.
8. Activar File protection y Data protection solo si se entienden los efectos sobre adjuntos, mensajes grandes, SPX y DKIM.
9. Hacer clic en Save.

Con varios servidores de correo internos, el tipo de routing es importante. Con Static host se cambia al siguiente host si el primero no es accesible. Con DNS host y varios A records, la entrega puede distribuirse. Esto puede ser práctico, pero debe encajar con el diseño de los servidores de correo, los certificados TLS y el troubleshooting.

Para servidores de correo internos, DNS es especialmente importante. El firewall debe poder resolver correctamente los destinos internos, y los remitentes externos deben alcanzar la entrada MX pública. Si la resolución DNS interna juega un papel, ayuda Configurar DNS Request Routes en Sophos Firewall.

Planificar policies para spam, malware y adjuntos

Mail Protection solo es tan buena como las policies que realmente se aplican. Una policy no solo debe crearse, sino nombrarse con un propósito claro.

Preguntas importantes de policy:

• ¿Qué dominios o grupos de destinatarios están afectados?
• ¿Se procesa tráfico de correo entrante, saliente o en ambas direcciones?
• ¿Qué ocurre con spam, malware, adjuntos sospechosos o tipos de archivo no deseados?
• ¿Los emails se bloquean, se ponen en cuarentena, se entregan o se marcan con cabeceras?
• ¿Debe usarse Recipient verification mediante Callout o Active Directory?
• ¿Quién puede revisar la cuarentena y liberar emails?
• ¿Qué procesos de falsos positivos existen?

Spam Protection no debe tratar SPF, RBL, Greylisting, BATV y Recipient verification como simples checkboxes. Los aciertos RBL o SPF no se procesan como acciones de spam normales, sino que pueden rechazar mensajes directamente. Recipient verification reduce backscatter y destinatarios inválidos, pero si hay problemas de AD, TLS o servidor de correo, también puede convertirse en fuente de errores.

En mensajes salientes, DKIM es especialmente sensible. SPX encryption, prefijos en el asunto, tipos de archivo bloqueados, Data Protection o un banner saliente pueden modificar headers o body. Eso puede romper el hash DKIM en el MTA receptor. Si las firmas salientes son importantes, debe decidirse si la firma se hará en el servidor de correo, en Sophos Firewall o en un gateway posterior.

Si se utiliza Zero-Day Protection, los adjuntos sospechosos pueden analizarse adicionalmente. Los límites, informes y decisiones de liberación se explican en Comprender y operar Sophos Firewall Zero-Day Protection.

Proteger relay y Device Access

Un error frecuente es confundir el mailflow MTA con un SMTP Relay abierto. El firewall no debe poder utilizarse como relay desde redes arbitrarias.

Para emails entrantes, SMTP debe poder aceptarse en el lado WAN para que los servidores externos puedan entregar el dominio. Para emails salientes, en cambio, debe estar claro qué hosts internos pueden relayar a través del firewall.

Comprobar:

• En Administration > Device access, SMTP Relay solo está activado en las zonas realmente necesarias.
• Si se usan ACL Exception Rules, las fuentes están definidas de forma estricta.
• En Email > Relay settings, bajo Host-based relay, solo están registradas como fuentes permitidas los servidores de correo, escáneres o servidores de aplicación definidos.
• Las zonas no necesarias, redes de invitados y redes untrusted no pueden relayar de forma general.
• Si servicios cloud como Exchange Online Protection deben entregar o relayar a través del firewall, los rangos de origen permitidos deben mantenerse con mucha precisión. Autorizaciones amplias con Any son un riesgo de Open Relay.
• El logging está activo para que abusos o configuraciones erróneas sean visibles.

Si impresoras, escáneres o aplicaciones necesitan enviar emails, debería documentarse para ello una ruta de relay interna propia. Estos sistemas no deberían comunicarse directamente con destinos SMTP externos arbitrarios si el entorno puede evitarlo.

Probar el mailflow

Después de la configuración, un único envío correcto no basta. Deben realizarse varias pruebas y documentarse los resultados.

Probar entrada

Comprobar al menos:

• El registro MX externo apunta a la dirección esperada.
• El puerto 25 es accesible desde fuera.
• El firewall acepta la conexión en MTA mode.
• El email se reenvía al servidor de correo interno.
• El destinatario existe y recibe el mensaje.
• La prueba de spam o malware se trata como se espera.
• La entrada de cuarentena o log es trazable.

Probar salida

Comprobar al menos:

• El servidor de correo interno envía por la ruta esperada.
• La regla de firewall y la mail policy se aplican.
• SPF, DKIM y DMARC encajan con la ruta de envío.
• El servidor destino acepta el mensaje.
• Se monitorizan bounces o mensajes Deferred.
• Ningún otro sistema interno envía directamente al exterior sin planificación.

Comprobar logs

Para una revisión visual rápida ayuda Log Viewer. Para un análisis más profundo son importantes los archivos de log de correo. La asignación está en Troubleshooting de Sophos Firewall: servicios y logs.

Archivos de log relevantes:

• SMTP MTA: smtpd_main.log.
• Errores SMTP: smtpd_error.log, smtpd_panic.log, smtpd_reject.log.
• Anti-Spam: sasi.log.
• Legacy SMTP/MTA: awarrensmtp.log, awarrenmta.log, awarrenmta_debug.log.
• POP/IMAP Proxy: warren.log.

En troubleshooting urgente, anotar la hora de prueba, recopilar remitente, destinatario, asunto, IP de origen y Message-ID, y después correlacionar Log Viewer y archivos de log por tiempo.

Cuarentena, spool y almacenamiento

Mail Protection genera datos locales. Según el volumen, los mensajes acaban en cuarentena, spool o áreas temporales. Por eso el espacio de almacenamiento, el estado del SSD y el plan de recovery son más relevantes que con una regla de firewall pura.

Preguntas operativas prácticas:

• ¿Quién revisa la cuarentena y con qué frecuencia?
• ¿Cómo se liberan los falsos positivos?
• ¿Cuándo se elimina un mensaje en lugar de liberarlo?
• ¿Cómo se detecta un mail spool creciente?
• ¿Existe monitoring para espacio de almacenamiento y System Health?
• ¿Se planifica una breve prueba de mailflow después de firmware updates?

Para temas de almacenamiento y reporting encajan Limpiar almacenamiento y reportes de Sophos Firewall y Comprobar Sophos Firewall SSD Health. En entornos HA también debe tenerse en cuenta que la cuarentena de correo y los datos de correo procesados pueden ser datos operativos ligados al nodo. Los fundamentos HA están en Variantes de cluster HA de Sophos Firewall.

Comprobar la cuarentena directamente en WebAdmin

Si un firewall se gestiona desde Sophos Central, el acceso por Central es practico. Aun asi, con Mail Protection conviene saber donde esta la cuarentena local y como revisarla directamente en el firewall.

Email > SMTP quarantine

Alli se pueden filtrar los mensajes en cuarentena por periodo, remitente, destinatario, asunto y motivo de cuarentena. Para la operacion son relevantes sobre todo tres acciones:

• Delete: Eliminar el mensaje de la cuarentena.
• Release: Liberar el mensaje al destinatario.
• Release and report: Liberar el mensaje e informar de una clasificacion incorrecta.

Importante: los mensajes infectados por virus y los mensajes clasificados como maliciosos por Zero-Day Protection no pueden liberarse simplemente. Para entradas de Zero-Day Protection también hacen falta permisos adecuados si se van a eliminar. Si la cuarentena se llena, se limpian emails antiguos. Es otro motivo para no revisar cuarentena y almacenamiento solo cuando llegan quejas.

En SFOS 22.0 MR1 hay un caso especial importante: si el firewall se gestiona desde Sophos Central, acciones de cuarentena como Release o Delete pueden fallar con Invalid API request. Esto no significa automaticamente que el flujo de correo, la cuarentena o la politica MTA esten rotos. La solucion practica es iniciar sesion directamente en el WebAdmin local del firewall y liberar o eliminar el mensaje en Email > SMTP quarantine.

Tras actualizar a SFOS 22.0 MR2 o posterior, se debe probar de nuevo el proceso: poner en cuarentena un mensaje de prueba inofensivo, ejecutar la accion por la via administrativa prevista y comprobar Log Viewer, la cuarentena y el buzon del destinatario.

Troubleshooting

No llegan emails externos

Primero comprobar DNS y accesibilidad: registro MX, IP pública, puerto 25, restos de NAT, MTA mode y dominio de correo responsable. Después comprobar en Log Viewer y en smtpd_main.log si la conexión llega al firewall. Si no hay conexión visible, el problema probablemente está antes de Mail Protection.

El firewall acepta emails, pero no los entrega

Entonces son más probables el servidor de correo interno, routing, DNS, puerto de destino, TLS, verificación de destinatario o policy. Se comprueba si el firewall puede alcanzar el servidor de correo y si este acepta la conexión. Reject logs y logs del servidor de correo deben evaluarse juntos por tiempo.

Muchos emails permanecen en el spool

Un spool creciente suele indicar problemas de entrega: servidor de correo interno no accesible, requisito TLS no encaja, falla la resolución DNS o el servidor destino rechaza el mensaje. En este caso no basta con volver a entregar mensajes individuales, sino que hay que buscar la causa en la ruta de routing y SMTP.

Un caso importante de orden de reglas se pasa por alto fácilmente: si una regla de firewall creada automáticamente o manualmente está por encima de la regla MTA y hace match con tráfico SMTP, la regla MTA real ya no se evalúa. Entonces los emails pueden quedar en el mail spool aunque DNS, puerto 25 y servidor de correo parezcan básicamente correctos.

Comprobar:

1. Abrir Rules and policies > Firewall rules.
2. Comprobar reglas por encima de la regla MTA o SMTP.
3. Revisar nuevas reglas creadas automáticamente, reglas IPsec, reglas hotspot o reglas colocadas manualmente en Top.
4. Realizar de nuevo la prueba SMTP y comparar Log Viewer, mail spool y smtpd_main.log.

La regla no debe moverse hacia abajo a ciegas si cumple otros fines productivos. Lo decisivo es si intercepta inesperadamente tráfico SMTP antes de la regla MTA.

Falta el digest de cuarentena para direcciones alias

Si los usuarios emplean direcciones alias, no se deben comprobar los ajustes de cuarentena solo para la dirección de correo primaria. Según Sophos, los ajustes de cuarentena no se aplican automáticamente por defecto a direcciones alias. Si faltan emails digest o liberaciones para destinatarios alias, las direcciones alias deben considerarse junto con la dirección primaria en el contexto de cuarentena o usuario.

Un remitente legítimo se detecta como spam

Los falsos positivos no deberían responderse de inmediato con excepciones amplias. Primero comprobar dominio remitente, SPF/DKIM/DMARC, cabeceras, reputación, policy match y destinatarios afectados. Si una excepción es necesaria, debería limitarse de forma estricta y documentarse con fecha de revisión.

Los sistemas internos no pueden relayar

Comprobar si SMTP Relay en Administration > Device access está permitido desde la zona correcta y si la fuente encaja con la ACL. Después revisar los logs de correo. Si un escáner o una aplicación debe relayar, la fuente debería documentarse como objeto host y no habilitarse innecesariamente toda una red.

Después de un firmware update el correo funciona de forma diferente

Después de firmware updates deben comprobarse MTA mode, policies, certificados, mail spool, cuarentena y logs relevantes. Para actualizaciones mayores también encaja Comprobar Sophos Firewall antes del upgrade a SFOS 22.

La accion de cuarentena muestra Invalid API request

Si Release o Delete falla con Invalid API request en un firewall abierto desde Sophos Central, comprobar primero la version de SFOS. En SFOS 22.0 MR1 este flujo puede estar afectado.

El siguiente paso no es reconstruir la politica de correo. Primero hay que entrar en el WebAdmin local del firewall y editar el mensaje en Email > SMTP quarantine. Despues documentar:

1. Version y build de SFOS.
2. Si la accion se intento desde Sophos Central o directamente en WebAdmin.
3. Remitente, destinatario, asunto y motivo de cuarentena.
4. Resultado tras la prueba directa en WebAdmin.
5. Si esta prevista o instalada una actualizacion a SFOS 22.0 MR2 o posterior.

Checklist operativa

• Licencia Mail Protection y soporte de appliance comprobados.
• MTA mode elegido deliberadamente y documentado.
• Registro MX, IP pública y servidor interno de destino correctos.
• Cambio MX, pruebas externas y rollback preparados.
• Ninguna regla DNAT paralela sin filtrar evita el MTA.
• Policies entrantes y salientes nombradas de forma comprensible.
• Address Group para los dominios protegidos mantenida correctamente.
• El orden de reglas del firewall no impide que se aplique la regla MTA.
• TLS, DKIM, banner, SPX y Data Protection revisados por posibles efectos secundarios.
• SMTP Relay permitido solo desde fuentes internas definidas.
• Proceso de cuarentena y falsos positivos definido.
• Direcciones alias consideradas en el proceso de cuarentena y digest.
• Mail spool, espacio de almacenamiento y System Health monitorizados.
• Logs conservados localmente, en Sophos Central o por Syslog durante suficiente tiempo.
• Después de firmware updates se realiza una prueba de mailflow.

Para retención más larga y correlación con otros eventos de seguridad, comprobar Central Firewall Reporting o Enviar Syslog de Sophos Firewall a SIEM.

FAQ