Cisco Secure Email: Gateway, AsyncOS und SMA

Cisco Secure Email Gateway, kurz SEG und historisch Email Security Appliance oder ESA, ist ein zustandsbehaftetes SMTP-Mail-Gateway. Es beendet eingehende SMTP-Sitzungen, entscheidet über die Annahme, verarbeitet Nachrichten in einer internen Work Queue und eröffnet für die Zustellung eine neue SMTP-Sitzung. Damit liegt die technische Verantwortungsgrenze nicht beim erfolgreichen TCP- oder TLS-Handshake, sondern bei der positiven SMTP-Antwort nach dem Nachrichteninhalt: Ab diesem Moment muss das Gateway zustellen oder einen normgerechten Fehler erzeugen (Cisco: Email Pipeline, RFC 5321).

Die zweite klassische Rolle ist der Cisco Secure Email and Web Manager, SMA. Er steht normalerweise nicht als regulärer MTA im produktiven Mailpfad. Er übernimmt zentrale Tracking- und Reportingdaten sowie – je nach Design – Spam-, Policy-, Virus- und Outbreak-Quarantänen mehrerer Gateways. Ein Ausfall des SMA kann daher die Zustellung auf den SEG-Knoten unberührt lassen und zugleich Suche, Endbenutzerquarantäne oder die Bearbeitung zurückgehaltener Nachrichten unterbrechen (Cisco: SMA Message Tracking, Cisco: Centralized Quarantines).

Beide Rollen laufen auf AsyncOS, einer von Cisco als Appliance-Einheit gepflegten Softwareplattform. Administratoren verwalten nicht die darunterliegenden Pakete wie auf einem allgemeinen Linux-Server; die belastbare technische Oberfläche besteht aus AsyncOS-Konfiguration, CLI, Weboberfläche, REST-API, Logabonnements, MIBs, Updatekanälen und den dokumentierten Integrationen. Ciscos Open-Source-Übersichten belegen zahlreiche eingebettete Komponenten, aber keine öffentlich wartbare Stückliste der proprietären Mailpipeline. Einzelne Bibliotheken dürfen deshalb nicht mit der Gesamtarchitektur gleichgesetzt werden (Cisco: Open Source Used in AsyncOS, Cisco: AsyncOS API).

Die Erklärung begleitet eine Nachricht durch Cisco Secure Email: vom Listener über HAT, RAT und Work Queue bis zur Zustellung. Danach folgen SMA, Clusterbetrieb, Abhängigkeiten, Diagnose und Wiederherstellung.

Produktrollen und Vertrauensgrenzen

Ein typisches On-Premises-Design setzt mindestens zwei SEG-Knoten in die DMZ und einen SMA in ein internes Managementnetz. DNS-MX oder ein vorgeschalteter Dienst verteilen eingehende Verbindungen auf die Gateways; ausgehend bestimmen Smarthost-Connectoren des Mailsystems den Gatewaypfad. Mehrere SEG-Knoten sind erst dann hochverfügbar, wenn DNS, Load Balancer oder der sendende MTA alternative Ziele verwenden können. Der AsyncOS-Konfigurationscluster allein übernimmt diese Verkehrslenkung nicht (Cisco: Centralized Management Using Clusters, RFC 5321, Address Resolution).

Cisco dokumentiert virtuelle Appliances, Public-Cloud-Deployments und einen betriebenen Secure Email Cloud Gateway. Diese Varianten teilen Produktbegriffe, verschieben aber Verantwortung: Bei der virtuellen Appliance verantwortet der Kunde Hypervisor, Netzwerk, Kapazität und Restore; beim Cloud Gateway stellt Cisco die Gateway-Infrastruktur bereit. Secure Email Threat Defense ist wiederum eine cloudnative Analyse- und Schutzplattform, die per Gateway, Journaling oder Microsoft-API integriert werden kann. Sie ist weder ein Synonym für die lokale Work Queue noch ein Ersatzbegriff für den SMA (Cisco: Secure Email Data Sheet, Cisco: Email Threat Defense Data Sheet).

