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.

El resumen de cuarentena para usuarios también utiliza este transporte, pero su horario, enlace al portal y asignación de usuarios son ajustes independientes.

Los textos visibles de autenticación, SMTP, administración y SMS en Administration > Messages constituyen una tercera capa independiente. Configurar el aviso de inicio de sesión y los mensajes en Sophos Firewall explica su contenido y sus pruebas; cambiar un mensaje no configura ni el transporte SMTP ni la selección de eventos.

La vía rápida:

Configurar el servidor de correo, el puerto, la autenticación, el cifrado, el remitente y el destinatario en Administration > Notification settings.
Enviar un correo de prueba y confirmar su entrega en el buzón de destino o en el seguimiento del servidor de correo.
Activar el interruptor global Email notifications en System services > Notification list.
Seleccionar únicamente los eventos ante los que pueda reaccionar un destinatario responsable.
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.

Si WebAdmin no está disponible o hay que corregir la dirección del destinatario mediante un acceso controlado a la CLI, abrir 2. System Configuration > 3. Set Email ID for system notification desde el Main Menu de la CLI. System Configuration es la opción 2 del Main Menu, no un submenú de Device Console (opción 4). Si ya se está en la opción 4, volver primero al Main Menu y seleccionar allí la opción 2. Esta opción solo cambia la dirección de correo del administrador para las alertas del sistema. No configura el servidor, el remitente, la autenticación y TLS ni el interruptor global y los eventos de la Notification list.

Primero se documenta la dirección anterior. Después se confirma el cambio con y, se introduce la nueva dirección y se comprueba que la dirección mostrada por SFOS no contiene errores. Enter vuelve al menú. A continuación, un correo de prueba y un evento real controlado deben llegar al nuevo destinatario; la confirmación de la consola por sí sola no demuestra la entrega.

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.

Antes de realizar cambios, anote la opción de servidor de correo seleccionada, el servidor, el puerto, Authentication, Connection security, el remitente, el destinatario, la interfaz de administración y los eventos seleccionados. Si el cambio afecta a los certificados, anote también la selección actual en Administration > Notification settings o Email > General settings, según corresponda. Compruebe que las credenciales y los tokens OAuth necesarios estén disponibles en un gestor seguro de contraseñas o secretos; no los incluya en capturas de pantalla sin proteger. Esta información permite restaurar la configuración anterior si la nueva ruta de correo no supera la prueba de entrega.

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.

Las interfaces físicas, bridge y LAG solo aparecen en el desplegable si tienen una dirección IP asignada. Si falta una interfaz, este requisito explica su ausencia; no se deben asignar direcciones IP ni modificar interfaces o rutas únicamente para añadir identificación a un mensaje.

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 este breve procedimiento:

Activar el Built-in email server en Administration > Notification settings.
Introducir el remitente, el destinatario y, opcionalmente, Management interface IP address.
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

Abrir Administration > Notification settings.
Seleccionar External email server.
Introducir la dirección IPv4 o el FQDN del servidor de correo y el puerto indicado.
En Authentication, seleccionar None, Basic u OAuth 2.0 según el servidor.
En Connection security, configurar el cifrado de transporte exigido por el servidor de correo.
Introducir el remitente, el destinatario y, opcionalmente, Management interface IP address.
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. 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.

El certificado que utiliza SFOS también depende del modo de correo. Con STARTTLS en MTA Mode, el firewall utiliza el certificado definido en Email > General settings. En Legacy Mode, se puede seleccionar un certificado para STARTTLS directamente en Administration > Notification settings; si no se selecciona ninguno, SFOS también utiliza el certificado de Email > General settings. Con SSL/TLS utiliza el certificado de Email > General settings. Por tanto, no cambie un certificado de forma aislada sin tener en cuenta el flujo de correo de producción.

Gmail y Microsoft 365 con OAuth 2.0

Para Gmail y Microsoft 365, en SFOS 22 y 23 se debe seleccionar OAuth 2.0. Para ello, en Notification settings se introducen Provider, Client ID, Client secret y Refresh token. El campo Client secret es opcional para Microsoft 365; sin embargo, el procedimiento para Microsoft 365 descrito aquí crea y utiliza expresamente un secreto. 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. El procedimiento siguiente describe estos pasos. Google y Microsoft modifican sus portales y requisitos independientemente de SFOS; por eso, antes de configurar el servicio para producción, hay que comprobar los requisitos actuales del proveedor y los permisos de la cuenta remitente prevista.

