Solucionar errores comunes del dispositivo Email Security

Introducción

Este documento describe errores de configuración comunes en el dispositivo de seguridad Cisco Email Security Appliance (ESA).

Entorno

• Producto:Cisco Email Security Appliance (ESA)
• Software:AsyncOS para ESA (la versión varía según la implementación)
• Alcance: Aplique esta guía a las políticas de correo entrante y saliente según corresponda; revise cada sección antes de realizar cambios.

Prerequisites

• Acceso administrativo al ESA (GUI o CLI)
• Posibilidad de revisar los registros de correo y el seguimiento de mensajes para su validación
• Servicios de reputación SenderBase Puntuación de reputación SBRS habilitado si se utilizan grupos de remitentes basados en SBRS
• Reconocimiento de que la tabla de acceso de host (HAT) clasifica los hosts de conexión antes de la evaluación de la política de correo, lo que afecta a la forma de aplicar controles posteriores

Verificación general

• Utilice Monitor > Overview y el rastreo de mensajes para confirmar la clasificación de grupo de remitentes esperada, las coincidencias de políticas y los resultados de entrega después de los cambios. Éxito significa que el grupo de remitentes, la política y el resultado de entrega esperados aparecen después del cambio.
• Supervise las cuarentenas y los falsos positivos durante 7-14 días después de ajustar la reputación o la configuración de filtrado, y ajústelos en función de los partners empresariales conocidos según sea necesario.

Errores de configuración comunes en el dispositivo de seguridad Email Security Appliance (ESA)

Utilice estas comprobaciones para identificar y corregir errores de configuración comunes en el dispositivo de seguridad Email Security Appliance (ESA). Cada subsección utiliza un patrón coherente de problema, causa, resolución y verificación para que el problema se pueda diagnosticar y corregir rápidamente.

Tabla de acceso de host (HAT)

Síntomas

• El spam se acepta debido a que los grupos de remitentes basados en la reputación son excesivamente permisivos.
• El correo legítimo se limita o bloquea debido a controles de conexión demasiado estrictos.

Causa

• Los grupos de remitentes se configuran con intervalos inadecuados de la puntuación de reputación de SenderBase (SBRS) o con valores de verificación del Sistema de nombres de dominio (DNS).

Resolución

1. No agregue valores SBRS positivos (por ejemplo, +5 o +7) a la lista de permitidos. Para las listas de permitidos basadas en SBRS, utilice sólo puntuaciones de 9.0 a 10.0 y valide con el seguimiento de mensajes.
2. Configure la lista de remitentes desconocidos y las funciones de verificación de DNS solo cuando sea necesario. Si no es necesario, inhabilite UNKNOWNLIST, Envelope SenderDNS Verification y Connecting HostDNS Verification.

3. Para evitar incoherencias en la configuración por directiva, configure los valores predeterminados globales: elija Políticas de correo > Políticas de flujo de correo > Parámetros de política predeterminados y establezca allí el tamaño del mensaje y otros parámetros predeterminados.
4. Establezca un valor máximo de conexiones predeterminado razonable para la mayoría de los remitentes (por ejemplo, 3) y aplíquelo como valor predeterminado para las nuevas políticas de flujo de correo; ajuste los remitentes de gran volumen conocidos según sea necesario.
5. Configure el rango de SBRS de la lista de bloqueo en función de su tolerancia al riesgo. En muchas implementaciones, el bloqueo de SBRS -10.0 a -2.0 puede dar como resultado tasas bajas de falsos positivos. Realice la validación con el seguimiento de mensajes y ajústelo para los partners empresariales.

Política

Síntoma/Impacto

• El correo se analiza o se pone en cuarentena de forma inesperada porque las políticas de correo no predeterminadas anulan los valores predeterminados globales.
• El correo saliente activa acciones innecesarias de filtro antispam/brotes de virus, lo que aumenta el tiempo de procesamiento y los falsos positivos.
• Los mensajes aparecen en blanco porque los archivos adjuntos infectados se eliminan y el cuerpo del mensaje sólo contiene el contenido eliminado.

Causa

• Las políticas no predeterminadas duplican o anulan la configuración predeterminada de antispam, antivirus, filtro de contenido o filtro de brotes de virus sin un requisito específico.
• Las políticas de salida aplican funciones de análisis centradas en el tráfico entrante.

Resolución

