E-mail de falha de VPN no FortiGate: filtre campos, não logs

Duas decisões se escondem em «envie-me um e-mail quando um login de VPN falhar». A primeira é como a notificação é entregue: um e-mail por evento, um resumo periódico ou um alerta de um coletor. A segunda é o que a mensagem contém. Errar na primeira inunda uma caixa de correio, e errar na segunda apaga os campos que tornam o alerta acionável. Nenhuma das decisões exige suprimir a categoria de log de VPN, que é o atalho que destrói silenciosamente a trilha de auditoria.

Três formas de entrega e quando cada uma serve

Escolha por quem responde e com que rapidez pode fazê-lo, não por qual opção é mais fácil de configurar. Um único FortiGate protegendo um escritório pode justificar o e-mail por evento. A mesma configuração num gateway que recebe tentativas de preenchimento de credenciais roubadas produz milhares de mensagens por dia e acaba filtrada numa pasta que ninguém lê.

Comece pelo registro do evento, não pela linha de assunto

Leia um evento armazenado representativo na versão que você realmente executa. A referência de logs do FortiOS 7.4.8 identifica a falha de login em SSL VPN como evento 39426, e os campos incluem action, user, remip, reason, tunneltype e vd. Projetar um filtro a partir de um assunto de e-mail encaminhado em vez desse registro é como as pessoas acabam casando um nome de campo que seu firmware escreve de outra forma. Abra dois ou três fracassos reais e confirme que os identificadores coincidem antes de escrever um gatilho. Os cinco minutos que isso leva são mais curtos que uma semana de alertas disparando no evento errado.

Um ponto de automação liga um gatilho de log de eventos a uma ação, e o gatilho é onde a seleção do evento deve ficar. Adicione apenas as condições de campo extras que o seu requisito precisa; um gatilho que filtra por um conjunto pequeno de campos ainda entrega comportamento não testado para o resto.

Construa um corpo compacto com substituições suportadas

Em versões que documentam a substituição de campos de log para ações de e-mail, o corpo pode ser curto e ainda útil. A forma abaixo é ilustrativa; confirme os nomes dos atributos e a sintaxe de substituição com a versão do firmware antes de adotá-la.

config system automation-trigger
    edit "ssl-vpn-login-fail"
        set event-type event-log
        set logid 39426
    next
end

config system automation-action
    edit "mail-vpn-fail"
        set action-type email
        set email-to "[email protected]"
        set email-subject "SSL-VPN login failed"
        set message "Account: %%log.user%% | Source: %%log.remip%% | Reason: %%log.reason%%"
    next
end

Um modelo que exibe um campo vazio não prova que o evento não tinha esses dados. Verifique primeiro o nome do campo e a sintaxe de substituição, depois teste com uma falha controlada e leia a mensagem real. Adicione a identidade do dispositivo e o horário de ocorrência para que quem responde encontre o registro completo sem adivinhar qual unidade enviou o e-mail.

Reduza o volume sem apagar o registro

Controle de taxa, agrupamento e correlação pertencem à camada de entrega. Elevar a severidade mínima dos e-mails para tudo é um instrumento contundente que esconde eventos não relacionados, e desativar a categoria de log de VPN é pior: os eventos deixam de ser gravados por completo. Mantenha o destino de log aprovado e a política de retenção exatamente como estavam, e deixe o caminho de notificação ficar mais silencioso. Documente o que você suprimiu, porque a próxima pessoa encontrará uma lacuna na caixa de correio e precisa saber que foi deliberado.

Quando o novo caminho estiver validado, retire qualquer regra de e-mail legada que se sobreponha por meio de uma mudança revisada. Terminar com dois caminhos que disparam ambos, ou com nenhum porque o antigo foi desativado primeiro, é um resultado comum de fazer a limpeza antes do teste.

Leia uma falha como uma falha

Um evento de autenticação falho não é uma sessão de VPN bem-sucedida, e um nome de usuário num evento não é atribuição verificada a uma pessoa. Correlacione o motivo com logins bem-sucedidos, atividade conhecida do usuário e tentativas repetidas antes de declarar uma conta comprometida, e diga no alerta quais desses você verificou.

Envie a notificação apenas a destinatários autorizados. Nomes de conta, identificadores internos de dispositivo e endereços de origem são sensíveis operacionalmente, e uma lista de distribuição que cresce por conveniência torna-se um caminho de vazamento. Um caminho acionável mais uma trilha de auditoria intacta é todo o objetivo.