Cisco Secure Email: Gateway, AsyncOS og SMA

Cisco Secure Email Gateway, forkortet SEG og historisk Email Security Appliance eller ESA, er en tilstandsbevarende SMTP-e-postgateway. Den avslutter innkommende SMTP-økter, avgjør om de skal godtas, behandler meldinger i en intern Work Queue og oppretter en ny SMTP-økt for levering. Den tekniske ansvarsgrensen ligger dermed ikke ved vellykket TCP- eller TLS-handshake, men ved det positive SMTP-svaret etter meldingsinnholdet: Fra dette tidspunktet må gatewayen levere eller generere en standardkonform feil (Cisco: Email Pipeline, RFC 5321).

Den andre klassiske rollen er Cisco Secure Email and Web Manager, SMA. Den står normalt ikke som en ordinær MTA i den produktive e-postflyten. Den håndterer sentrale sporings- og rapporteringsdata samt – avhengig av design – spam-, policy-, virus- og utbruddskarantener fra flere gatewayer. En feil på SMA kan derfor la leveringen på SEG-nodene fortsette upåvirket, samtidig som søk, sluttbrukerkarantene eller behandling av tilbakeholdte meldinger avbrytes (Cisco: SMA Message Tracking, Cisco: Centralized Quarantines).

Begge rollene kjører på AsyncOS, en programvareplattform Cisco vedlikeholder som en appliance-enhet. Administratorer administrerer ikke underliggende pakker som på en generell Linux-server; den pålitelige tekniske flaten består av AsyncOS-konfigurasjon, CLI, webgrensesnitt, REST-API, loggabonnementer, MIB-er, oppdateringskanaler og dokumenterte integrasjoner. Ciscos oversikter over åpen kildekode dokumenterer en rekke innebygde komponenter, men ingen offentlig vedlikeholdbar stykklistе over den proprietære e-postpipelinen. Enkelte biblioteker må derfor ikke sidestilles med totalarkitekturen (Cisco: Open Source Used in AsyncOS, Cisco: AsyncOS API).

Forklaringen følger en melding gjennom Cisco Secure Email: fra Listener via HAT, RAT og Work Queue til levering. Deretter følger SMA, klyngedrift, avhengigheter, diagnose og gjenoppretting.

Produktroller og tillitsgrenser

Et typisk lokalt design plasserer minst to SEG-noder i DMZ og én SMA i et internt administrasjonsnettverk. DNS-MX eller en foranliggende tjeneste fordeler innkommende forbindelser til gatewayene; utgående bestemmer smarthost-koblinger i e-postsystemet gatewaybanen. Flere SEG-noder er først høyt tilgjengelige når DNS, lastbalanserer eller den sendende MTA-en kan bruke alternative mål. AsyncOS-konfigurasjonsklyngen alene utfører ikke denne trafikkstyringen (Cisco: Centralized Management Using Clusters, RFC 5321, Address Resolution).

Cisco dokumenterer virtuelle appliances, Public Cloud-distribusjoner og en driftet Secure Email Cloud Gateway. Disse variantene deler produktbegreper, men flytter ansvar: For den virtuelle appliancen har kunden ansvar for hypervisor, nettverk, kapasitet og gjenoppretting; med Cloud Gateway leverer Cisco gatewayinfrastrukturen. Secure Email Threat Defense er derimot en skybasert analyse- og beskyttelsesplattform som kan integreres via gateway, journaling eller Microsoft-API. Den er verken et synonym for den lokale Work Queue eller et alternativt navn for SMA (Cisco: Secure Email Data Sheet, Cisco: Email Threat Defense Data Sheet).

Receipt: Listener, HAT og RAT

En Listener binder SMTP til et IP-grensesnitt og utgjør den første policygrensen. Public Listeners mottar vanligvis internettrafikk for lokale domener; Private Listeners mottar utgående meldinger fra kontrollerte nettverk. Disse rollene er konfigurasjon, ikke en iboende tillitsegenskap ved porten. En Private Listener med for bred relaytillatelse er et Open Relay, selv om den har et internt navn.

