Solucionar erros comuns do dispositivo de segurança de e-mail

Introdução

Este documento descreve erros comuns de configuração no Cisco Email Security Appliance (ESA).

Ambiente

• Produto:Cisco Email Security Appliance (ESA)
• Software:AsyncOS para ESA (a versão varia de acordo com a implantação)
• Escopo: Aplique esta orientação às políticas de entrada e saída de e-mail conforme aplicável; revise cada seção antes de fazer alterações.

Pré-requisitos

• Acesso administrativo ao ESA (GUI ou CLI)
• Capacidade de revisar logs de e-mail e rastreamento de mensagens para validação
• Serviços de reputação SenderBase Pontuação de reputação SBRS habilitada se estiver usando grupos de remetentes baseados em SBRS
• Consciência de que a HAT (Host Access Table, tabela de acesso a host) classifica os hosts de conexão antes da avaliação da política de e-mail, o que afeta a aplicação dos controles posteriores

Verificação geral

• Use Monitor > Overview e o rastreamento de mensagens para confirmar a classificação esperada do grupo de remetentes, as correspondências de políticas e os resultados de entrega após as alterações. Êxito significa que o grupo de remetente, a política e o resultado de entrega esperados aparecem após a alteração.
• Monitore as quarentenas e os falsos positivos por 7 a 144 dias após reforçar a reputação ou as configurações de filtragem e ajuste-os para parceiros comerciais conhecidos conforme necessário.

Erros comuns de configuração no Email Security Appliance (ESA)

Use essas verificações para identificar e corrigir erros comuns de configuração no Email Security Appliance (ESA). Cada subseção usa um padrão consistente de problema, causa, resolução e verificação para que o problema possa ser diagnosticado e corrigido rapidamente.

Tabela de acesso de host (HAT)

Sintomas

• O spam é aceito devido a grupos de remetentes baseados em reputação excessivamente permissivos.
• O e-mail legítimo é limitado ou bloqueado devido a controles de conexão excessivamente rígidos.

Causa

• Os grupos de remetentes são configurados com intervalos de SenderBase Reputation Score (SBRS) inadequados ou configurações de verificação do Sistema de Nome de Domínio (DNS).

Resolução

1. Não adicione valores SBRS positivos (por exemplo, +5 ou +7) à lista de permissões. Para listas de permissão baseadas em SBRS, use somente pontuações de 9.0 a 10.0 e valide com o controle de mensagens.
2. Configure a lista de remetentes desconhecidos e os recursos de verificação de DNS somente quando necessário. Se não for necessário, desabilite UNKNOWNLIST, Verificação de DNS de remetente de envelope e Verificação de DNS de host de conexão.

3. Para evitar configurações inconsistentes por política, configure os padrões globais: escolha Políticas de e-mail > Políticas de fluxo de e-mail > Parâmetros de política padrão e defina o tamanho da mensagem e outros parâmetros padrão.
4. Definir um valor máximo de conexões padrão razoável para a maioria dos remetentes (por exemplo, 3) e aplicá-lo como padrão para novas políticas de fluxo de email; ajuste para remetentes de alto volume conhecidos conforme necessário.
5. Configure o intervalo SBRS da lista de bloqueio com base na sua tolerância a riscos. Em muitas implantações, o bloqueio de SBRS -10.0 a -2.0 pode resultar em taxas baixas de falsos positivos. Valide com controle de mensagens e ajuste para parceiros comerciais.

Política

Sintoma/impacto

• Os e-mails são verificados ou colocados em quarentena inesperadamente porque as políticas de e-mail não padrão substituem os padrões globais.
• O correio de saída aciona ações antisspam/filtro de detecção desnecessárias, aumentando o tempo de processamento e falsos positivos.
• As mensagens aparecem em branco porque os anexos infectados são retirados e o corpo da mensagem contém apenas o conteúdo removido.

Causa

• As políticas não padrão duplicam ou substituem as configurações padrão de antisspam, antivírus, filtro de conteúdo ou filtro de epidemia sem um requisito específico.
• As políticas de saída aplicam recursos de varredura com foco na entrada.

Resolução