Receipt: Listener, HAT und RAT

Ein Listener bindet SMTP an eine IP-Schnittstelle und bildet die erste Policygrenze. Public Listener nehmen typischerweise Internetverkehr für lokale Domänen an; Private Listener erhalten ausgehende Nachrichten aus kontrollierten Netzen. Diese Rollen sind Konfiguration, keine inhärente Vertrauenseigenschaft des Ports. Ein Private Listener mit zu breiter Relayfreigabe ist ein Open Relay, auch wenn er intern benannt ist.

Die Host Access Table, HAT, ordnet verbindende Hosts Sender Groups zu. Deren Mail Flow Policies bestimmen unter anderem, ob eine Verbindung angenommen, abgewiesen, gedrosselt oder ohne einzelne Scans verarbeitet wird. Die Recipient Access Table, RAT, definiert für eingehende Nachrichten lokale Empfängerdomänen. Optional prüft LDAP konkrete Empfänger während der SMTP-Sitzung oder später in der Work Queue; alternativ kann SMTP Call-Ahead den nachgelagerten Server befragen. Cisco trennt damit vier Identitäten, die bei einer Störung nicht vermischt werden dürfen: Quell-IP, Envelope-Absender, Envelope-Empfänger und Headeridentitäten (Cisco: Email Pipeline, Incoming).

Eine saubere Listenerdokumentation enthält je Richtung mindestens Bind-IP und Port, erlaubte Quellnetze, erwartete EHLO-Namen, TLS-Modus, Clientzertifikatsanforderung, HAT-Reihenfolge, RAT-Domänen, Empfängerprüfung, maximale Nachrichtengrösse, Rate Limits und Bounce-Profil. Besonders kritisch ist die Reihenfolge: Eine frühe HAT-Ablehnung erzeugt keinen Message-ID-Datensatz wie eine später angenommene Nachricht; ein Helpdesk kann sie deshalb nicht mit derselben Suche finden.

Nach der SMTP-Annahme beginnt die eigentliche Inhalts- und Policyverarbeitung. Ihre Reihenfolge ist wichtig, weil ein frühes Resultat spätere Prüfungen, Empfängergruppen oder Zustellwege beeinflussen kann.

Work Queue: Reihenfolge, Splintering und Policy

Nach der Annahme gelangt die Nachricht in die Work Queue. Cisco dokumentiert dort Routing und Masquerading, Message Filters, Safe-/Blocklists, Anti-Spam, Anti-Virus, Graymail, Datei-Reputation und -Analyse, Content Filters, Outbreak Filters und Quarantänen. Die Reihenfolge ist Teil des Sicherheitsmodells. Eine Policyänderung wirkt im Allgemeinen nicht rückwirkend auf bereits eingelagerte Nachrichten; eine nachträgliche Aktivierung eines Scanners repariert daher nicht automatisch einen vorherigen Bypass (Cisco: Email Pipeline, Work Queue).

Message Filters arbeiten vor der empfängerbezogenen Mail Policy und können Nachrichten anhand von Envelope, Headern, Inhalt, Anhängen oder Verbindungsdaten verändern, archivieren, quarantänisieren, bouncen oder verwerfen. Danach kann AsyncOS eine Nachricht mit mehreren Empfängern splintern: Für unterschiedliche Empfängerpolicies entstehen getrennte Message IDs und damit unterschiedliche Endzustände. Ein einziger ursprünglicher Inject- oder ICID-Wert kann folglich in mehrere MIDs und Zustellresultate verzweigen. Tracking muss diesen Baum zeigen, nicht nur nach Betreff suchen.

