Realizzare un tunnel SSL per i servizi imap e pop3 "SSH tunneling over POP3 and over IMAP"

Transcript

1 Realizzare un tunnel SSL per i servizi imap e pop3 "SSH tunneling over POP3 and over IMAP" A chi serve questo documento? Questo documento è stato pensato per tutti coloro che vogliono nascondere attraverso una semplice operazione di tunneling (incapsulamento) le sessioni di posta elettronica originate da client di posta verso server che forniscono servizi di pop3 o imap. Per poter mettere in pratica quanto descritto consiglio di avere un server Linux sotto mano ed un client di posta che permetta di utilizzare il metodo di autenticazione protetta SSL. Piattaforma Utilizzata Un client Windows con Outlook e un client Linux con Netscape Mail ed un server con una Slackware 7.0 e kernel a bordo. Non dovrebbero esserci problemi comunque anche utilizzando distribuzioni e client differenti, anche se non ho avuto il tempo di farlo. I software impiegati (openssl, stunnel e sslwrap) mi sono comunque sembrati maturi e stabili, tanto da consentirmi di far funzionare tutto al primo colpo (o quasi ). Servizi e Crittografia In generale per molti servizi come (pop3, smtp, imap e http) non potendo supportare direttamente connessioni crittografate sono comunque predisposti per il protocollo SSL/TLS. Tuttavia, proprio perché intervengono solo a livello del protocollo TCP, può essere impossibile l'utilizzo di questi quando il protocollo finale prevede l'apertura di connessioni aggiuntive attraverso porte non prestabilite. In pratica, diventa impossibile il loro uso per servizi FTP. Comunque la loro applicazione avviene in larga parte per i servizi di posta elettronica imap e pop3, ed di quelli che ci occuperemo sostanzialmente. Perché realizzare un tunnel per la posta La posta elettronica è indubbiamente uno di servizi telematici più usati ancora oggi su internet. Purtroppo è anche il sistema più esposto dal punto di vista della sicurezza per le informazioni che trasporta, per il semplice fatto che normalmente tra il computer client (cioè quello che contatta) ed il server (quello che risponde) i dati transitano in chiaro. "In chiaro" significa semplicemente "non criptato", e questo implica che chiunque si trovi sulla nostra stessa rete può facilmente ricostruire le nostre conversazioni. Esistono programmi distribuiti liberamente su internet, come ad esempio mailsnarf, che possono consentirci di leggere la posta in transito su di un determinato host. Per tutti quelli che hanno la necessità di rendere riservate le loro conversazioni risulta allora indispensabile proteggere la posta elettronica con strumenti idonei quali la crittografia. Quello che verrà spiegato non è altro che l uso della crittografia per nascondere le password ed i dati (messaggi) contenuti nelle nel momento in cui effettuiamo la delicata operazione di scarico della posta. Se dovessi dirlo in maniera un po più tecnica direi che questo documento spiega come realizzare un semplice tunnel per i protocolli più diffusi di posta elettronica imap su porta 143 e pop3 su porta 110. Obiettivo del documento Ricordiamoci che tutte le operazioni verso imap o pop3 passano i dati in chiaro sulla rete il nostro obiettivo è cifrarli (password e dati). Ad esempio viene citata questa semplice sessione verso il protocollo 110

