Cisco Secure Email: Gateway, AsyncOS y SMA

Cisco Secure Email Gateway, abreviado SEG e históricamente Email Security Appliance o ESA, es una puerta de enlace de correo SMTP con estado. Termina las sesiones SMTP entrantes, decide su aceptación, procesa los mensajes en una Work Queue interna y abre una nueva sesión SMTP para la entrega. Por tanto, el límite de responsabilidad técnica no está en el handshake TCP o TLS correcto, sino en la respuesta SMTP positiva tras el contenido del mensaje: desde ese momento, la puerta de enlace debe entregar o generar un error conforme a la norma (Cisco: Email Pipeline, RFC 5321).

La segunda función clásica es Cisco Secure Email and Web Manager, SMA. Normalmente no actúa como MTA regular en la ruta de correo de producción. Gestiona datos centralizados de tracking y reporting y, según el diseño, cuarentenas de spam, políticas, virus y brotes de varios gateways. Por ello, una caída del SMA puede dejar intacta la entrega en los nodos SEG y, al mismo tiempo, interrumpir las búsquedas, la cuarentena de usuarios finales o el procesamiento de mensajes retenidos (Cisco: SMA Message Tracking, Cisco: Centralized Quarantines).

Ambas funciones se ejecutan en AsyncOS, una plataforma de software mantenida por Cisco como unidad de appliance. Los administradores no gestionan los paquetes subyacentes como en un servidor Linux general; la superficie técnica fiable consta de configuración de AsyncOS, CLI, interfaz web, API REST, suscripciones de logs, MIB, canales de actualización e integraciones documentadas. Los resúmenes de código abierto de Cisco prueban numerosos componentes integrados, pero no una lista de materiales públicamente mantenible de la canalización de correo propietaria. Por tanto, las bibliotecas individuales no deben equipararse con la arquitectura completa (Cisco: Open Source Used in AsyncOS, Cisco: AsyncOS API).

La explicación acompaña un mensaje a través de Cisco Secure Email: desde el listener, HAT, RAT y Work Queue hasta la entrega. Después se tratan SMA, operación en clúster, dependencias, diagnóstico y recuperación.

Roles de producto y límites de confianza

Un diseño local típico coloca al menos dos nodos SEG en la DMZ y un SMA en una red de administración interna. Los MX de DNS o un servicio previo distribuyen las conexiones entrantes entre los gateways; para el tráfico saliente, los conectores de smarthost del sistema de correo determinan la ruta por el gateway. Varios nodos SEG solo son de alta disponibilidad cuando DNS, el balanceador de carga o el MTA emisor pueden utilizar destinos alternativos. El clúster de configuración de AsyncOS por sí solo no asume este encaminamiento de tráfico (Cisco: Centralized Management Using Clusters, RFC 5321, Address Resolution).

Cisco documenta appliances virtuales, despliegues en nube pública y un Secure Email Cloud Gateway operado. Estas variantes comparten términos de producto, pero desplazan responsabilidades: con la appliance virtual, el cliente es responsable del hipervisor, la red, la capacidad y la restauración; con Cloud Gateway, Cisco proporciona la infraestructura de gateway. Secure Email Threat Defense es, en cambio, una plataforma nativa de nube para análisis y protección que puede integrarse mediante gateway, journaling o API de Microsoft. No es sinónimo de la Work Queue local ni un término alternativo para SMA (Cisco: Secure Email Data Sheet, Cisco: Email Threat Defense Data Sheet).

Receipt: listener, HAT y RAT

Un listener vincula SMTP a una interfaz IP y constituye el primer límite de políticas. Los listeners públicos suelen aceptar tráfico de Internet para dominios locales; los listeners privados reciben mensajes salientes desde redes controladas. Estas funciones son configuración, no una propiedad inherente de confianza del puerto. Un listener privado con una autorización de relay demasiado amplia es un relay abierto, aunque tenga un nombre interno.

