Cisco Secure Email: Gateway, AsyncOS e SMA

Cisco Secure Email Gateway, abbreviato SEG e storicamente Email Security Appliance o ESA, è un gateway di posta SMTP con stato . Termina le sessioni SMTP in entrata, decide l’accettazione, elabora i messaggi in una Work Queue interna e apre una nuova sessione SMTP per la consegna. Il confine della responsabilità tecnica non coincide quindi con il corretto handshake TCP o TLS, bensì con la risposta SMTP positiva dopo il contenuto del messaggio: da quel momento il gateway deve consegnare oppure generare un errore conforme allo standard (, ).

Il secondo ruolo classico è il Cisco Secure Email and Web Manager, SMA. Normalmente non opera come MTA regolare nel percorso produttivo della posta. Gestisce dati centralizzati di tracking e reporting nonché, a seconda del design, quarantene per spam, policy, virus e outbreak di più gateway. Un guasto dell’SMA può pertanto lasciare inalterata la consegna sui nodi SEG, interrompendo al contempo la ricerca, la quarantena dell’utente finale o la gestione dei messaggi trattenuti (, ).

Entrambi i ruoli operano su AsyncOS, una piattaforma software gestita da Cisco come unità appliance. Gli amministratori non gestiscono i pacchetti sottostanti come su un server Linux generico; l’interfaccia tecnica affidabile è costituita da configurazione AsyncOS, CLI, interfaccia web, REST API, sottoscrizioni ai log, MIB, canali di aggiornamento e integrazioni documentate. Le panoramiche Cisco sull’open source attestano numerosi componenti integrati, ma non un elenco pubblicamente manutenibile della pipeline di posta proprietaria. Le singole librerie non devono quindi essere equiparate all’architettura complessiva (, ).

La spiegazione segue un messaggio attraverso Cisco Secure Email: dal listener, tramite HAT, RAT e Work Queue, fino alla consegna. Seguono SMA, funzionamento in cluster, dipendenze, diagnostica e ripristino.

Ruoli del prodotto e limiti di fiducia

Un tipico design on-premises colloca almeno due nodi SEG nella DMZ e un SMA in una rete di gestione interna. Il DNS MX o un servizio a monte distribuiscono le connessioni in entrata ai gateway; in uscita, i connettori smarthost del sistema di posta determinano il percorso gateway. Più nodi SEG sono ad alta disponibilità solo quando DNS, load balancer o l’MTA mittente possono utilizzare destinazioni alternative. Il solo cluster di configurazione AsyncOS non assume questo instradamento del traffico (, ).

Cisco documenta appliance virtuali, deployment in Public Cloud e un Secure Email Cloud Gateway gestito. Queste varianti condividono termini di prodotto, ma spostano le responsabilità: per l’appliance virtuale, il cliente è responsabile di hypervisor, rete, capacità e ripristino; per il Cloud Gateway, Cisco fornisce l’infrastruttura del gateway. Secure Email Threat Defense è invece una piattaforma cloud-native di analisi e protezione, integrabile tramite gateway, journaling o API Microsoft. Non è né un sinonimo della Work Queue locale né un termine sostitutivo per l’SMA (, ).

Receipt: listener, HAT e RAT

Un listener associa SMTP a un’interfaccia IP e costituisce il primo limite di policy. I listener pubblici accettano tipicamente traffico Internet per domini locali; i listener privati ricevono messaggi in uscita da reti controllate. Questi ruoli sono configurazioni, non proprietà di fiducia intrinseche della porta. Un listener privato con autorizzazione relay troppo ampia è un open relay, anche se denominato interno.

La Host Access Table, HAT, assegna gli host che si connettono a Sender Groups. Le relative Mail Flow Policies stabiliscono, tra l’altro, se una connessione viene accettata, rifiutata, limitata o elaborata senza singole scansioni. La Recipient Access Table, RAT, definisce i domini destinatari locali per i messaggi in entrata. Facoltativamente, verifica destinatari specifici durante la sessione SMTP o successivamente nella Work Queue; in alternativa, SMTP Call-Ahead può interrogare il server a valle. Cisco separa così quattro identità che non devono essere confuse in caso di malfunzionamento: IP di origine, mittente envelope, destinatario envelope e identità delle intestazioni ().

Una documentazione pulita dei listener comprende per ciascuna direzione almeno IP e porta di binding, reti sorgenti consentite, nomi EHLO attesi, modalità TLS, requisiti per il certificato client, ordine HAT, domini RAT, verifica dei destinatari, dimensione massima del messaggio, rate limit e profilo di bounce. L’ordine è particolarmente critico: un rifiuto HAT anticipato non genera un record Message-ID come un messaggio accettato successivamente; l’helpdesk non può quindi trovarlo con la stessa ricerca.