1. Políticas de e-mail de nome para os destinatários aos quais se aplicam (por exemplo, Inbound_Executives) e filtros de conteúdo de nome para a ação que tomam (por exemplo, Q_basic_attachments e Dspoofers).
2. Para regras não padrão, selecione Usar configurações padrão para antisspam, antivírus, filtros de conteúdo e filtros de epidemia, a menos que uma exceção documentada seja necessária.
3. Desmarque a caixa de seleção Eliminar anexos infectados para evitar a entrega de mensagens com conteúdo retirado que podem aparecer em branco.
4. Para ações de antivírus de saída, notifique o remetente em vez do destinatário.
5. Desative filtros de detecção e antisspam em políticas de e-mail de saída, a menos que exista um caso de uso de saída explícito.

Verificar

• Use o controle de mensagens para confirmar se a política de e-mail pretendida corresponde e se as configurações de varredura padrão são herdadas onde esperado.
• Envie uma mensagem de teste de saída controlada e confirme se os filtros antisspam/epidemia não são aplicados, a menos que sejam configurados por exceção.

Relés de entrada

Sintomas

• Os servidores de email internos são tratados como remetentes externos, o que pode causar limitação inesperada, filtragem ou ações baseadas em reputação.

Causa

• As redes ou os endereços IP do servidor de email interno não estão configurados como relés de entrada, ou o recurso Relé de Entrada está desabilitado.
• Os hosts de retransmissão internos não são classificados em um grupo de remetente HAT dedicado, o que pode resultar em limites de conexão não intencionais ou comportamento de prevenção de ataque de coleta de diretório (DHAP).

Resolução

1. Na GUI, escolha Mail Policies > Incoming Relays e adicione seus endereços IP ou redes do servidor de e-mail interno.
2. Certifique-se de que o recurso de relé de entrada esteja habilitado (não adicione apenas entradas à tabela).
3. Crie um grupo de remetente HAT (Host Access Table, tabela de acesso a host) dedicado para retransmissões internas listadas na lista de permissões na lista anterior para fins de geração de relatórios. Configure nenhuma limitação de taxa e nenhuma prevenção de ataque de coleta de diretório (DHAP), se apropriado, enquanto mantém a verificação de antisspam e antivírus ativada, conforme necessário.O DHAP limita as tentativas inválidas de enumeração de destinatários durante a conversação do protocolo SMTP.
4. Se você eliminar e-mails com base na reputação do tráfego não retransmitido, adicione um filtro de mensagens que aplique tratamento equivalente a e-mails retransmitidos quando necessário. Exemplo:

Drop_Low_Reputation_Relayed_Mail:
if reputation <= -2.0
{ drop(); }

Verificar

• Em Monitor > Overview, confirme se os servidores internos não aparecem mais como remetentes externos não confiáveis.
• Em rastreamento de mensagens/logs de e-mail, confirme se o grupo de remetente esperado foi aplicado (por exemplo, um grupo de remetente de retransmissões internas).

DNS

Sintomas

• Seleção ou divisão do resolvedor DNS: a configuração DNS causa falhas de entrega, transações SMTP lentas ou falha nas verificações baseadas em DNS de reputação.

Ambiente

• Aplica-se a implantações que exigem resolução de DNS público, resolução de DNS somente interno ou split horizonDNS para domínios e serviços internos.

Sintomas

• O rastreamento de mensagens mostra falhas/timeouts de pesquisa DNS para consultas relacionadas a MX, AAA, PTRR ou reputação.
• A entrega de mensagens está atrasada devido a repetidas tentativas de DNS.

Causa

• O ESA é configurado para usar resolvedores que não podem resolver registros públicos necessários, registros internos necessários ou ambos.
• O Split-horizonDNS, que retorna respostas diferentes para o mesmo domínio com base na rede de origem, é necessário, mas não é implementado para domínios ou serviços internos.

Resolução

Configure a resolução do Sistema de Nomes de Domínio (DNS) com base no local onde o ESA resolve registros: a Internet pública, domínios somente internos ou ambos:

1. Use resolvedores recursivos públicos quando o ESA precisar principalmente de registros DNS públicos e quando a política permitir.

2. Use o DNS interno ou o DNS de split horizon quando o ESA tiver que resolver zonas somente internas, registros de intercâmbio interno de mensagens (MXX), registros do Lightweight Diretory Access Protocol (LDAPP) ou outros serviços privados.

3. O DNS público é apropriado quando o dispositivo resolve principalmente os registros de e-mail da Internet e não se aplicam zonas somente internas ou restrições de política.

Usar InternalDNS ou splitDNS quando necessário

