Exchange Server 2007

Utilizzo dell'ID mittente per combattere posta indesiderata e phishing

Craig Spiezle and Alexander Nikolayev

 

Panoramica:

  • Nozioni di base sull'ID mittente
  • Configurazione dell'ID mittente in Exchange Server
  • Vantaggi dell'autenticazione

La maggior parte delle tecnologie di identificazione e filtro è stata sviluppata in risposta alla crescente minaccia della posta indesiderata. Per garantire elevati livelli di efficienza, tali tecnologie prevedono un meccanismo di verifica basato su domande relative a ciascun messaggio di posta elettronica, ad esempio

domande sull'identità del mittente del messaggio. Purtroppo non è sempre semplice fornire una risposta ad una domanda di fondamentale importanza, come l'identità del mittente del messaggio. La posta elettronica viene in genere trasmessa su Internet senza che venga richiesta l'autenticazione del mittente o dei computer che agiscono per conto del mittente. Inviare un messaggio di posta elettronica facendo finta di essere un'altra persona è piuttosto semplice e non esiste alcun metodo automatico di rilevamento dei messaggi falsificati.

Il protocollo SMTP (Simple Mail Transfer Protocol), utilizzato per l'invio e la ricezione di posta elettronica, non è stato progettato per eseguire la verifica del mittente di un messaggio di posta elettronica. Con questo punto debole tecnologico, è possibile inserire come mittente qualsiasi nome e indirizzo. Per accertare l'effettiva provenienza dei messaggi, il filtro del contenuto o le misure di protezione da posta indesiderata non possono, di conseguenza, basarsi esclusivamente sulle informazioni delle intestazioni.

L'autenticazione della posta elettronica mira a far fronte a questo specifico punto debole. Grazie all'autenticazione, i sistemi di posta elettronica di invio e ricezione sono in grado di accertare che i messaggi abbiano effettivamente origine dai domini da cui dichiarano di provenire. In tal modo si semplifica il filtraggio della posta indesiderata da parte delle organizzazioni e, nel contempo, si garantisce che i messaggi di posta elettronica autorizzati raggiungano i destinatari previsti.

Sono attualmente disponibili due approcci all'autenticazione della posta elettronica non soggetti a royalty: Sender ID Framework (SIDF) e DomainKeys Identified Mail (DKIM). SIDF è una soluzione basata sul protocollo IP creata dalla fusione delle tecnologie Sender Policy Framework (SPF) e Microsoft Caller ID for E-Mail. Nell'aprile del 2006 la Internet Engineering Task Force (IETF) ha pubblicato le specifiche relative all'ID mittente come RFC 4405-4408. Una coalizione di soggetti interessati dei settori industriale e commerciale, tra cui Microsoft, consiglia la distribuzione di SIDF sulla base di determinati fattori, quali valore commerciale e tecnico, stabilità, maturità, semplicità di distribuzione, impatto minimo sulle prestazioni in ingresso e in uscita e interoperabilità con l'ecosistema della posta elettronica per i provider di servizi Internet (ISP) e gli ambienti aziendali.

DKIM rappresenta una fusione delle specifiche IIM (Identified Internet Mail) di Yahoo! DomainKeys e Cisco Systems Inc. Nel gennaio del 2006 la IETF ha approvato la creazione di un gruppo di lavoro DKIM e le specifiche sono attualmente in fase di revisione.

Sebbene non esista una soluzione perfetta per contrastare la posta indesiderata, SIDF rappresenta una significativa iniziativa industriale in grado di far fronte alle problematiche correlate ai domini falsificati. Rappresenta quindi un componente chiave per la riduzione degli attacchi di spamming e phishing e della creazione di un clima di maggiore fiducia e affidabilità per Internet. La tecnologia SIDF registra una sempre più vasta diffusione nelle organizzazioni di tutto il mondo. Attualmente più di 5,5 milioni di società e proprietari di domini hanno pubblicato i record SPF e più di 600 milioni di utenti sono protetti tramite SIDF. Inoltre, oltre un terzo del volume della posta elettronica prodotta ogni giorno a livello mondiale risulta ora autenticata e compatibile con SIDF.

Lo sviluppo e l'adozione in tutto il mondo di SIDF non sarebbero stati possibili senza il contributo e il supporto di molte organizzazioni e società, tra cui AOL, Authentication and Online Trust Alliance (AOTA), Bell Canada, E-Mail Senders Provider Coalition (ESPC), CipherTrust, Cisco Systems, IronPort Systems, MarkMonitor, Port25 Solutions Inc, Sendmail, Symantec, TRUSTe, VeriSign e altri ancora.

