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 resumo de quarentena para utilizadores também usa este transporte, mas o horário, o link do portal e a atribuição de contas são definições separadas.

Os textos visíveis de Authentication, SMTP, Admin e SMS em Administration > Messages constituem um terceiro nível separado. Configurar o aviso de início de sessão e as mensagens na Sophos Firewall explica o seu conteúdo e os testes; alterar uma mensagem não configura o transporte SMTP nem a seleção de eventos.

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.

Se o WebAdmin não estiver disponível ou for necessário corrigir o endereço do destinatário através de acesso controlado à CLI, abrir 2. System Configuration > 3. Set Email ID for system notification no Main Menu da CLI. System Configuration é a opção 2 do Main Menu, não um submenu da Device Console (opção 4). Se já estiver na opção 4, regressar primeiro ao Main Menu e selecionar aí a opção 2. Esta opção altera apenas o endereço de e-mail do administrador para alertas do sistema. Não configura o servidor, o remetente, a autenticação e TLS, nem o switch global e os eventos da Notification list.

Primeiro, documentar o endereço anterior. Depois, confirmar a alteração com y, introduzir o novo endereço e verificar se o endereço mostrado pelo SFOS contém erros. Premir Enter para regressar ao menu. Em seguida, uma mensagem de teste e um evento real controlado têm de chegar ao novo destinatário; a confirmação da consola, por si só, não comprova a entrega.

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.

Antes de qualquer alteração, registar a opção de servidor de e-mail selecionada, o servidor, a porta, Authentication, Connection security, o remetente, o destinatário, a interface de gestão e os eventos selecionados. Se a alteração abranger certificados, registar também a seleção atual em Administration > Notification settings ou Email > General settings, conforme aplicável. Confirmar que as credenciais e os tokens OAuth necessários estão disponíveis em segurança num gestor de palavras-passe ou de segredos; não os incluir em capturas de ecrã desprotegidas. Estas informações permitem restaurar a configuração anterior se a nova rota de e-mail não passar no teste de entrega.

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.

As interfaces físicas, bridge e LAG só aparecem na lista pendente se tiverem um endereço IP atribuído. Se faltar uma interface, este requisito explica a sua ausência; não se devem atribuir endereços IP nem alterar interfaces ou routing apenas para acrescentar identificação a uma mensagem.

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. O nome de utilizador distingue maiúsculas de minúsculas. 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.

O certificado utilizado pelo SFOS também depende do modo de e-mail. Com STARTTLS em MTA Mode, a firewall utiliza o certificado definido em Email > General settings. Em Legacy Mode, é possível selecionar um certificado para STARTTLS diretamente em Administration > Notification settings; sem seleção, o SFOS também utiliza o certificado de Email > General settings. Com SSL/TLS, utiliza o certificado de Email > General settings. Por isso, não se deve alterar um certificado isoladamente sem considerar o fluxo de e-mail produtivo.

Gmail e Microsoft 365 com OAuth 2.0

Para Gmail e Microsoft 365, deve selecionar-se OAuth 2.0 no SFOS 22 e 23. Para isso, em Notification settings são introduzidos Provider, Client ID, Client secret e Refresh token. O campo Client secret é opcional para o Microsoft 365; contudo, o procedimento Microsoft 365 aqui descrito cria e utiliza expressamente um secret. Por isso, este também é configurado neste procedimento.

No Gmail, é necessário configurar um projeto e a Gmail API no Google Cloud, bem como criar o cliente OAuth e o Refresh Token. O procedimento seguinte descreve estes passos. O Google e a Microsoft alteram os seus portais e requisitos independentemente do SFOS; por isso, antes de configurar um ambiente de produção, devem verificar-se os requisitos atuais dos fornecedores e as permissões da conta de envio prevista.

Configurar o Gmail OAuth 2.0 passo a passo