La Host Access Table, HAT, asigna hosts conectados a Sender Groups. Sus Mail Flow Policies determinan, entre otros aspectos, si una conexión se acepta, rechaza, limita o procesa sin determinados escaneos. La Recipient Access Table, RAT, define dominios de destinatarios locales para mensajes entrantes. Opcionalmente, LDAP comprueba destinatarios concretos durante la sesión SMTP o posteriormente en la Work Queue; como alternativa, SMTP Call-Ahead puede consultar al servidor posterior. Cisco separa así cuatro identidades que no deben confundirse durante una incidencia: IP de origen, remitente del sobre, destinatario del sobre e identidades de cabecera (Cisco: Email Pipeline, Incoming).

Una documentación limpia del listener incluye, como mínimo por dirección, IP y puerto de enlace, redes de origen permitidas, nombres EHLO esperados, modo TLS, requisito de certificado de cliente, orden de HAT, dominios RAT, validación de destinatarios, tamaño máximo de mensaje, límites de tasa y perfil de rebote. El orden es especialmente crítico: un rechazo HAT temprano no genera un registro de Message ID como un mensaje aceptado posteriormente; por ello, un equipo de soporte no puede encontrarlo con la misma búsqueda.

Tras la aceptación SMTP comienza el procesamiento real de contenido y políticas. Su orden es importante porque un resultado temprano puede influir en comprobaciones posteriores, grupos de destinatarios o rutas de entrega.

Work Queue: orden, splintering y políticas

Tras la aceptación, el mensaje llega a la Work Queue. Cisco documenta allí routing y masquerading, Message Filters, listas seguras/de bloqueo, antispam, antivirus, Graymail, reputación y análisis de archivos, Content Filters, Outbreak Filters y cuarentenas. El orden forma parte del modelo de seguridad. Por lo general, un cambio de política no afecta retroactivamente a mensajes ya almacenados; por tanto, activar posteriormente un escáner no corrige automáticamente una omisión previa (Cisco: Email Pipeline, Work Queue).

Los Message Filters operan antes de la Mail Policy relacionada con el destinatario y pueden modificar, archivar, poner en cuarentena, rebotar o descartar mensajes en función del sobre, cabeceras, contenido, adjuntos o datos de conexión. Posteriormente, AsyncOS puede fragmentar un mensaje con varios destinatarios: se generan Message IDs separados para políticas de destinatarios diferentes y, por tanto, estados finales distintos. En consecuencia, un único valor original de inyección o ICID puede ramificarse en varios MID y resultados de entrega. El tracking debe mostrar este árbol, no limitarse a buscar por asunto.

Las Mail Policies controlan filtros de escaneo y contenido basados en destinatarios o remitentes. Según Cisco, DLP se limita al procesamiento saliente. Las licencias, el estado de actualización de los motores y la conectividad en la nube también determinan qué comprobaciones se realizan realmente. Para cada política, una prueba sólida requiere un caso positivo inocuo, un caso negativo específico y el estado final esperado: entrega, modificación, cuarentena, descarte o rebote.

Delivery: SMTP Routes, Destination Controls y cola

En la fase Delivery, AsyncOS selecciona la ruta, la interfaz de origen y el destino. Las SMTP Routes reemplazan la resolución MX normal para dominios configurados; los Destination Controls limitan conexiones paralelas y destinatarios por destino. Los Virtual Gateways pueden proporcionar distintas direcciones IP de origen, nombres de host y colas de entrega. Estos ajustes influyen en la reputación, SPF, inclusión en listas permitidas por pares y el lugar donde espera un mensaje (Cisco: Email Pipeline, Delivery, RFC 7208).

TLS saliente es hop-by-hop. AsyncOS puede utilizar STARTTLS con los pares; que funcione protege este tramo de transporte, pero no dice nada sobre saltos anteriores o posteriores. Para políticas forzadas deben documentarse patrones de destino, validación de certificados, relación con el nombre y comportamiento ante errores. TLS oportunista puede volver a texto plano si falla el handshake; una política obligatoria debe, en cambio, poner en cola o fallar (Cisco: Verify and Troubleshoot TLS Certificates, RFC 3207).