Die Mail Policies steuern empfänger- oder absenderbezogene Scan- und Content-Filter. DLP ist laut Cisco auf ausgehende Verarbeitung beschränkt. Lizenzen, Updatezustand der Engines und Cloudkonnektivität entscheiden zusätzlich, welche Prüfungen tatsächlich stattfinden. Für jede Policy braucht ein belastbarer Test einen harmlosen Positivfall, einen gezielten Negativfall und den erwarteten Endzustand – Zustellung, Änderung, Quarantäne, Drop oder Bounce.

Delivery: SMTP Routes, Destination Controls und Queue

In der Delivery-Phase wählt AsyncOS Route, Quellinterface und Ziel. SMTP Routes überschreiben die normale MX-Auflösung für konfigurierte Domänen; Destination Controls begrenzen parallele Verbindungen und Empfänger pro Ziel. Virtual Gateways können unterschiedliche Quell-IP-Adressen, Hostnamen und Zustellqueues bereitstellen. Diese Einstellungen beeinflussen Reputation, SPF, Gegenstellen-Allowlisting und den Ort, an dem eine Nachricht wartet (Cisco: Email Pipeline, Delivery, RFC 7208).

Outbound-TLS ist hop-by-hop. AsyncOS kann STARTTLS mit Gegenstellen verwenden; der Erfolg schützt diese Transportstrecke, sagt aber nichts über vorherige oder nachfolgende Hops aus. Für erzwungene Richtlinien müssen Zielmuster, Zertifikatsprüfung, Namensbezug und Fehlerverhalten dokumentiert sein. Opportunistisches TLS darf bei einem Handshakefehler in Klartext zurückfallen; eine verpflichtende Policy muss stattdessen queuen oder scheitern (Cisco: Verify and Troubleshoot TLS Certificates, RFC 3207).

Queuealter ist wichtiger als reine Queuelänge. Ein hohes Volumen kann bei hohem Durchsatz gesund sein; wenige sehr alte Nachrichten weisen auf eine hartnäckige Ziel-, DNS-, TLS- oder Policyblockade hin. Für jede Route gehören älteste Nachricht, Retrygrund, nächster Versuch, Zielantwort und verantwortliche Gegenstelle in das Incidentbild.

Sobald die ESA eine Nachricht weitergegeben oder quarantänisiert hat, verlagert sich ein Teil der Administratorsicht auf die SMA. Sie ist jedoch kein Ersatz für die lokalen Queue- und Systemdaten der ESA.

SMA: Tracking, Reporting und Quarantänen

Der SMA sammelt Tracking- und Reportingdaten mehrerer SEG-Knoten. Message Tracking kann Endzustände wie Delivered, Dropped, Bounced, Quarantined, Queued, Processing und Splintered darstellen. Es ist aber ein abgeleiteter Index: Fehlen Exportdaten, ist ein Dienst verzögert oder liegt die Nachricht ausserhalb der Aufbewahrung, beweist ein leerer Treffer nicht, dass die Nachricht nie verarbeitet wurde. Primärnachweis bleiben die passenden Mail Logs und die MID-Kette auf dem SEG (Cisco: Tracking Messages).

Spamquarantäne und Policy-/Virus-/Outbreak-Quarantänen sind getrennte Dienste mit unterschiedlichen Benutzern, Freigabewegen und Aufbewahrungen. Zentralisierte Quarantänen speichern Nachrichten auf dem SMA hinter der Firewall und können in dessen Standardsicherung einbezogen werden. Bei 75, 85 und 95 Prozent Belegung erzeugt AsyncOS dokumentierte Schwellenalarme. Wird ein zentraler Quarantänedienst unerreichbar, braucht der Betrieb eine vorab getestete Entscheidung: temporär queuen, lokale Verarbeitung umstellen oder die zugehörige Policy kontrolliert deaktivieren (Cisco: Centralized Quarantines, Cisco: Centralizing Services).

Konfigurationscluster ist keine Mail-HA