2 server2:/usr/local/ssl# telnet server2 110 Trying Connected to server2.in.labtel.it. Escape character is '^]'. +OK server2 POP3 Server (Version 1.006d) ready at <Tue Feb 12 18:30: > user paolo +OK please send PASS command pass la_mia_password +OK 3 messages ready for paolo in /var/spool/mail/paolo list +OK 3 messages; msg# and size (in octets) for undeleted messages: RETR2 +OK message 2 (381 octets): X-POP3-Rcpt: paolo@server2 Return-Path: <root> Received: (from root@localhost) by server2.in.labtel.it (8.9.3/8.9.3) id SAA06377 for paolo; Tue, 12 Feb :30: Date: Tue, 12 Feb :30: From: root@server2.in.labtel.it Message-Id: < SAA06377@server2.in.labtel.it> To: paolo@server2.in.labtel.it Subject: Prova messaggio di prova I dati come si può notare sono tutti in chiari e facili prede per sniffer come sniffit o Phoss. Se non ci credete guardate come potete con Phoss intercettare il traffico in chiaro, basta lanciarlo all interno di un server che gestisca servizi come posta e ftp per ottenere uno output di questo tipo. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Source: :4618 Destination: :110 Protocol: POP3 Data: elena@netlink.it:pippo >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Source: :4619 Destination: :110 Protocol: POP3 Data: paolo:paperino >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Source: :4407 Destination: :110 Protocol: POP3 Data: marco:pluto >>>>>>>>>>>>>>>>>>>>>>>>>>>>> La realizzazione pratica si può ottenere utilizzando due metodi sostanziali. Nel primo caso il tunnel viene effettuato utilizzando STUNNEL e nel secondo usando SSLWRAP.

3 NETLinK S.a.S. Requirement for SSL wrap with STUNNEL A questo punto occorre verificare di avere il software necessario. Sul sistema occorre installare oltre al pop3d e imapd che diamo per scontati: Openssl - Stunnel - Universal SSL Wrapper Trovate entrambi nelle versioni più aggiornate su freshmeat Installiamo i pacchetti sul sistema, sono abbastanza semplici da compilare in alcuni casi li avrete già belli e pronti sulla maggior parte delle distribuzioni Linux. Non intendo trattare l utilizzo di openssl ma ricordo che una sua conoscenza aiuta molto ad effettuare queste operazioni. Questo pacchetto assieme al suo fratello openssh rappresenta l elemento basilare per far circolare i dati sulla rete in forma cifrata. Per chi ne volesse sapere di più consiglio: Anche al mitica bibbia Appunti Linux di D. Giacomini disponibile su e su molti altri siti contiene molte informazioni utili. Verifica dei servizi in ascolto sul sistema Se verifichiamo con un portscanner come nmap i servizi attivi sul sistema avremo server2:/usr/local/ssl# nmap server2 Starting nmap V by Fyodor (fyodor@dhp.com, Interesting ports on server2.in.labtel.it ( ): Port State Protocol Service 21 open tcp ftp 22 open tcp ssh 23 open tcp telnet 25 open tcp smtp 53 open tcp domain 80 open tcp http 110 open tcp pop open tcp imap2 443 open tcp https Nmap run completed -- 1 IP address (1 host up) scanned in 0 seconds Realizzazione del tunnel in pratica con STUNNEL Per poter realizzare il tunnel è necessario predisporre i due nuovi servizi (pope e imap) in ascolto sul sistema. Ricordiamo che i servizi sono mappati sotto il file /etc/service ad esempio