La antigüedad de la cola es más importante que su tamaño puro. Un volumen elevado puede ser saludable con un alto rendimiento; pocos mensajes muy antiguos indican un bloqueo persistente de destino, DNS, TLS o políticas. Para cada ruta, la imagen del incidente debe incluir el mensaje más antiguo, el motivo del reintento, el siguiente intento, la respuesta del destino y el par responsable.

En cuanto la ESA ha reenviado un mensaje o lo ha puesto en cuarentena, parte de la perspectiva administrativa se traslada al SMA. Sin embargo, no sustituye los datos locales de cola y sistema de la ESA.

SMA: tracking, reporting y cuarentenas

El SMA recopila datos de tracking y reporting de varios nodos SEG. Message Tracking puede mostrar estados finales como Delivered, Dropped, Bounced, Quarantined, Queued, Processing y Splintered. Sin embargo, es un índice derivado: si faltan datos de exportación, un servicio se retrasa o el mensaje queda fuera de retención, un resultado vacío no demuestra que el mensaje nunca se procesara. La evidencia principal sigue siendo los logs de correo correspondientes y la cadena MID en el SEG (Cisco: Tracking Messages).

La cuarentena de spam y las cuarentenas de políticas, virus y brotes son servicios separados con distintos usuarios, vías de liberación y retenciones. Las cuarentenas centralizadas almacenan mensajes en el SMA detrás del firewall y pueden incluirse en su copia de seguridad estándar. Con una ocupación del 75, 85 y 95 por ciento, AsyncOS genera alertas de umbral documentadas. Si un servicio central de cuarentena deja de estar disponible, la operación necesita una decisión previamente probada: poner temporalmente en cola, cambiar al procesamiento local o desactivar de forma controlada la política correspondiente (Cisco: Centralized Quarantines, Cisco: Centralizing Services).

Un clúster de configuración no es HA de correo

AsyncOS puede conectar varios gateways en un clúster de configuración peer-to-peer. Los ajustes se pueden mantener a nivel de clúster, grupo o máquina; no existe un nodo de clúster primario. Los miembros deben utilizar una versión compatible de AsyncOS y comunicarse mediante SSH o Cluster Communication Service. El clúster replica configuración, no sesiones SMTP activas, contenidos de cola, cuarentenas locales ni progreso de entrega (Cisco: Centralized Management Using Clusters).

Por ello, existen tres mecanismos separados:

• Distribución de tráfico: varios destinos MX, balanceadores de carga o failover de smarthost;
• Consistencia de configuración: clúster AsyncOS con overrides claros de clúster, grupo y máquina;
• Disponibilidad de datos: estado de cola por SEG y datos de tracking y cuarentena en el SMA.

La pérdida de un nodo tras una aceptación SMTP positiva puede afectar a mensajes que solo están en su cola local. El remitente no debe reenviarlos sin más mientras el estado original de entrega no esté claro; de lo contrario se generan duplicados. Por tanto, una prueba de recuperación no solo debe cargar la configuración, sino rastrear mensajes de prueba aceptados a través de una caída controlada de nodo.

Pila tecnológica y superficies de administración

AsyncOS es una plataforma de appliance cerrada. Cisco publica avisos de código abierto para los componentes incluidos, pero no un plan completo de código fuente o lenguajes de los servicios propietarios. Afirmaciones como «escrito en Python» o «basado en FreeBSD» no constituyen información operativa fiable sin evidencia del fabricante específica de la versión. Para los administradores es más relevante la siguiente pila verificable (Cisco: Open Source Used in AsyncOS):

Los cambios en la CLI siguen un patrón transaccional: los comandos modifican primero una configuración en ejecución, commit la activa y clearchanges la descarta. Un runbook debe indicar el diálogo completo y el modo de configuración; los fragmentos de copiar y pegar son peligrosos debido a diferencias entre versiones y clústeres. La API REST proporciona acceso autenticado de forma segura a informes, contadores, datos de tracking y cuarentena; su interfaz Swagger local documenta el alcance de API realmente instalado (Cisco: AsyncOS API, Cisco: SEG Support Documentation).