Dopo l’accettazione SMTP inizia la vera elaborazione di contenuto e policy. Il suo ordine è importante, poiché un risultato anticipato può influenzare verifiche successive, gruppi di destinatari o percorsi di consegna.

Work Queue: ordine, splintering e policy

Dopo l’accettazione, il messaggio entra nella Work Queue. Cisco documenta routing e masquerading, Message Filters, Safe-/Blocklist, anti-spam, anti-virus, Graymail, reputazione e analisi dei file, Content Filters, Outbreak Filters e quarantene. L’ordine fa parte del modello di sicurezza. Una modifica di policy in genere non agisce retroattivamente sui messaggi già inseriti; l’attivazione successiva di uno scanner non ripara quindi automaticamente un bypass precedente ().

I Message Filters operano prima della Mail Policy basata sui destinatari e possono modificare, archiviare, mettere in quarantena, respingere o scartare messaggi in base a envelope, intestazioni, contenuto, allegati o dati di connessione. Successivamente AsyncOS può effettuare lo splintering di un messaggio con più destinatari: vengono creati Message ID separati per policy destinatario diverse e quindi stati finali differenti. Un singolo valore inject o ICID originale può pertanto ramificarsi in più MID e risultati di consegna. Il tracking deve mostrare questo albero, non limitarsi alla ricerca per oggetto.

Le Mail Policies controllano filtri di scansione e contenuto basati su destinatario o mittente. Secondo Cisco, DLP è limitato all’elaborazione in uscita. Licenze, stato di aggiornamento dei motori e connettività cloud determinano inoltre quali controlli vengono effettivamente eseguiti. Per ogni policy, un test affidabile richiede un caso positivo innocuo, un caso negativo mirato e lo stato finale atteso: consegna, modifica, quarantena, drop o bounce.

Delivery: SMTP Routes, Destination Controls e coda

Nella fase di Delivery, AsyncOS seleziona route, interfaccia sorgente e destinazione. Le SMTP Routes sostituiscono la normale risoluzione MX per i domini configurati; i Destination Controls limitano le connessioni parallele e i destinatari per destinazione. I Virtual Gateways possono fornire indirizzi IP sorgente, hostname e code di consegna differenti. Queste impostazioni influenzano reputazione, SPF, allowlist della controparte e il punto in cui un messaggio resta in attesa (, ).

TLS in uscita è hop-by-hop. AsyncOS può usare con le controparti; il successo protegge questo tratto di trasporto, ma non dice nulla sui hop precedenti o successivi. Per policy obbligatorie devono essere documentati pattern di destinazione, verifica dei certificati, relazione con il nome e comportamento in caso di errore. TLS opportunistico può ricadere in testo in chiaro in caso di errore di handshake; una policy obbligatoria deve invece accodare o fallire (, ).

L’età della coda è più importante della sola lunghezza della coda. Un volume elevato può essere sano con throughput elevato; pochi messaggi molto vecchi indicano un blocco persistente di destinazione, DNS, TLS o policy. Per ogni route, l’immagine dell’incidente deve includere il messaggio più vecchio, il motivo del retry, il prossimo tentativo, la risposta della destinazione e la controparte responsabile.

Non appena l’ESA ha inoltrato o messo in quarantena un messaggio, parte della visibilità amministrativa si sposta sull’SMA. Tuttavia, non sostituisce i dati locali di coda e sistema dell’ESA.

SMA: tracking, reporting e quarantene

L’SMA raccoglie dati di tracking e reporting da più nodi SEG. Il Message Tracking può mostrare stati finali quali Delivered, Dropped, Bounced, Quarantined, Queued, Processing e Splintered. Tuttavia è un indice derivato: se mancano dati di esportazione, un servizio è in ritardo o il messaggio è fuori dal periodo di conservazione, un risultato vuoto non dimostra che il messaggio non sia mai stato elaborato. La prova primaria restano i Mail Logs pertinenti e la catena MID sul SEG ().

La quarantena spam e le quarantene per policy/virus/outbreak sono servizi separati con utenti, percorsi di rilascio e conservazione differenti. Le quarantene centralizzate memorizzano i messaggi sull’SMA dietro il firewall e possono essere incluse nel relativo backup standard. Al 75, 85 e 95 per cento di occupazione, AsyncOS genera soglie di allarme documentate. Se un servizio di quarantena centralizzato diventa irraggiungibile, l’esercizio richiede una decisione testata in anticipo: accodare temporaneamente, riconfigurare l’elaborazione locale o disabilitare in modo controllato la policy associata (, ).

Il cluster di configurazione non è Mail HA

AsyncOS può collegare più gateway in un cluster di configurazione peer-to-peer. Le impostazioni possono essere mantenute a livello di cluster, gruppo o macchina; non esiste un nodo cluster primario. I membri devono usare una versione AsyncOS compatibile e comunicano tramite SSH o Cluster Communication Service. Il cluster replica la configurazione, non le sessioni SMTP attive, il contenuto delle code, le quarantene locali o lo stato di avanzamento della consegna ().