Host Access Table, HAT, tilordner tilkoblende verter til Sender Groups. Deres Mail Flow Policies bestemmer blant annet om en forbindelse skal godtas, avvises, begrenses eller behandles uten enkelte skanninger. Recipient Access Table, RAT, definerer lokale mottakerdomener for innkommende meldinger. Valgfritt kontrollerer LDAP konkrete mottakere under SMTP-økten eller senere i Work Queue; alternativt kan SMTP Call-Ahead spørre den etterfølgende serveren. Cisco skiller dermed mellom fire identiteter som ikke må blandes ved en feil: kilde-IP, konvoluttavsender, konvoluttmottaker og headeridentiteter (Cisco: Email Pipeline, Incoming).

En ryddig Listener-dokumentasjon inneholder minst bind-IP og port per retning, tillatte kildenettverk, forventede EHLO-navn, TLS-modus, krav til klientsertifikat, HAT-rekkefølge, RAT-domener, mottakerkontroll, maksimal meldingsstørrelse, rate limits og bounce-profil. Rekkefølgen er særlig kritisk: En tidlig HAT-avvisning oppretter ingen Message-ID-post slik en senere godtatt melding gjør; helpdesk kan derfor ikke finne den med samme søk.

Etter SMTP-godkjenning begynner den egentlige innholds- og policybehandlingen. Rekkefølgen er viktig fordi et tidlig resultat kan påvirke senere kontroller, mottakergrupper eller leveringsbaner.

Work Queue: rekkefølge, splintering og policy

Etter godkjenning kommer meldingen inn i Work Queue. Cisco dokumenterer der routing og masquerading, Message Filters, Safe-/Blocklists, Anti-Spam, Anti-Virus, Graymail, filomdømme og -analyse, Content Filters, Outbreak Filters og karantener. Rekkefølgen er en del av sikkerhetsmodellen. En policyendring virker vanligvis ikke tilbake på meldinger som allerede er lagt i kø; senere aktivering av en skanner reparerer derfor ikke automatisk en tidligere bypass (Cisco: Email Pipeline, Work Queue).

Message Filters arbeider før den mottakerrelaterte Mail Policy og kan endre, arkivere, sette i karantene, bounce eller forkaste meldinger basert på konvolutt, headere, innhold, vedlegg eller forbindelsesdata. Deretter kan AsyncOS splitte en melding med flere mottakere: Ulike mottakerpolicyer oppretter separate Message IDs og dermed ulike sluttilstander. Én opprinnelig inject- eller ICID-verdi kan derfor forgrene seg til flere MIDs og leveringsresultater. Sporing må vise dette treet, ikke bare søke etter emne.

Mail Policies styrer mottaker- eller avsenderrelaterte skanne- og innholdsfiltre. Ifølge Cisco er DLP begrenset til utgående behandling. Lisenser, oppdateringsstatus for motorene og skytilkobling avgjør i tillegg hvilke kontroller som faktisk utføres. For hver policy trenger en robust test en ufarlig positiv test, en målrettet negativ test og forventet sluttilstand – levering, endring, karantene, drop eller bounce.

Delivery: SMTP Routes, Destination Controls og kø

I Delivery-fasen velger AsyncOS rute, kildegrensesnitt og mål. SMTP Routes overstyrer normal MX-oppløsning for konfigurerte domener; Destination Controls begrenser parallelle forbindelser og mottakere per mål. Virtual Gateways kan tilby ulike kilde-IP-adresser, vertsnavn og leveringskøer. Disse innstillingene påvirker omdømme, SPF, allowlisting hos motparter og stedet der en melding venter (Cisco: Email Pipeline, Delivery, RFC 7208).

Utgående TLS er hop-by-hop. AsyncOS kan bruke STARTTLS med motparter; suksess beskytter denne transportstrekningen, men sier ingenting om foregående eller påfølgende hopp. For tvungne policyer må målmønstre, sertifikatkontroll, navnerelasjon og feiloppførsel dokumenteres. Opportunistisk TLS kan falle tilbake til klartekst ved handshakefeil; en obligatorisk policy må i stedet sette i kø eller feile (Cisco: Verify and Troubleshoot TLS Certificates, RFC 3207).

