Configurar e testar notificações por e-mail no Sophos Firewall

Para que as notificações por e-mail funcionem, a Sophos Firewall precisa de duas configurações distintas: em Administration > Notification settings configura-se o transporte de e-mail. Em System services > Notification list define-se que eventos são efetivamente comunicados por e-mail.

O procedimento rápido:

Configurar servidor de e-mail, porta, autenticação, encriptação, remetente e destinatário em Administration > Notification settings.
Enviar uma mensagem de teste e confirmar a entrega na caixa de correio de destino ou no tracking do servidor de e-mail.
Ativar o switch global Email notifications em System services > Notification list.
Selecionar apenas os eventos aos quais um destinatário responsável possa reagir.
Além da mensagem de teste, acionar de forma controlada um evento real selecionado e verificar a respetiva entrega.

Uma mensagem de teste bem-sucedida comprova apenas que o caminho SMTP funciona, em princípio. Ainda não prova que o switch global de e-mail e os eventos corretos estão ativos. Inversamente, uma linha de evento selecionada não envia qualquer mensagem enquanto o transporte de e-mail não funcionar. Esta separação explica também por que motivo um servidor SMTP configurado, por si só, ainda não satisfaz operacionalmente o ponto Notification Emails do Sophos Firewall Health Check.

Preparar o envio de e-mail

Antes da configuração, deve confirmar-se com o administrador de e-mail responsável o servidor, a porta e o método de autenticação. Se for utilizado um FQDN como smtp.example.net, a firewall tem de o conseguir resolver e alcançar o servidor através do caminho de routing previsto. Só é necessária uma ligação geral à Internet se o servidor de e-mail ou o fornecedor OAuth selecionado estiver na Internet. Um relay SMTP interno também pode funcionar sem acesso direto da firewall à Internet.

Um exemplo 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: interface de gestão interna da firewall

Todos os valores com example.net devem ser substituídos pelo domínio próprio e pelos endereços autorizados pelo administrador de e-mail. Um endereço de distribuição costuma ser melhor do que uma caixa de correio pessoal: as responsabilidades podem ser alteradas sem reconfigurar cada firewall.

O campo Management interface IP address não controla a interface pela qual a ligação SMTP sai da firewall. O endereço IP selecionado é incluído na notificação e ajuda a identificar a firewall remetente. Em vários locais deve, por isso, escolher-se um IP de gestão permanentemente compreensível; com apenas uma firewall, None também pode ser suficiente.

Configurar o servidor de e-mail

Escolher Built-in ou External email server

A Sophos Firewall pode utilizar o Built-in email server ou um External email server. O envio integrado é prático para um início simples. Em ambientes de produção, um relay próprio ou um servidor de e-mail cloud é frequentemente mais rastreável, porque a autenticação, o tracking de mensagens, as autorizações de remetentes e os erros de entrega ficam visíveis num ponto central.

Por isso, recomendamos o External email server quando já existe um serviço SMTP operado de forma fiável.

Para o envio integrado, basta este procedimento curto:

Ativar o Built-in email server em Administration > Notification settings.
Introduzir remetente, destinatário e, opcionalmente, Management interface IP address.
Guardar e enviar a mensagem de teste.

O Built-in email server não dispõe de um tracking de relay próprio onde o administrador possa acompanhar a aceitação e o encaminhamento. Por isso, deve verificar-se a entrega efetiva com especial cuidado. Se falhar repetidamente ou se o domínio destinatário e os requisitos de segurança exigirem um caminho SMTP controlado, um External email server é a variante mais fácil de operar.

Configurar o External email server

Abrir Administration > Notification settings.
Selecionar External email server.
Introduzir o endereço IPv4 ou FQDN do servidor de e-mail e a porta indicada.
Em Authentication, selecionar None, Basic ou OAuth 2.0 de acordo com o servidor.
Em Connection security, definir a encriptação de transporte exigida pelo servidor de e-mail.
Introduzir remetente, destinatário e, opcionalmente, Management interface IP address.
Guardar e executar a função de mensagem de teste.