AsyncOS kann mehrere Gateways zu einem peer-to-peer Konfigurationscluster verbinden. Einstellungen lassen sich auf Cluster-, Gruppen- oder Maschinenebene halten; es gibt keinen primären Clusterknoten. Die Mitglieder müssen eine kompatible AsyncOS-Version verwenden und kommunizieren per SSH oder Cluster Communication Service. Das Cluster repliziert Konfiguration, nicht aktive SMTP-Sitzungen, Queueinhalte, lokale Quarantänen oder Zustellfortschritt (Cisco: Centralized Management Using Clusters).

Deshalb bestehen drei getrennte Mechanismen:

• Verkehrsverteilung: mehrere MX-Ziele, Load Balancer oder Smarthost-Failover;
• Konfigurationskonsistenz: AsyncOS-Cluster mit klaren Cluster-, Gruppen- und Machine-Overrides;
• Datenverfügbarkeit: Queuezustand pro SEG sowie Tracking- und Quarantänedaten auf dem SMA.

Ein Knotenverlust nach positiver SMTP-Annahme kann Nachrichten betreffen, die nur auf dessen lokaler Queue liegen. Der Absender darf sie nicht einfach erneut senden, solange der ursprüngliche Zustellstatus unklar ist; sonst entstehen Duplikate. Ein Recoverytest muss daher nicht nur die Konfiguration laden, sondern angenommene Testnachrichten durch einen kontrollierten Knotenausfall verfolgen.

Technologiestack und Administrationsflächen

AsyncOS ist eine geschlossene Applianceplattform. Cisco veröffentlicht Open-Source-Hinweise für mitgelieferte Komponenten, aber keinen vollständigen Quell- oder Sprachplan der proprietären Dienste. Aussagen wie „in Python geschrieben“ oder „basiert auf FreeBSD“ sind ohne versionsspezifischen Herstellernachweis keine belastbare Betriebsinformation. Für Admins ist folgender nachweisbarer Stack relevanter (Cisco: Open Source Used in AsyncOS):

CLI-Änderungen folgen einem transaktionalen Muster: Befehle ändern zunächst eine laufende Konfiguration, commit aktiviert sie, clearchanges verwirft sie. Ein Runbook muss den vollständigen Dialog und den Konfigurationsmodus nennen; reine Copy-and-paste-Fragmente sind wegen Release- und Clusterunterschieden gefährlich. Die REST-API liefert sicher authentisierten Zugriff auf Reports, Zähler, Tracking- und Quarantänedaten; ihre lokale Swagger-Oberfläche dokumentiert den tatsächlich installierten API-Umfang (Cisco: AsyncOS API, Cisco: SEG Support Documentation).

Netzwerk-, Identitäts- und Zeitabhängigkeiten

Nachdem die Mailpipeline feststeht, können ihre externen Verbindungen geprüft werden. Jede Zeile zeigt, welches System eine Verbindung beginnt, wofür sie gebraucht wird und wie sich ein Fehler bemerkbar macht.

Portnummern allein belegen keine aktive Funktion. Die Zuordnungen stammen aus der IANA Service Name and Port Registry; CCS und seine Konfigurierbarkeit dokumentiert Cisco im Clusterkapitel. Firewalls sollten Quelle, Ziel, Richtung, Protokoll, TLS- oder Authentisierungsanforderung und geschäftlichen Zweck enthalten.

LDAP kann Empfängerannahme, Routing, Gruppenmitgliedschaft und Adminauthentisierung speisen. Diese Abfragen haben unterschiedliche Schemata, Timeouts und Fehlerfolgen. Fällt Recipient Acceptance aus, darf das System je nach Konfiguration verzögert bouncen oder verwerfen; ein Authentisierungsfehler der GUI ist deshalb kein Beleg für einen Defekt der SMTP-Empfängerprüfung. Servicekonten, Base DNs, Filter, Referralverhalten, Zertifikatskette und Failoverreihenfolge sind pro Query zu dokumentieren (Cisco: Email Pipeline, LDAP Recipient Acceptance, RFC 4511).

