Comunicazioni

Server Trasporto Edge di Microsoft Exchange Parte 2

Kay Unkroth

Panoramica:

• Utilizzo dei registri e delle tracce del Trasporto Edge
• Configurazione della protezione dalla posta indesiderata tramite script
• Test di scenari di posta indesiderata tipici

Scarica il codice per questo articolo: Edge2007_11.exe (161KB)

Di fronte all'inondazione di posta indesiderata e ai contenuti dannosi che fluiscono in Internet, come è possibile garantire agli utenti un sistema di messaggistica affidabile e sicuro nell'organizzazione? Un metodo, la cui descrizione è iniziata il mese scorso nella prima parte di questa serie, è costituito dalla distribuzione di

server Trasporto Edge di Exchange Server 2007 e Forefront Security per Exchange Server in una rete perimetrale tra Internet e l'ambiente di produzione.

In questo secondo articolo conclusivo della serie verrà spiegato come analizzare gli agenti di Trasporto Edge in azione utilizzando le funzionalità di registrazione agente e traccia standard di Exchange Server 2007. Verrà anche utilizzato un metodo personalizzato per eseguire il dump di tutti gli oggetti evento dalla pipeline di trasporto su file XML. Verrà quindi illustrato come applicare impostazioni di protezione dalla posta indesiderata in un laboratorio per i test di Trasporto Edge in base alla configurazione utilizzata da Microsoft nel proprio ambiente di produzione aziendale. Infine, l'articolo si concluderà con alcuni interessanti e realistici scenari di test per vedere in che modo gli agenti di Trasporto Edge rispondono alle varie situazioni di posta indesiderata.

Per ulteriori informazioni sull'installazione del laboratorio per i test di Trasporto Edge e sull'architettura generale di Trasporto Edge, consultare il primo articolo di questa serie nel numero di ottobre 2007 di TechNet Magazine, disponibile all'indirizzo technetmagazine.com/issues/2007/10/Edge.

Utilizzo in modo intensivo script e file batch per automatizzare le attività di configurazione più importanti ed è possibile trovare questi script nel download del codice che accompagna questo articolo (accedere all'indirizzo technetmagazine.com/code07.aspx). Inoltre, per ulteriori informazioni sulla configurazione IT Microsoft degli agenti di Trasporto Edge, è consigliabile consultare il white paper tecnico "Trasporto Edge di Microsoft® Exchange Server 2007 e protezione della messaggistica", prodotto per Microsoft IT ShowCase È possibile scaricare questo white paper di IT Showcase dall'indirizzo microsoft.com/technet/itshowcase/content/edgetransport.mspx.

Registrazione e traccia

Exchange Server 2007 contiene numerose funzionalità di registrazione e traccia, tra cui la registrazione protocollo, la registrazione agente e la traccia della pipeline, che semplifica la diagnosi e la risoluzione dei problemi degli agenti di trasporto. Anche se in questo articolo non viene trattata nello specifico la risoluzione dei problemi relativi agli agenti di trasporto, le informazioni di registrazione e traccia sono utili per esaminare il funzionamento degli agenti di Trasporto Edge.

Se si desidera tenere traccia delle attività di invio e ricezione SMTP, è necessario attivare la registrazione protocollo per i connettori di invio e ricezione. Utilizzando l'ambiente di test, ho configurato la prima parte di questa serie (vedere la Figura 1), ho attivato la registrazione protocollo tramite la seguente impostazione nei cmdlet New-SendConnector e New-ReceiveConnector:

Figura 1** Ambiente di test **

–ProtocolLoggingLevel: Verbose

Per impostazione predefinita è possibile trovare i file di registro SMTP risultanti nelle sottocartelle in %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog.

La registrazione protocollo è utile se si desidera analizzare le conversazioni SMTP, anche se gli agenti di protezione dalla posta indesiderata non sempre interferiscono con la sessione SMTP. Ad esempio, l'agente filtro contenuto può contrassegnare solo i messaggi in ingresso con un valore del livello di probabilità di posta indesiderata (SCL). Finché il livello di probabilità di posta indesiderata è inferiore alla soglia specificata (l'impostazione predefinita è 7), l'agente filtro contenuto non determina il rifiuto del messaggio da parte del processo di Trasporto Edge. Pertanto la conversazione SMTP prosegue inalterata.