Antes de gerar o Refresh Token, verificar a conta de envio prevista, o cliente OAuth, a Redirect URI e o scope do Gmail com permissões alargadas descrito abaixo. Para o procedimento seguinte com User type: External, também tem de estar aprovada a utilização da aplicação OAuth em produção. Publish App não substitui a verificação exigida pelo fornecedor nem a aprovação do administrador responsável pelo Google Workspace ou pela segurança. Se a publicação não for permitida pelos requisitos atuais do Google ou pelas políticas internas, não contornar essas proteções: utilizar, em alternativa, um relay SMTP aprovado para garantir um caminho de alerta duradouro.

Iniciar sessão na Google Cloud Console com a conta Google prevista, criar um novo projeto e selecioná-lo.
Abrir APIs & Services > Library, procurar Gmail API e ativar a API.
Em APIs & Services > Credentials, clicar em Create credentials > OAuth client ID.
Se for pedido primeiro o ecrã de consentimento, abrir Configure the OAuth consent screen > Get started. Introduzir o nome da aplicação e o endereço de e-mail, selecionar User type: External, adicionar o endereço de contacto do programador e criar a configuração.
Selecionar Create OAuth client, definir Application type: Web application e atribuir um nome inequívoco.
Em Authorized redirect URIs, adicionar exatamente https://developers.google.com/oauthplayground.
Criar o cliente OAuth e guardar imediatamente o Client ID e o Client secret de forma segura.
Em Audience, verificar a conta de envio prevista e o estado atual da publicação. Enquanto a aplicação estiver em Testing, adicionar a conta como utilizador de teste em Add users. Esta lista de utilizadores de teste não restringe o acesso a uma aplicação externa depois de publicada.
Após obter a aprovação necessária, executar Publish App e confirmar que Publishing status passou de Testing para In production. Uma aplicação externa fica então, em princípio, disponível para ser autorizada por contas Google fora da lista de utilizadores de teste; continuam a aplicar-se as políticas das contas e da organização. Só depois gerar o Refresh Token. Neste procedimento do Gmail, um token gerado antes da publicação expira ao fim de sete dias; para uma utilização continuada, gerar por isso um novo Refresh Token após a publicação, em vez de continuar a utilizar o anterior.
Abrir o Google OAuth 2.0 Playground. Através do ícone de roda dentada, ativar Use your own OAuth credentials e introduzir o Client ID e o Client secret.
Em Step 1 Select & authorize APIs, expandir Gmail API v1, selecionar o scope https://mail.google.com e iniciar Authorize APIs. Utilizar a conta de envio prevista e, antes de dar consentimento, comparar a aplicação apresentada e as respetivas permissões com a configuração aprovada. Em caso de diferenças, interromper e verificar a configuração.
Em Step 2 Exchange authorization code for tokens, trocar o código por tokens e copiar o Refresh token de forma segura. O Client secret, o Authorization Code, o Access token e o Refresh token não devem constar de tickets, capturas de ecrã desprotegidas ou logs.
Na firewall, em Administration > Notification settings, configurar o External email server com Authentication: OAuth 2.0 e Provider: Gmail. Introduzir o Client ID, Client secret e Refresh token, guardar e enviar uma mensagem de teste. Confirmar a entrega efetiva na caixa de correio de destino ou no tracking do servidor de e-mail; os campos OAuth guardados, por si só, não comprovam que o caminho de e-mail funciona.

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. O procedimento Entra completo encontra-se imediatamente abaixo.

Configurar o Microsoft 365 OAuth 2.0 passo a passo

