Sendmail, SASL and SSL on Slackware 13 |
Home Page | Comments | Articles | Faq | Documents | Search | Archive | Tales from the Machine Room | Contribute | Set language to:en it | Login/Register
Dopo un bel 5 anni di attivita' ho deciso che il mio server aveva bisogno di un paio di nuovi dischi. Ma il sostituire i dischi significa anche reinstallare il tutto. Pertanto mi sono ritrovato a ripetere certe configurazioni che avevo gia' fatto e ri-risolvere certi problemi che avevo gia' risolto. Uno di questi e' come configurare l'autenticazione in sendmail con SASL.
Perche' l'autenticazione? Perche' io voglio essere in grado di inviare posta dal mio server usando un normale client, e per evitare di diventare un veicolo di invio spam, per fare del relay (aka: inviare posta a domini che non sono il mio) voglio avere un'autenticazione.
Io ho fatto il tutto usando Slackware 13.37 con installazione di default. Slack arriva con Sendmail gia' compilato con crittografia (TLS) ed autenticazione, ma so per certo che altre distribuzioni non lo fanno. Percui la prima cosa da fare e' verificare che la vostra installazione di sendmail supporti sia l'autenticazione che la crittografia.
Per fare cio' basta richiamare (da root) sendmail -d0.1 -bv root.
Eseguendo tale comando vi ritroverete una spataffiata di roba come la seguente:
Version 8.14.4 Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS PIPELINING SASLv2 SCANF SOCKETMAP STARTTLS TCPWRAPPERS USERDB XDEBUG ============ SYSTEM IDENTITY (after readcf) ============ (short domain name) $w = gort (canonical domain name) $j = gort.onlyforfun.net (subdomain name) $m = onlyforfun.net (node name) $k = gort ======================================================== root... deliverable: mailer local, user root
Le parti importanti sono SASLv2, che dice che sendmail e' compilato con il supporto per SASL v2 (sasl2) e STARTTLS che dice che Sendmail accetta il comando starttls per iniziare una conversazione crittografata (che e' utile per le password).
Se non ricevete questi risultati, forse dovrete ricompilare Sendmail con tali supporti.
La fase seguente e' configurare sendmail in moto che accetti le richieste e le esegua.
Per SSL/TSL occorre creare ed installare un certificato e la corrispondente chiave. Se il vostro server e' pubblico e/o se volete essere legittimi, dovrete acquistare un vero certificato SSL da una qualunque authority. Se non volete spendere soldi o non vi interessa (es. IO), o se volete solo fare dei test, potete risolvere con un certificato autofirmato. Per creare un certificato autofirmato basta usare OpenSSL (che dovrebbe essere installata sul server).
Per prima cosa occorre creare una chiave per firmare il certificato:
openssl genrsa -out smtp.key.pem 2048
Questo comando crea una chiave non-crittografata che non richiede password per essere usata. Una volta che avete la chiave e' possibile usarla per firmare un certificato:
openssl req -new -x509 -key smtp.key.pem -out smtp.cert.pem -days 1095
Questo comando crea il certificato e lo firma con la chiave richiesta prima. Il comando richiede un sacco di parametri sulla linea di comando. E' possibile accettare tutti i valori di default.
Se volete un certificato vero dovrete invece di un certificato autofirmato creare una RICHIESTA, il comando e' quasi uguale:
openssl req -new -key smtp.key.pem -out smtp.cert.csr
Questa richiesta dovrete inviarla alla vostra authority che vi creera' il certificato e ve lo mandera' indietro (dopo che avete pagato ovviamente).
Copiate la chiave ed il certificato da qualche parte (/etc) in modo che Sendmail li possa trovare (devono essere leggibili) e quindi procediamo a configurare Sendmail in modo da usarli.
Il sistema piu' semplice per configurare sendmail e' usare un file .mc e compilarlo creando un nuovo file .cf (configurazione). Slackware distribuisce un file .mc apposito in /usr/share/sendmail/cf/cf/sendmail-slackware-tls-sasl.mc (prima che cominciate a commentare, il 'cf/cf' non e' un errore!). Compilando il file si ottiene un equivalente file .cf che e' possibile copiare in /etc/mail come sendmail.cf e riavviare sendmail per renderlo attivo.
Il sistema piu' difficile e' quello di modificare sendmail.cf direttamente, se decidete di andare in questo senso fate una copia del file originale prima di modificarlo (ma non devo dirvelo vero?). I parametri da modificare/aggiungere sono:
C{TrustAuthMech}LOGIN PLAIN O AuthMechanisms=LOGIN PLAIN O AuthOptions=A p y O DaemonPortOptions=Port=smtp, Name=MTA O DaemonPortOptions=Port=smtps, Name=MSA-SSL, M=Esa O CACertPath=/etc/ssl/certs/ O CACertFile=/etc/ssl/certs/ca-certificates.crt O ServerCertFile=/etc/ssl/certs/smtp.cert.pem O ServerKeyFile=/etc/ssl/private/smtp.key.pem
Ovviamente dovrete metterci dove sono e come si chiamano i VOSTRI file chiave e certificati, io ho usato i nomi generici di 'smtp.cert' ed 'smtp.key' ma voi siete liberi di usare quello che vi pare.
Riavviare Sendmail e verificate che parta e non riporti errori in fase di avvio. A questo punto dovreste essere in grado di collegarvi usando Telnet e verificare che risponda in modo corretto: usare il comando 'EHLO' (NO, non e' un typo!) e guardate cosa vi risponde:
#telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. e220 dull.onlyforfun.net ESMTP Sendmail 8.14.4/8.14.4; Wed, 15 Aug 2012 14:01:11 +0200 ehlo dude 250-dull.onlyforfun.net Hello localhost [127.0.0.1], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-STARTTLS 250-DELIVERBY 250 HELP
Come si vede, la risposta include STARTLS. L'autenticazione viene attivate SOLO se si attiva la crittografia. Ma prima di attivare l'autenticazione, occorre configurare SASL.
SASL e' la libreria usata da diversi programmi per l'autenticazione. Supporta diversi 'meccanismi' di autenticazione, in particolare consente di autenticare usando un database esterno (PostGres o MySQL o quello che vi pare), usando LDAP, Kerberus o il normale file di password del sistema o un 'database' personalizzato. Il guaio e' configurarla.
Ora, quello che ha tirato scemo me e' che nella versione precedente di SASL l'unico file di configurazione richiesto era da mettere in /usr/lib/sasl2, chiamato 'Sendmail.conf' e contenente solo un paio di linee che specificano i 'meccanismi' da usare:
mech_list: PLAIN LOGIN pwcheck_method: saslauthd
Ma nella versione di SASL installata in Slack questo file va' messo in /etc/sasl2 (!) ed ovviamente non e' documentato da nessuna parte ne' e' spiegato da nessuna parte. Ora, non sono del tutto sicuro di CHI legge questo file (se sasl o sendmail) ma non ho trovato nessun riferimento a questo file nel codice. Quindi pigliatelo un po' come vi pare ma se non vi funziona verificate dove avete questo dannato file.
Una volta aggiunto il file dovrete riavviare (o avviare) SASL (saslauthd) e magari riavviare Sendmail.
E adesso siamo pronti a verificare l'intero sistema usando SASL ed OpenSSL:
openssl s_client -connect ip.del.vostro.server:smtps
Questo comando usa OpenSSL per connettersi al server usando SSL. Il risultato sara' che una caterva di roba relativa al certificato ed alla crittografia viene sparata sullo schermo e poi finirete con il "normale" messaggio di sendmail:
220 gort.onlyforfun.net ESMTP Sendmail 8.14.4/8.14.4; Wed, 15 Aug 2012 14:15:43 +0200 ehlo dude 250-gort.onlyforfun.net Hello localhost [127.0.0.1], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-AUTH LOGIN PLAIN 250-DELIVERBY 250 HELP
Notare che 'starttls' non e' piu' riportato (stiamo usando SSL) ma appaiono le informazioni di autenticazione.
Come si verificare che il server accetti l'autenticazione? Il sistema piu' semplice e' usare un vero client di posta, altrimenti potreste usare l'opzione s_client di openssl per accedere al server e mandare i messaggi di autenticazione.
Se qualche cosa non funziona la cosa migliore da fare e' aumentare il logging di Sendmail, in sendmai.cf modificare il parametro 0 LogLevel=9 e portarlo ad un livello piu' alto (99), questo riempira' il vostro log di messaggi vari, Warning ed altro, ma consentira' di avere un sacco di informazioni. In particolare, se vedete messaggi come:
AUTH: available mech=PLAIN LOGIN, allowed mech=CRAM-MD5 DIGEST-MD5
Significa che c'e' una discrepanza tra quello che e' configurato in SASL e quello che e' attivo in Sendmail. Verificate che SASL abbia le librerie di autenticazione in /usr/lib/sasl2.
AUTH failure (PLAIN): user not found (-20) SASL(-13): user not found: Password verification failed
Questo in genere significa che Sendmail o Sasl non riescono a trovare il famoso file 'Sendmail.conf'. Per evitare problemi io ho creato un symlink in /etc/sasl2 al file in /usr/lib/sasl2, in questo modo tutto rimane dove dovrebbe essere ma e' sempre leggibile.
Comments are added when and more important if I have the time to review them and after removing Spam, Crap, Phishing and the like. So don't hold your breath. And if your comment doesn't appear, is probably becuase it wasn't worth it.
By Nicholas posted 15/08/2012 18:20
Suggerimento: puoi avere un certificato ssl gratuito su http://www.startcom.org/
@ Nicholas By Davide Bianchi posted 16/08/2012 07:53
Suggerimento: puoi avere un certificato ssl gratuito su http://www.startcom.org/
Si', puoi anche averne uno firmato da 'SnakeOil ltd' e la garanzia/sicurezza e' la stessa...
-- Davide Bianchi
@ Davide Bianchi By Lanfranco posted 16/08/2012 08:36
>> Suggerimento: puoi avere un certificato ssl gratuito su http://www.startcom.org/
>Si', puoi anche averne uno firmato da 'SnakeOil ltd' e la garanzia/sicurezza e' la stessa...
Non era Canistracci Oil?
@ Davide Bianchi By DAniele posted 22/08/2012 13:38
Suggerimento: puoi avere un certificato ssl gratuito su http://www.startcom.org/
Si', puoi anche averne uno firmato da 'SnakeOil ltd' e la garanzia/sicurezza e' la stessa...
Non sono affatto d'accordo con questa affermazione. Su (putroppo molti) dispositivi consumer se vuoi poterti connettere a un server che usa un certificato autofirmato devi disattivare completamente la verifica dei certificati (per quel server), il che significa che non ricevi un warning nel caso in cui il certificato cambi (leggi MITM). Se invece usi un certificato emesso da una CA che viene riconosciuta (e startcom lo è) non hai bisogno di farlo e vieni avvisato in casi di cambiamento. Questa è almeno la mia esperienza.
Io uso e consiglio caldamente startcom per le cose "personali", dove si è sia admin che user e non è necessario o non si vogliono spendere soldi (per ambito business valgono considerazioni diverse, ovviamente).
-- DAniele
Davide Bianchi, works as Unix/Linux administrator for an hosting provider in The Netherlands.
Do you want to contribute?
read how.
This site is made by me with blood, sweat and gunpowder, if you want to republish or redistribute any part of it, please drop me (or the author of the article if is not me) a mail.
This site was composed with VIM, now is composed with VIM and the (in)famous CMS FdT.
This site isn't optimized for vision with any specific browser, nor
it requires special fonts or resolution.
You're free to see it as you wish.