1. Asigne un nombre a las directivas de correo electrónico de los destinatarios a los que se aplican (por ejemplo, Inbound_Executives) y asigne un nombre a los filtros de contenido de la acción que realizan (por ejemplo, Q_basic_attachment y Dspooferss).
2. Para las políticas no predeterminadas, seleccione Use Default Settings for Anti-Spam, Anti-Virus, Content Filters y Outbreak Filters a menos que se requiera una excepción documentada.
3. Desactive la casilla de verificación Eliminar archivos adjuntos infectados para evitar la entrega de mensajes con contenido eliminado que puede aparecer en blanco.
4. En el caso de acciones de antivirus salientes, notifique al remitente en lugar del destinatario.
5. Deshabilite los filtros de brote y el antispam en las políticas de correo saliente a menos que exista un caso práctico de salida explícito.

Verificación

• Utilice el rastreo de mensajes para confirmar que la política de correo deseada coincide y que la configuración de escaneo predeterminada se hereda donde se espera.
• Envíe un mensaje de prueba saliente controlado y confirme que no se aplican los filtros antispam/de brote de virus a menos que se configuren mediante una excepción.

Relays entrantes

Síntomas

• Los servidores de correo internos se tratan como remitentes externos, lo que puede provocar acciones inesperadas de limitación, filtrado o basadas en la reputación.

Causa

• Las redes o direcciones IP del servidor de correo interno no están configuradas como retransmisiones entrantes o la función de retransmisión entrante está deshabilitada.
• Los hosts de retransmisión interna no se clasifican en un grupo de remitentes HAT dedicado, lo que puede dar lugar a límites de conexión no deseados o a un comportamiento de prevención de ataques de recolección de directorios (DHAP).

Resolución

1. En la GUI, elija Mail Policies > Incoming Relays, y agregue las direcciones IP o redes de su servidor de correo interno.
2. Asegúrese de que la función de retransmisión entrante está activada (no sólo agregue entradas a la tabla).
3. Cree un grupo de remitentes dedicado de la tabla de acceso de host (HAT) para los transmisores internos enumerados en la lista de permitidos de la lista anterior con fines de generación de informes. Configure sin límite de velocidad y sin prevención de ataques de recolección de directorios (DHAP) si procede, mientras mantiene activado el análisis antispam y antivirus según sea necesario.DHAP limita los intentos de enumeración de destinatarios no válidos durante la conversación SMTP (Simple Mail Transfer Protocol, Protocolo simple de transferencia de correo).
4. Si descarta correo basándose en la reputación del tráfico no retransmitido, agregue un filtro de mensajes que aplique una gestión equivalente al correo retransmitido cuando sea necesario. Ejemplo:

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

Verificación

• En Monitor > Overview, confirme que los servidores internos ya no aparecen como remitentes externos no confiables.
• En los registros de correo/seguimiento de mensajes, confirme que se ha aplicado el grupo de remitentes esperado (por ejemplo, un grupo de remitentes de retransmisiones internas).

DNS

Síntomas

• Selección o división de resolución de DNS: la configuración de DNS provoca fallos de entrega, transacciones SMTP lentas o comprobaciones basadas en DNS con errores de reputación.

Entorno

• Se aplica a implementaciones que requieren resolución de DNS público, resolución de DNS solo interna o split-horizonDNS para dominios y servicios internos.

Síntomas

• El rastreo de mensajes muestra fallas de búsqueda de DNS/tiempos de espera para consultas MX, AAA,PTRR o relacionadas con la reputación.
• La entrega de correo se retrasa debido a repetidos reintentos de DNS.

Causa

• ESA está configurado para utilizar resoluciones que no pueden resolver los registros públicos requeridos, los registros internos requeridos o ambos.
• Split-horizonDNS, que devuelve respuestas diferentes para el mismo dominio basado en la red de origen, es necesario pero no se implementa para los dominios o servicios internos.

Resolución

Configurar la resolución del Sistema de nombres de dominio (DNS) en función de dónde resuelve el ESA los registros: Internet público, dominios internos exclusivamente o ambos:

1. Utilice resolvers recursivos públicos cuando el ESA necesite principalmente registros DNS públicos y la política lo permita.

2. Utilice DNS interno o DNS de horizonte dividido cuando el ESA deba resolver zonas solo internas, registros de intercambio de correo interno (MXX), registros de Protocolo ligero de acceso a directorios (LDAP) u otros servicios privados.

3. El DNS público es adecuado cuando el dispositivo resuelve principalmente registros de correo de Internet y no se aplican zonas de solo uso interno ni restricciones de políticas.

Utilice InternalDNS o splitDNS cuando sea necesario

• Dominios solo internos
• registros InternalMXX
• Split-horizonDNS (respuestas diferentes para el mismo dominio basadas en la red de origen)
• El cumplimiento o la política de seguridad requieren resoluciones recursivas internas
• Zonas de DNS privado necesarias para el enrutamiento
• Zonas de DNS privado necesarias para el protocolo ligero de acceso a directorios (LDAP)
• Zonas de DNS privado necesarias para los servicios internos utilizados por el ESA