Esistono quindi tre meccanismi separati:

• Distribuzione del traffico: più destinazioni MX, load balancer o failover smarthost;
• Coerenza della configurazione: cluster AsyncOS con override chiari di cluster, gruppo e macchina;
• Disponibilità dei dati: stato della coda per SEG nonché dati di tracking e quarantena sull’SMA.

La perdita di un nodo dopo l’accettazione SMTP positiva può interessare messaggi presenti solo nella relativa coda locale. Il mittente non deve semplicemente inviarli di nuovo finché lo stato di consegna originale non è chiaro; altrimenti si generano duplicati. Un test di recovery deve quindi non solo caricare la configurazione, ma seguire messaggi di test accettati durante un guasto controllato del nodo.

Stack tecnologico e superfici di amministrazione

AsyncOS è una piattaforma appliance chiusa. Cisco pubblica avvisi open source per i componenti forniti, ma non un piano completo dei sorgenti o dei linguaggi dei servizi proprietari. Affermazioni come «scritto in Python» o «basato su FreeBSD» non sono informazioni operative affidabili senza una prova del produttore specifica per versione. Per gli amministratori è più rilevante il seguente stack verificabile ():

Le modifiche CLI seguono un modello transazionale: i comandi modificano inizialmente una configurazione in esecuzione, commit la attiva, clearchanges la scarta. Un runbook deve indicare il dialogo completo e la modalità di configurazione; semplici frammenti copy-and-paste sono pericolosi a causa delle differenze tra release e cluster. La REST API offre accesso autenticato in modo sicuro a report, contatori, dati di tracking e quarantena; la sua interfaccia Swagger locale documenta l’effettivo ambito API installato (, ).

Dipendenze di rete, identità e tempo

Dopo aver definito la pipeline della posta, è possibile verificare le sue connessioni esterne. Ogni riga mostra quale sistema avvia una connessione, a cosa serve e come si manifesta un errore.

I soli numeri di porta non dimostrano una funzione attiva. Le assegnazioni provengono da ; Cisco documenta CCS e la sua configurabilità nel capitolo sui cluster. I firewall dovrebbero contenere sorgente, destinazione, direzione, protocollo, requisiti TLS o di autenticazione e scopo aziendale.

può alimentare l’accettazione dei destinatari, il routing, l’appartenenza ai gruppi e l’autenticazione admin. Queste query hanno schemi, timeout e conseguenze degli errori differenti. Se Recipient Acceptance non funziona, a seconda della configurazione il sistema può effettuare un bounce ritardato o scartare; un errore di autenticazione della GUI non prova quindi un difetto della verifica SMTP dei destinatari. Account di servizio, Base DN, filtri, comportamento dei referral, catena di certificati e ordine di failover devono essere documentati per ciascuna query (, ).

DNS e orario corretto sono dipendenze di sistema. La risoluzione MX e host controlla la consegna e la raggiungibilità del cluster; PTR e reputazione influenzano la classificazione. NTP mantiene correlabili gli orari dei log, Received e tracking. Cisco richiede hostname risolvibili o indirizzi IP usati in modo coerente per i cluster e descrive l’ora di sistema e NTP come parte della configurazione di base ().

In caso di guasti, si segue lo stesso percorso a ritroso: stato di delivery, decisione della Work Queue, policy di receipt, listener e dipendenze di rete.

Monitoraggio e triage degli incidenti

La domanda centrale è: il gateway ha accettato il messaggio, lo ha elaborato e a quale hop lo ha consegnato? A tal fine, gli ID di connessione, messaggio e delivery dei Mail Logs vengono concatenati. Il Message Tracking sull’SMA accelera la ricerca, ma non sostituisce i log grezzi. Segnali tecnici utili sono:

• tasso di accettazione, risposte 4xx/5xx e connessioni rifiutate per listener e Sender Group;
• Work Queue e Delivery Queue, età del messaggio più vecchio e risposte ricorrenti delle destinazioni;
• durata dell’elaborazione e dello splintering, errori dei motori di scansione ed età degli aggiornamenti;
• occupazione delle quarantene locali e centralizzate, eventi di rilascio e cancellazione;
• valore Resource Conservation, CPU, memoria, occupazione disco e alert critici;
• raggiungibilità e latenza di DNS, LDAP, SMA, servizi di aggiornamento e cloud;
• coerenza del cluster e override della macchina non intenzionali;
• scadenza e utilizzo di ogni certificato TLS nonché modifiche al truststore.