Køalder er viktigere enn ren kølengde. Et høyt volum kan være sunt ved høy gjennomstrømning; få svært gamle meldinger peker på en vedvarende mål-, DNS-, TLS- eller policyblokkering. For hver rute skal den eldste meldingen, retryårsak, neste forsøk, målsvar og ansvarlig motpart inngå i hendelsesbildet.

Så snart ESA har videresendt eller satt en melding i karantene, flyttes deler av administratorens oversikt til SMA. Den erstatter imidlertid ikke lokale kø- og systemdata på ESA.

SMA: sporing, rapportering og karantener

SMA samler sporings- og rapporteringsdata fra flere SEG-noder. Message Tracking kan vise sluttilstander som Delivered, Dropped, Bounced, Quarantined, Queued, Processing og Splintered. Det er imidlertid en avledet indeks: Hvis eksportdata mangler, en tjeneste er forsinket eller meldingen ligger utenfor oppbevaringstiden, beviser ikke et tomt treff at meldingen aldri ble behandlet. Primærbeviset er fortsatt de relevante Mail Logs og MID-kjeden på SEG (Cisco: Tracking Messages).

Spamkarantene og policy-/virus-/utbruddskarantener er separate tjenester med ulike brukere, frigivelsesprosesser og oppbevaringstider. Sentraliserte karantener lagrer meldinger på SMA bak brannmuren og kan inkluderes i standardbackupen. Ved 75, 85 og 95 prosent kapasitetsbruk genererer AsyncOS dokumenterte terskelvarsler. Hvis en sentral karantenetjeneste blir utilgjengelig, trenger driften en forhåndstestet beslutning: midlertidig sette i kø, endre til lokal behandling eller kontrollert deaktivere den tilhørende policyen (Cisco: Centralized Quarantines, Cisco: Centralizing Services).

Konfigurasjonsklynge er ikke e-post-HA

AsyncOS kan koble flere gatewayer til en peer-to-peer-konfigurasjonsklynge. Innstillinger kan holdes på klynge-, gruppe- eller maskinnivå; det finnes ingen primær klyngenode. Medlemmene må bruke en kompatibel AsyncOS-versjon og kommuniserer via SSH eller Cluster Communication Service. Klyngen replikerer konfigurasjon, ikke aktive SMTP-økter, køinnhold, lokale karantener eller leveringsfremdrift (Cisco: Centralized Management Using Clusters).

Derfor finnes tre separate mekanismer:

• Trafikkfordeling: flere MX-mål, lastbalanserer eller smarthost-failover;
• Konfigurasjonskonsistens: AsyncOS-klynge med klare overstyringer på klynge-, gruppe- og maskinnivå;
• Datatilgjengelighet: køtilstand per SEG samt sporings- og karantenedata på SMA.

Tap av en node etter positiv SMTP-godkjenning kan påvirke meldinger som bare ligger i den lokale køen. Avsenderen må ikke bare sende dem på nytt så lenge den opprinnelige leveringsstatusen er uklar; ellers oppstår duplikater. En gjenopprettingstest må derfor ikke bare laste konfigurasjonen, men følge godtatte testmeldinger gjennom en kontrollert nodefeil.

Teknologistakk og administrasjonsflater

AsyncOS er en lukket applianceplattform. Cisco publiserer merknader om åpen kildekode for medfølgende komponenter, men ingen fullstendig kilde- eller språkplan for proprietære tjenester. Påstander som «skrevet i Python» eller «basert på FreeBSD» er ikke pålitelig driftsinformasjon uten versjonsspesifikk produsentdokumentasjon. For administratorer er følgende dokumenterbare stakk mer relevant (Cisco: Open Source Used in AsyncOS):

CLI-endringer følger et transaksjonelt mønster: Kommandoer endrer først en kjørende konfigurasjon, commit aktiverer den, clearchanges forkaster den. En runbook må angi hele dialogen og konfigurasjonsmodusen; rene copy-and-paste-fragmenter er farlige på grunn av forskjeller mellom utgivelser og klynger. REST-API-et gir sikkert autentisert tilgang til rapporter, tellere, sporings- og karantenedata; det lokale Swagger-grensesnittet dokumenterer det faktisk installerte API-omfanget (Cisco: AsyncOS API, Cisco: SEG Support Documentation).