4 ftp 21/tcp ssh 22/tcp # SSH Remote Login Protocol telnet 23/tcp # 24 - private pop3 110/tcp # POP version 3 smtp 25/tcp #mail nameserver 42/tcp name # IEN 116 www 80/tcp http # WorldWideWeb HTTP imap 143/tcp # Interactive Mail Access A questo punto aggiungiamo in questo file i due nuovi servizi che parallelamente a pop3 e imap gireranno nel tunnel. Nel mio caso simap 993/tcp #Secure imap spop3 995/tcp #Secure pop3d A questo punto modifichiamo il file inetd.conf del sistema, visto che questi due processi girano in modalità inetd. Aggiungiamo al file sopra citato # SSL tunneling over IMAP con STUNNEL simap stream tcp nowait root /usr/local/sbin/stunnel stunnel -p /usr/local/ssl/imapd.pem -l /usr/sbin/imapd imapd # SSL tunneling over Pop3d con STUNNEL spop3 stream tcp nowait root /usr/local/sbin/stunnel stunnel -p /usr/local/ssl/pop3d.pem -l in.pop3d Una piccola spiegazione della sintassi del file inetd.conf serve a capire meglio la sintassi utilizzata: Ogni servizio in questo file ha la seguente sintassi service socket-type protocol flag user server-path server-args dove "service" è il nome del servizio, "socket-type" è il tipo di socket (può essere stream o dgram per il TCP o l'udp rispettivamente), "protocol" è il tipo di protocollo, "flag" indica se il server dovrà liberare la porta per consentire una nuova connessione (nowait) oppure se il servizio non sarà disponibile finché il server non avrà terminato la prima connessione (wait). Il campo "user" indica qual è l'utente proprietario del server che sarà attivato. Infine "server-path" e "server-args" specificano la locazione del server e quale argomenti gli si vogliono passare nel momento in cui viene lanciato. Nel caso specifico delle due sintassi utilizzate risulta chiaro che è stato tolto il wrapper tcpd (che in genere stabilisce modalità di accesso attraverso i file hosts.deny e hosts.allow) e rimpiazzato con l espressione "usr/sbin/stunnel stunnel -p /usr/local/ssl/certs/imapd.pem -l /usr/sbin/imapd imapd" oppure con quella /usr/local/sbin/stunnel stunnel -p /usr/local/ssl/pop3d.pem -l in.pop3d. Queste espressioni indicano chiaramente che il "vero" server è stunnel il quale si prende carico semplicemente di lanciare /usr/sbin/imapd e /usr/sbin/ipop3d, senza alcuna opzione aggiuntiva. La dicitura "-p /usr/local/ssl/certs/imad.pem" indica ad stunnel dove si trova il certificato. La cui creazione viene spiegata nelle righe successive. Creazione dei certificati Prima di poter utilizzare i servizi che consentono l'utilizzo del protocollo SSL occorre però che questo disponga di una chiave privata e di un certificato da esibire al client non appena questo si collega. Il certificato dovrebbe essere fornito da un'autorità di certificazione, ma in mancanza di questo lo si può creare in proprio, specie per utilizzi all interno di reti private.

5 Tali programmi, dal momento che offrono un servizio in modo autonomo, hanno la necessità di accedere direttamente alla chiave privata. Ecco perchè tale chiave non può essere protetta e di solito viene creato un file unico che contiene sia la chiave privata che il certificato. Il file contenente il certificato e la chiave, ha solitamente un nome corrispondente a quello dell'applicazione, con l'aggiunta dell'estensione.pem, collocato normalmente nella directory /usr/local/ssl/certs oppure /etc/ssl/certs/, nel nostro caso vengono messi più semplicemnte in /usr/local/ssl. Per poter generare un certificato contenete anche la chiave privata useremo i seguenti comandi: Nel mio caso ho usato per imapd openssl req -new -x509 -nodes -out imapd.pem -keyout imapd.pem -days 999 e per pop3d openssl req -new -x509 -nodes -out pop3d.pem -keyout pop3d.pem -days 999 La creazione del ceritifica comporta una serie di domande a cui rispondere. Sono abbastanza chiare ricordiamo solo di inserire quando viene richiesto il Common Name (eg, YOUR name) CN di inserire il nome di dominio completo su cui gira il servizio che vogliamo attivare, pena il non funzionamento dei servizi che vogliamo attivare. Country Name (2 letter code) [IT]: State or Province Name (full name) [Piemonte]: Locality Name (eg, city) [Collegno]: Organization Name (eg, company) [Netlink Sas]: Organizational Unit Name (eg, section) [Divisione Sicurezza]: Common Name (eg, YOUR name) [Netlink CA]: Address [info@nomesito.it]: Occorre anche ricordarsi di assegnare alla chiave privata non protetta (altrimenti il servizio non potrebbe funzionare) i giusti permessi per impedire l0acceso ad altri utenti. chmod 600 impad.pem chmod 600 pop3d.pem In caso contrario il sistema dovrebbe comunque funzionare ma segnalerebbe un errore di Wrong Permissions Dal momento che deve essere creata una chiave privata non protetta, il file che si genera non deve avere alcun permesso di accesso per gli utenti estranei. Occorre anche ricordarsi il punto preciso del filesystem in cui vengono creati i ceriticati perchè generalmente viene richiamato dal wrapper stesso con opzioni del tipo cert. Verifica del funzionamento A questo punto fate un bel kill HUP PID_inetd sul server e siamo pronti per provare. Per prima cosa verifichiamo con il solito portscanner l attività dei due nuovi servizi in ascolto sulle due nuove porte 993 e 995 rispettivamente. server2:/usr/local/ssl# nmap server2 Starting nmap V by Fyodor (fyodor@dhp.com,