Configurar Gmail OAuth 2.0 paso a paso

Antes de generar el Refresh Token, comprobar la cuenta remitente prevista, el cliente OAuth, la Redirect URI y el scope de Gmail con amplios permisos descrito más abajo. Para el procedimiento siguiente con User type: External, también debe estar autorizada la puesta en producción de la aplicación OAuth. Publish App no sustituye ni la verificación exigida por el proveedor ni la aprobación del administrador responsable de Google Workspace o de seguridad. Si la publicación no está permitida por los requisitos actuales de Google o las políticas propias, no eludir esas medidas de protección: utilizar un relay SMTP autorizado para disponer de una ruta de alertas duradera.

Iniciar sesión en Google Cloud Console con la cuenta de Google prevista, crear un proyecto nuevo y seleccionarlo.
Abrir APIs & Services > Library, buscar Gmail API y activar la API.
En APIs & Services > Credentials, hacer clic en Create credentials > OAuth client ID.
Si antes se solicita la pantalla de consentimiento, abrir Configure the OAuth consent screen > Get started. Introducir el nombre de la aplicación y la dirección de correo, seleccionar User type: External, añadir la dirección de contacto del desarrollador y crear la configuración.
Seleccionar Create OAuth client, establecer Application type: Web application y asignar un nombre inequívoco.
En Authorized redirect URIs, añadir exactamente https://developers.google.com/oauthplayground.
Crear el cliente OAuth y guardar inmediatamente de forma segura el Client ID y el Client secret.
En Audience, comprobar la cuenta remitente prevista y el estado actual de publicación. Mientras la aplicación esté en Testing, añadir la cuenta como usuario de prueba en Add users. Esta lista de usuarios de prueba no restringe el acceso a una aplicación externa una vez publicada.
Tras obtener la aprobación necesaria, ejecutar Publish App y comprobar que Publishing status ha cambiado de Testing a In production. Una aplicación externa queda entonces, en principio, disponible para que la autoricen cuentas de Google que no figuran en la lista de usuarios de prueba; siguen siendo aplicables las políticas de las cuentas y de la organización. Solo después se genera el Refresh Token. En este procedimiento de Gmail, un token generado antes de la publicación caduca al cabo de siete días; para un funcionamiento continuado, generar un nuevo Refresh Token después de publicar en lugar de seguir utilizando el anterior.
Abrir Google OAuth 2.0 Playground. Activar Use your own OAuth credentials mediante el icono de engranaje e introducir el Client ID y el Client secret.
En Step 1 Select & authorize APIs, desplegar Gmail API v1, seleccionar el scope https://mail.google.com e iniciar Authorize APIs. Utilizar la cuenta remitente prevista y, antes de dar el consentimiento, comparar la aplicación mostrada y sus permisos con la configuración aprobada. Si hay diferencias, cancelar y revisar la configuración.
En Step 2 Exchange authorization code for tokens, intercambiar el código por tokens y copiar de forma segura el Refresh token. El Client secret, el Authorization Code, el Access token y el Refresh token no deben incluirse en tickets, capturas sin protección ni logs.
En el firewall, en Administration > Notification settings, configurar el External email server con Authentication: OAuth 2.0 y Provider: Gmail. Introducir el Client ID, el Client secret y el Refresh token, guardar y enviar un correo de prueba. Confirmar la entrega real en el buzón de destino o en el seguimiento del servidor de correo; que los campos OAuth se hayan guardado no demuestra por sí solo que la ruta de correo funcione.

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 aquí 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. El procedimiento completo de Entra aparece justo a continuación.

Configurar Microsoft 365 OAuth 2.0 paso a paso

