Configurar y probar notificaciones por correo en Sophos Firewall

Para que las notificaciones por correo electrónico funcionen, Sophos Firewall necesita dos configuraciones separadas: en Administration > Notification settings se configura el transporte de correo. En System services > Notification list se determina qué eventos se notifican realmente por correo electrónico.

La vía rápida:

1. Configurar el servidor de correo, el puerto, la autenticación, el cifrado, el remitente y el destinatario en Administration > Notification settings.
2. Enviar un correo de prueba y confirmar su entrega en el buzón de destino o en el seguimiento del servidor de correo.
3. Activar el interruptor global Email notifications en System services > Notification list.
4. Seleccionar únicamente los eventos ante los que pueda reaccionar un destinatario responsable.
5. Además del correo de prueba, provocar de forma controlada un evento real seleccionado y comprobar su entrega.

Un correo de prueba correcto solo demuestra que la ruta SMTP funciona en principio. Todavía no demuestra que el interruptor global de correo y los eventos adecuados estén activados. A la inversa, una fila de evento seleccionada no envía ningún mensaje mientras el transporte de correo no funcione. Esta separación también explica por qué un servidor SMTP configurado por sí solo todavía no satisface operativamente el punto Notification Emails del Health Check de Sophos Firewall.

Preparar el envío de correo

Antes de configurar, hay que aclarar con el administrador de correo responsable el servidor, el puerto y el método de autenticación. Si se utiliza un FQDN como smtp.example.net, el firewall debe poder resolverlo y alcanzar el servidor por la ruta prevista. Solo se necesita una conexión general a Internet si el servidor de correo o el proveedor OAuth elegido se encuentra en Internet. Un relay SMTP interno también puede funcionar sin que el firewall tenga acceso directo a Internet.

Un ejemplo realista:

• Mailserver: smtp.example.net
• Port: 587
• Authentication: Basic
• Connection security: STARTTLS
• Sender: fw-zrh-01@example.net
• Recipient: firewall-alerts@example.net
• Management interface IP address: interfaz de gestión interna del firewall

Todos los valores con example.net se sustituyen por el dominio propio y las direcciones autorizadas por el administrador de correo. Una dirección de distribución suele ser mejor que un buzón personal: las responsabilidades pueden cambiar sin tener que reconfigurar cada firewall.

La opción Management interface IP address no controla por qué interfaz sale del firewall la conexión SMTP. La dirección IP seleccionada se incluye en la notificación y ayuda a identificar el firewall remitente. Por eso, cuando hay varias sedes conviene elegir una IP de gestión que sea comprensible de forma duradera; con un solo firewall también puede bastar None.

Configurar el servidor de correo

Elegir Built-in o External email server

Sophos Firewall puede utilizar el Built-in email server o un External email server. El envío integrado resulta práctico para empezar de forma sencilla. En entornos productivos, un relay o servidor de correo cloud propio suele ser más fácil de controlar, porque la autenticación, el seguimiento del correo, las autorizaciones de remitente y los errores de entrega quedan visibles en un punto central.

Por eso recomendamos el External email server cuando ya existe un servicio SMTP operado de forma fiable.

Para el envío integrado basta esta breve rama:

1. Activar el Built-in email server en Administration > Notification settings.
2. Introducir el remitente, el destinatario y, opcionalmente, Management interface IP address.
3. Guardar y enviar el correo de prueba.

Con el Built-in email server no existe un seguimiento propio del relay en el que el administrador pueda comprobar la aceptación y el reenvío. Por eso hay que verificar la entrega real con especial cuidado. Si falla repetidamente o el dominio destinatario y los requisitos de seguridad exigen una ruta SMTP controlada, un External email server es la variante más manejable.

Configurar External email server

1. Abrir Administration > Notification settings.
2. Seleccionar External email server.
3. Introducir la dirección IPv4 o el FQDN del servidor de correo y el puerto indicado.
4. En Authentication, seleccionar None, Basic u OAuth 2.0 según el servidor.
5. En Connection security, configurar el cifrado de transporte exigido por el servidor de correo.
6. Introducir el remitente, el destinatario y, opcionalmente, Management interface IP address.
7. Guardar y ejecutar la función de correo de prueba.