Dependencias de red, identidad y tiempo

Una vez establecida la canalización de correo, se pueden revisar sus conexiones externas. Cada fila muestra qué sistema inicia una conexión, para qué se necesita y cómo se manifiesta un error.

Los números de puerto por sí solos no prueban una función activa. Las asignaciones proceden de la IANA Service Name and Port Registry; Cisco documenta CCS y su configurabilidad en el capítulo de clústeres. Los firewalls deben incluir origen, destino, dirección, protocolo, requisitos de TLS o autenticación y finalidad empresarial.

LDAP puede alimentar la aceptación de destinatarios, routing, pertenencia a grupos y autenticación de administradores. Estas consultas tienen esquemas, tiempos de espera y consecuencias de error diferentes. Si falla Recipient Acceptance, el sistema puede, según la configuración, rebotar con retraso o descartar; por ello, un error de autenticación en la GUI no demuestra un defecto en la comprobación SMTP de destinatarios. Las cuentas de servicio, Base DN, filtros, comportamiento de referrals, cadena de certificados y orden de failover deben documentarse por consulta (Cisco: Email Pipeline, LDAP Recipient Acceptance, RFC 4511).

DNS y la hora correcta son dependencias del sistema. La resolución de MX y hosts controla la entrega y accesibilidad del clúster; PTR y reputación influyen en la clasificación. NTP mantiene correlacionables las horas de logs, Received y tracking. Cisco exige nombres de host resolubles o direcciones IP utilizadas de forma consistente para clústeres, y describe la hora del sistema y NTP como parte de la configuración básica (Cisco: Setup and Installation).

En caso de incidencias se sigue la misma ruta a la inversa: estado de entrega, decisión de Work Queue, política de Receipt, listener y dependencias de red.

Monitorización y triaje de incidentes

La pregunta central es: ¿Ha aceptado el gateway el mensaje, lo ha procesado y a qué salto lo ha entregado? Para ello, se encadenan identificadores de conexión, mensaje y entrega de los Mail Logs. Message Tracking en el SMA acelera la búsqueda, pero no sustituye los logs sin procesar. Las señales técnicas útiles son:

• tasa de aceptación, respuestas 4xx/5xx y conexiones rechazadas por listener y Sender Group;
• Work Queue y Delivery Queue, antigüedad del mensaje más antiguo y respuestas de destino recurrentes;
• duración de procesamiento y splintering, errores de Scan-Engine y antigüedad de actualizaciones;
• ocupación de cuarentenas locales y centralizadas, eventos de liberación y eliminación;
• valor de Resource Conservation, CPU, memoria, ocupación de disco y alertas críticas;
• disponibilidad y latencia de DNS, LDAP, SMA, servicios de actualización y nube;
• consistencia del clúster y Machine-Overrides no intencionados;
• vencimiento y uso de cada certificado TLS, así como cambios en el truststore.

En Resource Conservation Mode, AsyncOS limita progresivamente la aceptación para que la entrega pueda reducir el retraso; ante una escasez extrema de recursos no se aceptan mensajes nuevos. Por ello, el síntoma suele ser una disminución del rendimiento entrante, mientras que el desencadenante real es una ruta de destino lenta o un recurso lleno. Cisco proporciona estado y alertas en GUI/CLI; SNMPv3 y ASYNCOS-MAIL-MIB permiten monitorización externa (Cisco: Resource Conservation, Cisco: SNMP Monitoring).

Copia de seguridad, recuperación y actualización

Un archivo XML de configuración exportado es necesario, pero no es una copia de seguridad completa del sistema. Cisco documenta saveconfig, mailconfig y loadconfig; las frases de contraseña enmascaradas no se pueden volver a cargar. Los certificados y claves, el estado del clúster, Feature Keys, colas locales, cuarentenas locales, datos SMA y dependencias externas requieren evidencias propias (Cisco: System Administration, Cisco: Automated Configuration Backup).