6 Interesting ports on server2.in.labtel.it ( ): Port State Protocol Service 21 open tcp ftp 22 open tcp ssh 23 open tcp telnet 25 open tcp smtp 53 open tcp domain 80 open tcp http 110 open tcp pop open tcp imap2 443 open tcp https 993 open tcp simap 995 open tcp spop3 Nmap run completed -- 1 IP address (1 host up) scanned in 0 seconds Un tentativo di telnet ad una di queste due porte non sortisce più alcun effetto server2:/usr/local/ssl# telnet server2 995 Trying Connected to server2.in.labtel.it. Escape character is '^]'. A questo punto proviamo a scaricare la posta e a vedere se il sistema ce lo consente. In outlook (ma con netscape o con un client che supporta la connessione over ssl sarebbe lo stesso) Seguire i passaggi indicati: nel menu Strumenti di Outlook selezionare Account Qui scegliere la scheda Impostazioni Avanzate

7 Basta Spuntare la voce Il server necessità di una connessione protetta SSL, automaticamente ci viene proposta una porta la 995, quella in genere utilizzata ma si può comunque specificarne un'altra, ovviamente modificando anche il file /etc/services sul server. La stessa operazione va fatta per un account imap dopo averlo creato selezionando la stessa casella nella stessa scheda in questo caso la porta indicata è 993. Lo scarico della posta dovrebbe funzionare perfettamente, si potrebbe percepire un leggero ritardo, che possiamo considerare fisiologico in quanto è stato inserito il tunnel a controllo della posta. Nel caso in cui invece si utilizzi Netscape Navigator al primo accesso verrà effettuata l operazione di connessione al servizio protetto con il consenguente caricamento del certificato. In entrambi i casi può essere interessante osservare i log restituiti dal sistema: Feb 12 19:07:18 server2 stunnel[6770]: Using 'in.pop3d' as tcpwrapper service name Feb 12 19:07:18 server2 stunnel[6770]: stunnel 3.9 on i586-pc-linux-gnu PTHREAD+LIBWRAP Feb 12 19:07:18 server2 stunnel[6770]: in.pop3d connected from :2354 Feb 12 19:07:18 server2 in.pop3d[6771]: Servicing Feb 12 19:07:18 server2 stunnel[6770]: Connection closed: 226 bytes sent to SSL, 39 bytes sent to socket La connessione avviene sotto lo stetto controllo di stunnel, anche la chiusura della sessione indica che l invio dei dati (bytes) avviene attraverso il tunnel SSL.