El puerto predeterminado de SFOS es 25, pero no constituye una recomendación para todos los entornos. Lo decisivo es el listener del relay propio. Son habituales el 25 para un relay interno autorizado por la IP de origen, el 587 para entrega autenticada con STARTTLS o el 465 para SSL/TLS directo. El puerto, la autenticación y el modo de cifrado deben coincidir como conjunto con el servidor de correo.

None no significa lo mismo en los dos campos de selección: en Authentication desactiva el inicio de sesión en el servidor de correo. Esto puede ser correcto para un relay interno que autoriza exclusivamente la IP de origen del firewall. En Connection security, en cambio, None significa transmisión SMTP sin cifrar. Esta opción no es adecuada para rutas por Internet y solo debería utilizarse internamente si el modelo de seguridad lo permite expresamente.

Con Basic, el firewall utiliza nombre de usuario y contraseña. Según Sophos, el nombre de usuario distingue entre mayúsculas y minúsculas. El relay debe admitir el método de inicio de sesión utilizado; un mensaje de error sobre Authentication method indica en particular una diferencia respecto a LOGIN o PLAIN.

STARTTLS se malinterpreta con facilidad: el firewall sigue la capacidad del servidor de correo. Si el servidor ofrece STARTTLS, la conexión se cifra; si no lo ofrece, el mensaje puede transmitirse sin cifrar. Quien necesite imponer el cifrado debe utilizar SSL/TLS con el puerto y el listener del servidor correspondientes.

⚠️ Allow invalid certificate en Email > General settings no debería activarse como solución rápida. Es preferible corregir en el servidor de correo o en la cadena de confianza un certificado caducado, no fiable o que no coincide con el nombre del servidor.

Si el firewall utiliza Mail Protection en MTA Mode, el certificado empleado para enviar correo depende además de la configuración de Email > General settings. Por tanto, no debe modificarse de forma aislada sin tener en cuenta el flujo de correo productivo.

Gmail y Microsoft 365 con OAuth 2.0

Para Gmail y Microsoft 365, la ayuda actual de SFOS 22 exige OAuth 2.0. Para ello, en Notification settings se introducen Provider, Client ID, Client secret y Refresh token. Aunque la ayuda general de Sophos indica que el Client secret es opcional para Microsoft 365, el procedimiento para Microsoft 365 documentado por Sophos crea y utiliza uno expresamente. Por eso también se configura para este procedimiento.

En Gmail hay que configurar un proyecto y la Gmail API en Google Cloud, así como generar un cliente OAuth y un Refresh Token. Sophos detalla los pasos actuales en Configure OAuth 2.0 on Gmail.

Google no considera que un proyecto OAuth con User type External y Publishing status Testing sea una configuración productiva permanente: al utilizar el scope de Gmail, el Refresh Token caduca al cabo de siete días según Google OAuth 2.0. El scope de Gmail https://mail.google.com utilizado por Sophos permite, además de enviar, leer, crear y eliminar permanentemente correos electrónicos. Por eso la aplicación OAuth, las credenciales y una cuenta de envío preferiblemente dedicada deben protegerse y administrarse igual que una contraseña de servidor de correo.

En Microsoft 365, la aplicación necesita los permisos delegados SMTP.Send y offline_access; Authenticated SMTP debe estar activado para la cuenta remitente. La vía estándar documentada utiliza smtp.office365.com, el puerto 587 y STARTTLS. Si la dirección del remitente difiere del buzón autenticado, la cuenta necesita además Send As. Los pasos actuales de Entra se describen en Configure OAuth 2.0 on Microsoft 365.

Microsoft Security Defaults desactiva SMTP AUTH. Esta medida de protección no debería desactivarse de forma general para todo el tenant solo para que un firewall pueda enviar mensajes. Si la autorización específica para la cuenta remitente no encaja con el modelo de seguridad, la vía más limpia es un relay interno o externo previsto para este fin.

⚠️ Sophos sigue incluyendo NC-166854 en la Known Issues list actual: OAuth de Microsoft 365 para Notifications no funciona en los builds allí indicados 22.0.0.274, 22.0.0.323, 21.0.2.349 y 21.5.1.261. No se especifica una versión corregida. Por eso hay que comprobar el build exacto de SFOS y exigir que el correo de prueba se entregue correctamente. Que los campos Client ID, Secret y Token se hayan guardado todavía no demuestra que funcione.