In Resource Conservation Mode, AsyncOS riduce gradualmente l’accettazione affinché la consegna possa smaltire l’arretrato; in caso di estrema carenza di risorse non vengono accettati nuovi messaggi. Il sintomo è quindi spesso una riduzione del throughput in ingresso, mentre la causa effettiva è una route di destinazione lenta o una risorsa esaurita. Cisco fornisce stato e alert in GUI/CLI; SNMPv3 e ASYNCOS-MAIL-MIB consentono il monitoraggio esterno (, ).

Backup, recovery e upgrade

Un file di configurazione XML esportato è necessario, ma non costituisce un backup completo del sistema. Cisco documenta saveconfig, mailconfig e loadconfig; le passphrase mascherate non possono essere ricaricate. Certificati e chiavi, stato del cluster, Feature Keys, code locali, quarantene locali, dati SMA e dipendenze esterne richiedono prove proprie (, ).

Gli upgrade sono migrazioni dell’appliance. Prima vanno verificati percorso di destinazione, stati intermedi compatibili, requisiti dell’hypervisor o del cloud, modifiche delle funzionalità, ordine del cluster, spazio libero, downtime e limite di rollback. Le categorie di release Cisco GD e MD non sono una raccomandazione automatica per ogni ambiente; fanno fede i Security Advisories, la matrice di supporto e l’ambito delle policy proprie testato. La pagina di supporto e le spiegazioni sul lifecycle devono far parte della procedura di patch, non essere riportate come numero di versione statico nell’articolo (, ).

Strumenti diagnostici

La ricerca dei guasti segue il percorso del messaggio dall’esterno verso l’interno. Prima vengono verificati nomi e raggiungibilità, poi accettazione SMTP, eventi della pipeline, coda e, se necessario, la valutazione SMA.

Risoluzione DNS, MX e destinazione

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 e dig mostrano la risoluzione MX, forward e reverse. La query va ripetuta dalla prospettiva dei resolver interni ed esterni; le SMTP Routes di AsyncOS possono sostituire il risultato MX visibile.

TCP e 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 e nc dimostrano solo il percorso TCP. curl e openssl s_client richiedono STARTTLS e mostrano handshake e catena di certificati; solo la verifica prevista del nome e della fiducia dimostra la policy TLS configurata.

Messaggio SMTP di test autorizzato

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 e swaks inviano un messaggio di test controllato. Mittente, destinatario e destinazione devono essere autorizzati. Occorre registrare risposta SMTP finale, ICID/MID, MID di splintering, policy, stato di quarantena o delivery e arrivo effettivo.

Interfaccia web e 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 e curl verificano raggiungibilità HTTP e TLS. Un codice di stato non dimostra né accesso né autorizzazione di ruolo, importazione del tracking o funzionamento della quarantena. La pagina Swagger descrive solo l’API dell’istanza contattata; i test API produttivi usano un account minimo in sola lettura e non salvano token nella cronologia della shell.

Percorso pacchetti presso un punto di misurazione autorizzato

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 e tcpdump vedono solo il traffico nel punto di misurazione scelto. Un client admin non osserva automaticamente il percorso tra load balancer, SEG, SMA e MTA di destinazione. I dati dei pacchetti possono contenere contenuti SMTP prima di STARTTLS e metadati personali e devono essere protetti di conseguenza.

Storia tecnica

IronPort Systems sviluppò gateway di messaggistica specializzati e la linea di prodotti AsyncOS. Cisco annunciò l’acquisizione dell’azienda nel gennaio 2007 e assegnò la tecnologia di sicurezza email e web al proprio portafoglio di sicurezza (). In seguito, i nomi dei prodotti passarono da Cisco IronPort Email Security Appliance a Cisco Email Security Appliance fino a Cisco Secure Email Gateway; termini storici quali ESA, C-Series e M-Series restano visibili in runbook, messaggi di log, licenze e percorsi della documentazione.

L’idea architetturale è rimasta riconoscibile attraverso queste ridenominazioni: un gateway specializzato con la pipeline a tre stadi Receipt, Work Queue e Delivery e un sistema di gestione separato per dati aggregati e quarantene. In seguito si sono aggiunte appliance virtuali e Public Cloud, Cloud Gateway, REST API e servizi di analisi basati sul cloud. Email Threat Defense amplia il portafoglio con modelli API, journaling e gateway; non modifica retroattivamente i limiti di stato di un’installazione ESA/SMA esistente (, ).

Il nome di un’appliance installata non è quindi sufficiente come informazione sul lifecycle. Modello hardware, piattaforma virtuale, ramo AsyncOS, licenze attivate, aggiornamenti di motori e regole nonché servizi cloud dipendenti hanno cicli di vita propri. Le pagine Cisco di supporto, release ed end-of-life sono fonti operative dinamiche; un articolo statico dovrebbe collegarle, ma non fissare un presunto stato di versione sempre aggiornato (, ).

Fonti