BR Indice()

Introduzione

Questa guida illustra come installare e configurare un server mail.

È utile prendersi il tempo necessario per pianificare un corretto partizionamento del disco, possibilmente dedicando una partizione per /var/log e una per /var/spool/mail.

La gestione della posta elettronica in rete coinvolge tre attori :

• un client di posta, che è il programma deputato alla formattazione dei messaggi di posta;
• un Mail Transport Agent, MTA, che è un server che si occupa di instradare la posta al destinatario;
• un delivery agent, DA, che è il server che si occupa di consegnare la posta al destinatario.

Il meccanismo di instradamento è basato sull'associazione fra dominio di posta elettronica e dominio DNS. Pertanto, il MTA per consegnare la posta verso il destinatario utilizzerà interrogazioni DNS per effettuare la localizzazione del DA del destinatario.

Nei sistemi UNIX, il MTA usa il protocollo SMTP mentre i DA usano i protocolli POP3 o IMAP.

La fondamentale differenza fra i protocolli per il DA è che POP3 è progettato per il download dei messaggi sulla postazione client del destinatario, mentre IMAP consente di mantenerli sul server. Entrambi tali protocolli presentano vantaggi e svantaggi.

Inoltre, la configurazione qui presentata è arricchita con filtri anti-spam non nativi di postfix (si usa il prodotto spamassassin) e con un software in grado di coordinare la scansione asincrona dei messaggi di posta attraverso l'uso dei filtri anti-spam e antivirus (questo prodotto è mailscanner).

Verrà esaminata sia la configurazione del MTA per lo smistamento dei messaggi di utenti locali UNIX (ovvero gli utenti di sistema definiti con il comando adduser), che quella che utilizza come backend un DB LDAP (ovvero un servizio di directory standardizzato con gestione degli account di utenti di rete).

Installazione

Da un terminale digitare:

sudo apt-get -y install postfix postfix-ldap spamassassin dovecot-pop3d dovecot-imapd mailscanner

Configurazione

Mail transfer agent

I file di configurazione si trovano nella directory /etc/postfix e il file fondamentale è main.cf. Un altro file importante nella configurazione di postfix è /etc/aliases, che contiene tutti gli alias degli utenti di posta elettronica.

Per esempio, supponendo di avere un utente di sistema prova, è possibile definire nel file /etc/aliases un alias come segue:

p.miodominio.com:       prova

che indica semplicemente che l'utente di sistema prova è identificato dal sistema MTA come p.miodominio.com.

Il corrispondente file di configurazione per i servizi LDAP è /etc/postfix/ldap-aliases.cf e contiene le seguenti direttive:

server_host = nome completo del server LDAP

search_base = dc=miodominio,dc=com

dove ovviamente è necessario sostituire miodominio e com con il proprio basedn del dominio di ricerca LDAP.

Per configurare postfix, aprire il file /etc/postfix/main.cf e modificare il messaggio di benvenuto:

smtpd_banner = nostro messaggio di benvenuto

Quindi modificare le righe seguenti di conseguenza:

myhostname = FQDN di questo server (es : wilcoyote.example.com)

mydomain = dominio di posta (=dominio DNS nel caso di LAN)

alias_maps = hash:/etc/aliases,ldap:/etc/postfix/ldap-aliases.cf

Questo dice al MTA che deve controllare, per la risoluzione dei nomi utente, prima il file /etc/aliases e poi il database LDAP referenziato dalle direttive nel file /etc/aliases.

La direttiva:

myorigin = $mydomain

dice che si invia posta soltanto per il proprio dominio, mentre:

mydestination = dominio di posta (=dominio DNS nel caso di LAN) , localhost.localdomain,localhost

indica che si accetta posta indirizzata soltanto al proprio dominio o a localhost (127.0.0.1).

inet_interfaces = all

questo dice che il MTA all'avvio sta in ascolto su tutte le interfacce di rete (potreste voler cambiare questo comportamento!!)

smtpd_client_restrictions = reject_maps_rbl , reject_unknown_client , permit

qui cominciano le restrizioni d'accesso native di postfix: questa dice di non accettare posta indirizzata o provenienete da siti di possibili spammers (indicati nella direttiva maps_rbl_domains) e di non accettare connessioni da clients che non hanno record A in DNS

smtpd_sender_restrictions = reject_unknown_sender_domain , reject_non_fqdn_sender , permit

questa restrizione dice di non smistare posta proveniente da un mittente ignoto