8 A ulteriore conferma della bontà del nostro lavoro possiamo osservare come il nostro sniffer, Phoss nella fattispecie non sia in grado di captare più nessuna password. server2:/usr/local/ssl# /software/sicurezza/phoss PHoss (Phenoelit's own security sniffer) (c) 1999 by Phenoelit ( $Revision: 1.11 $ Requirement for SSL wrap with SSLWRAP La stessa procedura si può ottenere utilizzando un wrapper ancora più semplice cioè SSLWRAP. SSLwrap è un tunnel SSL/TLS che si inserisce al di sopra di servizi già esistenti che però non sono in grado di gestire direttamente questa funzionalità. Praticamente agisce come un proxy che, ricevendo connessioni attraverso le porte SSL/TLS, ripete le richieste ai servizi reali attraverso le porte normali. Uno schema di funzionamento per capire meglio come vengono effettuate le sessioni potrebbe essere questo: Client pop Connessione POP3S SSLWRAP 1050 Connessione POP3 110 Server Pop3 Come si può notare dallo schema SSLwrap può funzionare in un elaboratore distinto rispetto a quello che ospita i servizi per i quali è stato attivato. Naturalmente, nel tragitto che collega SSLwrap al servizio reale, i dati viaggiano in chiaro. Un problema dell'utilizzo di SSLwrap è dovuto al fatto che i servizi reali si trovano a comunicare sempre con lo stesso nodo, senza sapere da dove vengono realmente le richieste di connessione e senza poter applicare alcuna politica di filtro. Nel caso in cui SSLWRAP sia in funzione su di un nodo (sistema) differente si deve utilizzare l'opzione - addr. Ad esempio nella configurazione di inetd imaps stream tcp nowait sslwrap /usr/sbin/tcpd /usr/local/sbin/sslwrap cert /usr/local/ssl/impad.pem -port 143 -addr I software necessari oltre a: Openssl - sono sslwrap disponibile presso

9 Questo pacchettino giunto alla versione 2.06, di cui è possibile effettuare il download direttamente dal sito deve essere compilato e l eseguibile sslwrap copiato in una directory come /usr/local/sbin ad esempio. Realizzazione del tunnel in pratica con SSLWRAP Le operazioni sono analoghe a quelle effettuate con stunnel. Per prima cosa occorre aprire i nuovi servizi sicuri in ascolto che in genere vengono identificati con nomi diversi rispetto a prima. Nel file /etc/services del nostro sistema aggiungeremo: https 443/tcp # http TLS/SSL https 443/udp ssmtp 465/tcp # smtp TLS/SSL ssmtp 465/udp nntps 563/tcp # nttp TLS/SSL nntps 563/udp telnets 992/tcp # telnet TLS/SSL telnets 992/udp imaps 993/tcp # imap4 TLS/SSL imaps 993/udp ircs 994/tcp # irc TLS/SSL ircs 994/udp pop3s 995/tcp # POP3 TLS/SSL pop3s 995/udp ftps-data 989/tcp # ftp TLS/SSL ftps-data 989/udp ftps 990/tcp # ftp TLS/SSL ftps 990/udp Nel mio caso imaps 993/tcp # imap4 TLS/SSL pop3s 995/tcp # imap4 TLS/SSL Come si può notare simap e spop3 sono diventati imaps e pop3s. Poco cambia comunque. L uso di SSLWRAP può essere fatto per servizi che girano in modalità stand alone, cosa per altro sconsigliata e che sembra essere afflitta da parecchi bug oppure nella più sicura modalità inetd, come nel caso del nostro esempio. A questo punto modifichiamo il file inetd.conf del sistema, visto che questi due processi girano in modalità inetd. Aggiungiamo al file sopra citato # SSL tunneling over IMAP con SSLWRAP imaps stream tcp nowait sslwrap /usr/sbin/tcpd /usr/local/sbin/sslwrap -cert /usr/local/ssl/server.pem -port 143 # SSL tunneling over Pop3d con SSLWRAP pop3s stream tcp nowait sslwrap /usr/sbin/tcpd /usr/local/sbin/sslwrap -cert /usr/local/ssl/server.pem -port 143

