Soluzione Completa per Server di Posta con Domini e Utenti Virtuali (Debian Etch, Postfix, Mysql, Dovecot, DSpam, ClamAV, Postgrey, RBL) - Pagina 10

VII. Email Sicura

In un mondo ideale, i nostri utenti potrebbero inviare/ricevere email ogni volta che sono in rete, da qualsiasi luogo nel mondo. Sfortunatamente, questo è incredibilmente insicuro… le password vengono scambiate in chiaro tramite i protocolli SMTP e IMAP, e ciò significa che chiunque volesse potrebbe semplicemente ‘spiare’ la password.

Se i tuoi utenti non hanno bisogno di accesso diretto alla soluzione di posta, allora non darlo loro! Non ha senso stressarsi per una configurazione di email sicura se tutto ciò di cui hanno bisogno è il Webmail! Basta rendere sicura la loro connessione al server webmail e assicurarsi che il server webmail utilizzi una connessione di rete sicura quando comunica con i tuoi server di posta. Problema risolto! Se, d’altra parte, i tuoi utenti richiedono la possibilità di inviare/ricevere posta tramite internet senza utilizzare il webmail, beh, questo rende le cose più difficili. Non impossibile, solo difficile.

Quindi, ecco il tuo problema: SMTP e IMAP inviano le password in chiaro. Puoi farli inviare le password utilizzando MD5, ma l’MD5 di base può essere violato. Puoi farli inviare le password utilizzando MD5CRYPT, ma poi ti trovi a dover gestire più implementazioni (per non parlare del fatto che non tutti i client di posta supportano le password MD5). La soluzione? TLS (Transport Layer Security). Configureremo la nostra soluzione per supportare una connessione crittografata su internet. Anche se potremmo modificare alcuni dei nostri server esistenti per gestire questo, non ha senso complicare ulteriormente le loro configurazioni. Eseguiremo semplicemente un server separato per gestire tutto questo: secure-mail.example.com

NOTA: Nello scenario originale, la piccola impresa aveva più indirizzi IP statici. Poiché questo è il caso, siamo stati in grado di eseguire SMTP+TLS sulla porta 25, se non hai più indirizzi IP, allora ciò non è possibile. La ragione è abbastanza semplice: mentre IMAPS (IMAP sicuro) utilizza una porta diversa (993) rispetto all’IMAP standard (143), SMTP+TLS utilizza la STESSA porta di SMTP (25). Quindi, utilizzare un firewall per instradare in base alle porte ti consente di eseguire server IMAP e IMAPS separati, ma nessun firewall al mondo può instradare la porta 25 verso due macchine diverse. Anche con tutto ciò, potresti sempre eseguire SMTP+TLS su una porta non standard… accidenti, sarebbe anche più sicuro.

Quindi, tenendo tutto ciò a mente, configureremo un server di posta sicuro, che utilizza SMTP+TLS per inviare posta e IMAPS per riceverla.

A. Certificati SSL

La forma più semplice di crittografia è avere un semplice certificato autofirmato sul server. Questo genererà un messaggio di avviso quando i client si connettono per la prima volta, ma dovrebbero essere in grado di salvarlo per un uso futuro. Non è realmente sicuro, poiché chiunque può eseguire un attacco man-in-the-middle se non salvi il certificato.

Il livello successivo è utilizzare un certificato del server firmato da un’Autorità di Certificazione (CA), sia essa commerciale o forse la CA interna dell’azienda. In questo modo, il certificato del server sarà considerato attendibile, e se ora ricevi un avviso, c’è potenzialmente qualcosa di brutto che sta accadendo.

Ultimo ma non meno importante è utilizzare certificati client per accedere al server e utilizzare un certificato del server per autenticare il server ai client. Questo è abbastanza sicuro, ma non è supportato in tutti i client di posta. Thunderbird, tra gli altri, ha supporto per questo.

1. Certificato del server autofirmato

Prima crea le directory, crea la chiave privata e infine crea il certificato.

# mkdir -p /etc/ssl/example.com/mailserver/  
# cd /etc/ssl/example.com/mailserver/  
# openssl genrsa 1024 > mail-key.pem  
# chmod 400 mail-key.pem  
# openssl req -new -x509 -nodes -sha1 -days 365 -key mail-key.pem > mail-cert.pem

Nota che “Common Name (es. IL TUO nome)” DEVE corrispondere al nome del server, che in questo caso è secure-mail.example.com

2. Certificato Firmato da CA

Utilizzare un certificato firmato da una vera CA non è diverso dall’utilizzare uno autofirmato. È solo un altro passaggio nella creazione della coppia di chiavi. Se la tua azienda ha la propria CA, allora dovrebbe emettere un certificato per il server di posta. Una ricerca su Google per essere la tua CA ti darà abbastanza risposte per crearne uno tu stesso, se ne hai bisogno.