Exchange 2010: Difendersi dallo spoofing, lo spam che arriva dai nostri indirizzi di posta

In questi giorni si sta abbattendo sulle nostre mailbox un’ondata di spam che utilizza la tecnica del mail spoofing di tipo self-sending. In pratica si tratta di un particolare metodo di spamming dove le mail che riceviamo sembrano provenire da noi stessi o, comunque, da indirizzi di posta interni al nostro dominio. Ad esempio si veda l’immagine allegata:

Nell’esempio sembra che le mail siano inviate da una mail aziendale, come indicano le frecce. Questo tipo di attacco sfrutta una debolezza del protocollo SMTP il quale non prevede una tecnica di autenticazione. In questo articolo vedremo come difendersi da questo tipo di attacco in un ambiente con Exchange Server 2010.

Innanzitutto questo attacco è realizzabile in modo molto semplice laddove sul DNS pubblico del nostro dominio di posta non sia propriamente implementato il protocollo SPF (Sender Policy Framework). Vediamo cosa succede, senza SPF attivo, mandando una mail con mittente fasullo.

In questo caso ho utilizzato un PC esterno alla mia rete e tramite Putty ho inviato una mail al mio server Exchange tramite Telnet.

Ed ecco la mail che arriva al mio client, inesorabile:

Va da se che qualsiasi spammer potrebbe fare la stessa cosa e mi vedrei la mailbox piena di messaggi indesiderati. Non sarebbe possibile agire con regole, senza inventarsi qualcosa di macchinoso e complesso, perchè il dominio mittente sarebbe il mio e quindi rischierei di eliminare messaggi validi.

Per risolvere il problema devo quindi attivare il controllo del Sender ID (ID Mittente) dalla console di Exchange Server. Per farlo mi posiziono quindi su Configurazione dell’organizzazione, Protezione posta indesiderata e con il tasto destro del mouse attivo il controllo su ID Mittente.

Dalle proprietà del criterio vado poi a specificare che intendo rifiutare tutti i messaggi che non soddisfino tale controllo.

L’operazione successiva va eseguita sul DNS pubblico del nostro dominio. Devo infatti creare un record TXT e valorizzarlo secondo quella che è la sintassi stabilita dal protocollo SPF.
Il protocollo specifica, in merito ad un determinato dominio (nomeazienda.it), quali siano gli host autorizzati ad inviare mail con mittenti appartenenti al dominio stesso (utente@nomeazienda.it)

Nel mio caso l’SPF relativo al dominio andreamonguzzi.it è il seguente:

v=spf1 ip4:93.241.97.162/32 ip4:72.9.154.122/32 –all

Ho in pratica specificato che gli unici indirizzi IP autorizzati ad inviare mail sono quelli indicati. Uno è quello della mio server Exchange mentre l’altro è quello di un servizio cloud che gestisce un sistema di ticketing che invia mail a nostro nome. Nessun altro IP è autorizzato a inviare mail con mittente @andreamonguzzi.it.
Il caso classico prevederà di inserire tra gli IP autorizzati almeno quelli dei server SMTP relativi al nostro dominio o alla nostra connettività. Questo dato è facilmente ottenibile dal nostro ISP. Se ad esempio fossi titolare del dominio miaazienda.it e inviassi mail solo dal mio ufficio tramite una connessione NGI, dovrei inserire come IP autorizzato quelli dei server SMTP di NGI e/o quelli dei server SMTP dell’ISP gestore del mio dominio.
I parametri utilizzabili sono molteplici e rimando ad una guida completa sulla sintassi SPF reperibile qui.

Dopo aver ripristinato la configurazione SPF sul mio DNS, vediamo ora come si comporta lo stesso client Telnet utilizzato nell’esempio di poco fa inviando la stessa mail.

E’ possibile vedere come, adesso, tentando l’invio il server SMTP restituisca l’errore

550 5.7.1. Server ID (PRA) Not Permitted

A questo punto dovremmo aver ridotto la mole complessiva di spam in arrivo sulle nostre mailbox evitando, almeno, tutto quello di tipo self-sending.