Nettverks-, identitets- og tidsavhengigheter

Når e-postpipelinen er fastlagt, kan eksterne forbindelser kontrolleres. Hver rad viser hvilket system som starter en forbindelse, hva den trengs til og hvordan feil viser seg.

Portnumre alene dokumenterer ingen aktiv funksjon. Tilordningene kommer fra IANA Service Name and Port Registry; Cisco dokumenterer CCS og konfigurerbarheten i klyngekapitlet. Brannmurer bør inkludere kilde, mål, retning, protokoll, TLS- eller autentiseringskrav og forretningsformål.

LDAP kan forsyne mottakergodkjenning, ruting, gruppemedlemskap og administratorautentisering. Disse spørringene har ulike skjemaer, tidsavbrudd og feilkonsekvenser. Hvis Recipient Acceptance svikter, kan systemet avhengig av konfigurasjon bounce forsinket eller forkaste; en autentiseringsfeil i GUI er derfor ikke bevis på feil i SMTP-mottakerkontrollen. Tjenestekontoer, Base DNs, filtre, referral-oppførsel, sertifikatkjede og failoverrekkefølge skal dokumenteres per spørring (Cisco: Email Pipeline, LDAP Recipient Acceptance, RFC 4511).

DNS og korrekt tid er systemavhengigheter. MX- og vertsuppløsning styrer levering og klyngenåbarhet; PTR og omdømme påvirker klassifisering. NTP holder logg-, Received- og sporingstider korrelerbare. Cisco krever oppløsbare vertsnavn eller konsekvent brukte IP-adresser for klynger og beskriver systemtid samt NTP som del av grunnkonfigurasjonen (Cisco: Setup and Installation).

Ved feil følges samme bane bakover: leveringsstatus, Work Queue-beslutning, Receipt-policy, Listener og nettverksavhengigheter.

Overvåking og hendelsestriage

Det sentrale spørsmålet er: Godtok gatewayen meldingen, behandlet den og overleverte den til hvilket hopp? Til dette kobles forbindelses-, meldings- og Delivery-ID-er fra Mail Logs sammen. Message Tracking på SMA fremskynder søket, men erstatter ikke råloggene. Nyttige tekniske signaler er:

• Godkjenningsrate, 4xx-/5xx-svar og avviste forbindelser per Listener og Sender Group;
• Work- og Delivery-kø, alder på eldste melding samt gjentakende målsvar;
• Behandlings- og splinteringstid, Scan-Engine-feil og oppdateringsalder;
• Lokal og sentral karantenefylling, frigivelses- og slettingshendelser;
• Resource-Conservation-verdi, CPU, minne, diskbruk og kritiske varsler;
• Tilgjengelighet og latens for DNS, LDAP, SMA, oppdaterings- og skytjenester;
• Klyngekonsistens og utilsiktede Machine Overrides;
• Utløp og bruk av hvert TLS-sertifikat samt endringer i Truststore.

I Resource Conservation Mode begrenser AsyncOS godkjenning trinnvis slik at leveringen kan redusere etterslepet; ved ekstrem ressursmangel godtas ingen nye meldinger. Symptomet er derfor ofte synkende innkommende gjennomstrømning, mens den egentlige utløsende faktoren er en langsom målroute eller full ressurs. Cisco tilbyr status og varsler i GUI/CLI; SNMPv3 og ASYNCOS-MAIL-MIB muliggjør ekstern overvåking (Cisco: Resource Conservation, Cisco: SNMP Monitoring).

Backup, gjenoppretting og oppgradering

En eksportert XML-konfigurasjonsfil er nødvendig, men ingen fullstendig systembackup. Cisco dokumenterer saveconfig, mailconfig og loadconfig; maskerte passfraser kan ikke lastes inn igjen. Sertifikater og nøkler, klyngetilstand, Feature Keys, lokale køer, lokale karantener, SMA-data samt eksterne avhengigheter trenger egne bevis (Cisco: System Administration, Cisco: Automated Configuration Backup).