Per analizzare le azioni eseguite dagli agenti di protezione dalla posta indesiderata (filtro connessioni, filtro contenuto, regole Edge, filtro destinatario, filtro mittente e ID mittente) sui messaggi che passano dalla pipeline del trasporto, è necessario verificare i registri agente e non i registri protocollo. La registrazione agente è generalmente attivata in base al parametro AgentLogEnabled nel file EdgeTransport.exe.config. Per impostazione predefinita, i registri agente si trovano nella cartella %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\AgentLog. È possibile aprire i registri in Blocco Note, anche se il cmdlet Get-AgentLog visualizza le informazioni del registro agente in modo più intuitivo in Exchange Management Shell.

Un'altra funzionalità utile è la traccia della pipeline, che consente di acquisire istantanee dei messaggi provenienti da un determinato mittente quando passano attraverso la pipeline di trasporto. Il concetto è relativamente semplice: il processo di Trasporto Edge crea un'istantanea di ciascun messaggio prima e dopo aver richiamato gli agenti di ricezione SMTP e routing registrati per gli eventi OnEndOfHeaders, OnEndofData, OnSubmittedMessage e OnRoutedMessage. Confrontando le istantanee dei messaggi, è possibile osservare in che modo i singoli agenti modificano ciascun messaggio. Ovviamente, è imperativo che questa preziosa funzionalità venga attivata nell'ambiente di test.

Il seguente utilizzo del cmdlet Set-TransportServer attiva la traccia della pipeline per un utente test. Come era possibile prevedere, il parametro PipelineTracingEnable impostato su $true attiva la traccia della pipeline. L'indirizzo di posta elettronica dell'utente test è impostato nel parametro PipelineTracingSenderAddress:

Set-TransportServer –Identity EDGE01 
–PipelineTracingEnabled $true 
-PipelineTracingSenderAddress Contoso.User@contoso.com

Con la traccia della pipeline attivata, è possibile trovare i file di istantanea del messaggio per ciascun messaggio proveniente dal mittente specificato (in questo caso, si tratta di Contoso.User@contoso.com) nella cartella %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing\MessageSnapshots. Questa è la cartella predefinita. Per ciascun messaggio, i file di istantanea si trovano in una sottodirectory denominata in base a un GUID assegnato al messaggio. Si noti che è possibile trovare il messaggio originale in un file denominato Original.eml nonché alcune copie del messaggio nei file .eml che iniziano con SmtpReceive o Routing in base agli eventi rilevati e agli agenti installati. Per analizzare l'elaborazione degli agenti di protezione dalla posta indesiderata registrati per gli eventi di ricezione SMTP OnEndofData e OnEndOfHeaders, verificare i file SmtpReceive*.eml. Per analizzare l'elaborazione degli agenti antivirus e di altro tipo registrati per gli eventi di routing OnSubmittedMessage e OnRoutedMessage, analizzare invece i file Routing*.eml.

Dump personalizzato della pipeline

Le funzionalità di registrazione agente e traccia standard di Exchange Server 2007 rispondono a tutte le esigenze di risoluzione dei problemi malgrado le funzionalità standard non riguardino tutti gli eventi di trasporto. Ad esempio, la traccia della pipeline non è in grado di acquisire informazioni su OnConnectEvent, OnEhloCommand, OnMailCommand, OnRcptCommand, OnDataCommand ed eventi di trasporto simili perché l'host di invio non ha ancora trasferito alcun messaggio che potrebbe essere stato scritto nella cartella %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing. Per acquisire informazioni dettagliate su questi eventi, è necessario implementare un agente personalizzato che esegue il dump dei dati di evento su file nel file system.

Come è stato discusso nel mio articolo precedente, la creazione di agenti personalizzata non è complicata, quindi non ho potuto fare a meno di sviluppare un agente di ricezione SMTP e di un agente di routing per eseguire il dump di tutti gli oggetti evento dalla pipeline di trasporto in file XML. È possibile trovare un progetto Microsoft Visual Studio® 2005 corrispondente, denominato PipelineXMLDump, nel download disponibile per questo articolo. I due file importanti sono DumpAgents.cs, che implementa factory dell'agente e gli agenti, e XMLDump.cs, che implementa una classe helper per scrivere i campi degli oggetti origine evento e argomento evento per mezzo dei metodi System.Reflection nei file XML. Se si compila il codice sorgente e si copia il file PipelineXMLDump Dll risultante in una cartella denominata C:\PipelineXMLDump sul server Trasporto Edge, è possibile registrare e attivare gli agenti personalizzati utilizzando gli script RegisterPipelineXMLDump.ps1 e EnableDumpAgents.ps1 Gli script sono contenuti nella cartella di progetto PipelineXMLDump del download. Ovviamente, il fine degli agenti personalizzati è puramente illustrativo in quanto non sono stati testati a sufficienza e non devono mai installati su un server di produzione. L'utilizzo di questi agenti è a proprio rischio.