A porta predefinida no SFOS é 25, mas isso não constitui uma recomendação para todos os ambientes. O que conta é o listener do próprio relay. São comuns a porta 25 para um relay interno autorizado pelo Source IP, a 587 para submissão autenticada com STARTTLS ou a 465 para SSL/TLS direto. A porta, a autenticação e o modo de encriptação têm de corresponder, em conjunto, ao servidor de e-mail.

None não significa o mesmo nos dois campos de seleção: em Authentication, desativa a autenticação no servidor de e-mail. Isto pode ser correto para um relay interno que autorize exclusivamente o Source IP da firewall. Em Connection security, None significa, pelo contrário, uma transmissão SMTP não encriptada. Esta opção não é adequada para caminhos pela Internet e, mesmo internamente, só deve ser utilizada se o modelo de segurança o permitir expressamente.

Com Basic, a firewall utiliza um nome de utilizador e uma palavra-passe. Segundo a Sophos, o nome de utilizador é case-sensitive. O relay tem de suportar o método de autenticação utilizado; uma mensagem de erro relativa à Authentication method indica, em particular, uma diferença entre LOGIN e PLAIN.

STARTTLS é facilmente mal interpretado: a firewall segue a capacidade do servidor de e-mail. Se o servidor disponibilizar STARTTLS, a ligação é encriptada; se não o disponibilizar, a mensagem pode ser transmitida sem encriptação. Quando é obrigatório impor encriptação, utiliza-se SSL/TLS com a porta e o listener de servidor correspondentes.

⚠️ Allow invalid certificate em Email > General settings não deve ser ativado como solução rápida. É preferível corrigir no servidor de e-mail ou na cadeia de confiança um certificado expirado, não fidedigno ou que não corresponda ao nome do servidor.

Se a firewall utilizar Mail Protection em MTA Mode, o certificado utilizado para o envio de e-mail também depende da configuração em Email > General settings. Por isso, uma alteração não deve ser feita isoladamente sem considerar o fluxo de e-mail produtivo.

Gmail e Microsoft 365 com OAuth 2.0

Para Gmail e Microsoft 365, a ajuda atual do SFOS 22 exige OAuth 2.0. Para isso, em Notification settings são introduzidos Provider, Client ID, Client secret e Refresh token. Embora a ajuda geral da Sophos indique o Client secret como opcional para o Microsoft 365, o procedimento Microsoft 365 documentado pela Sophos cria e utiliza expressamente um. Por isso, este também é configurado nesse procedimento.

No Gmail, é necessário configurar um projeto e a Gmail API no Google Cloud, bem como criar o OAuth client e o Refresh Token. A Sophos apresenta os passos atuais em Configure OAuth 2.0 on Gmail.

O Google não trata um projeto OAuth com User type External e Publishing status Testing como configuração de produção permanente: ao utilizar o scope do Gmail, o Refresh Token expira após sete dias, segundo o Google OAuth 2.0. Além do envio, o scope do Gmail https://mail.google.com permite ler, criar e eliminar permanentemente mensagens de e-mail. Por isso, a aplicação OAuth, as credenciais e uma conta de envio tão dedicada quanto possível têm de ser protegidas e operadas com o mesmo cuidado que uma palavra-passe de servidor de e-mail.

No Microsoft 365, a aplicação precisa das permissões delegadas SMTP.Send e offline_access; para a conta remetente, Authenticated SMTP tem de estar ativo. O procedimento padrão documentado utiliza smtp.office365.com, porta 587 e STARTTLS. Se o endereço remetente for diferente da caixa de correio autenticada, a conta precisa adicionalmente de Send As. Os passos atuais do Entra estão descritos em Configure OAuth 2.0 on Microsoft 365.

Os Microsoft Security Defaults desativam o SMTP AUTH. Esta proteção não deve ser desativada indiscriminadamente em todo o tenant apenas para permitir que uma firewall envie mensagens. Se a autorização específica da conta remetente não for compatível com o modelo de segurança, um relay interno ou externo destinado a esse fim é o caminho mais limpo.

