La Posta
La scelta di quale prodotto usare è molto soggettivo, dipende molto dalla distribuzione in uso (molti non cambiano quello che la distro installa di default), normalmente la scelta corre tra le seguenti:
Sendmail
Qmail
Exim
Postfix
Le differenze sono notevoli e appunto queste differenze sono il motivo per cui si opta per uno o per l'altro, fra le caratteristiche che ognuno deve guardare, al di là delle preferenze personali, sono: modalità di amministrazione, sicurezza intrinseca, performance e longevità del prodotto. Vediamo una rapida panoramica delle differenze e della storia di questi 4 MTA:
Sendmail
Sendmail è nato agli inizi del 1980, attualmente è utilizzato da quasi i due quinti dei server mail. Dopo aver avuto uno sviluppo lento e poco orientato alla sicurezza l'enorme espansione di Internet l'ha visto in passato protagonista di vulnerabilità. Tuttavia dal 1999 ha subito un notevole sviluppo, fino ad arrivare a metà 2001 in cui si presentava al mondo Opensource in una forma rivoluzionata e con i principi con cui veniva sviluppato che ora comprendevano anche la sicurezza. Tutt'ora è un valido MTA con un gran numero di opportunità di configurazione.
Qmail
Qmail è nato come rimpiazzo di Sendmail, senza però avere alcuno compatibilità o interoperabilità con quest'ultimo, pertanto necessita di conoscenze specifiche. Tuttavia un discreto numero di mailserver si basano su questo prodotto, principalmente realizzato con particolare cura alla sicurezza, realizzato mediante un corpo principale di gestione della posta e tanti piccoli programmi userspace per poterlo gestire. Qmail ha una considerevole cura di path o addon inviati dai contributors e reperibili direttamente sul sito ufficiale. Qmail presenta una separazione delle funzioni in più demoni.
Exim
Exim è nato partendo dal codice di Smail3 (nato a sua volta come derivato da sendmail per i problemi di sicurezza di sendmail stesso), Exim è nato come general purpose mailer, senza una rivoluzione concettuale della struttura come è accaduto a Qmail. E' dotato di un file di configurazione monolitico, tramite il quale si può facilmente controllare il demone in tutti i suoi aspetti, finora non ha mostrato un discreto interesse per i temi della sicurezza e non ha finora mostrato vulnerabilità tali da compromettere lintegrità dei server su cui era installato. Exim può accettare numerosi plugin tutti richiamabili dal file di configurazione monolitico. Su tale prodotto esiste un supporto documentale molto elevato.
Postfix
Postfix è stato scritto inizialmente da Wietse Venema, esperto di sicurezza autore e coautore di diversi e famosi tools di controllo e monitoraggio. Postfix è il più giovane degli MTA qua elencati, tuttavia ha presentato fin da subito enormi potenzialità. Come funzionalità si colloca fra Exim e Qmail, è dotato di un file monolitico di configurazione ma il corpo del programma è stato “spezzato” in modo che un demone svolgesse un'unica funzione, prevenendo così l'acquisizione tramite scalata di diritti root tramite vulnerabilità (dato l'autore ed il supporto ricevuto finora anche quest'ultimo non ha mai dato “problemi”). Postfix è stato studiato anche per reggere grossi volumi di lavoro ed è, come Exim, un rimpiazzo di sendmail.
Per amore personale gli esempi che farò sono incentrati su postfix, ma concettualmente applicabili a qualsiasi MTA.
Normalmente tutti i provider offrono un servizio di SMTP (oppure in una lan interna), il servizio è quasi sempre con trasferimento in “chiaro” delle mail, questo vuol dire che chiunque si trovi sul percorso dal vostro pc al server di posta del vostro provider può liberamente leggere la vostra posta e carpire dati, password o informazioni riservate. Oltretutto, se avete un server di posta locale sia per l'invio che la ricezione della posta, avrete la necessità di avere garanzie che sarete gli unici a usare il vostro SMTP privato. A tale scopo esiste un modo per comunicare con il vostro SMTP privato in modo che possiate autenticarvi e contemporaneamente avere una cifratura sul messaggio che inviate, (tenete presente però che poi dal server SMTP del vostro provider al server di posta del destinatario la posta torna a iaggiare in chiaro). Tale sistema è conosciuto come TLS (molto simile ma non identico a SSL), tutti i demoni per l'invio della posta prevedono in un modo o nell'altro l'implementazione di tale sistema, per fare ciò è comunque indispensabile scaricare e installare OpenSSL (meglio la forma già pacchettizata della propria distribuzione) e i sorgenti del demone smtp (a meno che la forma pacchettizata sia già predisposta). Dopo aver installato e/o compilato il tutto e aver configurato il server SMTP come da propria documentazione (ognuno ha la sua configurazione, io per esempio uso Postfix, come molta altra gente, un buon howto per configurarlo viene riportato in seguito ed è una mail presa da una mailing list:
''Installate postfix (non mi interessa come, sorgenti, pacchetti rpm, deb, evocazione, summon elemental...), avendo cura che sia l'unico MTA sulla macchina (alcune distro installano sendmail a default).
Editate il file /etc/aliases e aggiungete un entry che rediriga la posta di root al vostro utente, ovvero:
root: io
fine aliases
editate /etc/postfix/main.cf e modificate le seguenti entry, lasciando invariate le altre cose:
myhostname = "il nome fqdn della vostra macchina" # quello che avete anche in /etc/hosts, sia eventualmente anche localhost.localdomain
mydomain = "il vostro dominio di appartenenza" # stesso discorso. nel caso anche localdomain
myorigin = "cosa devo attaccare all'indirizzo dopo @" # tipicamente $mydomain andra` benissimo.
relayhost = "server mail del vostro provider" # meglio se tra [] e con l'ip anziche` il nome
defer_transports = smtp
disable_dns_lookup = yes
alias_maps = hash:/etc/aliases # di solito commentato in diverse versioni, scegliete quella giusta
alias_database = hash:/etc/aliases # idem
mailbox_command = /usr/bin/procmail
canonical_maps = hash:/etc/postfix/canonical
virtual_maps = hash:/etc/postfix/virtual
fine main.cf
create due file in /etc/postfix
canonical
virtual
in canonical scrivete:
"utente locale" "indirizzo internet" # esempio pippo pippo@libero.it
in virtual scrivete:
"indirizzo internet" "utente locale" # il contrario
Fatto tutto questo digitate in sequenza:
[root@localhost] # postalias /etc/aliases
[root@localhost] # postmap /etc/postfix/canonical
[root@localhost] # postmap /etc/postfix/virtual
[root@localhost] # postfix check
(per controllare se ci sono errori)
[root@localhost] # /etc/init.d/postfix start
Accorgimenti:
La posta, cosi`, esce solo ad ogni "postfix flush" oppure "/usr/sbin/sendmail -q" per i romantici.
Potete fare uno scriptino cosi`:
-+- CUT HERE
#!/bin/sh
# Start deliveries.
/usr/sbin/sendmail -q
# Allow deliveries to start.
Sleep 10
# Loop until all messages have been tried at least once.
while mailq | grep '^[^ ]*\*' >/dev/null
do
sleep 10
done
-+- CUT HERE
da far girare quando siete connessi (tramite ip-up o ip-down a seconda dei gusti..)
PS: per chi avesse una connessione fissa al posto di<
defer_transports = smtp
metta
#defer_transports = smtp
Written by Tannoiser''
Occorre a questo punto creare un certificato digitale per poter usare TLS (come per SSL)utilizzando appunto gli eseguibili OpenSSL, creando sia quello pubblico che privato, generando un certificato appunto nello stesso in formato X.509.
Puntualizzazione: la cifratura su SMTP l'ho trattata in quanto per poter utilizzare un smtp casalingo spesso bisogna autenticarsi, e i metodi di autenticazione sono spesso abbinati a sistemi di cifratura, perciò, già che ci si autentica, tanto vale proteggere anche la trasmissione. Il fatto poi che una volta che voi inviate la posta al vostro provider per farla recapitare al destinatario fa si che la cifratura su smtp sia relativa, in quanto il percorso dal smtp del vostro provider al pop3/imap del destinatario la posta viaggia in chiaro.
Lo Standard POP3 è nato nel 1988 e presenta il grandissimo vantaggio di essere diffusissimo e conosciutissimo. Tuttavia presenta due lacune:
assenza di cifratura sulle trasmissioni
scarsa gestione delle mail se consultate da più macchine diverse
Il demone POP3 più diffuso è “Qpopper”, tale servizio prevede tuttavia un sistema di autenticazione a cifratura della password, ciò permette di non trasmettere mai la password in chiaro, però non permette la cifratura dei messaggi.
Occorre recuperare e installare qpopper, il quale di default utilizza per l'autenticazione PAM per la connessione POP3 standard, per utilizzare l'autenticazione APOP occorre creare un suo database con il comando “popauth -init” e inserire gli utenticon “popauth -user utente”. Per eliminarli “popauth -delete utente”. Lo standard APOP è supportato da una gran quantità di mailclient di tutti i sistemi operativi, tranne uno (guardafuori).
Pur essendo POP3 il più diffuso va sempre più prendendo piede IMAP, pur essendo nato nel 1986 è sempre stato scarsamente utilizzato e infatti si fa un po' fatica a trovare un client “usabile” in senso lato. Tale protocollo si differenzia da POP3 soprattutto per il fatto che la posta rimane sul server e viene consultata online, con possibilità di organizzarla in cartelle come fossero locali Ciò permette di poter liberamente consultare la posta ovunque ci si trovi e soprattutto presenta un sistema di autenticazione e cifratura basato su OpenSSL (IMAPS). Esistono diversi demoni IMAP, un po' come le distribuzioni devono essere accuratamente scelti in base alle caratteristiche che offrono (migrare in un secondo momento da uno all'altro spesso non è cosa semplice e indolore). Come per SMTP su TLS occorre anche qua la coppia IMAP+OpenSSL, opportunamente compilati (o come già detto pacchettizati pronti ma con il supporto). La creazione del certificato digitale per IMAPS deve essere del tipo PKCS12 e va creato nel seguente modo (esempio riferito a “IMAPD-2000”):
[sythos@gastrite]# cd /usr/share/ssl/certs
[sythos@gastrite]# make imapd.pem
[sythos@gastrite]# openssl pkcs12 -export -innewcert.pem -inkey newreq.pem -certfile cacert.pem -name “nomecertificato” -out mycert.p12
Tale certificato deve essere copiato sulle macchine da cui si vuole consultare la posta, MozillaMail (uno dei migliori client IMAPS) prevende l'apposita funzione di importazione del certificato (operazione che deve essere svolta solo una volta o al rinnovo del contratto).
Comunque si invii la posta l'uso di tools per la firma digitale o la cifratura delle mail, a tale scopo esiste GPG (equivalente di PGP). Molti client supportano GPG già nella forma pacchettizata dalla distribuzione, altrimenti occorre reperire e installare GPG e GPGME.
Ogni distribuzione ne prevede una versione più o meno recente di entrambi, dopo aver installato GPG per la propria distribuzione occorre generare almeno una identità operando secondo pochi e semplici passaggi.
Ogni utente può creare una propria identità con l'opzione –gen-key:
[sythos@gastrite] $ gpg –genkey
Verrà chiesta una password e una serie di dati, siate i più precisi e sinceri possibile. Per rendere la chiave fruibile dalgi altri occorre inviare la copia pubblica a un server, tale operazione si puà fare con:
[sythos@gastrite] $ gpg –keyserver keyserver.linux.it –send-key
Poi occorre settare i vari client di posta all'utilizzo almeno della firma digitale, per comunicazioni critiche anche la cifratura del corpo del messaggio. Chi riceve la mail firmata o criptata può procurarsi la chiave pubblica sul keyserver e verificarla/decriptarla, per avere la chiave occorre fare:
[sythos@gastrite] $ gpg –keyserver keyserver.linux.it –recv-key ID
ID è un codice alfanumerico a 8 cifre visibile nella mail.
Questo campo purtroppo è molto discusso e non esiste una legislazione chiara e uniforme, il giudizio su controversie è spesso affidata alla soggettività. Spesso chi deve “accudire” un server aziendale deve tutelare sprechi di banda e abusi degli strumenti aziendali da parte dei dipendenti. A difficoltà di comparare o scindere il concetto di corrispondenza epistolare cartacea (pr cui esiste una chiara e rigorosa legislatura) e la corrispondenza in formato elettronico sono notevoli. Di norma già all'atto dell'assunzione deve essere messo al corrente il personale che l'email, pur essendo di stretto uso personale, è uno strumento messo a disposizione dell'azienda per l'uso principalmente lavorativo. Un sysadmin non ha molti strumenti per controllare questo aspetto, vediamo alcuni aspetti e come potrebbe essere idoneo affrontarli.
alias/utente: è meglio utilizzare email “impersonali” e non riconducibili direttamente al dipendente, ovvero anziche “mario.rossi@azienda.it” un “email0023@azienda.it”, per poi configurare il client di posta per abbinare il nome dell'utilizzatore di quella mail in modo che chi riceva la mail possa riconoscere l'interlocutore, per esempio “Mario Rossi <email0023@azienda.it>”.
Mail quota: è sempre e comunque bene impostare un quota proporzionato al reale utilizzo, per esempio, per un incarico che richiede una corrispondenza composta da mail di solo testo pochi megabyte possono essere sufficienti, se invece l'utilizzatore delle mail deve lavorare con grossi allegati (documenti, disegni, immagini) occorerà incrementare tale quota. Con l'attuale costo dei dispositivi di memorizzazione va comunque bene, adeguandola al caso peggiore (presenza di allegati).
RBL: le RBL sono liste basate su database di server SMTP presenti su tutta la rete, che però per una misconfigurazione (involontaria o meno) non garantiscono l'autenticità di un numero conosciuto di utenti, tali server, definiti come “Open Relay”, sono spesso utilizzati da spammer per la diffusione di massa. Tale aspetto, anche se spesso sottovalutato (“tanto basta cancellarle appena arrivano” per esempio), non mette in diretto risalto fattori come lo spreco di banda o la diffusione (talvolta molte mail hanno elenchi di indirizzi in CC) si account in chiaro.
Filtri basati sul mittente: alcune utility tipo “Razor” permettono un monitoraggio delle mail in passaggio sul server di posta, confrontando gli indirizzi presenti nell'intestazione con quelli contenuti in un database centralizzato (contenente un elenco di indirizzi di spammer “conosciuti”), isolandole in caso di check positivo.
Filtri basati sul corpo del messaggio: una lettura da parte di un dipendente dei contenuti delle mail è uno degli aspetti più controversi, tuttavia sono utilizzabili alcuni programmi che analizzano soggetto e corpo del messaggio in cerca di alcune caratteristiche per poi agire a seconda della configurazione. Tra queste utility sono molto conosciute sanitizer e spamassassin.
Filtri basati sugli allegati: gli allegati delle mail possono contenere elementi potenzialmente dannosi, da apparentemente innocui eseguibili (magari viralmente infetti) e script che sfruttano vulnerabilità dei mailclient oppure macrovirus. Si può affrontare tale problema o bloccando tutte le mail contenenti file che corrispondono ad un pattern impostato (file .exe,.com,*.js,*.vb, etc.) mettendole in un area di quarantena per poi essere controllate in un secondo momento oppure con l'impiego di antivirus che in tempo reale controllano gli allegati.