Oppgraderinger er appliance-migreringer. Først må målbane, kompatible mellomtilstander, hypervisor- eller skykrav, funksjonsendringer, klyngerekkefølge, ledig lagring, nedetid og rollbackgrense kontrolleres. Ciscos utgivelseskategorier GD og MD er ingen automatisk anbefaling for ethvert miljø; avgjørende er Security Advisories, supportmatrise og det testede egne policyomfanget. Supportsiden og livssyklusforklaringene hører hjemme i patchprosedyren, ikke som et statisk versjonsnummer i artikkelen (Cisco: SEG Release Notes, Cisco: Software Lifecycle Support Statement).

Diagnoseverktøy

Feilsøkingen følger meldingsveien utenfra og innover. Først kontrolleres navn og tilgjengelighet, deretter SMTP-godkjenning, pipelinehendelser, kø og eventuelt SMA-evaluering.

DNS, MX og målopp­løsning

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 og dig viser MX-, fremover- og reversoppløsning. Spørringen må gjentas fra interne og eksterne resolverperspektiver; AsyncOS SMTP Routes kan overstyre det synlige MX-resultatet.

TCP og 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 og nc dokumenterer kun TCP-banen. curl og openssl s_client ber om STARTTLS og viser handshake samt sertifikatkjede; først forventet navne- og tillitskontroll dokumenterer den konfigurerte TLS-policyen.

Autorisert SMTP-testmelding

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 og swaks sender en kontrollert testmelding. Avsender, mottaker og mål må være autorisert. SMTP-sluttsvar, ICID/MID, Splinter-MIDs, policy, karantene- eller Delivery-status og faktisk ankomst skal registreres.

Webgrensesnitt og 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 og curl kontrollerer HTTP- og TLS-tilgjengelighet. En statuskode dokumenterer verken pålogging eller rolleautorisasjon, sporingsimport eller karantenefunksjon. Swagger-siden beskriver bare API-et til instansen som adresseres; produktive API-tester bruker en minimal skrivebeskyttet konto og lagrer ikke tokens i shellhistorikken.

Pakkebane ved et autorisert målepunkt

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 og tcpdump ser bare trafikken ved det valgte målepunktet. En administratorklient observerer ikke automatisk banen mellom lastbalanserer, SEG, SMA og mål-MTA. Pakkedata kan inneholde SMTP-innhold før STARTTLS og personrelaterte metadata, og må beskyttes tilsvarende.

Teknisk historie

IronPort Systems utviklet spesialiserte meldingsgatewayer og AsyncOS-produktlinjen. Cisco annonserte oppkjøpet av selskapet i januar 2007 og innlemmet e-post- og web-sikkerhetsteknologien i sin egen sikkerhetsportefølje (Cisco: Agreement to Acquire IronPort). Produktnavnene skiftet deretter fra Cisco IronPort Email Security Appliance via Cisco Email Security Appliance til Cisco Secure Email Gateway; historiske begreper som ESA, C-Series og M-Series er fortsatt synlige i runbooks, loggmeldinger, lisenser og dokumentasjonsstier.

Arkitekturideen forble gjenkjennelig gjennom disse omdøpingene: en spesialisert gateway med tretrinnspipelinen Receipt, Work Queue og Delivery samt et separat administrasjonssystem for aggregerte data og karantener. Senere kom virtuelle og Public Cloud-appliances, Cloud Gateway, REST-API-er og skybaserte analysetjenester. Email Threat Defense utvider porteføljen med API-, journaling- og gatewaymodeller; den endrer ikke i ettertid tilstandsgrensene til en eksisterende ESA-/SMA-installasjon (Cisco: Secure Email Data Sheet, Cisco: Email Threat Defense).

Navnet på en installert appliance er derfor ikke tilstrekkelig livssyklusinformasjon. Maskinvaremodell, virtuell plattform, AsyncOS-gren, aktiverte lisenser, motor- og regeloppdateringer samt avhengige skytjenester har egne livssykluser. Ciscos support-, utgivelses- og End-of-Life-sider er dynamiske driftskilder; en statisk artikkel bør lenke til dem, men ikke fastslå en angivelig varig aktuell versjonsstatus (Cisco: SEG End-of-Life Notices, Cisco: SEG Support).

Kilder

• 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