⚠️ A Sophos continua a indicar NC-166854 na atual Known Issues list: o OAuth do Microsoft 365 para Notifications não funciona nos builds aí indicados, 22.0.0.274, 22.0.0.323, 21.0.2.349 e 21.5.1.261. Não é indicada uma versão de correção. Por isso, deve verificar-se o build exato do SFOS e exigir uma mensagem de teste bem-sucedida. Os campos Client ID, Secret e Token guardados ainda não constituem prova de funcionamento.

Se estiver em utilização um build afetado, deve usar-se um relay SMTP suportado ou outro caminho de e-mail verificado até que um firmware corrigido seja confirmado de forma fiável. Exceções TLS inseguras ou Basic Authentication não verificada não são um bom substituto para um caminho de alerta funcional.

Selecionar eventos na Notification list

Depois de um teste de e-mail bem-sucedido, abre-se System services > Notification list. Primeiro, ativar Email notifications, depois selecionar as checkboxes da coluna Email para os eventos necessários e guardar com Save.

Nem todas as firewalls precisam da mesma seleção. Uma base adequada orienta-se pelos riscos e pelas funções efetivamente utilizadas:

Admin: logins falhados e demasiadas tentativas de login falhadas.
HA: portas ou interfaces monitorizadas que ficaram desligadas, quando existe um cluster HA.
Disk/Memory: avisos de armazenamento, para que uma área de relatórios ou de sistema cheia não seja detetada apenas na janela de manutenção. Os limites e as consequências são explicados em Verificar armazenamento e relatórios na Sophos Firewall.
Firmware: novo firmware e, sobretudo, instalações falhadas de acordo com o processo de atualização próprio.
System: atualizações falhadas de assinaturas ou bases de dados, arranque do sistema, utilização elevada da CPU e Gateway status.
IPS e Active threat response: começar por eventos críticos ou de bloqueio, caso exista um processo de triagem.
RED, AP e VPN: apenas para equipamentos efetivamente utilizados e ligações importantes.
Web - Instant alerts: categorias da web selecionadas conscientemente. Estas mensagens são enviadas em lotes de cinco minutos e exigem uma ativação separada da categoria, conforme descrito em Categorias da web e alertas instantâneos.

Ativar indiscriminadamente todos os eventos gera rapidamente fadiga de alertas. As mensagens de VPN, em particular, podem repetir-se aproximadamente a cada 60 segundos até a causa ser corrigida; com várias redes locais e remotas, pode ainda ser gerada uma mensagem por cada par de sub-redes. É preferível uma pequena seleção com uma reação clara: quem recebe o alerta, qual é a urgência e qual é o primeiro passo de verificação?

Algumas Default Notifications são enviadas automaticamente pela firewall e não podem ser desmarcadas. Entre elas encontram-se determinadas alterações de função e estado de HA, o estado de hosts virtuais e o reinício ou shutdown através do WebAdmin. O caminho de e-mail configurado também tem de estar acessível para estas mensagens.

Verificar mensagem de teste e evento real

A verificação é composta por duas etapas.

1. Confirmar a entrega SMTP com uma mensagem de teste

Enviar a mensagem de teste em Administration > Notification settings. A mensagem de sucesso da firewall ainda não é suficiente: na caixa de correio de destino, no filtro de spam ou no tracking do servidor de e-mail tem de ser visível que a mensagem foi realmente aceite e entregue.

Deve verificar-se:

O remetente e o destinatário estão corretos.
A firewall esperada é identificável pelo assunto, conteúdo ou IP de gestão.
A mensagem não fica permanentemente no spam ou na quarentena.
A lista de distribuição aceita mensagens do remetente configurado.

2. Testar a cadeia completa do evento

Depois, acionar de forma controlada um evento selecionado. São adequados, por exemplo:

um único login falhado com uma conta de teste, depois de verificar bloqueios e limites de login;
o estado Up/Down de um túnel VPN de teste expressamente destinado a esse fim;
Gateway status durante um teste de failover WAN planeado.

Reiniciar ou desligar um gateway produtivo, uma porta HA ou a própria firewall apenas para testar um e-mail seria desproporcionado. Um cenário de manutenção ou failover já planeado é o melhor teste.

Só quando o evento chega ao destinatário correto dentro do tempo esperado é que toda a cadeia está confirmada: deteção do evento, seleção do evento, switch global de e-mail, transporte SMTP e entrega.