Descrizione dell'ID mittente

Alcuni sondaggi del settore indicano che il 95% delle attività di phishing proviene da domini falsificati e utilizza indirizzi di posta elettronica di mittenti falsificati. La tecnologia SIDF rappresenta un significativo passo avanti per quanto riguarda l'elaborazione della posta indesiderata. SIDF, di per sé, non è in grado di risolvere il problema della posta indesiderata, ma contribuisce in modo significativo a ridurre al minimo le conseguenze degli attacchi di spamming e phishing. Sebbene non impedisca l'invio di posta indesiderata, questa tecnologia consente tuttavia di semplificare il rilevamento della posta indesiderata. Il framework consente ai mittenti di messaggi di posta elettronica di proteggere i relativi nomi di domini, la reputazione e i rispettivi marchi e svolge un ruolo fondamentale nell'adozione di decisioni di filtro basate sulla reputazione e sul comportamento del mittente.

Con l'ID mittente si tenta di verificare che tutti i messaggi di posta elettronica abbiano origine dal dominio Internet da cui dichiarano di essere stati inviati. A tale scopo si controlla l'indirizzo del server che invia il messaggio, confrontandolo con un elenco registrato di server autorizzati dal proprietario del dominio a inviare posta elettronica. La verifica viene eseguita automaticamente dal provider di servizi Internet (ISP) o dal server di posta del destinatario, prima che il messaggio venga recapitato nella Posta in arrivo dell'utente.

È opportuno ricordare che l'ID mittente, o qualsiasi altro meccanismo di autenticazione, non sostituisce i sistemi di filtro del contenuto e che con nessuna delle due tecnologie, SIDF e DKIM, viene eseguita la scansione del contenuto effettivo dei messaggi. Al contrario, con l'autenticazione si notifica al sistema di posta in arrivo che il messaggio può essere convalidato come proveniente dal mittente dichiarato. Poiché la maggior parte degli attacchi di spamming e phishing non proviene dai domini indicati, questo approccio consente di identificare automaticamente tali messaggi e di separarli dal flusso dei messaggi di posta elettronica in arrivo.

In SIDF il record SPF fornisce un semplice record di testo di tutti i server di posta in uscita associati a un dominio e dei rispettivi indirizzi IP. Un'organizzazione pubblica il record SPF nel relativo file di zona del server DNS, che viene in seguito controllato dai server di posta dei destinatari. L'impostazione di un record SPF è un'operazione semplice, rapida e gratuita. Con la procedura guidata Sender ID Framework SPF Record Wizard si forniscono istruzioni dettagliate per l'analisi dei server di posta di un dominio e la creazione di record personalizzati pronti per la pubblicazione. Ulteriori dettagli relativi alla pubblicazione di un record SPF sono disponibili sul sito Web all'indirizzo microsoft.com/senderid (in inglese). È possibile accedere alla procedura guidata direttamente dal sito microsoft.com/senderid/wizard (in inglese).

Il server di posta SMTP di ricezione esegue il ping del file di zona del dominio in DNS per verificare l'esistenza di un record SPF. Una volta individuato, l'indirizzo IP del server di invio viene controllato in base agli indirizzi IP elencati. Se viene rilevata una corrispondenza, il messaggio verrà convalidato come autentico. Se invece il record SPF nel dominio del mittente non corrisponde all'indirizzo IP da cui proviene il messaggio, verrà generato un errore, che avrà come risultato l'assegnazione di un punteggio negativo e il potenziale posizionamento nella cartella Posta indesiderata. Il processo viene descritto nella Figura 1.

Figura 1 Controllo nei record SPF dei messaggi in arrivo

