Comunicazioni

Server Trasporto Edge di Microsoft Exchange

Kay Unkroth

Panoramica:

• Ruolo del server Trasporto Edge di Exchange
• Configurazione di un laboratorio per i test
• Agenti ed eventi di trasporto
• Agenti interni

Scarica il codice per questo articolo: ExchangeEdge2007_10.exe (354KB)

In media, in un giorno lavorativo Microsoft riceve ogni giorno circa 13 milioni di tentativi di inoltro di messaggi da Internet e ne blocca oltre 10,5 milioni in quanto non legittimi. In situazioni

critiche, ad esempio durante attacchi di posta indesiderata o virus su Internet, il volume può aumentare fino a superare i 90 milioni. Naturalmente queste informazioni si riferiscono a Microsoft, tuttavia attacchi di phishing, posta indesiderata e virus introdotti con la posta elettronica, directory harvesting, attacchi distribuiti Denial of Service (DDoS) e problemi simili non interessano solo Microsoft. Nell'affrontare problemi di questo tipo, come viene garantita la distribuzione di messaggi legittimi agli utenti continuando a proteggere l'ambiente di messaggistica dal flusso di contenuti illegittimi e dannosi?

Un modo per ottenere una protezione della messaggistica affidabile consiste nel distribuire i server Trasporto Edge e Forefront Security per Exchange Server di Exchange Server 2007 in una rete perimetrale tra Internet e l'ambiente di produzione. In questo modo per tutto il perimetro viene collocato un team organizzato di oltre 10 agenti Trasporto Edge che consentono di proteggere gli utenti e i sistemi di produzione. L'importanza di bloccare il prima possibile il contenuto indesiderato è evidente. In teoria, ciò accade persino prima che il contenuto venga distribuito ai server, considerando il carico che l'ambiente di messaggistica deve sostenere in una situazione critica. Tuttavia, per proteggere la messaggistica è possibile fare molto di più che bloccare semplicemente i messaggi.

Questa è la prima parte di una serie dedicata all'architettura e alle funzionalità chiave di agenti contro virus e posta indesiderata disponibili con Exchange Server 2007 e Forefront Security per Exchange Server. Affinché le spiegazioni siano realistiche e pratiche, in questo primo articolo verrà illustrato come creare un laboratorio per i test che rispecchi il progetto di protezione della messaggistica utilizzato da Microsoft nell'ambiente di produzione aziendale. In seguito, verrà analizzata in dettaglio l'architettura Trasporto Edge di Exchange Server 2007.

In tutto l'articolo si farà grande uso di script e file batch per automatizzare le attività di configurazione più importanti. Questi file contengono commenti che spiegano i singoli passaggi eseguiti. È possibile trovare gli script nel download disponibile nel sito Web TechNet Magazine all'indirizzo technetmagazine.com/code07.aspx.

Topologia Trasporto Edge

Nella Figura 1 viene illustrato il progetto Trasporto Edge implementato da Microsoft IT nell'ambiente di produzione aziendale. Prima di approfondire l'architettura Trasporto Edge, è opportuno analizzare alcune funzionalità di progettazione molto interessanti. Per i dettagli relativi all'implementazione completa, vedere il white paper IT Showcase indicato nella barra laterale "Risorse di Exchange".