No Microsoft Entra admin center, criar um New registration em Identity > Applications > App registrations.
Atribuir um nome inequívoco. Para este procedimento, selecionar Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant). Em Redirect URI, selecionar a plataforma Web e introduzir https://outlook.office365.com/ como URI. Em alternativa, pode utilizar-se http://localhost/. A URI registada tem de ser reutilizada exatamente na sequência de autorização e na troca do código por tokens; se for utilizado localhost, substituir o valor de redirect_uri por http://localhost/ em ambos os exemplos seguintes.
Registar a aplicação e guardar o Application (client) ID de forma segura.
Em API permissions > Add a permission, configurar a permissão SMTP delegada para o recurso Outlook/Exchange e conceder o consentimento necessário. A Microsoft documenta para este efeito o scope https://outlook.office.com/SMTP.Send; solicita-se também offline_access para o Refresh Token. O requisito essencial é a permissão SMTP, não uma permissão do Graph como Mail.Send. Verificar o recurso selecionado e as permissões apresentadas de acordo com as instruções da Microsoft para SMTP com OAuth antes de criar o token. Se a permissão adequada não estiver disponível, não prosseguir com outra aparentemente semelhante.
No Microsoft 365 admin center, verificar a opção Authenticated SMTP para a conta de envio em Users > Active users > Mail > Email apps > Manage email apps e, se as políticas de segurança o permitirem, ativá-la e guardar. Esta opção da caixa de correio é distinta do registo da aplicação no Entra admin center.
Em Certificates & secrets > Client secrets > New client secret, criar um secret com data de expiração monitorizada. Copiar imediatamente o Value apresentado de forma segura; o Entra deixa de o mostrar depois de recarregar a página.
Abrir o URL seguinte num browser. Substituir YOUR_CLIENT_ID pelo Application ID e YOUR_RANDOM_STATE por um valor aleatório gerado exclusivamente para esta operação; o redirect_uri tem de corresponder ao registo da aplicação. Aplicar corretamente a codificação URL aos valores dos parâmetros. O valor de State tem de ser devolvido sem alterações na resposta; um valor de exemplo fixo não protege a operação. As instruções da Microsoft para o fluxo de código de autorização explicam a verificação de State e o PKCE para clientes adequados.

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 sessão com a conta de envio prevista, comparar o valor de State devolvido com o valor guardado e só recolher o código de autorização de curta duração do URL de redirecionamento se os valores coincidirem. Se forem diferentes, interromper e reiniciar o procedimento.
Enviar o código com um cliente API como application/x-www-form-urlencoded para o endpoint de token. Substituir todos os marcadores pelos valores desta aplicação. O bloco seguinte apresenta os campos em várias linhas para facilitar a leitura; no cliente API, devem ser introduzidos como campos de formulário individuais, para que os espaços e os caracteres especiais no código, no Secret e no Redirect URI sejam corretamente codificados. Não se trata de um comando de shell que possa ser copiado e executado sem alterações.

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 imediatamente o Refresh token devolvido de forma segura. O código de autorização, Client secret, Access token e Refresh token não devem ser incluídos em tickets, capturas de ecrã desprotegidas ou logs.
Na firewall, configurar o External email server em Administration > Notification settings com Authentication: OAuth 2.0 e Provider: Microsoft 365. Introduzir smtp.office365.com, porta 587, STARTTLS, Client ID, Client secret e Refresh token, guardar e enviar um e-mail de teste.

Para este procedimento de criação do token, o sistema que executa o cliente API e a firewall têm de utilizar o mesmo fuso horário. Verificar primeiro a hora do sistema e o fuso horário. O fuso horário da firewall não deve ser alterado espontaneamente em produção; o reinício necessário após essa alteração deve ser planeado numa janela de manutenção.

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.

⚠️ O erro conhecido NC-166854 afeta o OAuth do Microsoft 365 para Notifications nos builds do SFOS 22.0.0.274, 22.0.0.323, 21.0.2.349 e 21.5.1.261. Isto não permite concluir que todos os outros builds funcionam, nem que entretanto não tenha sido disponibilizada uma correção. Antes da entrada em produção, verificar o build exato do SFOS e o estado do erro ou da correção aplicável a esse build, 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.