Verificación

• Confirme que el ESA puede resolver los nombres de host públicos e internos necesarios (según corresponda) y que la entrega de correo y las comprobaciones basadas en DNS de reputación tienen éxito en el seguimiento de mensajes.

Filtros de contenido y mensajes

El error más común es agregar condiciones coincidentes en los filtros cuando no son necesarias.

• Condiciones en blanco: Deje la condición en blanco cuando el filtro deba ejecutarse para cada mensaje en una política de correo determinada.
• Comportamiento de evaluación: En los filtros de mensajes de asyncOS, una condición en blanco se evalúa como true, por lo que el filtro se ejecuta en cada mensaje que llega a él.
• Alcance: Controle el alcance adjuntando el filtro a la política de correo entrante o saliente adecuada.
• Pedido: Los filtros de mensajes evalúan los atributos y las acciones del mensaje en secuencia. Los filtros de contenido suelen estar determinados por la directiva de correo que los llama.

Examples:

• El uso de la condición rcpt-to en un filtro de mensajes suele ser innecesario cuando el objetivo es dirigirse a un usuario o grupo específico. Opte por una política de correo entrante basada en destinatarios y aplique el filtro de contenido a esa política cuando el requisito se asigne de forma limpia a destinatarios o grupos de destinatarios. Reserve las condiciones rcpt-to para las excepciones en las que la coincidencia de políticas no puede expresar el requisito.
• La comprobación de la presencia de un adjunto antes de descartarlo suele ser redundante cuando la intención es bloquear un tipo de adjunto específico. Configure el filtro para descartar el tipo de adjunto de destino directamente; utilice una prueba de presencia de datos adjuntos sólo cuando se requieran diferentes acciones, dependiendo de si existe un archivo adjunto.
• Utilice deliver() sólo cuando el mensaje deba omitir los filtros restantes. La acción deliver() detiene el procesamiento de filtros adicionales y luego entrega el mensaje; para entregar correo sin omitir los filtros restantes, no configure una acción deliver() explícita (se aplica la entrega implícita).

Prevención de retransmisión abierta

Síntoma/Impacto

• Las pruebas de retransmisión de terceros informan de que el dispositivo acepta direcciones de destinatarios malformadas o peligrosas.
• Las listas de bloqueo de publicaciones enumeran el IPP de envío porque el análisis de la dirección SMTP permite patrones comúnmente utilizados para validar retransmisiones abiertas.

Causa

• El análisis de direcciones SMTP y la gestión de caracteres del Protocolo simple de transferencia de correo permiten formatos de dirección no válidos (por ejemplo, dobles @ signos) o literales de dirección, que son direcciones IP escritas directamente en la dirección en lugar de un nombre de dominio.

Resolución

Algunos servicios comprueban si el Agente de transferencia de mensajes (MTA) acepta direcciones mal formadas que pueden indicar una condición de retransmisión abierta. Configure el análisis estricto y el comportamiento de rechazo para que el ESA rechace estas direcciones durante la conversación SMTP.

• Agregue un grupo de remitentes HAT dedicado para los orígenes de prueba de retransmisión que preceda a ALLOWLIST para los informes. Configure sin límite de velocidad y sin prevención de ataques de recolección de directorios (DHAP) si procede, mientras mantiene Anti-Spam y Anti-Virus habilitados según sea necesario.
• Habilite Strict Address Parsing (Loose es el valor predeterminado) para evitar el doble signo @ en las direcciones.
• Rechazar (no eliminar) caracteres no válidos para evitar la aceptación de direcciones mal formadas.
• Rechazar (no aceptar) literales de dirección e introduzca estos caracteres: *%!\\/?

Verificación

• Ejecute una prueba de retransmisión externa y confirme que el ESA rechaza las direcciones de destinatario mal formadas durante la conversación SMTP.
• Utilice el seguimiento de mensajes para confirmar que el grupo de remitentes de prueba de retransmisión coincide y que el correo se procesa con la configuración de análisis deseada.

Información Relacionada

• Obtenga asistencia técnica y documentación
• Guías de usuario de ReviewAsyncOSS para ESA
• Guías de instalación y configuración de Email Security Appliance (ESA) (HAT, políticas de correo electrónico y filtros de mensajes)

Historial de revisiones

Revisión	Fecha de publicación	Comentarios
3.0	01-Sep-2026	Recertificación.
1.0	13-Oct-2014	Versión inicial