En Microsoft Entra admin center, crear una New registration en Identity > Applications > App registrations.
Asignar un nombre inequívoco. Para este procedimiento, seleccionar Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant). En Redirect URI, seleccionar la plataforma Web e introducir https://outlook.office365.com/ como URI. Como alternativa, se puede utilizar http://localhost/. La URI registrada debe reutilizarse exactamente en la solicitud de autorización y en el intercambio de tokens; si se utiliza localhost, hay que sustituir el valor de redirect_uri por http://localhost/ en los dos ejemplos siguientes.
Registrar la aplicación y guardar de forma segura el Application (client) ID.
En API permissions > Add a permission, configurar el permiso SMTP delegado para el recurso de Outlook/Exchange y otorgar el consentimiento necesario. Microsoft documenta para ello el scope https://outlook.office.com/SMTP.Send; también se solicita offline_access para el Refresh Token. Lo decisivo es el permiso SMTP, no un permiso de Graph como Mail.Send. Comprobar la selección del recurso y los permisos mostrados con las instrucciones de Microsoft para SMTP con OAuth antes de crear el token. Si falta el permiso adecuado, no continuar con otro que parezca similar.
En Microsoft 365 admin center, comprobar la opción Authenticated SMTP para la cuenta remitente en Users > Active users > Mail > Email apps > Manage email apps y, si las políticas de seguridad lo permiten, activarla y guardar. Este ajuste del buzón no es el registro de la aplicación en Entra admin center.
En Certificates & secrets > Client secrets > New client secret, crear un secreto con una fecha de caducidad supervisada. Copiar inmediatamente de forma segura el Value mostrado; Entra deja de mostrarlo después de recargar la página.
Abrir la siguiente URL en un navegador. Sustituir YOUR_CLIENT_ID por el Application ID y YOUR_RANDOM_STATE por un valor aleatorio generado exclusivamente para esta operación; la redirect_uri debe coincidir con el registro de la aplicación. Codificar correctamente los valores de los parámetros para la URL. El valor de State debe devolverse sin cambios en la respuesta; un valor de ejemplo fijo no protege la operación. Las instrucciones de Microsoft sobre el flujo de código de autorización explican la comprobación de State y PKCE para los clientes compatibles.

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=YOUR_CLIENT_ID&response_type=code&redirect_uri=https://outlook.office365.com/&response_mode=query&scope=https://outlook.office365.com/.default+offline_access&state=YOUR_RANDOM_STATE

Iniciar sesión con la cuenta remitente prevista, comparar el valor de State devuelto con el valor guardado y obtener el código de autorización de corta duración de la URL de redirección solo si coinciden. Si no coinciden, cancelar y reiniciar el procedimiento.
Enviar el código con un cliente API como application/x-www-form-urlencoded al endpoint de token. Sustituir todos los marcadores por los valores de esta aplicación. El siguiente bloque muestra los campos en varias líneas para facilitar la lectura; en el cliente API se introducen como campos de formulario individuales para codificar correctamente los espacios y los caracteres especiales del código, el secreto y la Redirect URI. No es un comando de shell que pueda copiarse y ejecutarse sin cambios.

POST https://login.microsoftonline.com/common/oauth2/v2.0/token

client_id=YOUR_CLIENT_ID
&scope=https://outlook.office365.com/.default offline_access
&code=YOUR_AUTHORIZATION_CODE
&redirect_uri=https://outlook.office365.com/
&grant_type=authorization_code
&client_secret=YOUR_CLIENT_SECRET

Guardar inmediatamente de forma segura el Refresh token devuelto. El código de autorización, el Client secret, el Access token y el Refresh token no deben incluirse en tickets, capturas sin protección ni logs.
En el firewall, configurar el External email server en Administration > Notification settings con Authentication: OAuth 2.0 y Provider: Microsoft 365. Introducir smtp.office365.com, el puerto 587, STARTTLS, Client ID, Client secret y Refresh token, guardar y enviar un correo de prueba.

Para este procedimiento de generación del token, el sistema que ejecuta el cliente API y el firewall deben utilizar la misma zona horaria. Comprobar antes la hora del sistema y la zona horaria. La zona horaria del firewall no debe cambiarse de forma improvisada en producción; el reinicio necesario después del cambio debe realizarse en una ventana de mantenimiento.

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.