O e-mail e o SNMP são canais de saída separados. Para os traps, é também necessário configurar o agente SNMP e as comunidades ou os utilizadores adequados em Administration > SNMP. Depois, na Notification list, ativar o interruptor global SNMP traps e as checkboxes de eventos disponíveis para SNMP, e guardar. Selecionar e-mail não ativa os traps; para cada evento, pode escolher-se e-mail, SNMP ou ambos os canais disponíveis. O artigo sobre SNMP ligado abaixo explica a configuração e a verificação do gestor SNMP.

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 pronto para instalação, firmware instalado com sucesso e instalações falhadas, de acordo com o processo de atualização próprio.
Apenas SFOS 23 – Firmware > Security updates: Em System services > Notification list, ativar a coluna Email para Security updates. O interruptor global Email notifications e um caminho SMTP funcional continuam a ser necessários. Não existem notificações SNMP para atualizações de segurança por hotfix; esta limitação não se aplica indiscriminadamente a todos os hotfixes ou eventos de firmware. A entrega imediata não é garantida, e a ausência de email não comprova sucesso nem falha. Verificar as atualizações aplicadas através do procedimento de verificação de hotfixes do SFOS 23.
System: atualizações falhadas da base de dados WebCat, das assinaturas IPS e das definições de antivírus, arranque ou reinício do sistema, utilização elevada da CPU e Gateway status.
IPS: podem selecionar-se os níveis Critical, Major, Moderate, Minor e Warning. O alerta exige que a firewall registe o evento IPS e descarte o pacote. Para começar, são adequados eventos críticos com um processo de triagem definido.
Active threat response: os eventos de registo e de descarte para MDR, NDR Essentials, Sophos X-Ops e feeds de ameaças de terceiros são selecionados separadamente. Os tipos de correspondência e as limitações são descritos na secção seguinte.
RED: falha de ligação, falha de atualização de firmware, desautorização automática do dispositivo ou novo Unlock Code. AP: ponto de acesso offline ou falha de atualização de firmware. Selecionar apenas notificações de equipamentos efetivamente utilizados e definir um destinatário responsável.
VPN: túneis IPsec up, down e failover/failback, e ligações SSL VPN estabelecidas ou terminadas. As condições de ativação de IPsec explicadas abaixo são mais restritas do que esta lista geral; a seleção não garante uma notificação para cada alteração manual do estado de um túnel.
Virus: selecionar alertas para HTTP, FTP, SMTP, POP3 e IMAP4 de acordo com as funções de proteção efetivamente utilizadas. A checkbox não substitui a inspeção correspondente nem a respetiva deteção de eventos.
Web - Instant alerts: categorias da web selecionadas conscientemente. Estas mensagens são enviadas em lotes com intervalos fixos de cinco minutos, que não podem ser alterados, 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: alterações de função HA de Standalone, Primary ou Auxiliary, estado faulty de dispositivos HA, hosts virtuais up/down e reinício ou encerramento através do WebAdmin. O caminho de e-mail configurado também tem de estar acessível para estas mensagens. Uma categoria de eventos que não possa ser desmarcada não garante que uma mensagem chegue a uma caixa de correio inacessível.

Active threat response: distinguir correspondência e canal

Para cada um dos tipos de correspondência seguintes, existe um Log event e um Drop event:

Destination match for all traffic: o endereço de destino corresponde a uma entrada de um feed de ameaças.
Remote source match for inbound traffic: o endereço de origem remoto do tráfego de entrada corresponde a uma entrada.
Local source match for outbound traffic: o endereço de origem local do tráfego de saída corresponde a uma entrada.

Um alerta de registo, por si só, não comprova um bloqueio. Por outro lado, um evento de descarte depende de uma correspondência efetiva e da configuração de Active threat response correspondente; a checkbox de e-mail não gera uma correspondência nem cria uma nova regra de proteção.