DNS und korrekte Zeit sind Systemabhängigkeiten. MX- und Hostauflösung steuern Zustellung und Clustererreichbarkeit; PTR und Reputation beeinflussen Klassifikation. NTP hält Log-, Received- und Trackingzeiten korrelierbar. Cisco verlangt für Cluster auflösbare Hostnamen oder konsistent verwendete IP-Adressen und beschreibt Systemzeit sowie NTP als Teil der Grundkonfiguration (Cisco: Setup and Installation).

Bei Störungen wird derselbe Pfad rückwärts verfolgt: Deliverystatus, Work-Queue-Entscheidung, Receipt-Policy, Listener und Netzwerkabhängigkeiten.

Monitoring und Incident-Triage

Die zentrale Frage lautet: Hat das Gateway die Nachricht angenommen, verarbeitet und an welchen Hop übergeben? Dazu werden Verbindungs-, Message- und Delivery-IDs aus den Mail Logs verkettet. Message Tracking auf dem SMA beschleunigt die Suche, ersetzt aber nicht die Rohlogs. Sinnvolle technische Signale sind:

• Annahmerate, 4xx-/5xx-Antworten und abgewiesene Verbindungen je Listener und Sender Group;
• Work- und Delivery-Queue, Alter der ältesten Nachricht sowie wiederkehrende Zielantworten;
• Processing- und Splinteringdauer, Scan-Engine-Fehler und Updatealter;
• lokale und zentrale Quarantänebelegung, Freigabe- und Löschereignisse;
• Resource-Conservation-Wert, CPU, Speicher, Plattenbelegung und kritische Alerts;
• Erreichbarkeit und Latenz von DNS, LDAP, SMA, Update- und Cloudservices;
• Clusterkonsistenz und unbeabsichtigte Machine-Overrides;
• Ablauf und Verwendung jedes TLS-Zertifikats sowie Truststore-Änderungen.

Im Resource Conservation Mode drosselt AsyncOS die Annahme schrittweise, damit die Zustellung den Rückstand abbauen kann; bei extremer Ressourcenknappheit werden keine neuen Nachrichten angenommen. Das Symptom ist deshalb oft sinkender Inbound-Durchsatz, während der eigentliche Auslöser eine langsame Zielroute oder volle Ressource ist. Cisco stellt Status und Alerts in GUI/CLI bereit; SNMPv3 und ASYNCOS-MAIL-MIB ermöglichen externes Monitoring (Cisco: Resource Conservation, Cisco: SNMP Monitoring).

Backup, Recovery und Upgrade

Ein exportiertes XML-Konfigurationsfile ist notwendig, aber kein vollständiges Systembackup. Cisco dokumentiert saveconfig, mailconfig und loadconfig; maskierte Passphrasen können nicht wieder geladen werden. Zertifikate und Schlüssel, Clusterzustand, Feature Keys, lokale Queues, lokale Quarantänen, SMA-Daten sowie externe Abhängigkeiten benötigen eigene Nachweise (Cisco: System Administration, Cisco: Automated Configuration Backup).

Upgrades sind Appliancemigrationen. Vorher sind Zielpfad, kompatible Zwischenstände, Hypervisor- oder Cloudvorgaben, Featureänderungen, Clusterreihenfolge, freier Speicher, Downtime und Rollbackgrenze zu prüfen. Ciscos Releasekategorien GD und MD sind keine automatische Empfehlung für jede Umgebung; massgeblich sind Security Advisories, Supportmatrix und der getestete eigene Policyumfang. Die Supportseite und Lifecycle-Erklärungen gehören ins Patchverfahren, nicht als statische Versionszahl in den Artikel (Cisco: SEG Release Notes, Cisco: Software Lifecycle Support Statement).

Diagnosewerkzeuge