• Domínios somente internos
• Registros MXX internos
• Split-horizonDNS (respostas diferentes para o mesmo domínio com base na rede de origem)
• A política de conformidade ou segurança requer resolvedores recursivos internos
• Zonas PrivateDNS necessárias para roteamento
• Zonas PrivateDNS necessárias para o Lightweight Diretory Access Protocol (LDAPP)
• Zonas de DNS privado necessárias para serviços internos usados pelo ESA

Verificar

• Confirme se o ESA pode resolver os nomes de host internos e públicos necessários (conforme aplicável) e se a entrega de e-mail e as verificações baseadas em DNS de reputação obtiveram êxito no rastreamento de mensagens.

Filtros de mensagem e conteúdo

O erro mais comum é adicionar condições correspondentes nos filtros quando eles não são necessários.

• Condições em branco: Deixe a condição em branco quando o filtro precisar ser executado para cada mensagem em uma determinada política de email.
• Comportamento de avaliação: Em filtros de mensagem assíncronos, uma condição em branco é avaliada como verdadeira, de modo que o filtro é executado em cada mensagem que a alcança.
• Escopo: Controle o escopo anexando o filtro à Política de e-mails recebidos ou enviados apropriada.
• Pedido: Os filtros de mensagem avaliam os atributos e as ações da mensagem em sequência. Os filtros de conteúdo normalmente têm o escopo definido pela política de e-mail que os chama.

Examples:

• Usar a condição rcpt-to em um filtro de mensagem geralmente é desnecessário quando o objetivo é direcionar um usuário ou grupo específico. Prefira uma política de e-mails recebidos com base no destinatário e aplique o filtro de conteúdo a essa política quando o requisito for mapeado de forma limpa para destinatários ou grupos de destinatários. Reserve as condições de rcpt-to para exceções em que a correspondência de políticas não possa expressar o requisito.
• Testar a presença de um anexo antes de soltá-lo geralmente é redundante quando a intenção é bloquear um tipo de anexo específico. Configurar o filtro para soltar diretamente o tipo de anexo direcionado; use um teste de presença de anexo somente quando ações diferentes forem necessárias, dependendo da existência ou não de um anexo.
• Use delivery() somente quando a mensagem tiver que ignorar os filtros restantes. A ação deliver() para o processamento de filtros e então entrega a mensagem; para entregar e-mail sem ignorar os filtros restantes, não configure uma ação delivery() explícita (a entrega implícita se aplica).

Prevenção de Open Relay

Sintoma/impacto

• Os testes de retransmissão de terceiros relatam que o equipamento aceita endereços de destinatário perigosos ou malformados.
• Listas de bloqueio públicas listam o IPP de envio porque a análise de endereço SMTP permite padrões comumente usados para validar retransmissões abertas.

Causa

• A análise de endereço SMTP do protocolo SMTP de transferência de correspondência simples e o tratamento de caracteres permitem formatos de endereço inválidos (por exemplo, sinais @ duplos) ou literais de endereço, que são endereços IP gravados diretamente no endereço, em vez de um nome de domínio.

Resolução

Alguns serviços testam se o Agente de Transferência de Mensagens (MTA) aceita endereços malformados que possam indicar uma condição de retransmissão aberta. Configure o comportamento estrito de análise e rejeição para que o ESA rejeite esses endereços durante a conversação SMTP.

• Adicione um grupo de remetente HAT dedicado para fontes de teste de retransmissão, precedendo ALLOWLIST para relatório. Configure no rate limit e no Diretory Harvest Attack Prevention (DHAP), se apropriado, enquanto mantém o Anti-Spam e o Anti-Virus ativados, conforme necessário.
• Habilite a análise de endereço estrito (o padrão é Loose) para evitar sinais @ duplos nos endereços.
• Rejeitar (não remover) caracteres inválidos para impedir a aceitação de endereços mal formados.
• Rejeite (não aceite) literais de endereço e insira estes caracteres: *%!\\/?

Verificar

• Execute um teste de relé externo e confirme se o ESA rejeita endereços de destinatário malformados durante a conversação SMTP.
• Use o controle de mensagens para confirmar se o grupo de remetente do teste de retransmissão corresponde e se o e-mail é processado com as configurações de varredura desejadas.

Informações Relacionadas

• Obtenha suporte técnico e documentação
• Guias do usuário do ReviewAsyncOSS forESA
• Guias de instalação e configuração do Email Security Appliance (ESA) (HAT, políticas de e-mail e filtros de mensagens)

Histórico de revisões

Revisão	Data de publicação	Comentários
3.0	01-Sep-2026	Recertificação.
1.0	13-Oct-2014	Versão inicial