Sendmail, SASL ed SSL su Slackware 13


Home Page | Commenti | Articoli | Faq | Documenti | Ricerca | Archivio | Storie dalla Sala Macchine | Contribuire | 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 gort.onlyforfun.net ESMTP Sendmail 8.14.4/8.14.4; Wed, 15 Aug 2012 14:01:11 +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-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.


I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

4 messaggi this document does not accept new posts
Nicholas Di Nicholas - postato il 15/08/2012 18:20

Suggerimento: puoi avere un certificato ssl gratuito su http://www.startcom.org/ :\)

--
Nicholas


Davide Bianchi@ Nicholas Di Davide Bianchi - postato il 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


Lanfranco@ Davide Bianchi Di Lanfranco - postato il 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?  wink

--
Lanfranco


DAniele@ Davide Bianchi Di DAniele - postato il 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


Precedente Successivo

Davide Bianchi, lavora come Unix/Linux System Administrator presso una societa' di "sicurezza informatica" (aka: $networkgestapo) di Haarlem. Contatti: mail: davide AT onlyforfun.net , Jabber: davideyeahsure AT gmail.com,

Volete contribuire? Leggete come!.
 
 

Il presente sito e' frutto del sudore della mia fronte (e delle mie dita), se siete interessati a ripubblicare uno degli articoli, documenti o qualunque altra cosa presente in questo sito per cortesia datemene comunicazione (o all'autore dell'articolo se non sono io), cosi' il giorno che faccio delle aggiunte potro' avvisarvi e magari mandarvi il testo aggiornato.


Questo sito era composto con VIM, ora e' composto con VIM ed il famosissimo CMS FdT.

Questo sito non e' ottimizzato per la visione con nessun browser particolare, ne' richiede l'uso di font particolari o risoluzioni speciali. Siete liberi di vederlo come vi pare e piace, o come disse qualcuno: "Finalmente uno dei POCHI siti che ancora funzionano con IE5 dentro Windows 3.1".

Web Interoperability Pleadge Support This Project
Powered By Gort