A ajuda da Sophos sobre notificações indica que as correspondências de origem local e remota não são suportadas pelo Sophos X-Ops. Existe, porém, o conflito com a matriz SVG de tráfego documentado no artigo NDR/ATR, em particular quanto à correspondência de origem local. Por isso, a opção de e-mail não comprova um comportamento específico de correspondência do X-Ops nem resolve este conflito; os casos em disputa devem ser esclarecidos separadamente antes de serem considerados um requisito de proteção. Os alertas de correspondência de origem remota não são encaminhados para o serviço central da Sophos, mas os respetivos logs são visíveis em Central Firewall Reporting (CFR). A designação do serviço central varia entre versões (Sophos Fusion (anteriormente Sophos Central) ou Sophos Fusion); isto não implica uma extensão do encaminhamento de alertas. Por isso, para estes eventos, deve verificar-se o caminho local de e-mail e logs, em vez de depender apenas da apresentação central de alertas.

Compreender as condições de ativação e as repetições

Uma checkbox ativa não significa que cada breve alteração de estado gere um e-mail. No SFOS 22.0 e 23.0, os eventos seguintes têm estas condições:

Admin: Sign-in failed inclui credenciais incorretas ou uma OTP (palavra-passe de utilização única) incorreta. Too many failed sign-in attempts é ativado ao atingir o número de tentativas falhadas configurado em Administration > Admin and user settings > Login security. Este limite explica o alerta; não é uma instrução para provocar o bloqueio de uma conta.
High CPU usage: O primeiro registo de notificação só é gerado quando a utilização da CPU atinge 95% e permanece continuamente nos 95% ou acima durante pelo menos 25 minutos. São gerados novos registos a cada 25 minutos até a utilização descer abaixo de 95%. Um pico breve sem e-mail de evento não comprova, por isso, uma falha SMTP.
Gateway status: A seleção do evento está ativa por predefinição. Para enviar mensagens, o switch global separado Email notifications tem, ainda assim, de estar ativo.

Nos eventos de disco, a utilização tem de permanecer continuamente no respetivo limite ou acima durante pelo menos 50 segundos. Depois, os logs e as notificações repetem-se com a frequência predefinida seguinte até a utilização descer abaixo do limite:

Área	Limite de notificação	Repetição
Armazenamento de configuração	≥80%	a cada 50 segundos
Armazenamento de assinaturas	≥90%	a cada 50 segundos
`/var`	≥80%	a cada 12 horas

Em /var, o limite inferior já gera logs; as notificações só começam no limite superior de 80%. Se a utilização ultrapassar o limite superior e depois descer abaixo do inferior, a recuperação é registada, mas não é enviada uma notificação de recuperação. Isto é distinto do comportamento de aviso e paragem dos relatórios explicado no artigo de armazenamento ligado acima; aqui, a ausência de um e-mail de recuperação não é uma falha de entrega.

Para IPsec, o âmbito documentado é mais restrito do que qualquer alteração Up/Down de VPN: as notificações aplicam-se apenas a túneis host-to-host e site-to-site com as condições de desligamento descritas:

Dead peer detection (DPD).
Falha no restabelecimento da ligação após DPD.
A IPsec Security Association (SA) expirou e tem de ser restabelecida.
Esta lista também inclui o regresso do túnel após perda de conectividade sem intervenção do administrador.

Se estiver configurada uma descrição nas definições da ligação IPsec, a notificação inclui-a. Isto não garante notificações para cada desligamento manual nem para túneis de acesso remoto ou SSL VPN.

Os tempos de CPU descrevem a geração de logs de notificação e os intervalos de disco a repetição documentada, não uma hora de chegada garantida à caixa de correio. Se faltar um e-mail, comparar primeiro a condição do evento, a hora do log e o tracking do servidor de e-mail. Não se devem provocar saturação de CPU ou disco, bloqueios de login, interrupções HA ou falhas de VPN em produção apenas para testar um alerta.

Verificar mensagem de teste e evento real

A verificação é composta por duas etapas.

1. Confirmar a entrega SMTP com uma mensagem de teste