10 la spiegazione sulla sintassi dell inetd è già stata anticipata. Ricordiamo che nel caso di sslwrap il servizio sicuro gira affianco a quello in chiaro di cui cifra le connessione. Pertanto il servizio pop3 e imap2 in chiaro non vanno sospesi come invece si faceva per stunnel. Per poter utilizzare il servizio nel modo più corretto e sicuro occorre non farlo girare come root ma come utente sslwrap. Per un corretto funzionamento ed un corretto accesso di questo utente al certificato ricordiamo di creare un utente ed un gruppo di nome sslwrap e di assegnare come utenti al file chown sslwrap.sslwrap server.pem con permissions chmod 0600 server.pem Sono segnalati dei Bug per quel che concerne l accesso al certificato. Nel nostro caso ha correttamente funzionato utilizzando i seguenti utenti e permission: chown root.sslwrap server.pem e come con permissions chmod 0640 server.pem A questo punto basta settare nella scheda Impostazioni avanzate di Outlook che Il server necessità di una connessione protetta SSL attraverso le porte standard indicate per poter ottenere lo scarico della posta crittografato e sicuro da sguardi indiscreti. Come si può notare il log del sistema è differente da quello usato da stunnel che cifra la sessione direttamente lanciando il demone. Feb 14 11:24:19 server2 sslwrap[28701]: connect from Feb 14 11:24:19 server2 imapd[28703]: connect from Feb 14 11:24:19 server2 imapd[28703]: Login user=pavan host=localhost [ ] Feb 14 11:24:19 server2 imapd[28703]: Command stream end of file, while reading line user=pavan host=localhost [ ] In questo caso si ottiene una chiamata dalla postazione che richiede il servizio (from ) attraverso sslwrap, il quale effettua a sua volta la richiesta dal localhost al servizio in ascolto sulla porta non protetta (143), il tutto esattamente come nello schema sopra descritto. Differenze tra i due metodi Potremmo dire che sslwrap è più immediato (minimale?), mentre stunnel richiede un po più di tempo per la compilazione. C è comunque da dire che Stunnel è un tunnel SSL/TLS che si inserisce al di sopra di servizi già esistenti che però non sono in grado di gestire direttamente questa funzionalità. Ma in aggiunta a quanto fa già SSLwrap, può essere usato anche per la funzionalità opposta, utilizzando un client che non è in grado di gestire il protocollo SSL/TLS. Va fatto notare proprio a proposito di questo che nel caso dell utilizzo di stunnel possiamo disattivare (commentandoli con un cancelletto posto davanti) dentro il file inetd.conf sia il servizio pop3 che imap2, cosa che invece non va fatta se si utilizza sslwrap che richiede espressamente il servizio in chiaro per poterci comunicare.

11 NETLinK S.a.S. Stunnel invece è in grado di gestire direttamente con il servizio le chiamate che arrivano alle porte protette non necessitando dell attivazione da inetd dei servizi in chiaro. Note Entrambi i sistemi soon abbastanza affidabili, anche se è consigliabile leggersi sui rispettivi siti le FAQ e BUGS riscontrati. Per sslwrap ricordo di assegnare al file le giuste permission. Nel caso in cui il client segnalasse il seguente messggio: Il server a cui si è connessi utilizza un certificato di protezione che non è stato verificato. come in genere capita se si utilizza outlook vi consiglio di convertire con opennssl il certtificato un formato browser compatibile (p12). Nle nostro caso openssl pkcs12 -export -in democa/cacert.pem -inkey democa/private/cakey.pem -out server.p12 -certfile server.pem A questo punto caricando il suddetto certificato il browser lo riconoscerà come emesso dalla nostra CA interna e quindi valido e verificato. Per concludere volevo solo segnalare che sono possibili errori ed imperfezioni, vi sarei grato se me le segnalaste all indirizzo pavan@netlink.it Doc: sslwrap.pdf Dott. Paolo PAVAN [Netlink Sas] pavan@netlink.it Data: Gennaio-Febbraio 2002 Note finali Il presente documento è a semplice scopo divulgativo. L autore non si assume la responsabilità di eventuali danni diretti o indiretti derivanti dall'uso dei programmi, o dall applicazione delle configurazioni menzionanate nel seguente articolo. L uso od il riutilizzo del presente articolo è liberamente consentito per scopi didattici o informativi previa citazione della fonte. Per il presente documento sono stati utilizzati spunti provenienti da Appunti Linux di D. Giacomini. e dagli HOWTO relativi ai programmi trovati liberamente disponibili su Internet. In blu sono state spcificate le configuraziona da utilizzare in corsivo i comandi lanciata sul sistema con gli estratti dei relativi file di log.

12