⚠️ El error conocido NC-166854 afecta a OAuth de Microsoft 365 para Notifications en los builds de SFOS 22.0.0.274, 22.0.0.323, 21.0.2.349 y 21.5.1.261. Esto no permite concluir que todos los demás builds funcionen ni que siga sin haber una corrección disponible. Antes de poner en servicio esta ruta de correo, hay que comprobar el build exacto de SFOS y el estado del error y de su corrección para ese build, 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.

El correo electrónico y SNMP son canales de salida independientes. Para los traps, también hay que configurar el agente SNMP y las comunidades o usuarios correspondientes en Administration > SNMP. Después, activar el interruptor global SNMP traps y las casillas de eventos disponibles para SNMP en Notification list, y guardar. Seleccionar el correo electrónico no activa los traps; para cada evento se puede elegir correo electrónico, SNMP o ambos canales disponibles. El artículo sobre SNMP enlazado más abajo explica la configuración y las pruebas del gestor SNMP.

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 listo para instalar, firmware instalado correctamente e instalaciones fallidas de acuerdo con el proceso de actualización propio.
Solo SFOS 23 – Firmware > Security updates: En System services > Notification list, activar la columna Email para Security updates. Siguen siendo necesarios el interruptor global Email notifications y una ruta SMTP funcional. Las actualizaciones de seguridad mediante hotfix no disponen de notificaciones SNMP; esta limitación no se aplica de forma general a todos los hotfixes ni a todos los eventos de firmware. No se garantiza la entrega inmediata, y la ausencia de correo no demuestra ni éxito ni fallo. Comprobar las actualizaciones aplicadas mediante el procedimiento de verificación de hotfixes de SFOS 23.
System: actualizaciones fallidas de la base de datos WebCat, las firmas IPS y las definiciones antivirus, inicio o reinicio del sistema, uso elevado de CPU y Gateway status.
IPS: se pueden seleccionar los niveles Critical, Major, Moderate, Minor y Warning. La alerta requiere que el firewall registre el evento IPS y descarte el paquete. Para empezar, conviene seleccionar eventos críticos con un proceso de triaje definido.
Active threat response: los eventos de registro y descarte para MDR, NDR Essentials, Sophos X-Ops y feeds de amenazas de terceros se seleccionan por separado. Los tipos de coincidencia y las restricciones se explican en el apartado siguiente.
RED: pérdida de conexión, fallo de actualización de firmware, desautorización automática del dispositivo o nuevo Unlock Code. AP: punto de acceso desconectado o fallo de actualización de firmware. Seleccionar únicamente notificaciones de dispositivos realmente utilizados y asignar un destinatario responsable.
VPN: túneles IPsec up, down y failover/failback, así como conexiones SSL VPN establecidas o desconectadas. Las condiciones de activación de IPsec explicadas más abajo son más limitadas que esta lista general; la selección no garantiza una notificación para cada cambio manual de estado del túnel.
Virus: seleccionar alertas para HTTP, FTP, SMTP, POP3 e IMAP4 según las funciones de protección realmente utilizadas. La casilla no sustituye ni la inspección correspondiente ni su detección de eventos.
Web - Instant alerts: categorías web seleccionadas de forma consciente. Estos mensajes se envían en lotes fijos de cinco minutos que no se pueden modificar 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: cambios de rol HA desde Standalone, Primary o Auxiliary, estado faulty de dispositivos HA, hosts virtuales up/down, y reinicios o apagados mediante WebAdmin. También para estos mensajes debe estar disponible la ruta de correo configurada. Que la categoría de eventos no pueda desmarcarse no garantiza que un mensaje llegue a un buzón inaccesible.

Active threat response: distinguir la coincidencia y el canal

Para cada uno de los siguientes tipos de coincidencia existen un Log event y un Drop event:

Destination match for all traffic: la dirección de destino coincide con una entrada de un feed de amenazas.
Remote source match for inbound traffic: la dirección de origen remota del tráfico entrante coincide con una entrada del feed.
Local source match for outbound traffic: la dirección de origen local del tráfico saliente coincide con una entrada del feed.

Una alerta de registro por sí sola no demuestra un bloqueo. A su vez, un evento de descarte depende de la coincidencia real y de la configuración correspondiente de Active threat response; la casilla de correo electrónico no genera ni una coincidencia ni una regla de protección nueva.