Die Fehlersuche folgt dem Nachrichtenweg von aussen nach innen. Zuerst werden Namen und Erreichbarkeit geprüft, danach SMTP-Annahme, Pipelineereignisse, Queue und gegebenenfalls die SMA-Auswertung.

DNS, MX und Zielauflösung

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 und dig zeigen MX-, Forward- und Reverseauflösung. Die Abfrage ist aus interner und externer Resolverperspektive zu wiederholen; AsyncOS SMTP Routes können das sichtbare MX-Ergebnis übersteuern.

TCP und 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 und nc belegen nur den TCP-Pfad. curl und openssl s_client fordern STARTTLS an und zeigen Handshake sowie Zertifikatskette; erst die erwartete Namens- und Trustprüfung belegt die konfigurierte TLS-Policy.

Autorisierte SMTP-Testnachricht

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 und swaks senden eine kontrollierte Testnachricht. Absender, Empfänger und Ziel müssen autorisiert sein. Festzuhalten sind SMTP-Endantwort, ICID/MID, Splinter-MIDs, Policy, Quarantäne oder Delivery-Status und die tatsächliche Ankunft.

Weboberfläche und REST-API

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 und curl prüfen HTTP- und TLS-Erreichbarkeit. Ein Statuscode belegt weder Anmeldung noch Rollenberechtigung, Trackingimport oder Quarantänefunktion. Die Swagger-Seite beschreibt nur die API der angesprochenen Instanz; produktive API-Tests verwenden ein minimales Read-only-Konto und speichern keine Tokens in der Shellhistorie.

Paketpfad an einer autorisierten Messstelle

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 und tcpdump sehen nur den Verkehr an der gewählten Messstelle. Ein Adminclient beobachtet nicht automatisch den Pfad zwischen Load Balancer, SEG, SMA und Ziel-MTA. Paketdaten können SMTP-Inhalte vor STARTTLS und personenbezogene Metadaten enthalten und sind entsprechend zu schützen.

Technische Geschichte

IronPort Systems entwickelte spezialisierte Messaging-Gateways und die AsyncOS-Produktlinie. Cisco kündigte die Übernahme des Unternehmens im Januar 2007 an und ordnete dessen E-Mail- und Web-Security-Technik dem eigenen Sicherheitsportfolio zu (Cisco: Agreement to Acquire IronPort). Produktnamen wechselten in der Folge von Cisco IronPort Email Security Appliance über Cisco Email Security Appliance zu Cisco Secure Email Gateway; historische Begriffe wie ESA, C-Series und M-Series bleiben in Runbooks, Logmeldungen, Lizenzen und Dokumentationspfaden sichtbar.

Die Architekturidee blieb über diese Umbenennungen erkennbar: ein spezialisiertes Gateway mit der dreistufigen Pipeline Receipt, Work Queue und Delivery sowie ein separates Managementsystem für aggregierte Daten und Quarantänen. Später kamen virtuelle und Public-Cloud-Appliances, Cloud Gateway, REST-APIs und cloudbasierte Analysedienste hinzu. Email Threat Defense erweitert das Portfolio um API-, Journaling- und Gatewaymodelle; es ändert nicht rückwirkend die Zustandsgrenzen einer vorhandenen ESA-/SMA-Installation (Cisco: Secure Email Data Sheet, Cisco: Email Threat Defense).

Der Name einer installierten Appliance reicht deshalb nicht als Lifecycleinformation. Hardwaremodell, virtuelle Plattform, AsyncOS-Zweig, aktivierte Lizenzen, Engine- und Regelupdates sowie abhängige Cloudservices haben eigene Lebenszyklen. Ciscos Support-, Release- und End-of-Life-Seiten sind dynamische Betriebsquellen; ein statischer Artikel sollte sie verlinken, aber keinen vermeintlich dauerhaft aktuellen Versionsstand festschreiben (Cisco: SEG End-of-Life Notices, Cisco: SEG Support).