Isolar erros de forma sistemática

A mensagem de teste já falha

A API do SFOS 22 distingue várias classes de erro:

Failed to connect ou SMTP server failed to respond: verificar resolução do FQDN, rota, porta, firewall a montante e listener do servidor de e-mail.
Password mismatch: verificar nome de utilizador, maiúsculas/minúsculas, palavra-passe e, se aplicável, uma conta bloqueada.
Authentication method mismatch: verificar se o relay e o SFOS suportam em comum LOGIN ou PLAIN com Basic Authentication.
STARTTLS not supported: a porta e Connection security não correspondem ao listener do servidor.
Mail server refused to communicate: verificar autorização do relay, endereço remetente, Source IP permitido e logs do servidor de e-mail.
Couldn’t generate the OAuth 2.0 access token: verificar Provider, Client ID, Secret, Refresh Token, permissões e hora do sistema.

A partir de um sistema de administração num caminho de rede comparável, é possível verificar previamente DNS e STARTTLS sem alterar o servidor de e-mail:

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

smtp.example.net e 587 devem ser substituídos pelo servidor e porta próprios. nslookup confirma apenas a resolução de nomes do sistema de administração. openssl s_client mostra a acessibilidade SMTP, o handshake TLS e a cadeia de certificados, mas não verifica a rota do ponto de vista da firewall, a respetiva autenticação nem a entrega posterior.

No Log Viewer e, para uma análise mais aprofundada, em cschelper.log, o momento do teste pode ser correlacionado com o e-mail gerado pelo sistema. O acesso aos Service Logs e a distinção em relação à Advanced Shell são explicados em Serviços e logs da Sophos Firewall. Os logs MTA, como smtpd_main.log, pertencem principalmente à Mail Protection e não são, de forma geral, o log de Notifications.

A mensagem de teste chega, mas faltam mensagens de eventos

Nesse caso, o transporte funciona e a procura começa em System services > Notification list:

Email notifications está globalmente ativo?
O evento concreto está selecionado na coluna Email?
O evento esperado ocorreu realmente e corresponde à categoria correta?
Existe um atraso ou agrupamento conhecido, por exemplo nos Web Instant Alerts?
O filtro de spam, a quarentena ou o tracking do servidor de e-mail mostram uma aceitação ou rejeição?

Para um evento especial individual, deve também verificar-se a respetiva condição técnica. Um alerta IPS, por exemplo, não é gerado apenas por uma checkbox ativa, mas apenas quando uma regra IPS adequada regista e descarta o evento. Uma mensagem VPN depende do tipo de túnel e do estado Up/Down efetivo.

O OAuth do Microsoft 365 guarda, mas não envia

Primeiro, comparar a versão e o build do SFOS com NC-166854. Depois, verificar Client ID, Client secret, Refresh token, SMTP.Send, offline_access, Authenticated SMTP para a conta remetente e a hora correta do sistema.

Se a mensagem de teste continuar a falhar num build não indicado como afetado, não se trata automaticamente do mesmo erro. A mensagem exata, o build do SFOS e os logs de autenticação do fornecedor devem então fazer parte da análise seguinte ou de um ticket de suporte.

Operar as notificações

Manter os destinatários como lista de distribuição funcional com um Owner responsável.
Voltar a testar a mensagem de teste e um evento real após alterações ao servidor de e-mail, DNS, routing, certificado, credenciais, aplicação OAuth ou firmware.
Testar todo o caminho de alerta pelo menos trimestralmente, se nenhum sistema central de monitorização o supervisionar continuamente.
Documentar a expiração e a rotação de palavras-passe, Client Secrets e Tokens.
Adaptar regularmente a seleção de eventos a novas funções e serviços desativados.
Definir um primeiro passo de verificação e um caminho de escalamento para cada alerta importante.

O e-mail é um bom canal de alerta direto, mas não substitui a retenção ou correlação central de logs. Para um histórico mais longo e análise de segurança, consulte Enviar Syslog da Sophos Firewall para um SIEM. Para monitorização de estado clássica e traps, SNMP Hardware Monitoring é o complemento adequado.