Può capitare che alcune applicazioni abbiano bisogno di spedire mail verso indirizzi di posta esterni all’azienda, utilizzando un server Exchange interno (2007 o 2010). Alcuni esempi possono essere :
- un software di backup che deve spedire le mail di avvenuto/fallito backup
- un software di monitoraggio che deve spedire mail contenenti avvisi, alert, report o altro
- un software fax che deve spedire periodicamente le mail contenenti il report dei fax ricevuti ultimamente
- il Visualizzatore Eventi di Windows 7/Windows Server 2008, che dà la possibilità di spedire una mail a qualcuno al verificarsi di un certo evento
Tipicamente, queste applicazioni sono in grado di formattare le mail, ci chiedono di indicare loro un server di posta a cui consegnarle, e poi dovrà essere compito del server di posta inoltrarle all’indirizzo SMTP di destinazione. Inoltre, queste applicazioni di solito non sanno effettuare un’autenticazione col server di posta stesso.
In questo caso, siamo davanti al cosiddetto “Relay Anonimo” : un server di posta deve, cioè, essere in grado di ricevere in carico una mail da un’entità non autenticata (l’applicazione), ed effettuarne un “relay” verso l’indirizzo SMTP esterno specificato nella mail. I server Exchange di Microsoft rifiutano, per default, questo tipo di operazione, per ragioni di sicurezza.
Il Relay Anonimo potrebbe essere utilizzato dagli spammer per nascondere la sorgente dei loro messaggi, e quindi rappresenta un grosso problema di sicurezza se utilizzato maldestramente.
In Exchange 2007 e 2010 il relay si configura utilizzando gli “Accepted Domains”, configurati sui server Edge o Hub. Per un certo dominio di posta (o per tutti i domini, ma non fatelo!!!… vorrebbe dire “Open Relay”, e finireste subito in blacklist!!…), si può istruire il server Exchange a riceverne le mail e ad inoltrarle verso altri server di posta esterni. Ma questo non è ciò che voglio spiegare in questo articolo.
Vi farò invece vedere come restringere il relay anonimo in base alla sorgente del messaggio da inoltrare, che, ripeto, può essere un’applicazione interna non in grado di autenticarsi col server Exchange.
Il trucco consiste nel creare un “Receive Connector” dedicato a ricevere mail dall’applicazione, al quale dovremo indicare di non autenticare l’applicazione stessa, e di considerarla in qualche modo un’entità “di fiducia”. In questo modo Exchange eseguirà il relay delle sue mail anche verso l’esterno.
Nel mio esempio, simulo l’applicazione non autenticata con un banale Telnet Client, aperto su un Windows 7 con indirizzo IP 10.10.0.50, mentre il server Exchange si chiama VAN-EX1, ed è nella stessa rete del client. Sul server Exchange, i Receive Connectors sono configurati come di default (Fig. 1) :
Fig. 1
In Fig. 2 mi sono connesso dal client alla porta 25 di VAN-EX1 e ho provato a spedire una mail verso un indirizzo di posta esterno (info@ivansalvade.it), ottenendo come esito ”Unable to Relay” :
Fig. 2
Il comportamento è corretto : il Receive Connector “Default VAN-EX1″, non consente il relay anonimo verso l’esterno di una mail da lui ricevuta.
Creo ora un nuovo Receive Connector che configurerò per il relay anonimo (Fig. 3) :
Fig. 3
Lascio inalterati i Local Network Settings… (Fig. 4) :
Fig. 4
… ma modifico i Remote Network Settings eliminando la voce preesistente “0.0.0.0-255.255.255.255″ ed inserendo unicamente l’indirizzo IP del client (Figg. 5 e 6) :
Fig. 5
Fig. 6
Terminata la creazione del nuovo Receive Connector, si entra nelle sue proprietà per modificare due parametri (Fig. 7) :
Fig. 7
Nel tab “Permission Groups” devo selezionare la voce “Exchange Servers” (Fig. 8 ) e nel tab “Authentication” devo selezionare la voce “Externally Secured” (Fig. 9) :
Fig. 8
Fig. 9
Cosa significano questi due parametri?
Con il settaggio “Externally Secured” si avvisa Exchange di considerare la connessione sicura, senza preoccuparsi di doverla autenticare. Questo è utile quando tra client e server esiste già un’associazione IPSec o una VPN (non è il nostro caso), oppure quando noi personalmente riteniamo il client “sicuro” (è il nostro caso).
Quando imposto “Externally Secured” nel tab “Authentication” sono obbligato a selezionare anche la voce “Exchange Servers” nel tab “Permission Groups”. La selezione è imposta dal wizard, che altrimenti genererebbe un errore.
La combinazione di “Externally Secured” e “Exchange Servers” assegna al Receive Connector (e quindi alle connessioni entranti su di esso) le seguenti autorizzazioni :
- Ms-Exch-Accept-Headers-Routing
- Ms-Exch-SMTP-Accept-Any-Sender
- Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
- Ms-Exch-SMTP-Submit
- Ms-Exch-Accept-Exch50
- Ms-Exch-Bypass-Anti-Spam
- Ms-Exch-Bypass-Message-Size-Limit
- Ms-Exch-SMTP-Accept-Any-Recipient
- Ms-Exch-SMTP-Accept-Authentication-Flag
L’autorizzazione “Ms-Exch-SMTP-Accept-Any-Sender” permette al connettore di accettare qualunque tipo di mittente nelle mail. L’autorizzazione “Ms-Exch-SMTP-Accept-Any-Recipient” è proprio quella che garantisce al connettore di eseguire relay dei messaggi a qualunque destinatario. Se non ci fosse questa autorizzazione, sarebbe garantito solo il relay verso destinatari facenti parte della lista dei domini accettati.
Molto interessanti anche le autorizzazioni “Ms-Exch-Bypass-Anti-Spam” e “Ms-Exch-Bypass-Message-Size-Limit”: significa che i messaggi provenienti dagli IP specificati nel connettore bypassano i controlli anti-spam e pure i controlli sulla grandezza massima dei messaggi.
Ricordo ancora che, con questo sistema, gli indirizzi IP di provenienza delle mail sono considerati totalmente “di fiducia”, ed Exchange si fida della nostra valutazione “personale” fatta su tali indirizzi.
Rifacciamo ora la prova di spedizione di una mail dal client 10.10.0.50 verso l’indirizzo esterno info@ivansalvade.it. Questa volta l’esito è “Recipient OK” (Fig. 10) : Exchange ha infatti utilizzato il nuovo connettore impostato su “Externally Secured”, in quanto la mail proveniva esattamente dall’indirizzo IP 10.10.0.50, dichiarato come IP sorgente nel connettore. In presenza di due connettori con indirizzi IP parzialmente sovrapposti (nel nostro caso il connettore “Default VAN-EX1″ comprende anche 10.10.0.50), viene utilizzato quello con l’indirizzo IP (o il range di indirizzi IP) più specifico.
Fig. 10
Buon Relay Anonimo a tutti…. ma non esagerate perchè è pericoloso!!! 