Las actualizaciones son migraciones de appliance. Antes deben comprobarse ruta de destino, estados intermedios compatibles, requisitos de hipervisor o nube, cambios de funciones, orden del clúster, espacio libre, tiempo de inactividad y límite de rollback. Las categorías de versión GD y MD de Cisco no son una recomendación automática para todos los entornos; son determinantes los Security Advisories, la matriz de soporte y el alcance de políticas propio probado. La página de soporte y las explicaciones de ciclo de vida deben formar parte del procedimiento de parcheo, no figurar como número de versión estático en el artículo (Cisco: SEG Release Notes, Cisco: Software Lifecycle Support Statement).

Herramientas de diagnóstico

La resolución de problemas sigue la ruta del mensaje desde fuera hacia dentro. Primero se comprueban nombres y accesibilidad, después aceptación SMTP, eventos de canalización, cola y, si procede, la evaluación SMA.

DNS, MX y resolución de destino

Resolve-DnsName -Type MX example.ch
Resolve-DnsName seg1.example.ch -Type A,AAAA
Resolve-DnsName 192.0.2.25 -Type PTR

dig +short MX example.ch
dig +short A seg1.example.ch
dig +short AAAA seg1.example.ch
dig +short -x 192.0.2.25

Resolve-DnsName y dig muestran resolución MX, directa e inversa. La consulta debe repetirse desde la perspectiva de resolvedores internos y externos; las SMTP Routes de AsyncOS pueden anular el resultado MX visible.

TCP y SMTP-TLS

Test-NetConnection seg1.example.ch -Port 25 -InformationLevel Detailed
curl.exe --verbose --ssl-reqd smtp://seg1.example.ch:25

nc -vz seg1.example.ch 25
openssl s_client -starttls smtp -connect seg1.example.ch:25 \
  -servername seg1.example.ch -showcerts

Test-NetConnection y nc solo prueban la ruta TCP. curl y openssl s_client solicitan STARTTLS y muestran el handshake y la cadena de certificados; solo la validación esperada de nombre y confianza prueba la política TLS configurada.

Mensaje de prueba SMTP autorizado

curl.exe --verbose --ssl-reqd --url smtp://seg1.example.ch:25 `
  --mail-from test-sender@example.ch `
  --mail-rcpt test-recipient@example.net `
  --upload-file .\seg-test.eml

swaks --server seg1.example.ch --port 25 --tls \
  --from test-sender@example.ch --to test-recipient@example.net \
  --data seg-test.eml

curl y swaks envían un mensaje de prueba controlado. El remitente, destinatario y destino deben estar autorizados. Deben registrarse la respuesta SMTP final, ICID/MID, MID de fragmentación, política, estado de cuarentena o entrega y la llegada real.

Interfaz web y API REST

Invoke-WebRequest -Method Head -Uri https://sma.example.ch/
Invoke-WebRequest -Method Head -Uri https://seg1.example.ch/swagger

curl --head --verbose https://sma.example.ch/
curl --head --verbose https://seg1.example.ch/swagger

Invoke-WebRequest y curl comprueban accesibilidad HTTP y TLS. Un código de estado no prueba inicio de sesión, autorización de roles, importación de tracking ni función de cuarentena. La página Swagger solo describe la API de la instancia consultada; las pruebas de API de producción utilizan una cuenta mínima de solo lectura y no guardan tokens en el historial de shell.

Ruta de paquetes en un punto de medición autorizado

pktmon filter remove
pktmon filter add SEG-SMTP -p 25
pktmon start --capture --pkt-size 0 --file-name seg.etl
pktmon stop
pktmon pcapng seg.etl -o seg.pcapng

tcpdump -ni any -s 0 -w seg.pcap 'tcp port 25 or tcp port 443'