Primeiro, verificar a configuração de e-mail guardada em Administration > Notification settings e executar a função de mensagem de teste disponível no build do SFOS utilizado. O caminho para o teste de relatórios é Reports > Show report settings > Report scheduling: selecionar um relatório, abrir Send test mail, introduzir o endereço do destinatário de teste e clicar em Send. Este teste de relatório verifica o transporte de e-mail, não a seleção de eventos; o seu destinatário não é automaticamente o destinatário guardado para os alertas do sistema. 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. O conteúdo do relatório e o agendamento são verificados separadamente, conforme descrito no artigo sobre relatórios ligado abaixo.

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;
um evento VPN documentado num túnel de teste expressamente destinado a esse fim, desde que o tipo de túnel e a condição de ativação correspondam à notificação selecionada; uma alteração manual Up/Down de IPsec, por si só, não é um teste de alerta fiável;
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 o evento e descarta o pacote. Uma mensagem VPN depende do tipo de túnel e do estado Up/Down efetivo.

O OAuth do Gmail deixa de funcionar após uma alteração da palavra-passe

No procedimento de notificações do Gmail aqui descrito, com o scope https://mail.google.com, o Refresh Token fica inválido quando a palavra-passe da conta Gmail utilizada para o envio é alterada. A firewall deixa então de conseguir obter um novo Access Token com esse token. Esta afirmação não abrange todos os tokens OAuth do Google nem o Microsoft 365.

Verificar se foi alterada a palavra-passe desta conta de envio específica. Comparar o cliente OAuth, a conta, as permissões aprovadas e Publishing status: In production com a configuração documentada. Um token gerado antes de Publish App também não constitui uma base duradoura após sete dias; verificar as duas causas separadamente.
Com o acesso atual à conta e as credenciais do próprio cliente OAuth, repetir a autorização do Gmail e a troca de tokens seguindo o procedimento do Playground descrito acima. Verificar a aplicação e as permissões solicitadas antes de dar consentimento e guardar o novo Refresh Token de forma segura.
Em Administration > Notification settings, com Provider: Gmail, substituir o Refresh token inválido pelo novo e guardar. O Client ID e o Client secret têm de corresponder ao cliente OAuth utilizado; não alterar sem motivo as definições de SMTP, TLS, remetente, destinatário ou eventos.
Enviar uma mensagem de teste e confirmar a entrega efetiva na caixa de correio de destino ou no tracking do servidor de e-mail. Depois, verificar um evento selecionado acionado de forma controlada, tal como descrito na secção sobre a cadeia completa do evento.

Voltar a introduzir o token antigo não o torna válido. Não repor a palavra-passe da conta apenas para restaurar o caminho de e-mail anterior. Se o envio continuar a falhar após a nova autorização, registar a mensagem de erro exata, o build do SFOS e a configuração do fornecedor, sem secrets ou tokens, para prosseguir a análise. Até ser confirmado o restabelecimento, utilizar um caminho de alerta alternativo aprovado ou o relay SMTP documentado.

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

Se a entrega falhar após uma alteração, restaurar primeiro a configuração de e-mail registada: opção de servidor, servidor, porta, Authentication, Connection security, remetente, destinatário e interface de gestão, além da seleção de certificado anterior, caso tenha sido alterada. Manter a seleção de eventos se esta não tiver feito parte da alteração. Depois de guardar, voltar a confirmar o caminho de alerta anterior com uma mensagem de teste e um evento selecionado acionado de forma controlada. O restauro só fica concluído quando ambas as mensagens tiverem efetivamente chegado.

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.

A checklist diária de administração da Sophos Firewall reúne os sinais de estado, segurança e administração que também devem ser controlados ativamente durante o funcionamento.

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.

Para análises PDF enviadas diariamente ou semanalmente, não se utiliza a Notification list, mas um agendamento de relatório próprio. Agendar e enviar relatórios da Sophos Firewall por e-mail explica a seleção do relatório, o bookmark, o teste de transporte e a verificação do conteúdo.

Alterar o endereço do destinatário através de CLI Main Menu > 2. System Configuration