La ayuda de notificaciones de Sophos indica que Sophos X-Ops no admite coincidencias de origen local ni remoto. Sin embargo, existe la contradicción con la matriz de tráfico SVG documentada en el artículo sobre NDR/ATR, especialmente respecto a la coincidencia de origen local. Por tanto, la opción de correo no demuestra un comportamiento concreto de coincidencia de X-Ops ni resuelve esta contradicción; los casos discutidos deben aclararse por separado antes de utilizarlos como requisito de protección. Las alertas de coincidencia de origen remoto no se reenvían al servicio central de Sophos, pero sus registros son visibles en Central Firewall Reporting (CFR). El nombre del servicio central varía entre versiones (Sophos Central o Sophos Fusion); esto no implica una ampliación del reenvío de alertas. Por eso, para estos eventos se comprueba la ruta local de correo y registros, en lugar de confiar únicamente en la visualización central de alertas.

Interpretar las condiciones de activación y las repeticiones

Una casilla activada no significa que cada cambio breve de estado genere un correo. En SFOS 22.0 y 23.0, los siguientes eventos tienen estas condiciones:

Admin: Sign-in failed incluye credenciales incorrectas o una OTP (contraseña de un solo uso) incorrecta. Too many failed sign-in attempts se activa al alcanzar el número de intentos fallidos configurado en Administration > Admin and user settings > Login security. Este umbral explica la alerta; no es una instrucción para provocar el bloqueo de una cuenta.
High CPU usage: El primer registro de notificación solo se genera cuando el uso de CPU alcanza el 95 % y se mantiene de forma continua en el 95 % o por encima durante al menos 25 minutos. Se generan más registros cada 25 minutos hasta que el uso baja del 95 %. Por tanto, un pico breve sin correo de evento no demuestra un fallo de SMTP.
Gateway status: La selección del evento está activada de forma predeterminada. Para enviar mensajes también debe estar activado el interruptor global independiente Email notifications.

Para los eventos de disco, el uso debe mantenerse de forma continua en el umbral correspondiente o por encima durante al menos 50 segundos. Después, los registros y las notificaciones se repiten con la siguiente frecuencia predeterminada hasta que el uso baja del umbral:

Área	Umbral de notificación	Repetición
Almacenamiento de configuración	≥80 %	cada 50 segundos
Almacenamiento de firmas	≥90 %	cada 50 segundos
`/var`	≥80 %	cada 12 horas

En /var, el umbral inferior ya genera registros; las notificaciones solo empiezan en el umbral superior del 80 %. Si el uso supera el umbral superior y después baja del inferior, se registra la recuperación, pero no se envía ninguna notificación de recuperación. Esto es distinto del comportamiento de advertencia y detención de los informes explicado en el artículo de almacenamiento enlazado arriba; aquí, la ausencia de un correo de recuperación no es un fallo de entrega.

Para IPsec, el alcance documentado es más limitado que cualquier cambio Up/Down de VPN: las notificaciones solo se aplican a túneles host-to-host y site-to-site con las condiciones de desconexión descritas:

Dead peer detection (DPD).
Fallo al restablecer la conexión después de DPD.
La IPsec Security Association (SA) ha caducado y debe restablecerse.
Esta lista también incluye que el túnel vuelva a levantarse tras perder conectividad sin intervención del administrador.

Si se configura una descripción en los ajustes de la conexión IPsec, la notificación la incluye. Esto no garantiza notificaciones para cada desconexión manual ni para túneles de acceso remoto o SSL VPN.

Los tiempos de CPU describen la generación de registros de notificación y los intervalos de disco la repetición documentada, no una hora garantizada de llegada al buzón. Si falta un correo, primero se comparan la condición del evento, la marca de tiempo del registro y el seguimiento del servidor de correo. No se deben provocar saturaciones de CPU o disco, bloqueos de inicio de sesión, interrupciones de HA ni fallos de VPN en producción solo para probar una alerta.

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