pktmon y tcpdump solo ven el tráfico en el punto de medición elegido. Un cliente administrador no observa automáticamente la ruta entre el balanceador de carga, SEG, SMA y el MTA de destino. Los datos de paquetes pueden contener contenido SMTP antes de STARTTLS y metadatos personales, por lo que deben protegerse en consecuencia.

Historia técnica

IronPort Systems desarrolló gateways de mensajería especializados y la línea de productos AsyncOS. Cisco anunció la adquisición de la empresa en enero de 2007 e integró su tecnología de seguridad de correo electrónico y web en su propia cartera de seguridad (Cisco: Agreement to Acquire IronPort). Posteriormente, los nombres de producto cambiaron de Cisco IronPort Email Security Appliance, pasando por Cisco Email Security Appliance, a Cisco Secure Email Gateway; términos históricos como ESA, C-Series y M-Series siguen siendo visibles en runbooks, mensajes de log, licencias y rutas de documentación.

La idea arquitectónica siguió siendo reconocible tras estos cambios de nombre: un gateway especializado con la canalización de tres etapas Receipt, Work Queue y Delivery, y un sistema de gestión separado para datos agregados y cuarentenas. Más tarde se añadieron appliances virtuales y de nube pública, Cloud Gateway, API REST y servicios de análisis basados en la nube. Email Threat Defense amplía la cartera con modelos de API, journaling y gateway; no modifica retroactivamente los límites de estado de una instalación ESA/SMA existente (Cisco: Secure Email Data Sheet, Cisco: Email Threat Defense).

Por ello, el nombre de una appliance instalada no basta como información de ciclo de vida. El modelo de hardware, plataforma virtual, rama AsyncOS, licencias activadas, actualizaciones de motores y reglas, así como servicios de nube dependientes, tienen ciclos de vida propios. Las páginas de soporte, versiones y fin de vida de Cisco son fuentes operativas dinámicas; un artículo estático debe enlazarlas, pero no fijar un estado de versión supuestamente siempre actual (Cisco: SEG End-of-Life Notices, Cisco: SEG Support).

Fuentes

• Cisco – AsyncOS User Guide: Understanding the Email Pipeline
• IETF RFC 5321 – Simple Mail Transfer Protocol
• Cisco – SMA User Guide: Tracking Messages
• Cisco – SMA User Guide: Centralized Quarantines
• Cisco – Open Source Used in Email Security Appliance AsyncOS
• Cisco – AsyncOS API
• Cisco – AsyncOS User Guide: Centralized Management Using Clusters
• Cisco – Secure Email Gateway and Secure Email and Web Manager Data Sheet
• Cisco – Secure Email Threat Defense Data Sheet
• IETF RFC 7208 – Sender Policy Framework
• Cisco – Verify and Troubleshoot TLS Certificates on ESA
• IETF RFC 3207 – SMTP Service Extension for Secure SMTP over TLS
• Cisco – Centralizing Services on a Secure Email and Web Manager
• Cisco – Secure Email Gateway Support Documentation
• IANA – Service Name and Transport Protocol Port Number Registry
• IETF RFC 4511 – Lightweight Directory Access Protocol
• Cisco – Setup and Installation
• Cisco – Resource Conservation Mode
• Cisco – SNMP Monitoring on ESA
• Cisco – AsyncOS User Guide: System Administration
• Cisco – Automate Configuration Backup of a Clustered ESA
• Cisco – Secure Email Gateway Release Notes
• Cisco – Secure Email Gateway Software Lifecycle Support Statement
• Microsoft Learn – Resolve-DnsName
• ISC BIND 9 – dig manpage
• Microsoft Learn – Test-NetConnection
• OpenBSD – nc manpage
• curl – command line manpage
• OpenSSL – s_client
• swaks – SMTP test tool
• Microsoft Learn – Invoke-WebRequest
• Microsoft Learn – pktmon
• tcpdump – manual page
• Cisco – Agreement to Acquire IronPort
• Cisco – Secure Email Gateway End-of-Life Notices