Figura 1** Controllo nei record SPF dei messaggi in arrivo **(Fare clic sull'immagine per ingrandirla)

Dopo che il messaggio è stato contrassegnato, SIDF consente al server di posta del destinatario di analizzare il messaggio in base ai comportamenti precedenti, alla reputazione del mittente, al contenuto e ad altri criteri che è possibile definire in base alle proprie esigenze. Questa capacità costituisce un'ulteriore misura di protezione. Gli spammer sono in grado, ad esempio, di registrare record SPF pubblicati e domini identici per trarre in inganno gli utenti e la rete di destinazione, inducendoli a pensare che la posta proviene da un mittente autorizzato. Anche se il messaggio di posta elettronica è in grado di superare il controllo di autenticazione, la reputazione del mittente come spammer è sufficiente perché il messaggio venga bloccato, contrassegnato come posta indesiderata o eliminato.

Opzioni di distribuzione dell'ID mittente

L'autenticazione della posta elettronica in uscita tramite SIDF non richiede modifiche all'infrastruttura o aggiornamenti software e non è specifica per il software client o server. Le organizzazioni che intendono incorporare l'autenticazione in ingresso per proteggere le relative società e i rispettivi dipendenti dovranno, tuttavia, aggiornare i sistemi in ingresso e l'agente di trasferimento messaggi (MTA), nonché distribuire software o apparecchiature che supportino SIDF. La maggior parte dei più importanti fornitori di prodotti per la protezione da posta indesiderata e agenti di trasferimento messaggi commerciali e open source, tra cui Microsoft® Exchange Server e Exchange Hosted Filtering, offre soluzioni integrate.

Microsoft ha integrato SIDF in tutti i prodotti di messaggistica, compresi Microsoft Exchange Server 2003 Service Pack 2 (SP2), Exchange Server 2007, Microsoft Exchange Hosted Filtering, Microsoft Windows Live™ Mail, MSN® Hotmail®, Outlook® Express e i client di collaborazione e messaggistica di Office Outlook.

Persino Microsoft non è tuttavia esente dalla ricezione di posta indesiderata. Il traffico giornaliero medio in ingresso in Microsoft è di circa 15 milioni di messaggi e, durante i recenti attacchi di spamming, si è registrato un numero di messaggi da due a quattro volte superiore. In un ambiente di questo tipo un metodo valido in grado di garantire una corretta protezione dalla posta indesiderata consiste nell'implementazione accurata delle tecnologie disponibili.

Microsoft offre una soluzione di protezione da posta indesiderata interna di Exchange Server basata sul filtro dell'ID mittente in Exchange Server 2003 e sull'agente dell'ID mittente in Exchange Server 2007. In entrambe le versioni di Exchange Server, lo stato dell'ID mittente è basato sulla valutazione del record dell'ID mittente che risiede sui server DNS corrispondenti. Il dominio effettivo viene determinato dall'analisi delle intestazioni dei messaggi RFC 2822 nel seguente ordine di priorità:

  1. Resent-Sender
  2. Resent-From
  3. Sender
  4. From

Il dominio del mittente (o l'entità responsabile dell'inserimento di un messaggio nel flusso di messaggistica, poiché i sistemi di posta elettronica sono autorizzati a inoltrare i messaggi per conto di altri server di posta) viene determinato dall'individuazione della prima definizione delle intestazioni sopra illustrate nell'ordine definito. Se non viene rilevata nessuna di queste intestazioni, SIDF utilizzerà il valore MAIL FROM definito nella specifica RFC 2821 del protocollo SMTP.

Configurazione dell'ID mittente

In Exchange Server 2007 l'agente dell'ID mittente può essere abilitato sui server in cui sia installato il ruolo Trasporto edge. Se l'agente dell'ID mittente viene abilitato, verranno filtrati tutti i messaggi che passano attraverso i connettori di ricezione: tutto il traffico non autenticato in arrivo (da origini esterne) sarà soggetto all'elaborazione dell'ID mittente. In Exchange Server 2003 lo stato dell'ID mittente viene reso permanente da server a server nel blob EXCH50. In Exchange Server 2007 è stato aggiunto anche ai metadati del messaggio. Nella destinazione finale entrambi vengono convertiti in una proprietà MAPI, per consentirne l'utilizzo futuro da parte dei client.

La configurazione del filtro dell'ID mittente in Exchange Server 2003, disponibile nelle proprietà Recapito messaggi, prevede solo l'impostazione della modalità di gestione delle convalide non riuscite in Exchange Server.

Per abilitare l'ID mittente in Exchange Server 2007, è sufficiente aprire l'Exchange Management Console per un server in cui sia configurato il ruolo Trasporto edge, fare clic sulla scheda Anti-spam, quindi selezionare ID mittente e, nel riquadro Azioni, fare clic su Attiva o Disattiva per abilitare/disabilitare l'agente dell'ID mittente, come illustrato nella Figura 2. Per abilitare/disabilitare l'ID mittente è inoltre possibile utilizzare l'Exchange Management Shell, come illustrato nella Figura 3.

Figura 2 Controlli di Exchange Management Console per l'agente dell'ID mittente in Exchange Server 2007

Figura 2** Controlli di Exchange Management Console per l'agente dell'ID mittente in Exchange Server 2007 **(Fare clic sull'immagine per ingrandirla)

Figura 3 Abilitazione dell'ID mittente mediante l'Exchange Management Shell

Figura 3** Abilitazione dell'ID mittente mediante l'Exchange Management Shell **(Fare clic sull'immagine per ingrandirla)

Nella finestra di dialogo Proprietà ID mittente sarà indicato lo stato dell'agente, abilitato o disabilitato. Nella scheda Azione sono disponibili opzioni molto simili alle opzioni presenti in Exchange Server 2003 (vedere la Figura 4).

Figura 4 Proprietà delle azioni dell'agente dell'ID mittente in Exhange Server 2007

Figura 4** Proprietà delle azioni dell'agente dell'ID mittente in Exhange Server 2007 **(Fare clic sull'immagine per ingrandirla)

Non esiste alcun differenza sostanziale tra Exchange Server 2003 e Exchange Server 2007 in termini di funzionalità e implementazione dell'ID mittente. Per il filtro dell'ID mittente (in Exchange Server 2003) e per l'agente dell'ID mittente (in Exchange Server 2007) si utilizza lo stesso algoritmo sottostante per l'estrazione e la verifica. Anche la gamma delle azioni che è possibile eseguire è identica: Elimina messaggio (eliminazione automatica), Rifiuta messaggio (risposta di protocollo SMTP di livello 500) e Contrassegna messaggio con risultato ID mittente e continua l'elaborazione. Quest'ultima opzione rappresenta l'azione predefinita in entrambe le versioni di Exchange Server.

In Exchange Server 2007 i codici di stato FAIL e TempError possono attivare l'azione Rifiuta messaggio (in Exchange Server 2003 l'azione può essere attivata solo dal codice di stato FAIL). L'agente dell'ID mittente deve essere configurato in modo esplicito per l'attivazione dell'azione Rifiuta messaggio nei messaggi con il codice di stato TempError poiché, per impostazione predefinita, tali messaggi verranno accettati nel sistema, contrassegnati con il risultato dell'ID mittente ed elaborati in seguito.

Questa opzione di configurazione non viene esposta dall'interfaccia utente grafica, per configurare le azioni dell'ID mittente per il codice di stato TempError è necessario utilizzare l'Exchange Management Shell. Per forzare ad esempio l'agente dell'ID mittente a rifiutare messaggi con il codice di stato TempError, utilizzare il cmdlet dell'agente dell'ID mittente seguente:

Set-SenderIDConfig -TempErrorAction Reject

La gamma dei risultati dello stato dell'ID mittente e delle possibili azioni in Exchange Server 2007 è simile ai risultati del filtro dell'ID mittente di Exchange Server 2003, come illustrato nella Figura 5.

Figure 5 Azioni e stato dell'ID mittente in Exchange Server 2007

Stato dell'ID mittente Descrizione Azioni
Neutro I dati dell'ID mittente pubblicati non hanno prodotto risultati espliciti StampStatus
Pass L'indirizzo IP si trova nel set consentito StampStatus
Fail L'indirizzo IP non si trova nel set consentito StampStatus, Elimina o Rifiuta
SoftFail L'indirizzo IP del PRA potrebbe non trovarsi nel set consentito StampStatus
Nessuno Non esistono dati pubblicati StampStatus
TempError Si è verificato un errore temporaneo, ad esempio la non disponibilità del server DNS StampStatus o Reject
PermError Si è verificato un errore irreversibile, ad esempio un errore nel formato del record StampStatus

Exchange, se configurato per l'esecuzione di tale operazione, elimina solo i messaggi che non hanno superato il processo di verifica dell'ID mittente. Nessun altro risultato determinerà l'attivazione dell'azione di eliminazione del messaggio. I messaggi in arrivo a cui è stato assegnato lo stato Neutro, Nessuno, SoftFail, TempError o PermError verranno contrassegnati in modo appropriato e trasferiti per consentire ulteriori verifiche della posta indesiderata. In alcuni casi, quando il formato del messaggio non è corretto e manca l'indirizzo IP FROM, non è possibile contrassegnare nel messaggio lo stato dell'ID mittente. In questa situazione il messaggio non viene ignorato né rifiutato, ma viene trasmesso per consentirne un'ulteriore elaborazione senza lo stato dell'ID mittente impostato. Viene inoltre registrato un evento appropriato per informare gli utenti della presenza di un messaggio di questo tipo.

In Exchange Server 2007 la definizione dei domini dei mittenti e dei destinatari di Exchange Server che devono essere esclusi dalla verifica dell'ID mittente è piuttosto semplice. Questa opzione di configurazione è disponibile solo se si utilizza l'Exchange Management Shell. Per escludere, ad esempio, il dominio contoso.com dal filtro dell'ID mittente, eseguire il comando:

Set-SenderIDConfig -BypassedSenderDomains contoso.com

Analogamente, per escludere i messaggi inviati a specifici destinatari di Exchange Server dal filtro dell'ID mittente, eseguire il comando:

Set-SenderIDConfig -BypassedRecipients user@contoso.com

Per ottenere in Exchange Server 2007 i valori di configurazione dell'ID mittente impostati tramite i cmdlet dell'Exchange Management Shell ma non disponibili tramite l'interfaccia utente grafica, è sufficiente eseguire il comando Get-SenderIDConfig nell'Exchange Management Shell, come illustrato nella Figura 6.

Figura 6 Cmdlet di configurazione dell'ID mittente

Figura 6** Cmdlet di configurazione dell'ID mittente **(Fare clic sull'immagine per ingrandirla)

È possibile utilizzare l'Exchange Management Shell per eseguire rapidamente la verifica manuale dell'indirizzo IP e del nome di dominio corrispondente. Per controllare lo stato dell'ID mittente, eseguire il comando:

Test-SenderID -IPAddress <IPAddress>-PurportedResponsibleDomain <SMTPDomain>

Se il dominio non esiste, verrà visualizzato un risultato simile a quello mostrato nella Figura 7.

Figura 7 Verifica dello stato dell'ID mittente di un indirizzo

Figura 7** Verifica dello stato dell'ID mittente di un indirizzo **(Fare clic sull'immagine per ingrandirla)

Vantaggi dell'ID mittente

Oltre agli ovvi benefici derivanti dall'autenticazione dei messaggi di posta elettronica e dalla riduzione della quantità di posta indesiderata ricevuta dagli utenti, il protocollo SIDF offre ulteriori vantaggi. Durante il processo di sviluppo del protocollo, Microsoft ha focalizzato l'attenzione su diversi obiettivi chiave, quali prestazioni, costo, distribuzione, scalabilità e interoperabilità.

SIDF esegue prima l'autenticazione del mittente di un messaggio di posta elettronica e successivamente consente di attribuire un punteggio relativo alla reputazione del mittente. Di conseguenza, questa tecnologia è in grado di ridurre in modo significativo il volume di messaggi di posta elettronica indesiderati e falsificati nonché di migliorare il recapito di messaggi autorizzati inviati da mittenti conosciuti e affidabili. La creazione di un record SPF è gratuita e le aziende che lo desiderino possono garantire la conformità con il protocollo SIDF senza alcuna difficoltà. Le organizzazioni che intendono garantire la conformità ai requisiti di un nuovo standard vanno sostenute. Con SIDF, la garanzia della conformità è semplice quanto la pubblicazione di un record SPF.

SIDF è stato sviluppato per operare all'interno del software esistente, ove possibile, e può essere utilizzato con un'ampia gamma di architetture di posta elettronica e di software client e server. Qualsiasi servizio di autenticazione, perché sia efficace, deve essere in grado di soddisfare le esigenze sia dei più piccoli server di posta domestici che degli ISP di grandi dimensioni. SIDF è in grado di supportare i requisiti di un singolo così come di migliaia di server di posta elettronica, oltre che dei server affidati in outsourcing ad altre organizzazioni.

Il 18 e 19 aprile del 2007, Microsoft e un consorzio industriale di oltre 30 organizzazioni e partner ospiteranno l'evento Authentication & Online Identity Summit a Boston, MA. Durante l'evento si esamineranno i case study e si offrirà un'analisi tecnica dell'ID mittente, descrivendo in dettaglio il valore di business dell'autenticazione della posta elettronica. Per ulteriori informazioni, visitare il sito Web all'indirizzo aotalliance.org/summit2007 (in inglese). Per informazioni su strumenti e risorse, è possibile visitare i siti Web microsoft.com/senderid e microsoft.com/exchange (in inglese).

Craig Spiezle è Director of Technology Strategy and Planning for Windows Live Safety presso Microsoft. In qualità di Product Manager per l'autenticazione della posta elettronica, Craig ha svolto un ruolo fondamentale nella promozione dell'ID mittente sul mercato. Craig, che ha iniziato la sua carriera professionale in Microsoft nel 1992, ha occupato diverse posizioni di responsabilità, tra cui marketing internazionale, strategie di supporto dei prodotti, OEM e sviluppo dei mercati emergenti.

Alexander Nikolayev è Program Manager in Microsoft ed è responsabile dei protocolli sul lato server, del modulo principale di trasporto e dei componenti di protezione dalla posta indesiderata per Exchange Server e Windows Server. Ha conseguito un MBA presso l'University of Mary. È possibile leggere le pubblicazioni di Alexander sul blog del team di Exchange all'indirizzo blogs.technet.com/exchange (in inglese).

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