Cybersecurity

Mettere in sicurezza il mail server: come fare e i vantaggi

07 Febbraio 2014

Tra le svariate best practices necessarie all’implementazione di un mail server sicuro, ce ne sono due che, benché molto efficaci e di semplice implementazione, vengono molto spesso snobbate dagli admin.

Mi riferisco all’implementazione di un certificato SSL sul server stesso e all’impostazione di porte alternative per le connessioni dei client.

 

  1. Perché SSL è così importante?
Il motivo principale per cui viene utilizzato SSL è quello di crittografare le informazioni sensibili inviate attraverso Internet, in modo che soltanto il destinatario possa decifrarle. 
Non pensiamo a una comunicazione Internet come a un unico salto tra due sistemi: le informazioni inviate su Internet sono trasferite da computer a computer per arrivare al server di destinazione. 
Senza crittografia, ogni computer tra sorgente e destinazione riceve i dati in chiaro (che siano numeri di carta di credito, nomi utente, password, messaggi di posta o altre informazioni). 
Quando si utilizza un certificato SSL, l'informazione diventa indecifrabile per tutti tranne che per il server cui si stanno inviando le informazioni, proteggendo così da hacker e ladri di identità.
Queste considerazioni sono tanto più valide riguardo a un protocollo testuale non crittografato come SMTP.
 
Un altro vantaggio dell’SSL è la validazione del destinatario: in altre parole, con un certificato SSL si può verificare di stare inviando informazioni proprio al server desiderato e non a quello di un criminale. 
Per la natura stessa delle comunicazioni in Internet, l’utente invia informazioni utilizzando metafore specifiche, come il nome DNS del server, ma non ha alcun controllo sull’effettiva corrispondenza di queste metafore con la realtà
È di non molto tempo fa la notizia di un attacco riuscito al DNS provider più grande del mondo: un “dirottamento” della traduzione DNS di un mail server aziendale causerebbe la perdita delle informazioni inviate a esso, che potrebbero essere usate per scopi criminali oppure, meno allarmisticamente, la perdita di opportunità di business.
In caso di server certificato, il client sarebbe sempre in grado di riconoscere l’effettiva identità dell’interlocutore e in caso di problemi interrompere la connessione o visualizzare un allarme.
Se poi il certificato è firmato da una CA (Autorità di Certificazione) attendibile, questo ci mette anche al riparo da attacchi di tipo Man in the middle, in cui un terzo sconosciuto si frappone tra sorgente e destinatario intercettando ed eventualmente modificando il messaggio.

 

  1. Cambiare le porte di comunicazione dei client
L’implementazione di un certificato sul server di posta presuppone già un cambio nelle porte di comunicazione tra i client di posta e il server: ad esempio, la porta standard dell’IMAP-S (IMAP over SSL) è la 993, mentre quella del POP3-S è la 995.

Cosa possiamo fare invece per la porta SMTP?
Cominciamo col dire che secondo i primi RFC, la porta SMTP-S è la 465. Molti server (compreso MDaemon) la implementano ancora, sebbene dal 2005 sia considerata best practice utilizzare la porta 587 (MSA, o mail submission agent). 

Quali sono i vantaggi?
Il primo, squisitamente tecnico, è che una connessione alla porta MSA richiede immediatamente autenticazione. 
Vediamo un esempio: connettiamoci via telnet alla porta 25 e 587 del mail server di Achab e chiediamo di inviare una email come furio.borsi.
Sulla porta 25, il server accetta il mittente e attende che io prosegua con la sessione SMTP.



Sulla 587, invece, la sessione viene interrotta perché il server sgancia un errore 530, poiché è richiesta l’autenticazione.



Inoltre, utilizzare porte diverse per le comunicazioni tra i server e tra client e server ci permette di implementare un’altra best practice, nota come Separation of Concerns, che è una delle tecniche fondamentali per affrontare situazioni complesse: in sostanza, separiamo gli ambiti (o le aree di competenza) di funzionalità diverse, in modo da avere la possibilità di fare troubleshooting isolatamente in caso di problemi.
Autore
Furio Borsi
Si appassiona al mondo digitale fin da bambino, con il glorioso Commodore 64, sul quale si diverte a scrivere semplici programmi in Basic e modificare giochi. Nel 1990 riceve in regalo il suo primo PC (i386), seguito un paio d'anni dopo da un i486dx. In questi anni affina le sue attitudini al problem solving, scassando hardware e software e divertendosi a rimetterlo a posto. ;) Diventa così "quello che se ne capisce" per i suoi familiari e amici, arrivando a collaborare con alcuni studi professionali per la gestione del parco macchine e dei server Windows. Finito il liceo, studia DAMS con indirizzo multimediale a Bologna e Imperia. Nel 2002, dopo un anno sabbatico a Londra, lavora come sviluppatore junior in un'azienda che produce software per database territoriali in ambito Pubblica Amministrazione. In questo periodo si avvicina con passione a problematiche sistemistiche e di network management su reti estese. Nel 2007 entra a far parte dello staff di Achab, per cui si occupa di formazione e supporto, in particolare riguardo a Kaseya, e gestione del parco macchine e della rete.
Commenti (2)

Buongiorno,
grazie ma come ci si procura un certificato SSL? Quanto costa mediamente?
Grazie.

Anonimo,

Ciao V., ci sono moltissime autorità di certificazione che emettono certificati. La quasi totalità li emette a pagamento (Verisign, Thawte, GoDaddy, Comodo) ad un costo variabile a seconda del certificato e della durata. Ce ne sono alcune (come CACert) che li emettono gratuitamente.

Furio Borsi,

Lascia un commento

Il tuo indirizzo e-mail non verrà pubblicato, lo utilizzeremo solamente per inviarti la notifica della pubblicazione del tuo commento. Ti informiamo che tutti i commenti sono soggetti a moderazione da parte del nostro staff.