Dovecot, 2° parte

ed accertiamoci dello stato di Dovecot :



Controlliamo se riusciamo ad estrarre gli utenti dal database con doveadm :



Possiamo chiedere a doveadm di elencare le caselle postali di un utente:


Possiamo creare con doveadm una nuova cartella per un utente: e poi elencarne il contenuto

All'inverso, possiamo cancellare una cartella con doveadm : ed accertarsi dell'eliminazione.

Possiamo, sempre con doveadm, cercare dove sono posti i file di log:

Per quanto riguarda i file di log, possiamo chiedere a doveadm di mostrarci i 1000 ultimi errori ed avvisi, ma soltanto dall'ultimo riavvio:

Affrontiamo un'ultima utilità di doveadm, utile per fare il backup di ogni cartella del singolo utente.

Generiamo una cartella apposita,/home/backup/ : e rendiamo proprietario e gruppo della cartella vmail :
Con doveadm facciamo il backup delle cartelle del singolo utente verso una cartella in /home/backup:

ed elenchiamone il contenuto

Con un semplice "cronjob", potremmo implementare un backup a scadenza fissa, con relativa cancellazione dei file dopo tot periodo, ed avere sempre una copia delle mail transitate nel server, per un eventuale recupero, in caso di disgraziata cancellazione della mail da parte dell'utente.

Per conoscere altri usi di doveadm, usate l'opzione help.


Quando abbiamo scritto la query per estrapolare gli utenti e le loro password, abbiamo nominato default_pass_scheme con valore ARGON2I .

Ma cosa significa?

Per conoscere i vari tipi di cifratura (default_pass_scheme) supportati da Dovecot, utilizziamo
doveadm-pw, il generatore di hash per password ed anche il validatore degli hash creati,
con l'opzione per elencarne gli schemi predisposti: -l

Tra i tanti schemi, si trova anche ARGON2I (argon 2 i).

Ma come funziona?

L'hashing della password rende la password da testo in chiaro a stringa di caratteri casuali di una lunghezza specifica.

Una caratteristica dell'hashing è il modificare enormemente l'hash anche per piccoli cambiamenti nel testo in chiaro da cifrare; ad esempio pass1 e pass2 saranno completamente diversi e non solo nella parte finale.

Però, se facciamo l'hashing di pass1 e, in un secondo momento, noi, oppure un'altro utente, generiamo un hashing sempre per una password chiamata pass1, il risultato sarà identico.

Per ovviare a ciò, usiamo il "salting": nel creare l'hash del testo in chiaro, verrano aggiunti dei caratteri casuali alle parole da sottoporre ad hashing: pass1&ht5@ , pass1$%bf2
Il risultato, partendo da testi identici, saranno hash completamente diversi.

Argon2 è un algoritmo di hashing delle password progettato per essere resistente agli attacchi a forza bruta (dove un attaccante prova un numero elevato di password fino a trovare quella giusta) e agli attacchi a tabella arcobaleno (che utilizzano tabelle pre-calcolate per invertire gli hash).

I "rounds" sono il numero di iterazioni che l'algoritmo esegue per generare l'hash del testo in chiaro.
Maggiore è il numero di rounds, più tempo si impiega per calcolare l'hash, ma anche più tempo impiega un attaccante a provare diverse password.
Questo rende l'algoritmo più resistente agli attacchi.

Il parallelismo indica quanti thread vengono utilizzati per creare l'hashing del testo.
Il thread è una unità di esecuzione indipendente all'interno del processore.
Minore è il suo valore e maggiore sono le risorse a disposizione per l'hashing.

Per resistere agli attacchi, Argon2 utilizza un'elevata quantità di calcoli e risorse.
Non possiamo esagerare con il numero di rounds, senza rallentare eccessivamente la macchina.
Pensiamo ad un server con tanti utenti e tante generazioni di hash o validazioni di hash: il sistema andrebbe presto in crisi.

In doveadm-pw, per argon2i, il valore di default per i rounds è 3 e 1 per il parallelismo.
Perciò, se non diversamente indicato, doveadm userà questi valori.

Per generare password più robuste, useremo doveadm-pw con 5 rounds per lo schema argon2i :
Doveadm ci chiede di inserire la password e di confermarla

L'analisi dell'hash risultante ci dice:

$argon2i : abbiamo usato lo schema di hashing ARGON2I;

$v=19 : versione dell'hash; (0x13 numero esadecimale = 19 in decimale), perciò argon2 v1.3

$m=32768 : quantità di memoria usata in kilobytes;

t=5 : numero di "rounds" effettuati;

p=1 : quantità di parallelismo;

$AjyU3lnVSE0PkvMY6rz+sw : salt usato;

$9nBzMQCvoOMoneP9wPAHRvTu3mQDFFNelW/fWieP57Y : hash della password .


Adesso proviamo se quanto dichiarato per il salting è reale.

Digitiamo lo stesso comando, con la stessa password:
Doveadm ci chiede di inserire la password e di confermarla

Stavolta il salt è diverso e, di conseguenza, anche l'hashing della password è diversissimo.


Potremmo anche provare di quanto rallenta il sistema, mettendo, nel comando per creare la password cifrata, 10 iterazioni, invece di 5:
A meno che abbiate una macchina estremamente potente, con tanta memoria e processori superperformanti, la differenza di tempo per creare l'hash si apprezza molto bene.

Adesso, abbiamo i mezzi e la conoscenza per sostituire le password inserite, alla creazione del database, in chiaro nella colonna riguardante la password di ogni utente.

Avviamo MariaDB :
Una volta entrati, usiamo il nostro database, serverdiposta:


Leggiamo cosa avevamo inserito nella tabella mailbox:

Dovremo sostituire ogni password relativa al proprio utente.

Per fare ciò, dovremo generare una password cifrata e sostituirla a quella esistente.

Per comodità, apriremo un'altra finestra del terminale solo per generare l'hash della password e, dopo aver copiato il testo, lo inseriremo in una query scritta nella finestra del terminale già aperta e posizionata nel database.

Nulla toglie di poter creare la password, copiarla in un file di testo, riaccedere al database ed inserire la password ricopiandola nella query; tutte operazioni fatte nella solita finestra.


Generiamo una nuova password in una finestra del terminale

e copiamo l'hash risultante nella query scritta nel pannello aperto sul database:

Raccomandiamo estrema attenzione agli spazi e ai non spazi, alle virgolette singole da porre prima e dopo l'hash ed anche prima e dopo l'utente .

Ripetiamo questa procedura tante volte quanti sono gli utenti e relativa password da cambiare:

Finito l'aggiornamento delle password, diamo un ultimo controllo alla tabella :

Usciamo dal database:


Possiamo finalmente controllare se l'autenticazione, tramite il database, funziona; e lo facciamo sempre tramite doveadm .

Usiamo la funzione auth test , poi indichiamo l'utente seguito dalla sua password, così come dovremo fare nel client di posta:

Succeeded : l'autenticazione è riuscita ;



Failed, invece, ne indica il fallimento.

Così facendo, possiamo testare tutte le autenticazioni degli utenti.

Stavolta, la configurazione del Server di Posta è finita: il sistema è completo ed espandibile all'infinito, moderato solo dalla vostra volontà.

Possiamo creare utenti, aggiungere domini da gestire, spedire e ricevere posta con i client di posta.

Però, per essere "accolti" nella comunità dei Mail Server, per presentarsi ad essi senza essere emarginati in oscure liste nere, manca la definizione di alcuni record DNS, che saranno i nostri biglietti da visita, molto dettagliati.