Primero, comprobar la configuración de correo guardada en Administration > Notification settings y ejecutar la función de correo de prueba disponible en el build de SFOS utilizado. La ruta de prueba de informes es Reports > Show report settings > Report scheduling: seleccionar un informe, abrir Send test mail, introducir la dirección del destinatario de prueba y hacer clic en Send. Esta prueba de informes comprueba el transporte de correo, no la selección de eventos; su destinatario no es automáticamente el destinatario guardado para las alertas del sistema. 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. El contenido y la programación del informe se comprueban por separado, tal como se describe en el artículo sobre informes enlazado más abajo.

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;
un evento VPN documentado en un túnel de prueba destinado expresamente a ello, siempre que el tipo de túnel y la condición de activación coincidan con la notificación seleccionada; un cambio manual Up/Down de IPsec por sí solo no es una prueba fiable de alertas;
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:

¿Está activado globalmente Email notifications?
¿Está seleccionado el evento concreto en la columna Email?
¿Ha ocurrido realmente el evento esperado y corresponde a la categoría correcta?
¿Existe un retraso o agrupación conocidos, por ejemplo con Web Instant Alerts?
¿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 el evento y descarta el paquete. Una notificación VPN depende del tipo de túnel y del estado Up/Down real.

Gmail OAuth deja de funcionar tras cambiar la contraseña

En el procedimiento de notificaciones de Gmail descrito aquí, con el scope https://mail.google.com, el Refresh Token queda invalidado cuando se cambia la contraseña de la cuenta remitente de Gmail utilizada. El firewall ya no puede obtener un nuevo Access Token con ese token. Esto no significa que ocurra con todos los tokens OAuth de Google ni con Microsoft 365.

Comprobar si se ha cambiado la contraseña de esta cuenta remitente concreta. Comparar el cliente OAuth, la cuenta, los permisos aprobados y Publishing status: In production con la configuración documentada. Tampoco un token generado antes de Publish App sirve como base duradera después de siete días; comprobar ambas causas por separado.
Con el acceso actual a la cuenta y las credenciales del cliente OAuth propio, repetir la autorización de Gmail y el intercambio de tokens siguiendo el procedimiento de Playground descrito arriba. Comprobar la aplicación y los permisos solicitados antes de dar el consentimiento y guardar el nuevo Refresh Token de forma segura.
En Administration > Notification settings, con Provider: Gmail, sustituir el Refresh token invalidado por el nuevo y guardar. El Client ID y el Client secret deben corresponder al cliente OAuth utilizado; no modificar sin motivo los ajustes SMTP, TLS, de remitente, destinatario o eventos.
Enviar un correo de prueba y confirmar su entrega real en el buzón de destino o en el seguimiento del servidor de correo. Después, comprobar un evento seleccionado activado de forma controlada, como se describe en el apartado sobre toda la cadena de eventos.

Volver a introducir el token anterior no lo hace válido de nuevo. No restablecer la contraseña de la cuenta solo para recuperar la ruta de correo anterior. Si el envío sigue fallando tras repetir la autorización, anotar el mensaje de error exacto, el build de SFOS y la configuración del proveedor, sin secretos ni tokens, para continuar el análisis. Hasta confirmar la recuperación, utilizar una ruta alternativa de alertas autorizada o el relay SMTP documentado.

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

Si la entrega falla después de un cambio, restaure primero la configuración de correo anotada: opción de servidor, servidor, puerto, Authentication, Connection security, remitente, destinatario e interfaz de administración, además de la selección de certificado anterior si se modificó. Mantenga la selección de eventos si no formaba parte del cambio. Después de guardar, confirme de nuevo la ruta de alerta anterior mediante un correo de prueba y un evento seleccionado activado de forma controlada. La restauración solo termina cuando ambos mensajes han llegado realmente.

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.

La lista diaria de administración de Sophos Firewall resume qué señales de estado, seguridad y administración deben revisarse también de forma activa durante el funcionamiento.

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.

Para enviar análisis PDF a diario o semanalmente no se utiliza Notification list, sino una programación de informes independiente. Programar informes de Sophos Firewall y enviarlos por correo explica la selección, los bookmarks, la prueba de transporte y el control del contenido.

Cambiar la dirección del destinatario desde CLI Main Menu > 2. System Configuration