Si un build indicado está afectado, se utiliza un relay SMTP compatible u otra ruta de correo verificada hasta que exista una confirmación fiable de un firmware corregido. Las excepciones TLS inseguras o una Basic Authentication no verificada no son un buen sustituto de una ruta de alertas funcional.

Seleccionar eventos en Notification list

Después de una prueba de correo correcta, se abre System services > Notification list. Allí se activa primero Email notifications, después se marcan las casillas de la columna Email para los eventos necesarios y se guarda con Save.

No todos los firewalls necesitan la misma selección. Una base razonable se orienta a los riesgos y a las funciones realmente utilizadas:

• Admin: inicios de sesión fallidos y demasiados intentos de inicio de sesión fallidos.
• HA: puertos o interfaces supervisados desconectados cuando se utiliza un clúster HA.
• Disk/Memory: advertencias de almacenamiento para que un área de informes o del sistema llena no se descubra por primera vez durante la ventana de mantenimiento. Comprobar el almacenamiento y los informes en Sophos Firewall explica los umbrales y las consecuencias.
• Firmware: firmware nuevo y, sobre todo, instalaciones fallidas de acuerdo con el proceso de actualización propio.
• System: actualizaciones fallidas de firmas o bases de datos, inicio del sistema, uso elevado de CPU y Gateway status.
• IPS y Active threat response: empezar por eventos críticos o de bloqueo cuando exista un proceso de triaje.
• RED, AP y VPN: solo para dispositivos realmente utilizados y conexiones importantes.
• Web - Instant alerts: categorías web seleccionadas de forma consciente. Estos mensajes se envían en lotes de cinco minutos y necesitan una activación separada de la categoría, tal como se describe en Web Categories e Instant Alerts.

Activar todos los eventos de forma indiscriminada genera rápidamente fatiga de alertas. En particular, las notificaciones VPN pueden repetirse aproximadamente cada 60 segundos hasta que se resuelva la causa; si existen varias redes locales y remotas, también puede generarse un mensaje por cada par de subredes. Es mejor una selección pequeña con una reacción clara: quién recibe la alerta, qué urgencia tiene y cuál es el primer paso de comprobación.

El firewall envía automáticamente algunas Default Notifications y no permite desmarcarlas. Entre ellas se encuentran determinados cambios de rol y estado de HA, el estado de hosts virtuales y los reinicios o apagados mediante WebAdmin. También para estos mensajes debe estar disponible la ruta de correo configurada.

Comprobar el correo de prueba y un evento real

La comprobación consta de dos etapas.

1. Confirmar la entrega SMTP con un correo de prueba

Enviar el correo de prueba en Administration > Notification settings. El mensaje de éxito del firewall todavía no basta: el buzón de destino, el filtro de spam o el seguimiento del servidor de correo debe mostrar que el mensaje se ha aceptado y entregado realmente.

Se comprueba lo siguiente:

• El remitente y el destinatario son correctos.
• El firewall esperado puede identificarse mediante el asunto, el contenido o la IP de gestión.
• El mensaje no permanece en spam o cuarentena.
• La lista de distribución acepta los mensajes del remitente configurado.

2. Probar toda la cadena de eventos

Después se provoca de forma controlada un evento seleccionado. Algunos ejemplos adecuados son:

• un único inicio de sesión fallido con una cuenta de prueba, después de comprobar los bloqueos y umbrales de inicio de sesión;
• el estado Up/Down de un túnel VPN de prueba destinado expresamente a ello;
• Gateway status durante una prueba de failover WAN planificada.

Reiniciar o desconectar un gateway productivo, un puerto HA o el propio firewall solo para comprobar un correo electrónico sería desproporcionado. Una situación de mantenimiento o failover ya planificada es una prueba mejor.

La cadena completa solo queda confirmada cuando el evento llega al destinatario correcto en el tiempo esperado: detección del evento, selección del evento, interruptor global de correo, transporte SMTP y entrega.

Delimitar errores de forma sistemática

El correo de prueba ya falla

La API de SFOS 22 distingue varias clases de error:

• Failed to connect o SMTP server failed to respond: comprobar la resolución FQDN, la ruta, el puerto, el firewall precedente y el listener del servidor de correo.
• Password mismatch: comprobar el nombre de usuario, las mayúsculas y minúsculas, la contraseña y, si procede, si la cuenta está bloqueada.
• Authentication method mismatch: comprobar si el relay y SFOS admiten conjuntamente LOGIN o PLAIN con Basic Authentication.
• STARTTLS not supported: el puerto y Connection security no coinciden con el listener del servidor.
• Mail server refused to communicate: comprobar la autorización del relay, la dirección del remitente, la IP de origen permitida y los logs del servidor de correo.
• Couldn’t generate the OAuth 2.0 access token: comprobar Provider, Client ID, Secret, Refresh Token, permisos y hora del sistema.

Desde un sistema de administración con una ruta de red comparable se pueden comprobar previamente DNS y STARTTLS sin modificar el servidor de correo:

nslookup smtp.example.net
openssl s_client -starttls smtp -connect smtp.example.net:587 -servername smtp.example.net

Se sustituyen smtp.example.net y 587 por el servidor y el puerto propios. nslookup solo confirma la resolución de nombres del sistema de administración. openssl s_client muestra la disponibilidad SMTP, el handshake TLS y la cadena de certificados, pero no comprueba la ruta desde la perspectiva del firewall, su inicio de sesión ni la entrega posterior.

En Log Viewer y, para un análisis más profundo, en cschelper.log, el momento de la prueba puede correlacionarse con el correo generado por el sistema. El acceso a los logs de servicios y la delimitación respecto a Advanced Shell se describen en Servicios y logs de Sophos Firewall. Los logs MTA como smtpd_main.log pertenecen principalmente a Mail Protection y no son de forma general el log de Notifications.

El correo de prueba llega, pero faltan correos de eventos

En ese caso el transporte funciona y la búsqueda comienza en System services > Notification list:

1. ¿Está activado globalmente Email notifications?
2. ¿Está seleccionado el evento concreto en la columna Email?
3. ¿Ha ocurrido realmente el evento esperado y corresponde a la categoría correcta?
4. ¿Existe un retraso o agrupación conocidos, por ejemplo con Web Instant Alerts?
5. ¿Muestran el filtro de spam, la cuarentena o el seguimiento del servidor de correo una aceptación o un rechazo?

Para un evento especializado concreto también debe comprobarse su condición funcional. Por ejemplo, una alerta IPS no se produce únicamente por una casilla activada, sino cuando una regla IPS adecuada registra y descarta el evento. Una notificación VPN depende del tipo de túnel y del estado Up/Down real.

Microsoft 365 OAuth guarda, pero no envía

Primero se compara la versión y el build de SFOS con NC-166854. Después se comprueban Client ID, Client secret, Refresh token, SMTP.Send, offline_access, Authenticated SMTP para la cuenta remitente y la hora correcta del sistema.

Si el correo de prueba sigue fallando en un build que no figura como afectado, no se trata automáticamente del mismo error. El mensaje exacto, el build de SFOS y los logs de inicio de sesión del proveedor deben incluirse en el análisis posterior o en un ticket de soporte.

Operar las notificaciones

• Mantener el destinatario como lista de distribución funcional con un responsable definido.
• Volver a comprobar el correo de prueba y un evento real después de modificar el servidor de correo, DNS, routing, el certificado, las credenciales, la aplicación OAuth o el firmware.
• Probar la ruta completa de alertas al menos trimestralmente si ningún sistema de monitorización central la supervisa continuamente.
• Documentar la caducidad y la rotación de contraseñas, Client Secrets y Tokens.
• Adaptar periódicamente la selección de eventos a funciones nuevas y servicios desactivados.
• Definir para cada alerta importante un primer paso de comprobación y una vía de escalado.

El correo electrónico es un buen canal de alerta directo, pero no sustituye el almacenamiento central de logs ni su correlación. Para disponer de un historial más largo y realizar evaluaciones de seguridad, puede utilizarse Enviar Syslog de Sophos Firewall a un SIEM. Para la monitorización clásica del estado y los traps, Monitorización de hardware mediante SNMP es el complemento adecuado.