Un pinguino per postino
di Tommaso Di Donato
La posta elettronica è diventata, per le ditte come per il navigatore occasionale, un servizio
imprescindibile. Questo articolo vuole essere il primo di una serie dedicata ai mail server,
a partire della configurazione dei servizi basilari smtp e pop3, fino ad arrivare a qualcosa di
un po' più avanzato, ad esempio web-mail e mailing list.
In passato, parlare di mail server linux era equivalente a parlare di Sendmail, il più noto e diffuso software
SMTP per *nix. Nonostante questa sua diffusione, non si può dire che Sendmail godesse di buona fama in quanto
a sicurezza...anche se le ultimissime versoni hanno subìto un pesante lavoro di riprogettazione, ed ora sono
molto affidabili! Ma fu questa fama di "mail server bacato" che, in passato, spinse alcuni virtuosi a scrivere
da zero un nuovo software SMTP interamente pensato in funzione della sicurezza. E fu così che nacquero
Postfix e Qmail: l'idea che sta alla base è avere un programma di facile configurazione e amministrazione, con
potenti funzionalità di sicurezza e filtri anti-spamming, stabile e veloce.
Nell'articolo tratteremo di Postfix, scaricabile direttamente dal sito www.postfix.org
o da uno dei numerosi mirror. Anche se ormai molte distribuzioni lo includono già nei CD in forma
di binario precompilato, per motivi "didattici" lo installeremo partendo direttamente dai sorgenti.
Una piccola nota per gli utenti RedHat: per poter compilare i sorgenti, sarà necessario installare prima il
pacchetto db3-devel (che potrete poi rimuovere al termine dell'installazione).
Postfix è stato interamente progettato, sin dall'inizio, per essere sicuro e veloce: esso è costituito da numerosi
demoni, ognuno dei quali si occupa di un processo ben definito. Solo uno si essi, master, è eseguito con privilegi
"elevati", tutti gli altri possono essere facilmente eseguiti con bassissimi privilegi (creando un utente ad hoc), e
soprattutto possono essere tutti confinati in una gabbia "chroot" (vedi appendice A).
Fig.1: Anatomia di Postfix: in giallo sono rappresentati i processi, in azzurro i file di configurazione
Lo scopo di Postfix è quello di sostituire interamente Sendmail, mantenedone però, in tutto e per tutto, la compatibilità: ciò significa
che migrare un server da Sendmail a Postfix risulterà completamente trasparente ad ogni altra applicazione!
Per prima cosa, occorre innanzi tutto creare almeno un utente di sistema operativo: in questa fase però ne aggiungeremo 2, in modo
tale da avere la possibilità di creare una gabbia chroot per i vari demoni.Verifichiamo innanzi
tutto di non avere precedentemente installato Sendmail: per una distribuzione RedHat, ad esempio, il pachetto viene installato
automaticamente, e va pertanto rimosso; da esso dipendono altri programmi, per cui sarà neccesario il flag --nodeps.
rpm -e sendmail --nodeps
Verifichiamo anche di non avere già un utente "mail" (grep mail /etc/passwd), quindi procediamo alla creazione dei 2 nuovi account,
ad esempio "postfix" e "mail":
adduser postfix -s /bin/false -d /dev/null
passwd -l postfix
adduser mail -s /bin/false -d /dev/null
passwd -l mail |
A questo punto, siamo pronti per compilare i sorgenti: dopo esserci posizionati nella directory in cui abbiamo scompattato l'archivio,
procediamo col comando
Se abbiamo installato il compilatore C, e se il nostro sistema è uno di quelli supportati (mi meraviglierei del contrario!!!), tutto
dovrebbe procedere senza particolari intoppi; a questo punto, dobbiamo installare quanto compilato:
Ci verranno ora richieste alcune informazioni sul nostro sistema, ad esempio dove posizionare i file di configurazione, gli
eseguibili e le pagine di help. Non c'è molto da dire su questo, dipende dalla distribuzione in esame e dai gusti personali...Facciamo
invece attenzione agli ultimi 2 parametri, mail_owner e setgid: il primo è l'utente proprietario dei vari demoni, mentre
il secondo è il proprietario della directory maildrop, e serve principalmente per motivi di sicurezza. Chi vuole approfondire
il motivo della sua esistenza (non temete, nessuna disquisizione filosofica sull'Essere!) troverà qualcosa in appendice
A. Lo script di installazione creerà le directory di configurazione (/etc/postfix) e quelle relative alle code dei messaggi
(/var/spool/postfix); al termine avviserà di andare immediatamente a modificare il file di configurazione principale main.cf.
L'installazione è terminata, e siamo pronti per configurarci il nostro mail server! Io pero' consiglio un paio di operazioni ulteriori;
lo script di installazione crea nella directory /etc/postfix tutti i file di configurazione, e una serie di file di esempio: a mio avviso,
sarebbe più "pulito" mantenere in questa directory lo stretto necessario, e spostare gli esempi altrove... Ad esempio:
mkdir /usr/share/doc/postfix
mv /etc/postfix/sample* /usr/share/doc/postfix/
mv /etc/postfix/LIC* /usr/share/doc/postfix/
mv /etc/postfix/*.default /usr/share/doc/postfix/
mv /etc/aliases /etc/postfix |
La configurazione di Postfix è veramente intuitiva: nessun parametro dal nome astruso, ed una abbondanza di commenti incredibile. Per una
configurazione tipica, i file che ci interessano sono aliases e main.cf: il primo definisce gli alias per gli utenti di sistema
operativo, mentre il secondo contiene la configurazione vera e propria.
/etc/postfix/aliases
Contiene la "mappatura" di un un utente di posta elettronica con un utente di s.o. Questo è molto importante per 2 motivi: in primis, è fondamentale che esistano gli alias per l'utente postfix (per il corretto funzionamento del programma) e per root (che sarebbe preferibile non ricevesse mail direttamente). Questo è vero in ogni caso, sia che il nostro Postfix funga mail server interno, sia che si tratti del mail server di un ISP.
Il secondo motivo per cui è importante la creazione di alias è l'esistenza di alcuni account "di ruolo" che vanno creati nel rispetto della cosidetta netiquette
, ad esempio postmaster, info, abuse, ecc; dal momento che nella pratica spesso è un solo utente a svolgere tutte le sovracitate funzioni, è
possibile fare in modo che le relative e-mail vengano automaticamente "girate" nella casella dell'utente. Vediamo un esempio: sul mio sistema,
io svolgo le funzioni di sistemista e postmaster; avrò quindi un account, ad esempio tom. Il mio file /etc/postfix/aliases conterrà quindi le voci:
| postmaster: | tom |
| abuse: | tom |
| info: | tom |
| postfix: | root |
| root: | tom |
Come vedete, è possibile utilizzare anche degli alias "ricorsivi" (Postfix->root->tom). A questo punto, occorrerà utilizzare il comando /usr/bin/newaliases per
rendere effetttive le modifiche (vedrete che verrà creato un file aliases.db, sul cui significato torneremo nel prossimo articolo).
/etc/postfix/main.cf
Veniamo ora alla configurazione vera e propria di Postfix; vedremo che i parametri da modificare per ottenere un
sistema immediatamente funzionante sono davvero pochissimi! Per prima cosa, visto che abbiamo posizionato il file degli alias in
/etc/postfix/, dovremo rendere partecipe Postfix della nostra decisione: aggiungeremo (o modificheremo, qui va verificato che i parametri
non siano già impostati) le righe
alias_maps = hash:/etc/postfix/aliases
alias_database = hash:/etc/postfix/aliases |
A questo punto, passiamo ai settaggi fondamentali: il nome del server, e il dominio che verrà considerato "locale"; ipotizzando di voler
configurare il mail server primario del dominio plutojournal.it, scriveremo:
myhostname = mail.plutojournal.it #<--questo è il nome del server, come apparirà negli header del messaggio
mydestination = $myhostname, $mydomain #<--specifica che solo user@plutojournal.it e user@mail.plutojournal.it sono considerati "locali" |
Per "locale" si intende il dominio che ha le relative mailbox proprio sul nostro server.
A questo punto, il nostro server è pronto? Si! Cioè, no... Abbiamo già un server funzionante, ma che tutti quanti, là fuori, possono usare come server di invio...e noi
non vogliamo lo spamming!! Bisogna allora decidere quali client saranno autorizzati ad inviare mail tramite il nostro Postfix: la cosa più comoda è utilizzare il
parametro mynetworks, specificando un range di indirizzi IP. Ad esempio, ipotizzando di voler concedere il servizio SMTP alla nostra LAN (la cui subnet potrebbe essere 192.168.1.x) e ad un client esterno (con IP 1.2.3.4), scriveremo:
| mynetworks = 192.168.1.0/24, 1.2.3.4 |
Perfetto, siamo pronti! Controlliamo di non aver fatto macro-errori di configurazione
postfix check
e se tutto è andato bene, siamo pronti ad avviarlo
postfix start
Congratulazioni!
Questo articolo vuole essere il primo di una serie, dedicata alla configurazione di Postfix come server di posta elettronica.
In questa prima "puntata" si è trattato della
configurazione di base, ma le possibilità offerte da questo software sono decisamente più ampie, e certamente scalabili fino alla cosiddetta fascia "enterprise": vedremo più avanti come sarà possibile progettare architetture molto complesse, con un livello di scalabilità praticamente illimitato.
Chroot jail
In estrema sintesi, una chroot jail è una sottodirectory entro cui viene eseguito un applicativo, che l'applicativo stesso vede
come la root del file system. Questo implica che, in caso di un baco del programma, ogni eventuale comando che potrà essere lanciato non
avrà modo di interagire con quanto sta al di fuori della gabbia (da qui il termine). Confinare quindi gli applicativi in una chroot jail
risulta un ottimo metodo per aumentare la sicurezza del sistema (Bind 8.x docet).
Com'è stato già detto nell'articolo, il programma Postfix non è un applicativo "monolitico", ma è composto da numerosi processi semi-
indipendenti: ad esempio, una volta che postfix è in esecuzione, nella lista dei processi appariranno i programmi master, pickup e
qmgr (ed altri, a seconda che vi siano o meno messaggi da processare).
In pratica, i "sottoprocessi" sono eseguiti con privilegi minimi, e di seguito vedremo anche come sia possibile confinarli in un ambiente
chroot'ed; io consiglio vivamente di optare per questo settaggio: sappiamo che la cossiddetta "chroot jail" non è la panacea per
tutti i problemi di sicurezza, ma vista la facilità con cui in questo caso è possibile realizzarla, il gioco vale sicuramente la candela!
Per prima cosa, sarà necessario editare il file di configurazione /etc/postfix/master.cf: esso contiene le impostazioni dei singoli processi
che conpongono Postfix; è necessario nodificare in "y" la quinta colonna (quella denominata "chroot", apputo) di ogni servizio, ad eccezione
di local e pipe. A questo punto, basterà andare nella cartella sorgenti-postfix/examples/chroot-setup,
e lanciare lo script corrispondente alla vostra piattaforma, ad esempio "LINUX2" (dovete prima renderlo eseguibile, di default non lo è).
In pratica, lo script non fa altro che creare in
/var/spool/postfix le directory etc, lib e usr; all'interno di esse, copia i file indispensabili all'esecuzione dei processi e
quelli relativi alle impostazioni di sistema (localtime, resolve.conf, ecc). Fatto questo, lo script fa ricaricare a Postfix il file di configurazione,
e il gioco è fatto! Va solo ricordato che d'ora in poi, ogni modifica a uno dei file copiati dallo script genererà un warning:
ecco ad esempio il messaggio che trovo il /var/log/maillog, se avvio postfix dopo aver aggiunto un utente:
postfix-script: warning: /var/spool/postfix/etc/passwd and /etc/passwd differ
Quindi, nel caso si trovino messaggi come questo, bisognerà ricordarsi di copiare i file aggiornati nella directory corrispondente.
Setgid e Maildrop
Abbiamo visto che, all'atto dell'installazione, abbiamo optato per assegnare un gid (Grup ID) alla directory Maildrop. Praticamente,
questo significa che la directory non è world-writeable; vediamo cosa implica questa scelta: avere una directory Maildrop w-w significa
che ogni utente locale può tranquillamente inviare un messaggio aggiungendolo alla coda delle mail da inviare, anche se il demone
Postfix non è attivo. Ma solo gli utenti locali, perchè la directory in esame non è utilizzata per le mail ricevute dalla rete. Il problema
di questo tipo di configurazione è che un utente potrebbe creare in Maildrop un link alla posta di qualcun'altro, o creare un falso messaggio
contenente un link a file di sistema. L'eventualità è remota (anche grazie a scrupolosi controlli della coda dei messaggi), ma possibile.
Utilizzando invece una Maildrop non world-writeable, i problemi di sicurezza sono completamente superati; e senza nessun inconveniente, a
patto di spedire sempre la posta con Postfix attivo (il che non mi sembra una limitazione troppo forte!).
L'autore
Tommaso Di Donato è sistemista Linux e Microsoft dal 1998; è stato dba Oracle presso la PA, nell'ambito
del progetto di informatizzazione dei Centri Protesi INAIL in Italia.
Attualmente lavora presso un portale Internet, in qualità di sistemista e dba; si occupa inoltre di
sicurezza informatica e TLC per un importante gruppo industriale italiano.
|