In questo articolo vediamo due best practice per mettere in sicurezza il server di posta:
- Installare un certificato SSL sul server:
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 cercato SSL si può verificare di stare inviando informazioni proprio al server desiderato e non a quello di un criminale.
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.
Inoltre, un certificato firmato da una CA (Autorità di Certificazione) attendibile 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.
- Cambiare le porte di comunicazione dei client
Per quanto riguarda il protocollo SMTP, secondo i primi RFC, la porta over SSL è 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).
Il primo beneficio, squisitamente tecnico, è che una connessione alla porta MSA richiede immediatamente autenticazione.
Iniziando una sessione sulla porta 25, quando il mittente si presenta, il server lo accetta senza validazione e attende le istruzioni successive.
Sulla 587, invece, la sessione viene interrotta perché il server sgancia un errore 530 – Autenticazione richiesta.
Inoltre, utilizzare porte diverse per le comunicazioni tra 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.