DumpAgents.cs illustra come implementare tutti i gestori eventi di ricezione SMTP e routing supportati dalla pipeline di trasporto. Questo può costituire un buon punto di partenza se si desidera implementare agenti personalizzati. I miei agenti di dump scrivono file XML nelle sottocartelle in %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineXMLDump che corrispondono all'identificatore della sessione SMTP (agente di ricezione SMTP) o all'identificatore del messaggio (agente di routing). Nella Figura 2 viene illustrato un esempio di informazioni sull'argomento dell'evento passate all'agente di ricezione SMTP nel gestore OnConnectEvent. L'esempio rivela l'endpoint IP locale (indirizzo IP e porta) che ha accettato una richiesta di connessione in entrata.

Figura 2** Informazioni sull'argomento scaricate durante l'evento OnConnect **(Fare clic sull'immagine per ingrandirla)

Preparazione delle esecuzioni di test

Basta con la teoria su registrazione, traccia e dump. Passiamo ad alcune esecuzioni di test che illustrano gli agenti di protezione dalla posta indesiderata in azione. Di seguito viene fornito un breve riepilogo che rispecchia il più possibile la configurazione di Microsoft IT nell'ambiente di test. Come è stato accennato in precedenza, le informazioni generali sono disponibili nel white paper tecnico "Trasporto Edge di Microsoft Exchange Server 2007 e protezione della messaggistica".

Per iniziare, basta disattivare l'agente di riscrittura degli indirizzi dei messaggi in ingresso, di filtro allegati e di riscrittura degli indirizzi dei messaggi in uscita eseguendo lo script EDGE01_disable_agents.ps1 disponibile nel download che accompagna l'articolo. Non è necessario riscrivere gli indirizzi perché i destinatari utilizzano gli stessi indirizzi di posta elettronica sia internamente che esternamente. Non viene utilizzato l'agente filtro allegati perché sono disponibili funzionalità di filtro degli allegati sostitutive in Forefront Security.

L'ambiente di test non è connesso a Internet e questo rende difficile testare l'agente filtro connessioni. Per risolvere il problema, è possibile creare un elenco di blocco IP nell'host Internet eseguendo il file INTERNET01_create_IP_block_list.bat. Controllare che Windows® Support Tools sia installato perché contiene lo strumento della riga di comando DNS (dnscmd.exe). In caso contrario, è possibile dedicare un po' di tempo alla creazione manuale di record DNS utilizzando la console DNS.

Ora è possibile configurare l'agente filtro connessioni eseguendo lo script EDGE01_add_block_list_provider.ps1. Questo script aggiunge un provider elenco indirizzi IP bloccati per ip-bl.consolidatedmessenger.com. Si tratta dell'elenco di indirizzi IP bloccati di Consolidated Messenger, già creato nell'ambiente di test tramite l'esecuzione del file INTERNET01_create_IP_block_list.bat nell'host Internet, come citato in precedenza. Microsoft IT utilizza anche l'elenco indirizzi IP bloccati locale e l'elenco IP consentiti, ma queste funzionalità non richiedono la configurazione manuale. È importante notare che Microsoft IT non utilizza i provider di elenco indirizzi IP consentiti.

Quindi, configurare l'agente filtro destinatario eseguendo lo script EDGE01_recipient_filter.ps1 per bloccare i messaggi a destinatari inesistenti e i messaggi alle caselle di posta e alle liste di distribuzione globali riservate per uso interno o solo in uscita.

Anche l'agente filtro mittente richiede un aggiornamento della configurazione. Microsoft IT utilizza il filtro dei mittenti come contromisura contro gli attacchi flood di posta da indirizzi mittente specifici e per bloccare determinati server di elenco e origini simili che sono non ritenuti pertinenti per l'azienda. Microsoft IT utilizza inoltre il filtro dei mittenti per bloccare i messaggi con informazioni sul mittente non valide o mancanti. Applichiamo questa configurazione all'ambiente di test eseguendo lo script EDGE01_sender_filter.ps1 sul server Trasporto Edge.

Se si desidera rispecchiare la configurazione di Microsoft IT è anche necessario configurare i record Sender Policy Framework (SPF) in DNS. Per generare una record SPF che attesta l'autorità del server Trasporto Edge per i messaggi dal dominio adventure-works.com, è possibile utilizzare la procedura guidata Microsoft per la creazione di record SPF del framework ID mittente disponibile all'indirizzo microsoft.com/mscorp/safety/content/technologies/senderid/wizard. È possibile fare un tentativo e specificare un nome di dominio Internet esistente. Nell'ambiente di test, è possibile eseguire il file INTERNET01_create_SPF_record.bat nell'host Internet.

Tutto qui. Non è necessario configurare altri parametri perché la maggior parte degli agenti è provvista di impostazioni predefinite appropriate. Per eseguire una rapida verifica delle impostazioni predefinite più importanti per gli agenti regole Edge, ID mittente, analisi protocollo e filtro contenuto, eseguire lo script EDGE01_check_defaults.ps1 sul server Trasporto Edge.

Agenti di Trasporto Edge in azione

Ora, ipotizziamo il funzionamento degli agenti di Trasporto Edge in alcuni scenari di messaggistica realistici. Per inviare messaggi di test al server Trasporto Edge, utilizzo il servizio SMTP e POP3 incluso in Windows Server 2003 e Outlook® Express come client di messaggistica, adottando le impostazioni predefinite per la maggior parte del tempo, ma controllando che la registrazione sia attivata.

Ma prima, un avvertimento: non seguire i passaggi o eseguire gli script descritti in questa sezione se nell'ambiente di test è attiva una connessione a un sistema di produzione o a Internet. Il test viene svolto a proprio rischio.

Il primo agente che viene testato è filtro connessioni. Merita di essere il primo perché è quello con il funzionamento più difficoltoso su un server Trasporto Edge. In Microsoft, l'agente filtro connessioni blocca circa l'88% di tutti gli invii di messaggi Internet. Su 13 milioni di tentativi di invio che hanno luogo in una normale giornata lavorativa, solo 1,5 milioni provengono da mittenti legittimi.

Quindi inviamo un messaggio di posta elettronica come Fabrikam.User@Fabrikam.com ad Administrator@adventure-works.com. Se tutto funziona correttamente, l'amministratore non dovrebbe ricevere il messaggio. Al contrario, Fabrikam.User dovrebbe ricevere una notifica sullo stato del recapito indicante che il destinatario non ha ricevuto il messaggio. Fabrikam.User verifica che l'indirizzo di posta elettronica sia corretto, invia di nuovo lo stesso messaggio e Fabrikam.User riceve ancora una notifica sullo stato del recapito. Quindi Fabrikam.User chiama l'assistenza e riferisce il problema. Non è la prima segnalazione. Infatti, nessuno in Fabrikam è più in grado di comunicare con Adventure Works. È accaduto qualcosa. Il problema è urgente. Tentando di risolverlo rapidamente, si controllano i registri SMTP nella cartella %systemroot%\system32\Logfiles\SMTPSVC1 in INTERNET01 e, come è illustrato dal testo rosso nella Figura 3, ecco il problema.

Figure 3 I registri SMTP illustrano il problema

... 220 mail.adventure-works.com Microsoft ESMTP MAIL Service ready at Thu, 
31 May 2007 12:21:33 -0700,
... EHLO, -, INTERNET01,
... 250-mail.adventure-works.com Hello [192.168.1.100],
... MAIL, -, FROM:<Fabrikam.User@fabrikam.com> SIZE=840,
... 250 2.1.0 Sender OK,
... RCPT, -, TO:<Administrator@adventure-works.com>,
... 550 5.7.1 E-mail rejected because your IP address is listed by 
ip-bl.consolidatedmessenger.com. Please visit 
http://www.consolidatedmessenger.com/ip-bl for more information. 
If you still need assistance, contact cmipbl@adventure-works.com.,
... RSET, -, -,
... 250 2.0.0 Resetting,
... QUIT, -, -,
... 221 2.0.0 Service closing transmission channel,

La risposta di errore 550 indica che Consolidated Messenger ha inserito il proprio indirizzo IP dell'host Internet in un elenco indirizzi IP bloccati. La cosa è abbastanza ragionevole. Si contatta Consolidated Messenger per essere rimossi dall'elenco. Come si potrà constatare, è più facile essere inseriti nell'elenco di blocco di Consolidated Messenger che essere rimossi. L'eliminazione richiederà dei giorni, se non settimane.

È necessario un aiuto più rapido, così si contatta Adventure Works tramite l'indirizzo di posta elettronica cmipbl@adventure-works.com. Si invia un messaggio di posta elettronica come Fabrikam.Admin@Fabrikam.com, descrivendo la situazione e chiedendo di sbloccare l'indirizzo IP Internet dell'host (in questo caso 192.168.1.100). Dopo avere verificato l'identità, Adventure Works sblocca l'indirizzo utilizzando il comando seguente per autorizzare un'eccezione temporanea che scade automaticamente dopo 30 giorni:

Add-IPAllowListEntry -IPAddress 192.168.1.100 
-ExpirationTime (get-date).AddDays(30)

Trenta giorni dovrebbero essere sufficienti per sistemare le cose con Consolidated Messenger e Adventure Works non deve perdere tempo nella manutenzione manuale dell'eccezione. Tramite la concessione di eccezioni temporanee, Adventure Works tiene al minimo l'overhead amministrativo associato alla manutenzione degli elenchi indirizzi IP consentiti.

Mittente attendibile

Quindi, è possibile testare il riconoscimento dei mittenti attendibili del filtro contenuto, una nuova e interessante funzionalità che aumenta la precisione del filtro posta indesiderata. EdgeSync propaga le informazioni sui mittenti attendibili dall'ambiente interno in formato hash e crittografato ai server Trasporto Edge. L'agente filtro contenuto utilizza queste informazioni durante il processo di filtro per prendere decisioni consapevoli. È necessario solamente ottenere informazioni sui mittenti attendibili (ovvero, elenco Mittenti attendibili, elenco Destinatari attendibili, elenco Mittenti bloccati e contatti esterni) in Active Directory® utilizzando il cmdlet Update-SafeList e replicando quindi le informazioni sul server Trasporto Edge utilizzando il cmdlet Start-EdgeSynchronization. Microsoft IT esegue il cmdlet Update-SafeList in base a una pianificazione durante gli orari di minor traffico. Nel nostro ambiente di test è sufficiente eseguire manualmente uno script corrispondente (HUB-MBX-01_update_safelist.ps1).

Per prima cosa, ripulire l'ambiente di test eseguendo lo script EDGE01_clean_up.ps1 sul server Trasporto Edge per rimuovere la voce dell'elenco indirizzi IP consentiti creata in precedenza. Ciò è necessario perché l'agente filtro contenuto non agisce sui messaggi provenienti dalle origini presenti in questo elenco. Quindi, è necessario rimuovere la voce dell'elenco indirizzi IP bloccati per 100.1.168.192.ip-bl.consolidatedmessenger.com dall'elenco di blocco di Consolidated Messenger eseguendo il file INTERNET01_clean_up.bat sull'host Internet. In caso contrario, l'host di Internet simulato non sarà in grado di inviare messaggi, come dimostrato in precedenza.

Infine, inviare un messaggio che l'agente filtro contenuto considera quasi certamente come posta indesiderata. Questo è difficile perché l'agente filtro contenuto utilizza la soglia di livello di probabilità di posta indesiderata predefinita per recapitare la maggior parte dei messaggi agli utenti al fine di ridurre al minimo i falsi positivi. Dopo vari test, ho trovato ancora una versione di messaggio che alza la valutazione della soglia del livello di probabilità di posta indesiderata al livello di rifiuto. Per inviare il messaggio come Contoso.User@Contoso.com, eseguire lo script INTERNET01_contoso_msg.vbs nell'host Internet.

Il mio script utilizza una connessione SMTP anonima per inviare il messaggio al servizio SMTP in INTERNET01. Per un funzionamento corretto, è necessario configurare il servizio SMTP per l'inoltro dei messaggi per gli utenti anonimi. In Gestione IIS, aprire le proprietà per il Server virtuale SMTP predefinito. Nella scheda relativa all'accesso, fare clic sul pulsante che consente di inoltrare i messaggi e selezionare l'opzione che consente di inviare tutto tranne l'elenco specificato. Tra breve verranno spiegate le implicazioni di questa configurazione.

Quando si esegue lo script per inviare questo messaggio, Contoso.User dovrebbe ricevere una notifica sullo stato del recapito indicante che il recapito non è riuscito con: Codice diagnostico: smtp;550 5.7.1 Messaggio rifiutato a causa di limitazioni del contenuto. È anche possibile visualizzare questa risposta nel registro SMTP nell'host Internet e se si esegue il comando Get-AgentLog | Select-Object -Last 1 sul server Trasporto Edge per visualizzare l'ultima voce del registro agente, dovrebbe essere possibile vedere che il messaggio è stato rifiutato perché il livello SCL era 7, come illustrato nella Figura 4.

Figura 4** Messaggio bloccato a causa di limitazioni del contenuto **(Fare clic sull'immagine per ingrandirla)

Ora, Contoso.User non è uno spammer. È una sfortuna che in questo caso il messaggio non sia passato, ma Contoso.User è generalmente in grado di comunicare con i destinatari di Adventure Works. Quindi Contoso.User comunica all'amministratore in un altro messaggio di posta elettronica che il messaggio originale è stato erroneamente bloccato. L'amministratore conosce Contoso.User e, per garantire che i filtri posta indesiderata non blocchino più i suoi messaggi in futuro, aggiunge Contoso.User all'elenco Mittenti attendibili. A tal scopo in Office Outlook 2007, fare clic con il pulsante destro del mouse su un messaggio ricevuto da Contoso.User, puntare su Posta indesiderata, quindi fare clic su Aggiungi mittente all'elenco Mittenti attendibili.

All'intervallo consueto, viene eseguito il cmdlet Update-SafeList per aggiornare le informazioni degli indirizzi attendibili in Active Directory e dopo la successiva sincronizzazione di Edge, Contoso.User potrà comunicare con l'amministratore senza falsi positivi. Per simulare questa procedura, eseguire lo script HUB-MBX-01_update_safelist.ps1.

Ora eseguire lo script INTERNET01_contoso_msg.vbs per inviare di nuovo il messaggio di Contoso.User. Al termine controllare il registro agente sul server Trasporto Edge utilizzando il comando Get-AgentLog | Select-Object -Last 1 e in ReasonData è possibile notare che il filtro contenuto non è stato aggirato. I falsi positivi per Contoso.User sono così terminati.

Attacco di posta indesiderata

Concludiamo adesso il discorso sulle esecuzioni di test. Come è stato certamente notato, durante il test precedente ho configurato l'host Internet come inoltro aperto, cosa che consente l'accesso agli spammer. Vediamo quindi che cosa accade se Spam.Sender@cohovineyards.com nota questa configurazione debole e abusa dell'host per inviare migliaia di messaggi di posta indesiderata a Adventure Works. Lo script INTERNET01_spam_msg.vbs invia solo un messaggio di posta indesiderata, ma è possibile modificarlo e cambiare il valore max_loop per generare più script.

Per simulare un attacco di posta indesiderata, ho inviato 1.000 messaggi al mio host compromesso in modo che vengano inoltrati al server Trasporto Edge. Il servizio SMTP limita il numero di messaggi per la connessione in uscita a 20, quindi è stato necessario un po' di tempo per inoltrare un numero sufficiente di messaggi di posta indesiderata prima che l'agente analisi protocollo sul server Trasporto Edge ne ricevesse a sufficienza e reagisse.

L'agente analisi protocollo assiste l'agente filtro connessioni mantenendo automaticamente le voci di elenco indirizzi IP bloccati basato sull'analisi del protocollo SMTP e sugli aggiornamenti della reputazione IP di Microsoft Update. In questo caso, l'analisi del protocollo SMTP ha intercettato i messaggi di posta indesiderata. L'agente di analisi protocollo tiene traccia di ciascuna valutazione SCL di ciascun messaggio per calcolare un valore SCL medio che utilizza per determinare un livello di reputazione del mittente (SRL). All'aumentare del numero di messaggi illegittimi arrivati durante la campagna di posta indesiderata simulata, il valore SRL dell'host Internet è aumentato fino a superare la soglia di blocco SRL. Come risultato, per 24 ore l'host è andato a finire sull'elenco degli IP bloccati. Da questo host non è più arrivata posta indesiderata e la cosa è avvenuta automaticamente. Non è stato necessario alcun intervento dell'amministratore.

Nella Figura 5 viene illustrato l'elenco degli IP bloccati risultante e le modifiche corrispondenti nella gestione dei messaggi. Prima di bloccare l'host, il server Trasporto Edge ha rifiutato ciascun messaggio di posta indesiderata durante l'evento OnEndOfData perché era l'agente filtro contenuto che agiva su ciascun messaggio in base alla soglia SCL (per riferimento, vedere la Figura 4). Il messaggio è stato inviato, anche se senza successo. Dopo il blocco dell'host, la connessione è stata rifiutata dall'agente filtro connessioni durante l'evento OnMailCommand. I messaggi non vengono più inviati. Consente di risparmiare larghezza di banda di rete e risorse di elaborazione per disconnettere gli spammer prima dell'invio dei messaggi.

Figura 5** Interruzione di un host Internet dannoso **(Fare clic sull'immagine per ingrandirla)

Ulteriori test

Naturalmente, sono disponibili numerose altre funzionalità di agente e scenari che è possibile testare. Ad esempio, è possibile testare il filtro mittente inviando messaggi come Blocked.User@Contoso.com o Blocked.User@Fabrikam.com. È possibile testare il filtro destinatario inviando messaggi a Blocked.User@adventure-works.com. È anche possibile utilizzare Telnet per simulare attacchi directory harvesting (raccolta di directory) con intervalli di tarpitting variabili. Microsoft utilizza l'intervallo predefinito di cinque secondi per le risposte 5yz SMTP sul connettore di ricezione Internet, che per Microsoft IT è una quantità di tempo sufficiente per vanificare l'efficacia degli attacchi di directory harvesting per gli spammer. Tuttavia è possibile applicare valori diversi utilizzando il cmdlet Set-ReceiveConnector, come dimostrato nello script EDGE01_tarpitting.ps1.

È anche possibile andare più a fondo e verificare i file di istantanea che vengono creati dalla traccia della pipeline per i messaggi da Contoso.User@Contoso.com. Esaminare gli indicatori dell'antivirus, X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0, utilizzato da Forefront Security per contrassegnare i messaggi sottoposti a scansione. Quando Forefront Security sul server Trasporto Hub trova questo indicatore con informazioni di versione recenti, non deve eseguire la scansione del messaggio una seconda volta. Se si tenta di ingannare Forefront Security inserendo falsi indicatori degli antivirus nei messaggi di test, è possibile osservare in azione il firewall intestazioni, che rimuove questi indicatori subito dopo l'evento OnDataCommand, molto prima che venga attivato l'evento OnSubmittedMessage che richiama l'agente routing FSE.

Mentre si esaminano le intestazioni di messaggio nei file di istantanea, è possibile decidere di creare un record di test SPF per Contoso.Com che identifica un indirizzo IP errato come mittente legittimo. Un metodo per ottenere questo risultato è l'esecuzione del file INTERNET01_wrong_SPF_record.bat nell'host Internet. Quindi è necessario inviare un messaggio di test come Contoso.User@Contoso.com e osservare l'intestazione X-MS-Exchange-Organization-SenderIdResult e Received-SPF:

X-MS-Exchange-Organization-SenderIdResult: SoftFail
Received-SPF: SoftFail (EDGE01.extranet.adventure-works.com: domain of transitioning
Contoso.User@Contoso.com discourages use of 192.168.1.100 as permitted sender)

Conclusioni

Come si è visto in questo articolo e in quello precedente, i server Trasporto Edge di Exchange Server 2007 sono provvisti di una serie completa di agenti di trasporto per implementare funzionalità di protezione dalla posta indesiderata affidabili e di elevata precisione, tra cui filtro connessioni, analisi protocollo e filtro contenuto. L'architettura di trasporto è estendibile e supporta l'implementazione di ulteriori agenti per funzionalità aggiuntive. L'agente routing FSE è un buon esempio di agente aggiuntivo che consente di integrare Forefront Security per Exchange Server nell'architettura di trasporto.

Insieme a funzionalità aggiuntive, quali il tarpitting connessione, firewall intestazioni, TLS e autenticazione, i server Trasporto Edge offrono i mezzi necessari per ottenere un livello estremamente elevato di protezione della messaggistica a diversi livelli e senza singoli i punti di errore. Tramite la distribuzione di server Trasporto Edge e di Forefront Security in una rete perimetrale, rigorosamente separati dall'organizzazione di Exchange Server interna, è possibile tenere il flusso di contenuto illegittimo e dannoso lontano dall'ambiente di messaggistica e garantendo il recapito dei messaggi legittimi con un numero estremamente ridotto di falsi positivi per gli utenti.

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 gestiti di documentazione e localizzazione.

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