Saltar para o conteudo
Avanet

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

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 autenticação, SMTP, administração 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:

  1. Configurar servidor de e-mail, porta, autenticação, encriptação, remetente e destinatário em Administration > Notification settings.
  2. Enviar uma mensagem de teste e confirmar a entrega na caixa de correio de destino ou no tracking do servidor de e-mail.
  3. Ativar o switch global Email notifications em System services > Notification list.
  4. Selecionar apenas os eventos aos quais um destinatário responsável possa reagir.
  5. 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.

Alterar o endereço do destinatário através da Device Console

Se o WebAdmin não estiver disponível ou for necessário corrigir o endereço do destinatário através de acesso controlado à consola, utilizar 2. System Configuration > 3. Set Email ID for system notification. 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.

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:

  1. Ativar o Built-in email server em Administration > Notification settings.
  2. Introduzir remetente, destinatário e, opcionalmente, Management interface IP address.
  3. 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

  1. Abrir Administration > Notification settings.
  2. Selecionar External email server.
  3. Introduzir o endereço IPv4 ou FQDN do servidor de e-mail e a porta indicada.
  4. Em Authentication, selecionar None, Basic ou OAuth 2.0 de acordo com o servidor.
  5. Em Connection security, definir a encriptação de transporte exigida pelo servidor de e-mail.
  6. Introduzir remetente, destinatário e, opcionalmente, Management interface IP address.
  7. 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. O procedimento seguinte corresponde ao guia atual da Sophos Configure OAuth 2.0 on Gmail.

Configurar o Gmail OAuth 2.0 passo a passo

  1. Iniciar sessão na Google Cloud Console com a conta Google prevista, criar um novo projeto e selecioná-lo.
  2. Abrir APIs & Services > Library, procurar Gmail API e ativar a API.
  3. Em APIs & Services > Credentials, clicar em Create credentials > OAuth client ID.
  4. 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.
  5. Selecionar Create OAuth client, definir Application type: Web application e atribuir um nome inequívoco.
  6. Em Authorized redirect URIs, adicionar exatamente https://developers.google.com/oauthplayground.
  7. Criar o cliente OAuth e guardar imediatamente o Client ID e o Client secret de forma segura.
  8. Em Audience > Add users, adicionar a conta Google que irá enviar posteriormente as notificações.
  9. 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.
  10. 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.
  11. Em Step 2 Exchange authorization code for tokens, trocar o código por tokens e copiar o Refresh token de forma segura.
  12. Na firewall, configurar o External email server em Administration > Notification settings com Authentication: OAuth 2.0 e Provider: Gmail. Introduzir o Client ID, Client secret e Refresh token, guardar e enviar um e-mail de teste.

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.

Configurar o Microsoft 365 OAuth 2.0 passo a passo

  1. No Microsoft Entra admin center, criar um New registration em Identity > Applications > App registrations.
  2. Atribuir um nome inequívoco. Para o procedimento documentado pela Sophos, selecionar Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant) e introduzir https://outlook.office365.com/ como plataforma Web em Redirect URI. A mesma URI tem de ser reutilizada exatamente mais tarde.
  3. Registar a aplicação e guardar o Application (client) ID de forma segura.
  4. Em API permissions > Add a permission > Microsoft Graph > Delegated permissions, adicionar SMTP.Send e offline_access. Em seguida, executar Grant admin consent.
  5. Para a conta de envio, ativar Authenticated SMTP em Users > Active users > Mail > Email apps > Manage email apps.
  6. 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.
  7. Abrir o URL seguinte num browser. Substituir YOUR_CLIENT_ID pelo Application ID; o redirect_uri tem de corresponder ao registo da aplicação.
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=12345
  1. Iniciar sessão com a conta de envio prevista e copiar o código de autorização de curta duração do URL de redirecionamento.
  2. 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.
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
  1. 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.
  2. 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.

A Sophos exige que o sistema que executa o cliente API e a firewall utilizem o mesmo fuso horário durante a criação do token. 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; a Sophos exige depois um reinício, que 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.

⚠️ 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:

  1. Email notifications está globalmente ativo?
  2. O evento concreto está selecionado na coluna Email?
  3. O evento esperado ocorreu realmente e corresponde à categoria correta?
  4. Existe um atraso ou agrupamento conhecido, por exemplo nos Web Instant Alerts?
  5. 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.

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.