smtpd_recipient_restrictions = reject_unauth_destination , reject_non_fqdn_recipient , reject_unknown_recipient_domain , permit

questa restrizione dice di non effettuare il relay (ovvero di non permettere di inviare posta elettronica da mittenti che non siano di questo sito) e di non smistare posta proveniente da un mittente ignoto

N.B. : la restrizione reject_unauth_destination dice al server di posta di impedire l'open relay e sostituisce la direttiva check_relay_domains

smtpd_helo_restrictions = reject_invalid_hostname , reject_non_fqdn_hostname , reject_unknown_hostname , permit

queste restrizioni dicono di non accettare il saluto dal client che non risponda con un hostname esistente nel DNS (respingere se l'hostname presentato è invalido , non è nel formato FQDN o non ha record A o PTR nè MX nel DNS).Queste restrizioni sono molto importanti , poichè ad oggi molti spammers fanno uso di comandi helo-faked per velocizzare la spedizione di spam.

maps_rbl_domains = rbl.maps.vix.com,dul.maps.vix.com,relays.mail-abuse.org

questa restrizione dice di non smistare posta proveniente da o indirizzata verso i domini elencati

Ora potete avviare il servizio postfix del MTA con il comando:

/etc/init.d/postfix start 

Tutti i log files inerenti lo startup dei servizi postfix ed i relativi accessi sono contenuti nei files /var/log/mail.warn, /var/log/mail.err, /var/log/mail.info.

Qualora si voglia aggiungere un po' di sicurezza in più, c'è un'ulteriore direttiva da usare nel file main.cf per limitare lo spam. La direttiva è:

smtp_helo_restrictions = reject_invalid_hostname , reject_non_fqdn_hostname , reject_unknown_hostname , permit_nak*ed_ip_address , permit

Questa restrizione opera nel modo seguente :

• rifiuta l'accesso al servizio per client che non rispondono al messaggio di benvenuto del server Postfix con un nome host valido (gli spammers lo fanno spesso per risparmiare tempo)
• rifiuta l'accesso al servizio MTA se il nome host passato di seguito al comando helo non è un fqdn hostname (cioè della forma mail.example.com)
• rifiuta l'accesso al servizio MTA se l'hostname che segue il comando helo non può essere risolto (questo capita quando lo spammer mette di seguito al comando helo una stringa casuale , allora l'MTA interroga un DNS per risolvere il nome host immesso , se non lo trova rifiuta l'accesso)
• consente l'accesso se di seguito al comando helo viene concatenato un IP

Come vedete in coda viene messa la direttiva permit che dice che al di fuori delle restrizioni applicate tutto il resto viene accettato.

Applicate queste restrizioni con moderazioni perchè potrebbero impedire al servizio di funzionare correttamente.

DA

Per la configurazione del DA si proceda come segue : Eseguite il comando:

#vi /etc/dovecot/dovecot.conf

e modificate la riga protocols come segue :

protocols = pop3 pop3s imap imaps

questo abiliterà i servizi pop3(s) e imap(s) alla'avvio di dovecot.

A questo punto per avviare il vostro DA basta eseguire il comando :

#/etc/init.d/dovecot start

ed esaminando l'output del comando ps -A|grep dovecot noterete che il servizio si è avviato con successo.

Web mail

Il servizio di posta elettronica fruibile dal browser Web, webmail, richiede che siano installati il web server e il programma squirrelmail per l'accesso alle mailboxes attraverso il browser web.

Ora si procede all'installazione di apache2 e di squirrelmail con i comandi :

#sudo apt-get -y install apache2

#sudo apt-get -y install squirrelmail

Per predisporre squirrelmail alla gestione della posta elettronica in modalità protetta (attraverso l'uso di certificati con SSL server-side) si userà il comando per generare un certificato per il server web :

#apache2-ssl-certificate -days 3650

dove 3650 è la durata di validità del certificato (10 anni, cambiarlo a proprio piacimento se si vuole).

A questo punto procedere all'aggiunta di un nuovo Virtual Host nel file /etc/apache2/sites-enabled/000-default come segue :

<VirtualHost 192.168.0.1>

SSLCertificateFile /etc/apache2/ssl/apache.pem

DocumentRoot /usr/share/squirrelmail

ServerName webmail.example.com

</VirtualHost>

dove ovviamente si sosituiranno 192.168.0.1 e webmail.example.com con l'IP e l'alias name del server di posta web.

Per sperimentare l'accesso attraverso imap da browser web non resta che eseguire i comandi :

#/etc/init.d/dovecot start
  
#/etc/init.d/apache2 start

ed immettere il comando da shell :

#firefox https://webmail.example.com:80 ed il gioco è fatto! 

MailScanner

Per ottenere un ulteriore livello di protezione sul vostro MTA e DA potete associare una scansione antivirus ed un filtro anti-spam che effettuino il controllo di ogni messaggio di posta smistato dal vostro sistema.

Come detto vi occorre il software MailScanner e un AntiVirus (nell'esempio riportiamo Clamav) che si installano nel modo seguente :

#sudo apt-get -y install mailscanner

#sudo apt-get -y install clamav-daemon

#sudo apt-get -y install clamav-freshclam

Effettuata l'installazione si proceda con il comando :

#vi /etc/MailScanner/MailScanner.conf

e si modifichino le righe seguenti :

VirusScanner''' = clamav

%org-name%''' = Nome della vostra Azienda

%report-dir%''' = /etc/MailScanner/reports/it

QuarantineInfections''' = no

Information Header Value''' = Informazioni personali dell'azienda

Warning Is Attachment''' = no

Notices Include Full Headers''' = yes

Spam List''' = ORDB-RBL SBL+XBL EasyNet-DNSBL BLITZEDALL SORBS-DNSBL spamcop.net

a questo punto salvate e riavviate mailscanner con il comando :

#/etc/init.d/mailscanner restart

Controllate il corretto avvio in /var/log/syslog e con il comando

ps -A|grep mailscanner

Migliorare le prestazioni

Il performance tuning dipende da alcuni parametri del vostro mail server :

• process availability

• CPU speed

• DNS lookup time

• disk I/O speed

• network throughput

Come effettuare il tuning del process availability :

• modificate il max numero di processi di postfix per rispondere ai picchi di carico

in main.cf :

default_process_limit = 100

L'ottimizzazione procede attraverso l'analisi dei fattori che condizionano le prestazioni di un Mail Server , ovvero :

• CPU limitation :

se il carico sul vostro processore supera il 50% (esaminatelo con top ed individuate se la causa è imputabile ai processi di postfix) allora cambiate processore!

• DNS lookup :

poichè il primo passo per inoltrare emails sono queries DNS , se il tempo di risposta per una query DNS è alto pensate a ottimizzare il vostro DNS o meglio ancora implementate un caching NS al vostro interno per velocizzare le risoluzioni

• Disk I/O limitation :

usate dischi SCSI (postfix usa code di mail in /var/spool/mail e sposta i dati da una coda all'altra) e montate le partizioni con l'opzione noatime (postfix non usa i timestamps)

Sicurezza dei protocolli di posta

Il protocollo SMTP non è stato progettato per essere sicuro.

Come vedete per spedire un messaggio di posta elettronica non è necessaria alcuna autenticazione da parte dell'utente , pertanto chiunque può tentare di sfruttare problemi di sicurezza di un server SMTP.

Vi chiederete allora se è possibile utilizzare meccanismi di protezione per aumentare la sicurezza dei vostri servers SMTP,in particolare per crittografare un'intera sessione (ovvero dal primo all'ultimo bit).

L'uso dei certificati digitali così come quello della Strong Authentication con SASL è possibile attraverso opportuni moduli messi a disposizione dai programmi di posta stessi , il problema è (per fare l'esempio della protezione tramite certificati) che ciò che verrà crittografato è il traffico fra il client ed il vostro server di posta , ma al di fuori del vostro server (ovvero fino al server SMTP che smista la posta per il dominio del destinatario) le comunicazioni avverranno in chiaro...questo a meno che anche il dominio remoto non utilizzi un sistema di certificati come il vostro.

Questo perchè la protezione di una sessione SMTP con certificati richiede che tutte le entità che comunicano abbiano un certificato verificabile da una Root CA...pertanto se anche uno solo dei vostri destinatari non avrà un certificato , allora la comunicazione fra il vostro server di posta ed il server di posta di quel dominio avverrà in modo non protetto.

E considerazioni analoghe possono essere fatte per i metodi di autenticazione forte che utilizzano la libreria SASL.

Pertanto l'implementazione di meccanismi di protezione delle intere sessioni di posta è subordinata all'implementazione di una PKI globale (cioè estesa a tutti i domini di posta da voi raggiungibili) nel caso dei certificati digitali e di un protocollo SMTP che richieda l'autenticazione di default nel caso di SASL.

Questo richiederà probabilmente un nuovo standard per le comunicazioni di posta.

Pertanto dovete valutare se vale la pena implementare all'interno della vostra azienda la protezione delle sessioni SMTP con questi metodi. Questo potrebbe fare al caso vostro se volete proteggere le comunicazioni interne , ma quelle con l'esterno resteranno sempre esposte al rischio di attacchi e violazioni.

Per fare un esempio concreto se state gestendo un sistema di posta fra N aziende consociate che si scambiano dati sensibili , allora potreste voler creare una PKI ed utilizzare i certificati emessi per garantire l'integrità e la confidenzialità delle informazioni scambiate durante le sessioni. Tuttavia deve esservi chiaro che tutte le sessioni di posta con domini esterni a tali consociate non saranno prote*tte.

E per quanto riguarda i protocolli POP3 e IMAP , la cosa è anche peggiore.

I clients POP3 e IMAP nella loro configurazione standard inviano le credenziali di autenticazione dell'utente di posta in chiaro sulla rete... Pertanto chiunque sarà in grado di catturarle avrà una facile base di accesso al vostro sistema.

La protezione tramite SASL o certificati digitali è sempre possibile , ma come spiegato per essere realmente utile dovrebbe riguardare tutti i domini da cui ricevete la posta , non soltanto il vostro.

Tuttavia se non è possibile assicurare una protezione globale di un'intera sessione di posta, la crittografia a chiave pubblica rende comunque possibile proteggere almeno i dati da voi scambiati in un messaggio...cioè il contenuto di tale messaggio oltre che file allegati.

Questo è la'rgomento del paragrafo seguente.

Protezione di messaggi con GPG

GPG (Gnu Privacy Guard) è un programma che utilizza la crittografia a chiave asimmetrica per garantire la confidenzialità e l'integrità delle informazioni scambiate in un messaggio di posta.

Per utilizzarlo dovete installare su tutte le postazioni client il pacchetto gpg con il comando :

sudo apt-get -y install gpg

Pertanto voi potete crittografare il contenuto di un messaggio di posta utilizzando la chiave pubblica dell'utente al quale volete spedirlo e firmare il file crittografato con la vostra chiave privata in modo da assicurarne l'autenticità.

Descriviamo con un esempio pratico il flusso delle azioni che l'utente pippo@example.com deve fare per spedire un messaggio protetto all'utente pluto@prova.edu.

• L'utente pippo crea la sua coppia di chiavi privata/pubblica con il comando

gpg --gen-key

Selezionare 1 come algoritmo (ElGamal) per poter utilizzare le chiavi per la cifratura e la firma.

• pippo visualizza le chiavi create con il comando

gpg --list-keys

• pippo esporta la sua chiave pubblica nel repository comune utilizzando il comando

gpg --export -o pippo
sftp pippo@publickeys:/keys/pippo

• pippo preleva la chiave pubblica di pluto@prova.edu dalla directory /keys sul server publickeys (che funge da repository comune di tutte le chiavi pubbliche degli utenti del sistema di posta comune) e la importa nel suo DB delle chiavi (generato con gpg --gen-key)

sftp pippo@publickeys:/keys/pluto
gpg --import pluto

questo metterà la chiave di pluto nella directory corrente di pippo.

• pippo ora crittografa il messaggio di posta contenuto nel file README.txt con la chiave pubblica di pluto e lo firma con la sua chiave privata

gpg -se -r pluto README.txt

• pippo spedisce il messaggio README.txt.gpg a pluto@prova.edu usando il suo mail server

• pluto importa la chiave pubblica di pippo con il comando

sftp pluto@publickeys:/keys/pippo
gpg --import pippo

• l'utente pluto va a decifrare il messaggio con il comando

gpg -o README.txt -d README.txt.gpg 

• se pippo visualizza un messaggio del tipo

Good signature...

allora vuol dire che il messaggio non è stato alterato durante la consegna , altrimenti in caso di compromissione visualizzerà un messaggio del tipo

Bad Signature...

Autore : Cristiano Valli

Ulteriori risorse

• [http://www.postfix.org/ Sito ufficiale del progetto Postfix]

• [http://www.dovecot.org/ Sito ufficiale del progetto Dovecot]

• [http://www.squirrelmail.org/ Sito ufficiale del progetto SquirrelMail]

CategoryDaRevisionare CategoryServer