Figura 1** Topologia Trasporto Edge in Microsoft **(Fare clic sull'immagine per ingrandirla)

Se si analizza la Figura 1, è possibile notare che la topologia Trasporto Edge in Microsoft è completamente ridondante. Non esiste un solo punto di errore in qualsiasi posizione. Per il bilanciamento del carico, Microsoft IT utilizza esternamente il DNS round robin e internamente i connettori di messaggistica con più teste di ponte. È importante notare anche che per la ricerca di virus tutti i server di trasporto (Hub ed Edge) eseguono Forefront Security per Exchange Server. In questo modo Microsoft IT è in grado di eseguire la scansione di tutti i messaggi in ingresso e in uscita non appena questi raggiungono un server di trasporto nella topologia di invio dei messaggi.

Un altro aspetto importante della progettazione relativo alla protezione riguarda i server Trasporto Edge che non fanno parte dell'ambiente Active Directory®. Infatti, non è necessario distribuire i server Trasporto Edge in nessuna foresta di Active Directory. Tuttavia, per mantenere un framework di gestione coerente, è necessario applicare una serie di criteri comune e supportare Single Sign-On. Microsoft distribuisce tutti i server Trasporto Edge in una foresta extranet diversa dall'ambiente di produzione.

Infine, è possibile vedere come tutti i messaggi provenienti da Internet raggiungono Microsoft tramite i server Trasporto Edge con sede in Nord America. I server Trasporto Edge con sede a Dublino e a Singapore gestiscono soltanto i messaggi in uscita. Il vantaggio di concentrare tutto il traffico in ingresso sui server Trasporto Edge del Nord America consiste nel centralizzare i controlli di protezione e contro la posta indesiderata impedendo l'invio dei messaggi in uscita da datacenter regionali di grandi dimensioni alla struttura di messaggistica interna.

Omesh Desai, Systems Engineer di Microsoft IT, ha progettato la topologia Trasporto Edge in Microsoft. Quando ho chiesto a Omesh informazioni sulle più importanti funzionalità di progettazione, ha risposto "Durante la progettazione del server Trasporto Edge, sono state sfruttate le funzionalità di difesa da posta indesiderata e virus di Exchange per la protezione della messaggistica a più livelli nella struttura della messaggistica. La protezione perimetrale della messaggistica ha la priorità, ma un modello di gestione semplice è ugualmente importante. I server Trasporto Edge consentono di migliorare la protezione attraverso configurazioni firewall più rigide pur consentendo maggiore accuratezza dei servizi contro la posta indesiderata tramite la reputazione IP, gli aggiornamenti automatici del filtro contenuti, l'aggregazione dell'elenco indirizzi attendibili, nonché la convalida del timbro per i messaggi di posta elettronica. Per impostazione predefinita vengono crittografate tutte le comunicazioni interne tra server e, se possibile vengono crittografate anche le comunicazioni con le destinazioni esterne.

"Nei server Trasporto Edge, vengono utilizzati due processori dual core a 64 bit e otto gigabyte di memoria. Sei di questi server, il cui carico di lavoro è stato bilanciato attraverso in due datacenter, sono sufficienti per sostenere picchi di inoltro messaggi come avviene durante attacchi di virus in Internet".

Laboratorio per i test di Trasporto Edge

Installazione del laboratorio per i test

Poiché è consigliabile utilizzare nomi di dominio e indirizzi IP privati non esistenti, decidiamo di utilizzare AdventureWorks.com e gli indirizzi IP negli intervalli 192.168.xxx.0-24. Non sono presenti sistemi ridondanti o array di firewall perché non sto eseguendo il test del bilanciamento del carico o della tolleranza di errore. Ovviamente, per motivi di sicurezza, non è possibile discutere degli attuali sistemi firewall utilizzati da Microsoft IT. Questi dettagli non sono importanti per questo ambiente di test.

Nel mio ambiente di test utilizzo ISA Server 2006 perché è probabilmente uno dei sistemi firewall più comuni utilizzato con Exchange Server 2007. L'esecuzione di ISA Server 2006 su entrambi i firewall, interno ed esterno, consente di mantenere a un livello moderato la complessità dell'ambiente di test, sebbene per aumentare la protezione negli ambienti di produzione consiglio l'uso di diversi sistemi firewall esterni e interni. Poiché questi aggiornamenti non rientrano nell'ambito di questo articolo, non sono stati distribuiti i criteri IP Security (IPSEC) e non è stato preparato l'ambiente per Transport Layer Security (TLS).

Tuttavia, ho utilizzato le macchine virtuali e un software di valutazione a 32 bit, che è possibile scaricare dal sito Web di Microsoft. Microsoft non supporta la versione a 32 bit di Exchange Server 2007 in fase di produzione, ma questo non rappresenta un problema in un ambiente di test.

Dove possibile, il laboratorio per i test si basa sulle impostazioni predefinite. Soltanto la configurazione IP, i firewall e le aree DNS richiedono particolare attenzione prima di eseguire Exchange Server 2007 e sottoscrivere il server Trasporto Edge nell'ambiente di produzione. Per i dettagli relativi alla configurazione dell'indirizzo IP, fare riferimento, nel laboratorio per i test, al file IP Configuration.xls che si trova nel download complementare. Se si utilizzano le stesse assegnazioni dell'indirizzo IP, è possibile configurare rapidamente il firewall esterno, definito ISA01, eseguendo lo script ISA01_Firewall_Policies.vbs direttamente nel computer ISA01 e utilizzare ISA02_Firewall_Policies.vbs per il firewall interno (ISA02). Il download complementare contiene anche i file batch che consentono di configurare i server DNS (INTERNET01_DNS_Config.bat, AD01_DNS_Config.bat e AD02_DNS_Config.bat). Poiché questi file batch utilizzano lo strumento della riga di comando DNS (dnscmd.exe), è necessario che vengano installati gli strumenti di supporto di Windows, altrimenti, è necessario creare manualmente i record DNS utilizzando la console DNS.

Per evitare qualunque interferenza proveniente dagli ambienti esistenti, il mio laboratorio per i test non è connesso a Internet. Questo isolamento è una buona precauzione perché impedisce il download degli aggiornamenti della firma, della reputazione IP, nonché degli aggiornamenti del filtro contenuti, ma questo non è fondamentale per lo scopo dei nostri test. Per evitare i messaggi di errore, è necessario passare a Aggiornamenti utilità di analisi nella console amministratore di Forefront Server Security, quindi impostare la frequenza di aggiornamento per tutti i motori di scansione e specificare una data nel passato.

Per analizzare queste funzionalità in azione, è utile creare un ambiente di test. Il buon senso suggerisce di non utilizzare mai un sistema di produzione per eseguire un test. È necessario prima di tutto un server che esegue Exchange Server 2007 per i ruoli server Cassetta postale, Accesso client e Trasporto Hub ed è necessario un secondo server Exchange per il ruolo del server Trasporto Edge. È possibile ignorare l'installazione del server Trasporto Edge se vengono distribuiti tutti gli agenti di trasporto sul server con più ruoli eseguendo lo script Install-AntispamAgents.ps1 (disponibile sui server Trasporto Hub nella cartella %ProgramFiles%\Microsoft\Exchange Server\Scripts). Questo approccio, però, non assomiglia affatto alla distribuzione di Microsoft IT. Un laboratorio per i test realistico deve ricorrere a più server. Nella Figura 2 viene illustrato l'ambiente di test utilizzato per la ricerca di questo articolo. Un'illustrazione più dettagliata è disponibile nel download complementare. Per ulteriori informazioni sull'impostazione del laboratorio, vedere la barra laterale "Installazione del laboratorio per i test".

Figura 2** Ambiente di test di Trasporto Edge **(Fare clic sull'immagine per ingrandirla)

Durante la sottoscrizione del server Trasporto Edge e la configurazione dei connettori associati, Microsoft IT rimuove tutti i connettori predefiniti e procede poi alla creazione di quattro connettori di invio per comunicare in modo efficiente con diversi tipi di host SMTP (Simple Mail Transfer Protocol) e server Trasporto Hub interni. Il primo connettore di invio è un connettore Internet generale per tutte le destinazioni che non corrispondono a specifiche definizioni dello spazio degli indirizzi.

Il secondo connettore di invio è un connettore Internet con le definizioni dettagliate di spazio degli indirizzi per le destinazioni conosciute che non supportano SMTP estesi (domini HELO). Impostando il parametro ForceHELO per questo connettore su $true, durante le connessioni SMTP Microsoft IT evita una sequenza inutile di EHLO, Failure Response 500.

Il terzo è un connettore Internet con le definizioni dettagliate di spazio degli indirizzi per i partner e altri domini remoti che supportano TLS per comunicare in maniera sicura durante le connessioni crittografate (domini TLS). Questo connettore prevede che il parametro RequireTLS sia impostato su $true.

Il quarto connettore di invio è un connettore in ingresso che consente di trasferire i messaggi ricevuti via Internet ai server Trasporto Hub nell'ambiente aziendale. Ancora, per ulteriori dettagli relativi alla configurazione del server Trasporto Edge, vedere il white paper IT Showcase della barra laterale "Risorse di Exchange" alla fine di questo articolo.

Per applicare una topologia del connettore di tipo Microsoft IT al laboratorio per i test, ho seguito una procedura basata sugli script creata da Omesh per uso interno da parte di Microsoft IT. Per motivi legati alla protezione, ho modificato e accorciato drasticamente i singoli comandi, ma la topologia del connettore risultante corrisponde ancora alla topologia di Microsoft IT. Di seguito viene riportata la procedura:

1. Sul server Exchange con più ruoli (HUB-MBX-01) e il server Trasporto Edge (EDGE01), rimuovere i connettori predefiniti.
2. In HUB-MBX-01, creare un nuovo connettore di ricezione eseguendo lo script HUB-MBX-01_recv_connector.ps1, disponibile nel download di questo articolo.
3. Su EDGE01, creare due nuovi connettori di ricezione per la connettività di messaggistica interna ed esterna eseguendo lo script EDGE01_recv_connector.ps1.
4. Su EDGE01, creare un file di sottoscrizione utilizzando il seguente comando:

    New-EdgeSubscription -FileName 
    "c:\subscriptionfile.xml" 

In seguito, copiare il file di sottoscrizione risultante nella cartella principale del server Trasporto Hub (c:\subscriptionfile.xml).

5. Su HUB-MBX-01, verificare che il percorso del file di sottoscrizione sia c:\subscriptionfile.xml, quindi eseguire lo script HUB-MBX-01_complete_subscription.ps1. Questo script importa il file di sottoscrizione per la Sincronizzazione Edge senza la creazione automatica di un connettore di invio, crea i connettori di invio per Internet e la connettività interna e replica la configurazione risultante al server Trasporto Edge tramite la Sincronizzazione Edge.

6. Verificare la configurazione inviando messaggi di test come Contoso.User@contoso.com e Fabrikam.User@fabrikam.com dall'host Internet a Administrator@adventureworks.com e rispondendo ai messaggi ricevuti per verificare il funzionamento del trasferimento dei messaggi in ingresso e in uscita.

Suggerisco di aprire i singoli file di script nel Blocco note e di analizzare i cmdlet e i parametri utilizzati da questi script per eseguire la configurazione. Informazioni dettagliate su questi cmdlet e parametri sono disponibili in linea nella documentazione del prodotto per Exchange Server 2007.

Architettura Trasporto Edge

Adesso iniziamo a discutere sugli agenti Trasporto Edge che, da quando ho installato il ruolo del server Trasporto Edge, aspettano che qualcuno dica HELO o EHLO. Se eseguiamo il cmdlet Get-TransportAgent sul server Trasporto Edge, vengono visualizzate le 11 voci elencate nella Figura 3. Tutti gli agenti vengono attivati per impostazione predefinita per fornire la protezione di messaggistica con le impostazioni appropriate.

Figure 3 Agenti di trasporto

Nel cmdlet Get-TransportAgent e nella Figura 3 vengono elencati gli agenti in base alla priorità, anche se questo non è l'ordine secondo cui gli agenti eseguono il proprio lavoro. L'ordine delle operazioni eseguite dipende principalmente dalla sequenza degli eventi di ricezione e di invio SMTP per cui vengono registrati gli agenti. Per vedere come sono combinati gli agenti e gli eventi, vedere il diagramma illustrato nella Figura 4, che mostra il modo in cui gli agenti di trasporto si integrano nell'architettura Trasporto Edge.

Figura 4** Agenti di trasporto nell'architettura Trasporto Edge **(Fare clic sull'immagine per ingrandirla)

Gli eventi di trasporto si verificano in varie fasi durante l'elaborazione dei messaggi per richiamare il codice aggiuntivo per il filtro contro la posta indesiderata, la ricerca di virus e altre attività. In questo progetto collegato ed estensibile, il processo Trasporto Edge (EdgeTransport.exe) assume il ruolo di origine eventi. I gestori eventi, in altre parole gli agenti di trasporto, sono oggetti delegati gestiti basati su Microsoft® .NET Framework 2.0, registrati con l'origine eventi per ricevere le notifiche di richiamata.

Nella Figura 5 vengono illustrate le registrazioni evento per tutti gli agenti installati su un server Trasporto Edge con Forefront Security. Può risultare difficile ordinare queste registrazioni a causa dell'elevato numero di registrazioni di agenti, ma non è impossibile. Se si esegue il comando Get-TransportPipeline | Format-List sul server Trasporto Edge, è possibile analizzare opportunamente le registrazioni per ogni singolo evento di trasporto. È sufficiente verificare che il servizio Microsoft Exchange Transport (MSExchangeTransport.exe) sia in esecuzione e che dall'ultimo riavvio del servizio sia stato inviato almeno un messaggio tramite il server Trasporto Edge. Come indicato dall'output, è possibile che più agenti si registrino per lo stesso tipo di evento e che singoli agenti si registrino per più eventi. Le registrazioni evento dipendono dai requisiti di elaborazione dell'agente corrispondente.

Figura 5** Registrazioni evento per gli agenti di trasporto **(Fare clic sull'immagine per ingrandirla)

Uno degli eventi più importanti è l'evento di invio OnSubmittedMessage, attivato quando un messaggio raggiunge la coda di invio. Tutti i messaggi devono passare attraverso questa coda se giungono tramite SMTP, il file system o qualunque altro meccanismo. Il classificatore è un componente principale dell'architettura di trasporto di Exchange Server, responsabile della risoluzione dei destinatari, della biforcazione e dell'invio dei messaggi, nonché della generazione della notifica sullo stato del recapito (DSN, Delivery Status Notification). L'evento OnSubmittedMessage risulta essere pertanto una scelta di registrazione ideale per gli agenti che devono elaborare tutti i messaggi ricevuti. L'agente di invio FSE è un componente di Forefront Security registrato affinché l'evento OnSubmittedMessage invii tutti i messaggi ricevuti ai motori di scansione antivirus. Poiché l'agente di invio FSE è registrato per l'evento OnSubmittedMessage, nessun messaggio può ignorare la soluzione antivirus.

Pertanto, per quale motivo tutti gli agenti non si registrano per l'evento OnSubmittedMessage e considerano terminate tutte le operazioni? Il motivo è che si desidera bloccare i messaggi indesiderati il prima possibile, prima che il server confermi l'avvenuto recapito. Altrimenti, i server potrebbero trovarsi a dover elaborare 90 milioni di messaggi indesiderati durante un attacco di posta indesiderata o virus, a generare 90 milioni di rapporti di mancato recapito (NDR) che potrebbero rappresentare un pericolo serio per gli utenti inconsapevoli. Gli attacchi di posta indesiderata e virus utilizzano quasi sempre informazioni falsificate sull'origine. L'invio di milioni di NDR ai destinatari che non hanno creato i messaggi originali non solo è uno spreco di risorse proprie e delle organizzazioni di destinazione, ma rappresenta anche un'opportunità per gli utenti malintenzionati di eseguire attacchi DDoS o attacchi che prevedono una vera inondazione della posta elettronica. Per proteggere se stessi e gli altri, è importante arrestare i mittenti dannosi.

Per bloccare un messaggio, è necessario che un agente di trasporto interrompa la conversazione SMTP con l'host remoto prima che il server confermi la ricezione dei dati con un codice di stato 250 OK. Secondo il principio di archiviazione e inoltro SMTP, in caso di mancata conferma dell'avvenuta ricezione del messaggio, il server può eliminare senza rischi tutti i dati ricevuti senza generare alcun NDR. Tale operazione può essere eseguita dagli agenti di ricezione SMTP. Questi interagiscono con la sessione SMTP perché il pipeline di trasporto li richiama in base agli eventi di ricezione SMTP nel momento in cui l'host remoto effettua la connessione al server, stabilisce una sessione SMTP, trasmette i verbi SMTP, inoltra i messaggi e termina la connessione. Gli eventi di ricezione SMTP associati a ogni passaggio sono elencati nella Figura 6. Grazie alla possibilità di rifiutare i messaggi prima della consegna e di scollegare gli host SMTP remoti, tutti gli agenti contro la posta indesiderata di Exchange Server 2007 vengono implementati come agenti di ricezione SMTP.

Figure 6 Eventi sessione SMTP

È importante riconoscere la differenza tra gli agenti di invio e di ricezione SMTP, con particolare attenzione al relativo contesto di elaborazione. Nonostante gli agenti di invio abbiano accesso completo alle proprietà dei messaggi, gli agenti di ricezione SMTP sono più sensibili al contesto perché interagiscono con la sessione SMTP. Ad esempio, un filtro contro la posta indesiderata non può agire sulle proprietà dei messaggi fino a quando l'host remoto non ha trasferito effettivamente il messaggio. Pertanto, è importante registrare l'agente per l'evento di ricezione SMTP corretto. Per maggiori dettagli, vedere la barra laterale "Sviluppo dell'agente di trasporto".

Risorse di Exchange

• Protezione della messaggistica e Trasporto Edge di Microsoft Exchange Server 2007 (White paper tecnico su Microsoft IT Showcase)
• Script center di Windows PowerShell
• Exchange Server 2007 TechCenter
• Blog del team di Microsoft Exchange "You Had Me From EHLO"

Resta sintonizzato!

Facciamo una breve pausa prima di addentrarci negli scenari di architettura di trasporto e test. Finora ho affrontato molti argomenti, dalla distribuzione di tipo Microsoft IT dei server Trasporto Edge agli eventi interni attivati nel pipeline di trasporto durante l'elaborazione dei messaggi. Nella seconda parte di questa serie continuerò ad analizzare il comportamento degli agenti Trasporto Edge in alcuni scenari di test interessanti.

Nel frattempo, consiglio di scaricare la versione di prova di 90 giorni di Microsoft Visual Studio 2005 Professional Edition (go.microsoft.com/fwlink/?LinkId=98043) e seguire le spiegazioni di Steve per compilare e installare gli agenti di esempio nell'ambiente di test. Anche se non sei uno sviluppatore, scoprirai presto quanto è semplice eseguire queste attività. Non ci si dovrebbe meravigliare se aumentasse il numero di applicazioni aziendali che dipendono dagli agenti personalizzati, considerato quanto sia conveniente in Exchange Server 2007 sviluppare questi componenti con Visual Studio 2005.

Kay Unkroth è un imprenditore che ha lavorato per oltre 15 anni come Support Engineer, sviluppatore di sistema, consulente, istruttore e autore, dedicandosi principalmente alle tecnologie server di Microsoft. Kay è inoltre fondatore, nonché presidente, della Biblioso Corporation, una società specializzata in servizi di documentazione e localizzazione gestiti.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.