Ricerche IT

Scenario

Facendo riferimento ai due precedenti articoli su Postfix e Dovecot, dove si era vista una configurazione minimale di un server di posta e l’utilizzo di alias e domini virtuali, sempre basandoci sull’ambiente di test precedentemente illustrato, in questo articolo vedremo come utilizzare le mailbox virtuali su Postfix, e quindi come accedere a queste mailbox con Dovecot. L’utilizzo di mailbox virtuali è un passo avanti rispetto alle configurazioni precedentemente trattate, poiché con questo tipo di caselle di posta elettronica, facciamo in modo che le mailbox siano completamente distinte dagli utenti di sistema, in questo modo non saremo costretti a creare un utente Linux da utilizzare ogniqualvolta abbiamo bisogno di una casella di posta. Oltre alle mailbox, avremo anche dei domini virtuali, in tal modo potremo ospitare sullo stesso server caselle di posta elettronica riferite a diversi domini, con tutti i vantaggi del caso. Le informazioni su mailbox e domini virtuali saranno contenute in file di testo sul file system del sistema operativo.

Configurazione di Postfix

Andremo a configurare mailbox virtuali sul server Giapeto per i domini cerere.mail e saturno.mail. In questa situazione, se esistono, è bene cancellare dal file di configurazione /etc/postfix/main.cf tutte le impostazioni relative ad alias e domini virtuali, poiché queste impostazioni andranno eventualmente riscritte secondo il formato richiesto dalle mailbox virtuali. La configurazione precedentemente descritta si esplicita nelle seguenti direttive nel file di configurazione /etc/postfix/main.cf; le altre informazioni riferite ai parametri basilari di Postfix rimangono quelle descritte nell’articolo riguardante la configurazione di base di Postfix:

1
2
3
4
5
6
7

virtual_mailbox_domains = cerere.mail saturno.mail
virtual_mailbox_base = /var/spool/vmail
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_minimum_uid = 5000
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
virtual_alias_maps = hash:/etc/postfix/virtual

La prima riga fa riferimento ai domini virtuali per i quali il sistema è abilitato a ricevere messaggi di posta, cioè cerere.mail e saturno.mail. La seconda riga fa riferimento alla directory di base scelta come deposito di tutta la posta ricevuta su questo server, al cui interno vi saranno le varie sottodirectory relative ai domini virtuali, e per ogni dominio virtuale vi saranno le directory riferite alle varie mailbox di quel dominio, dove verrà depositata la posta elettronica, secondo il formato di archiviazione Maildir, come vedremo di seguito. La terza riga indica il file dove vengono elencate le mailbox virtuali definite sul sistema e la loro posizione sul file system, a partire dalla directory definita in precedenza col parametro virtual_mailbox_base. La quarta riga specifica l’id minimo dell’utente utilizzato dal sistema per andare a scrivere i file rappresentanti i messaggi di posta sul file system, nella posizione indicata con il parametro virtual_mailbox_base; questo utente avrà un ID utente e un ID di gruppo, specificati con precisione nella quinta e nella sesta riga della porzione del file di configurazione specificata poco sopra. La settima e ultima riga è opzionale, e indica la posizione del file contenente gli alias virtuali delle mailbox virtuali effettive, come descritto nell’articolo precedente riguardante gli alias virtuali, anche se nell’articolo precedente gli alias si riferivano alle mailbox di sistema e non a quelle virtuali.

Modificata la configurazione di Postfix, creiamo la directory che conterrà le mailbox virtuali:

mkdir /var/spool/vmail

Ora invece dobbiamo creare la mappa che conterrà l’elenco delle mailbox virtuali definite sul sistema:

touch /etc/postfix/vmailbox

Quindi andremo ad editare il file vmailbox appena creato per definire l’elenco delle mailbox sul nostro sistema, in questo modo:

1
2
3
4

salvor.hardin@cerere.mail   cerere.mail/salvor.hardin/
hober.mallow@cerere.mail    cerere.mail/hober.mallow/
preem.palver@saturno.mail   saturno.mail/preem.palver/
stor.gendibal@saturno.mail  saturno.mail/stor.gendibal/

Questo è un tipico file di mappa di Postfix, dove nella prima colonna sono indicate le mailbox virtuali, mentre nella seconda è indicato il percorso della casella in cui andrà depositata la posta, a partire dalla “radice” che altro non è che il percorso indicato nella direttiva virtual_mailbox_base del file main.cf, come visto in precedenza; ad esempio, la posta della mailbox virtuale salvor.hardin@cerere.mail verrà depositata nella directory /var/spool/vmail/cerere.mail/salvor.hardin. Da notare lo slash (/) alla fine del percorso di ogni mailbox virtuale, il quale indica a Postfix di archiviare la posta nel formato Maildir.

Creare a questo punto la mappa in formato .db partendo dal file appena editato:

postmap /etc/postfix/vmailbox

Ora editiamo il file di mappa /etc/postfix/virtual in cui andare ad inserire gli alias per le mailbox virtuali:

1
2
3
4

postmaster@cerere.mail    salvor.hardin@cerere.mail
abuse@cerere.mail         salvor.hardin@cerere.mail
postmaster@saturno.mail   preem.palver@saturno.mail
abuse@saturno.mail        preem.palver@saturno.mail

e compiliamo quindi la mappa degli alias:

postmap /etc/postfix/virtual

Configurazione di Dovecot

Configurato Postfix, dobbiamo informare anche Dovecot delle mutate impostazioni di archiviazione della posta elettronica, per cui Dovecot dovrà essere informato della nuova posizione delle mailbox; inoltre, Dovecot non si baserà più sugli utenti di sistema per l’autenticazione sulla casella di posta, per cui andremo a fornirgli un file in cui sono elencati gli utenti ed un file in cui sono elencate le relative password, secondo lo schema stesso di Linux, basato su un file passwd dove sono indicati gli utenti, ed un file shadow dove sono elencate le password. Di seguito vediamo le impostazioni da inserire nel file di configurazione di Dovecot /etc/dovecot/dovecot.conf, fare attenzione ad aprire e chiudere le graffe, esistenti e non, all’interno del file di configurazione:

1
2
3
4
5
6
7
8
9
10

mail_location = Maildir:/var/spool/vmail/%d/%n
auth default {
  mechanisms = plain login
  userdb passwd-file {
    args = /var/spool/vmail/%d/etc/passwd
  }
  passdb passwd-file {
    args = /var/spool/vmail/%d/etc/shadow
  }
}

Nella riga 1 andiamo a specificare la posizione in cui Dovecot andrà a leggere la posta archiviata da Postfix, utilizzando delle variabili; ciò consente a Dovecot di leggere la posta di più domini, utilizzando la variabile %d, che indica la parte dopo la chiocciola dell’indirizzo di posta (il dominio), e la variabile %n, che indica la parte prima della chiocciola dell’indirizzo di posta (il nome utente): tra l’altro, ciò comporta l’accortezza di autenticarsi indicando, alla richiesta del nome utente, l’indirizzo completo di posta.

La seconda riga indica l’inizio della sezione riguardante le impostazioni di autenticazione su Dovecot, che sono evidenziate ad iniziare dalla terza riga, che indica i meccanismi di transito sulla rete delle password, che nel caso illustrato vengono trasmesse in chiaro per l’autenticazione su Dovecot; questo causa qualche problema di sicurezza, poiché le password viaggiano in chiaro sulla rete, quindi basta sniffarla il tempo necessario per carpire le password. Quarta e quinta riga indicano la posizione del file in cui sono indicati gli utenti possessori di una casella di posta, mentre settima e ottava riga indicano il percorso del file contenente il nome utente e la relativa password; da notare che anche in questo caso è stata utilizzata la variabile %d, seguita dalla directory etc/ che conterrà i due file: tale directory è stata creata semplicemente per coerenza con la struttura delle directory Linux, ma non è assolutamente necessaria.

Creazione directory, utenti e password

Ora bisogna creare gli utenti e le password sia per l’accesso di Postfix alla directory /var/spool/vmail, sia per l’autenticazione su Dovecot da parte di un qualsiasi MUA (Mail User Agent). Cominciamo creando l’utente di sistema che useremo per l’accesso alla directory in cui saranno contenute le mailbox virtuali:

useradd -d /var/spool/vmail -s /bin/false -m -U -u 5000 vmail

Con questo comando creiamo l’utente vmail, a cui assegnamo la home directory /var/spool/vmail e la shell “fasulla” /bin/false, ed a cui assegnamo l’id utente 5000, come indicato nella configurazione di Postfix; inoltre, con l’opzione –U andiamo a creare un gruppo con caratteristiche identiche all’utente appena creato. È possibile notare che la home directory assegnata all’utente vmail corrisponde alla directory indicata in Postfix come directory “root” per l’archiviazione di posta elettronica, in questo modo assegnamo subito a questo utente l’ownership (ovvero la proprietà) della directory, poiché sarà l’utente vmail che effettivamente avrà il compito di archiviare sul file system la posta elettronica.

Il passaggio successivo consiste nel creare le directory relative ai domini, ai file contenenti utenti e password, ed alle mailbox virtuali. Iniziamo con le directory relative ai domini cerere.mail e saturno.mail:

1
2

mkdir /var/spool/vmail/cerere.mail
mkdir /var/spool/vmail/saturno.mail

Ora creiamo la directory etc per ogni dominio, che conterrà i file relativi ad utenti e password corrispondenti alle mailbox virtuali create per ogni dominio; gli utenti e le password verranno utilizzati da Dovecot per autenticare l’accesso alle caselle di posta virtuali:

1
2

mkdir /var/spool/vmail/cerere.mail/etc
mkdir /var/spool/vmail/saturno.mail/etc

Ora andiamo a creare, per ogni dominio, il file degli utenti (passwd) e delle password (shadow), coerentemente con quanto indicato nel file di configurazione di Dovecot:

1
2
3
4

touch /var/spool/vmail/cerere.mail/etc/passwd
touch /var/spool/vmail/cerere.mail/etc/shadow
touch /var/spool/vmail/saturno.mail/etc/passwd
touch /var/spool/vmail/saturno.mail/etc/shadow

Creati i file, bisogna inserire il contenuto relativo a utenti e password, di seguito sono elencati i comandi per inserire i contenuti dei due file degli utenti passwd:

Utenti per il dominio cerere.mail

1
2

echo salvor.hardin::5000:5000::/var/spool/vmail/cerere.mail/salvor.hardin >> /var/spool/vmail/cerere.mail/etc/passwd
echo hober.mallow::5000:5000::/var/spool/vmail/cerere.mail/hober.mallow >> /var/spool/vmail/cerere.mail/etc/passwd

Utenti per il dominio saturno.mail

1
2

echo preem.palver::5000:5000::/var/spool/vmail/saturno.mail/preem.palver >> /var/spool/vmail/cerere.mail/etc/passwd
echo stor.gendibal::5000:5000::/var/spool/vmail/saturno.mail/stor.gendibal >> /var/spool/vmail/cerere.mail/etc/passwd

Dall’analisi di questi file, si può intuire che nel file viene indicato il nome utente, poi l’ID utente e di gruppo (il 5000 preso per l’utente locale vmail), quindi viene indicata la directory in cui Dovecot andrà a leggere la posta per quell’utente

Ora bisogna popolare il file shadow con le password degli utenti. Siccome voglio che le password siano criptate (ad esempio utilizzando l’algoritmo md5, anche se non è il più sicuro che esista), per generare le password dovrò utilizzare il comando dovecotpw. Ad esempio, per assegnare a tutti gli utenti la password Password00, dovrò scrivere qualcosa del genere:

Password per il dominio cerere.mail

1
2

echo salvor.hardin:$(dovecotpw –s md5 –p Password00) >> /var/spool/vmail/cerere.mail/etc/shadow
echo hober.mallow:$(dovecotpw –s md5 –p Password00) >> /var/spool/vmail/cerere.mail/etc/shadow

Password per il dominio saturno.mail

1
2

echo preem.palver:$(dovecotpw –s md5 –p Password00) >> /var/spool/vmail/saturno.mail/etc/shadow
echo stor.gendibal:$(dovecotpw –s md5 –p Password00) >> /var/spool/vmail/saturno.mail/etc/shadow

A questo punto, avendo trafficato con l’utente root all’interno della directory /var/spool/vmail, è necessario reimpostare l’ownership della directory e del suo contenuto con il comando

chown –R 5000:5000 /var/spool/vmail

Collaudo del sistema

Per testare il server di posta elettronica, è sufficiente inviare una mail ad uno degli indirizzi di posta appena creati, e Postfix, alla ricezione della mail, creerà la directory in cui depositare la posta e che rappresenterà il deposito di tutta la posta per quella determinata mailbox. Se voglio controllare cosa accade durante la ricezione della mail, sia per curiosità, sia per motivi di troubleshooting, è possibile consultare il log della posta, contenuto nel file /var/log/mail.log, che ci darà tutte le informazioni che ci necessitano. Se invece voglio controllare in tempo reale che accade, posso utilizzare un’opzione sciccosa del comando tail in questo modo:

tail –f /var/log/mail.log

che mi mostrerà appunto in tempo reale le righe che vengono eventualmente aggiunte al file /var/log/mail.log.

Conclusioni

Questa configurazione comincia ad essere un tantino più professionale rispetto alle configurazioni proposte in precedenza, infatti ora possiamo gestire con maggiore flessibilità più domini ed i relativi utenti, che non sono più utenti di sistema, per cui possiamo avere lo stesso nome utente per domini diversi. Questa configurazione però ha anche alcuni difetti, ovvero il metodo di creazione di utenti e password per l’accesso alla posta elettronica, che è un po’ macchinoso basandosi sulla riga di comando; un’altra mancanza non indifferente è rappresentata dal fatto che sostanzialmente, con questa configurazione, ci fidiamo di tutto ciò che ci arriva, poiché non vi sono restrizioni sulla posta in arrivo.

Per la definizione delle mappe delle mailbox virtuali e degli alias, nonché per la definizione di utenti e password per Dovecot, vedremo in seguito una configurazione in cui Postfix e Dovecot utilizzano MySQL al posto delle tecniche trattate finora, mentre per spam e antivirus verranno analizzati alcuni strumenti come greylist e blacklist, e ClamAV come sistema di scansione antivirus della posta elettronica. Rimane fondamentale una corretta configurazione di Postfix per impedire che il nostro MTA funga da open relay, ciò dipende essenzialmente, per quanto visto finora, da ciò che si inserisce nel parametro mynetworks, come illustrato negli articoli precedenti.

Link di riferimento

How to configure PostFix and Dovecot for Virtual Users with out a Database

Lo appunto qui così non mi dimentico.

E’ possibile configurare Apache 2 sotto Debian Lenny per fare rimanere il web server in ascolto su determinate porte e su determinati indirizzi IP, tramite la direttiva Listen. Questa direttiva (o più direttive Listen), in Debian è presente nel file di configurazione /etc/apache2/ports.conf, che viene richiamato tramite una direttiva include dal file principale di configurazione di Apache, /etc/apache2/apache2.conf.

Ad esempio, avendo un server web Debian Lenny con Apache 2, con due indirizzi IP come indicato di seguito:

IP1: 192.168.1.1
IP2: 5.6.7.8

se voglio che il server rimanga in ascolto su tutti e due gli indirizzi sulla porta 80, mi basta lasciare la direttiva predefinita indicata come di seguito:

Listen 80

la quale indica che Apache rimane in ascolto su tutte le interfacce di rete sulla porta 80. Se invece desidero che Apache rimanga in ascolto solamente sull’IP2 sulla porta 80, il contenuto del file ports.conf sarà il seguente:

Listen 5.6.7.8:80

Se invece ho l’esigenza di avere Apache in ascolto su entrambi gli indirizzi IP, ma su porte diverse, il file ports.conf si presenterà così:

Listen 192.168.1.1:80
Listen 5.6.7.8:8080

Dopo ogni modifica al file ports.conf, devo far ripartire Apache con il comando

/etc/init.d/apache2 restart

per applicare le modifiche effettuate.

Panoramica

Nel precedente articolo riguardante la posta elettronica su Linux (le cui avvertenze valgono anche per il presente post), è stato creato un mail server in grado di gestire un unico dominio di posta. Accade però piuttosto spesso di dover gestire più domini di posta, per cui, o si installa un mail server per ogni dominio (cosa che avrebbe un senso solo in caso di alto traffico), oppure, si fanno convivere sullo stesso server di posta più domini, che in caso di realtà medio-piccole è la soluzione ideale. Un’altra casistica non contemplata nel precedente articolo riguarda le liste di distribuzione, cioé la possibilità di avere un indirizzo di posta che recapiti il messaggio ricevuto su più caselle postali. Per questi test faremo riferimento all’ambiente di test descritto in precedenza, dove verrà utilizzato il mail server di test Titano, il quale gestisce il dominio urano.mail; tenere presente che dobbiamo creare le zone DNS relative ai domini virtuali utilizzati nel server DNS Windows Server 2003 DCServer.

Alias e domini virtuali

Per poter gestire la posta di più domini, è necessario definire, oltre al già citato urano.mail (indicato nella direttiva mydestination del file di configurazione /etc/postfix/postfix.conf) che sarà il dominio locale, anche i cosidetti domini virtuali, che corrispondono ai domini che dovremo gestire. A questo punto, è utile distinguere i domini locali dai domini virtuali: nel nostro caso, abbiamo un dominio locale, urano.mail, in cui, ad ogni utente creato sul sistema, corrisponde una casella di posta elettronica; in questo contesto, l’utilizzo di un dominio virtuale, ci consente di definire degli indirizzi di posta con dominio diverso da quello locale, che vengono mappati su una casella di posta elettronica del dominio locale, e che vengono quindi definiti alias virtuali.

Supponiamo, ad esempio, che il nostro mail server debba gestire i domini virtuali miranda.mail, ariel.mail e umbriel.mail; per farlo, dovremo dire a Postfix che intendiamo agire da server SMTP anche per questi domini, come mostrato di seguito:

virtual_alias_domains = miranda.mail ariel.mail umbriel.mail

Ora, dobbiamo inserire nel file di configurazione di Postfix (main.cf) il percorso del file in cui è contenuta la mappa con gli alias virtuali, in cui, ad una casella di posta locale, corrispondono uno o più indirizzi appartenenti ai domini virtuali definiti poc’anzi:

virtual_alias_maps = hash:/etc/postfix/virtual

Definito il file della mappa degli alias virtuali, dobbiamo creare il file stesso ed editarlo:

touch /etc/postfix/virtual
nano /etc/postfix/virtual

Il file va creato seguendo uno stile preciso, come mostrato di seguito:

h.mallow@miranda.mail       hober.mallow@urano.mail
s.hardin@ariel.mail         salvor.hardin@urano.mail
p.palver@umbriel.mail       preem.palver@urano.mail
s.gendibal@umbriel.mail     stor.gendibal@urano.mail

Come si può vedere, nella colonna sinistra del file mettiamo gli alias virtuali, mentre nella colonna di destra, indichiamo a quale utente di sistema va recapitata la posta indirizzata a quello specifico alias virtuale. Ora dobbiamo creare la mappa vera e propria, tramite la “compilazione” in formato binario del file /etc/postfix/virtual, con il comando postmap:

postmap /etc/postfix/virtual

che creerà il file /etc/postfix/virtual.db che sarà quello effettivamente usato da Postfix per l’interrogazione degli alias virtuali.

Così facendo, se spediamo ad esempio una mail a s.hardin@ariel.mail, questa verrà depositata fisicamente nella casella di posta salvor.hardin@urano.mail; ciò in alcune situazioni può andare bene, ma in altre situazioni, questo stato di cose potrebbe non andarci a genio, come in quei casi in cui vogliamo che le caselle di posta dei domini virtuali siano trattate come mailbox a sé stanti, e non legate agli utenti di sistema. Postfix permette di gestire anche queste casistiche, tramite le mailbox virtuali, che verranno esaminate in un articolo successivo.

Liste di distribuzione tramite alias virtuali

Tramite gli alias virtuali è possibile creare anche liste di distribuzione, ovvero indirizzi di posta elettronica virtuali che servono per reindirizzare i messaggi ricevuti dall’alias virtuale stesso agli indirizzi di posta specificati come destinatari del messaggio.

Vediamo un esempio: aggiungiamo una riga al file /etc/postfix/virtual come mostrato di seguito:

oratori@umbriel.mail        p.palver@umbriel.mail, s.gendibal@umbriel.mail

Come già specificato, sulla sinistra compare l’alias virtuale, sulla destra compaiono gli indirizzi di posta a cui vogliamo reindirizzare i messaggi ricevuti sull’indirizzo oratori@umbriel.mail; da notare che i diversi indirizzi devono essere separati da una virgola, e che, in questo caso i membri della lista di distribuzione sono a loro volta alias virtuali, ma potrebbero essere tranquillamente utenti di sistema.

Salvato il file, dobbiamo ricompilare il file /etc/postfix/virtual in questo modo:

postmap /etc/postfix/virtual

Ora possiamo testare il corretto funzionamento della lista di distribuzione, e se tutto va bene, inviando un messaggio all’indirizzo oratori@umbriel.mail, il messaggio arriverà ai due indirizzi p.palver@umbriel.mail e s.gendibal@umbriel.mail, i quali, essendo alias, non hanno una propria casella di posta e quindi il messaggio finirà effettivamente nelle caselle di posta preem.palver@urano.mail e stor.gendibal@urano.mail.

Conclusioni

In questo articolo abbiamo apportato qualche miglioramento al nostro server di posta basilare, ora possiamo gestire più domini sulla stessa macchina e possiamo gestire liste di distribuzione all’interno della nostra organizzazione. I metodi utilizzati possono essere utilizzati in piccole realtà, ma per ambienti più complessi, è bene utilizzare altre metodiche per raggiungere gli stessi risultati, che verranno illustrate in altri articoli sull’argomento.

Avvertenza

Questo articolo è stato redatto a scopo didattico e di test, per cui, si sconsiglia fortemente di adottare questa configurazione in ambiente di produzione, poiché non fornisce i necessari requisiti di sicurezza, a causa del tipo di installazione trattata e NON dei prodotti utilizzati.

Panoramica

In questo articolo verrà trattata l’installazione basilare di un server di posta elettronica su un server Debian Etch. La configurazione proposta rispecchia quella trattata nell’ambiente di test precedentemente descritto, dove verrà preso come server di posta il server Titano, il quale ha l’indirizzo IP 192.168.1.11 e su cui verrà configurato il dominio di posta urano.mail. I prodotti scelti per questa installazione di test sono Postfix, che funge da MTA ed espone il servizio SMTP, e Dovecot, che verrà utilizzato per esporre i servizi POP3 ed IMAP4, per far sì che gli utenti della rete possano consultare la propria posta elettronica. Lo scambio di e-mail avverrà con il server Exchange DCServer (dominio giove.mail) e con il server Linux Giapeto (dominio saturno.mail), il quale verrà configurato allo stesso modo del server Titano.

Cenni teorici

In questo articolo, verranno usati software che permettono la trasmissione e la ricezione di messaggi di posta elettronica. Per scambiare i messaggi tra i vari mail server, il protocollo usato sulla rete Internet è SMTP (Simple Mail Transfer Protocol), il quale, come dice il nome, è responsabile della trasmissione, e ricezione, dei messaggi di posta elettronica tra server di posta. Il server SMTP passa il messaggio ricevuto al Mail Delivery Agent (MDA), che spesso diventa un Local Delivery Agent (LDA), il quale si occupa di depositare il messaggio nella casella di posta elettronica dell’utente locale.

L’archiviazione del messaggio ricevuto, per quanto concerne il mondo Linux / Unix, può avvenire principalmente in due formati, mbox e maildir. Mbox ha la peculiarità di archiviare tutti i messaggi di posta elettronica in un unico file per ogni utente, mentre maildir crea un file per ogni messaggio ricevuto. Entrambi i sistemi presentano vantaggi e svantaggi in termini di flessibilità e prestazioni; a mio parere lo svantaggio principale di mbox è il fatto che, usando un unico file monolitico per ogni casella, in caso di problemi si rischia di perdere l’intero contenuto della casella stessa, cosa che diventa molto più difficile utilizzando maildir.

Un MTA ha il compito di movimentare i messaggi di posta, ma non è in grado di presentarli in una qualche forma all’utente finale. Per raggiungere lo scopo, bisogna installare un server POP3 e/o IMAP4, protocolli che permettono di poter presentare i messaggi di posta in un formato riconoscibile ad una applicazione client installata sull’host dell’utente finale, chiamata client di posta elettronica o Mail User Agent (MUA). POP3 è un protocollo piuttosto datato che consente appunto la lettura della posta elettronica tramite un Mail User Agent, il quale normalmente si connette al server POP3 e scarica i messaggi cancellandoli dal server; tale comportamento è d’ostacolo per quegli utenti che debbono consultare la posta da diverse posizioni, oppure per quegli utenti che condividono l’utilizzo di una mailbox. Per ovviare a questi problemi, esiste il protocollo IMAP4, che mantiene i messaggi di posta sul server, in modo tale da metterli a disposizione a prescindere dalla posizione dalla quale ci si connette; inoltre, mantiene una connessione permanente tra client e server, con i vantaggi del caso, rendendosi quindi il protocollo da scegliere per utilizzi professionali del servizio di posta elettronica.

Nel nostro caso, useremo Postfix come MTA, archiviando la posta nel formato maildir, quindi utilizzeremo Dovecot come server IMAP e POP3 e Outlook e Windows Mail come MUA.

Installazione e configurazione di Postfix

Per installare i software che ci servono, utilizzeremo i pacchetti .deb della distribuzione, in modo da mantenere un ambiente coerente, rinunciando però alle ultime versioni dei software (che è la filosofia di Debian, orientata alla stabilità ed alla sicurezza). Riguardo all’installazione di Postfix, basta un semplice:

apt-get install postfix

che richiede di specificare che tipo d’installazione di Postfix effettuare, noi sceglieremo “Sito Internet”, senza specificare uno smart host, poiché, nell’ambiente di test, non è necessario spedire mail al “mondo reale”:

Figura 1 - Scelta installazione Postfix

dopodiché, ci verrà richiesto il dominio da utilizzare per la posta elettronica, noi indicheremo il dominio urano.mail, come mostrato in figura 2:

Figura 2 - Scelta del dominio

Ora Postfix è installato, si tratta di fare qualche piccolo aggiustamento alla configurazione. Per prima cosa, abilitiamo la rete LAN del server Titano a mandare posta tramite il nostro MTA aggiornando il parametro mynetworks nel file di configurazione /etc/postfix/main.cf, che diventerà così:

mynetworks = 127.0.0.1/8 192.168.1.0/24

Quindi aggiungiamo due parametri, che indicano la directory di spooling delle mail e il formato di archiviazione dei messaggi delle mailbox, scegliendo Maildir, che creerà una directory Maildir per ogni home directory presente sul sistema:

queue_directory = /var/spool/postfix
home_mailbox = $HOME/Maildir/

Fatto questo, chiudiamo e salviamo il file /etc/postfix/main.cf, quindi possiamo far ripartire Postfix tramite il comando:

/etc/init.d/postfix restart

Ora, possiamo creare gli utenti di sistema, che fungeranno anche da mailbox per il server di posta. Gli utenti non hanno bisogno di un accesso shell, per cui verrà fornita loro la shell /bin/false, e faranno parte del gruppo mail:

useradd -m -g mail -s /bin/false salvor.hardin
useradd -m -g mail -s /bin/false hober.mallow

Ora possiamo provare a mandare una mail da un client di posta già configurato nell’ambiente di test all’indirizzo salvor.hardin@urano.mail, se tutto va come deve andare, dando il seguente comando

ls -l /home/salvor.hardin/Maildir/new

dovremmo vedere un file, ed aprendolo con un editor di testo, è possibile leggere il contenuto che altri non è che il testo della mail precedentemente inviata, comprese le intestazioni. A questo punto possiamo considerare terminata la configurazione di Postfix.

Installazione e configurazione di Dovecot

Per verificare il corretto funzionamento di Postfix, abbiamo consultato il file system del server Titano, ma per un utente “normale”, la cosa è alquanto scomoda. Si impone quindi l’installazione di un server POP3 - IMAP che consenta ad un qualsiasi client con installato un MUA di consultare la posta elettronica. La nostra scelta ricade su Dovecot, il quale ha la simpatica caratteristica di cercare di rendere semplice la propria configurazione e di supportare entrambi i formati di archiviazione della posta più diffusi, mbox e maildir. Per installare Dovecot ricorriamo al solito apt:

apt-get install dovecot-common dovecot-popd dovecot-imapd

Fatto questo, come per Postfix, anche con Dovecot dovremo fare qualche piccola modifica al file di configurazione, il cui percorso è /etc/dovecot/dovecot.conf. Per prima cosa, andremo a specificare quali protocolli rendere disponibili con Dovecot, impostando in questo modo la direttiva protocols:

protocols = imap imaps pop3 pop3s

Scendendo poco più giù nel file di configurazione, configureremo Dovecot in modo tale che accetti le password inviate dal client come testo in chiaro (ciò non è molto sicuro ma ci aiuta a semplificarci la vita in questo ambiente di test), impostando questa direttiva:

disable_plaintext_auth = no

Ora dobbiamo impostare il percorso in cui si trovano le caselle di posta ed il formato in cui sono archiviati, nel nostro caso maildir:

mail_location = maildir:~/Maildir

Il resto del file può essere lasciato invariato, quindi salviamo il file e riavviamo il demone Dovecot, tramite il solito

/etc/init.d/dovecot restart

dopodiché possiamo testare il nostro server IMAP configurando un qualsiasi MUA che supporti il protocollo IMAP; io ad esempio, per velocità, ho testato Windows Mail, il client di posta predefinito di Windows Vista, che funziona senza problemi con il server IMAP Dovecot senza bisogno di accorgimenti particolari, se si esclude il fatto che a prima vista sembra non comparire la cartella Posta in arrivo; in questo caso, basta sottoscrivere la cartella Posta in arrivo, la quale comparirà immediatamente rendendo possibile leggere i messaggi presenti nella casella di posta in oggetto.

Considerazioni personali sui MUA per Windows

Siccome, per i miei test, avevo a disposizione Windows Mail, ho utilizzato quello. Ho testato altri client di posta, cominciando da Microsoft Outlook (quello compreso nella suite Office, per intenderci), ed i risultati sono stati sconfortanti. Utilizzando Outlook 2003 per connettermi in IMAP sul server di posta, per prima cosa sul server vengono create solo le cartelle Posta in arrivo e Posta indesiderata, per cui, tra le altre cose, non viene creata la cartella Posta inviata; se anche creiamo la cartella Posta inviata a mano, con Outlook 2003 non c’è modo di archiviare la posta inviata nella cartella sul server.

Inizialmente, non usando praticamente mai IMAP, pensavo che fosse un mio problema, invece, surfando sul Web, ho potuto constatare che si tratta di una “caratteristica” di Outlook, che è aggirabile solamente creando una regola ad hoc. Per me tutto ciò è delirante. Si comporta leggermente meglio invece Outlook 2007, che ha gli stessi difetti di Outlook 2003, ma il cui comportamento relativamente alla posta inviata è modificabile in modo semplice agendo sulla configurazione dell’account di posta. In questo articolo del blog ilcava.it è descritto come procedere in questi casi. Da quanto ho potuto vedere io, anche con Outlook 2007 la cartella Posta inviata va creata a mano.

A questo punto ho voluto provare anche Thunderbird per Windows, che si comporta decisamente meglio, infatti, basta configurare normalmente un account di posta, che crea solamente le cartelle Posta in arrivo e Cestino, ma al primo invio di un messaggio, viene creata automaticamente sul server la cartella Posta inviata, così come viene creata una cartella Drafts se si salva un messaggio come bozza. Come già segnalato, Windows Mail si comporta piuttosto bene con IMAP.

Non ho provato alcun MUA per Linux, ma immagino che non diano particolari problemi.

Se qualcuno tra i lettori ha qualche suggerimento relativamente a quanto scritto con l’utilizzo di Outlook con IMAP, ed in particolare dell’interazione tra Outlook e Dovecot, i commenti sono a disposizione.

Conclusioni

Dopo aver testato con successo il corretto funzionamento di Postfix e Dovecot, possiamo ritenere conclusi, per il momento, i nostri test. Come scritto nell’avvertenza all’inizio dell’articolo, questa configurazione è adatta solamente a scopi (auto)didattici, poiché, configurando in questo modo un server di posta, non abbiamo nessuna protezione contro i virus, contro lo spam e contro il phishing (anche se, soprattutto nell’ultimo caso, la miglior protezione l’abbiamo sopra le spalle, basta usarla), inoltre, non utilizziamo quegli strumenti (come database relazionali o LDAP) per definire domini virtuali e caselle di posta. In poche parole, questa configurazione è decisamente migliorabile, e questi passi in avanti saranno oggetto dei prossimi articoli sull’argomento.

Link di riferimento

• Postfix (home page)
• Dovecot (home page)
• Protocollo SMTP (Wikipedia)
• Protocollo POP3 (Wikipedia)
• Protocollo IMAP (Wikipedia)
• MTA, MDA, MUA (Documentazione Red Hat Linux)
• Configurazione di Postfix (Blog di Marco Buttignon)

Su un server Linux, uno strumento indispensabile per l’amministrazione del server stesso è il server SSH, come OpenSSH, tramite il quale possiamo avere un accesso sicuro alla shell del sistema operativo, per poter amministratore comodamente il nostro server Linux.

In ambiente Windows, un accesso SSH non è una cosa indispensabile, risulta più utile avere un accesso via Remote Desktop per amministrare il server, allo stesso tempo però, può comunque avere un senso l’accesso SSH su server Windows, un po’ per determinate operazioni da svolgere via riga di comando, un po’ per poter scaricare o caricare file da o sul server attraverso SCP e SFTP, che possono diventare comodi soprattutto se ci connettiamo al server in remoto, via VPN, oppure se dobbiamo amministrare o trasferire dati da una macchina Linux ad una macchina Windows, in questo modo non saremo costretti ad utilizzare X oppure ad installare Samba per il trasferimento dati da/verso Windows.

Per quanto concerne il software che funge da server SSH, ne esistono diversi, e direi che più o meno tutti sono un’implementazione di SSH in ambiente emulato Cygwin; io ne ho provati due, Freesshd e CopSSH, che rispondono a due esigenze diverse, in particolare, Freesshd fornisce l’ambiente di shell di Windows, mentre CopSSH fornisce un sottoinsieme dei comandi presenti nella shell Bash di Linux.

Personalmente, tra un’implementazione completa della shell di Windows come quella di Freesshd (che appunto richiama direttamente l’interprete dei comandi di Windows, cmd.exe) ed una che (secondo le mie prove, che ammetto non essere state esaustive) risulta, all’atto pratico, avere una parte dei comandi Bash ed una parte dei comandi di Windows, come accade con CopSSH, preferisco Freesshd; tanto per fare un esempio, con Freesshd riesco a vedere i processi in esecuzione con il comando tasklist, cosa che non riesco a fare con Copssh.

Per poter utilizzare un server SSH su Windows, l’utente col quale faccio il logon al server deve obbligatoriamente consentire l’accesso interattivo al server, se così non è, va modificata l’opportuna policy (si tratta di policies diverse a seconda se il server è controller di dominio oppure no) sul server Windows, e questo può comportare qualche problema di sicurezza in più, cosa che secondo me rappresenta il vero svantaggio dell’avere attivo un server SSH su Windows. Entrambi i software hanno una procedura che permette di specificare quali utenti definiti sul server Windows possono accedere via SSH al server stesso, va da sé che, se vogliamo amministrare decentemente il server Windows, dovremo accedere allo stesso con un’utenza amministrativa, se invece necessitiamo del solo SFTP, è sufficiente abilitare l’utente all’accesso, dopodiché saranno le autorizzazioni impostate sulle cartelle del server Windows a stabilire le possibili azioni dell’utente.

Tornando a FreeSSHD, l’installazione del prodotto è decisamente banale, basta cliccare sempre su Avanti (Next); durante l’installazione verrà creato il servizio FreeSSHDService, in modo che il “demone” sia sempre attivo, quindi dovremo accedere alla configurazione del programma, cliccando col tasto destro sull’icona del programma posta nella systray e, scegliendo la voce Settings dal menu contestuale, è possibile gestire il server SSH, e soprattutto, è possibile abilitare o disabilitare l’accesso SSH agli utenti di Windows tramite la scheda Users, come mostrato in figura 1:

Figura 1 - Scheda Users di FreeSSHD

A questo punto, è sufficiente utilizzare un client SSH come Putty in ambiente Windows, o utilizzando il comando ssh in ambiente Linux/Unix, e collegandosi al server (finora ho provato solamente con nome utente e password, senza utilizzare certificati) si può testare il corretto accesso al server Windows.

Purtroppo, per un motivo che non sono ancora riuscito a capire, al primo tentativo viene restituito l’errore “Incoming packet was garbled on decryption” con Putty oppure l’errore “Bad packet length” su Linux, seguito da un numero; la cosa strana è che tentando una seconda volta, senza cambiare nulla, la connessione avviene senza nessun problema, se qualcuno sa o ha idea da cosa possa dipendere, farebbe cosa molto gradita scrivendolo nei commenti.

Una volta verificato il corretto accesso al server Windows, è possibile configurare anche SFTP, andando a specificare nella configurazione di FreeSSHD qual è la directory root SFTP del server Windows tramite la scheda SFTP, come mostrato in figura 2:

Figura 2 - Scheda SFTP di FreeSSHD

Ora non ci resta che testare il corretto funzionamento di una connessione SFTP; per Windows, si possono utilizzare due programmi, WinSCP (che a dispetto del nome consente anche la connessione SFTP) e FileZilla, il quale, oltre alle normali connessioni FTP, permette di stabilire connessioni SFTP basandosi sull’onnipresente Putty.

Questa configurazione, secondo le prove che ho potuto fare, funziona abbastanza bene, con alcuni difetti: per prima cosa, ho letto sul Web che FreeSSHD peccherebbe un po’ in stabilità, finora io non ho avuto problemi, ma non ne ho fatto un uso intensivo; secondariamente, per quanto riguarda SFTP, l’unica configurazione possibile riguarda la root directory accessibile dagli utenti, impedendo agli stessi di poter accedere alle cartelle di livello superiore, e ciò è positivo dal punto di vista della sicurezza, poiché in questo modo si possono abilitare diversi utenti che comunque non hanno la possibilità di gironzolare per il disco, però, allo stesso tempo, questa impostazione riguarda TUTTI gli utenti, per cui anche gli utenti con privilegi amministrativi, utilizzando SFTP, non possono operare ad un livello superiore rispetto alla home directory, anche se, in realtà, utilizzando Linux, è possibile superare questa limitazione utilizzando scp, per poterlo fare però bisogna conoscere il percorso esatto del file da prelevare; altra limitazione, la shell fornita per default da FreeSSHD è quella di Windows, per cui WinSCP non funziona in modalità SCP, funziona però perfettamente in modalità SFTP.

In conclusione, installare un server SSH su Windows, è utile, secondo me, solo in determinate occasioni, soprattutto se da client Linux dobbiamo accedere o condividere file con un server Windows, oppure può risultare utile su connessioni remote particolarmente lente, altrimenti, secondo me è più utile utilizzare Remote Desktop, utilizzabile anche da Linux tramite il pacchetto rdesktop.

La versione pacchettizzata di MySQL Server 5 per Linux Debian Etch 4.0 ha una caratteristica, non accetta connessioni sulla porta 3306 (la porta a cui risponde MySQL) se non da localhost, cioè sé stesso. Questo può essere un problema se vogliamo o dobbiamo tenere due macchine separate per un’applicazione (o sito) ed il relativo database.

La soluzione al problema è molto semplice, si tratta di commentare la seguente voce

bind-address = 127.0.0.1

presente nel file di configurazione di MySQL, /etc/mysql/my.cnf, dopodiché, dobbiamo abilitare uno o più utenti per poter connettersi in remoto su un particolare database utilizzando l’istruzione SQL GRANT:

GRANT ALL privileges ON testDB.* TO 'testUSR'@'192.168.0.3' IDENTIFIED BY 'testPWD'

così facendo, si abilita l’utente testUSR a connettersi al database testDB dall’host 192.168.0.3. A questo punto, è sufficiente far ripartire il demone di MySQL per abilitare la modifica effettuata al file my.cnf:

/etc/init.d/mysql restart

e questo è tutto.

Se si deve gestire un firewall Linux con iptables, in determinate situazioni può riverlarsi indispensabile poterne gestire il logging nel modo più lineare possibile; il passo più logico per raggiungere questo scopo è quello di effettuare un logging su file delle attività di iptables che si intende monitorare. Si tenga presente che questi passaggi sono stati effettuati su Debian Etch.

L’operazione consta di più passaggi:

1. configurazione di iptables per fare in modo che venga fatto il logging di determinati tipi di traffico su file;
2. installazione e configurazione di syslog-ng, che consentirà di specificare uno specifico file su cui redirigere il logging di iptables;
3. configurazione di logrotate per poter ruotare i file di log di iptables.

Configurazione di iptables

Per prima cosa, dobbiamo decidere quale tipo di traffico vogliamo monitorare, in questo caso, scegliamo di monitorare il traffico icmp verso l’ipotetica interfaccia esterna del nostro firewall. Se si prende come riferimento l’articolo precedente riguardante iptables, bisogna aggiornare lo script di iptables, caricando per prima cosa il modulo ipt_LOG tramite la direttiva:

modprobe ipt_LOG

Ora è possibile specificare un’istruzione per il logging del traffico ICMP sull’interfaccia esterna, assumendo che questa prenda il nome eth1:

iptables -A INPUT -i eth1 -p icmp -j LOG --log-level 4 --log-prefix='LOG_ICMP '

quest’istruzione è da inserire prima dell’eventuale direttiva che consente o nega il traffico ICMP verso l’interfaccia eth1. Da notare la direttiva log-prefix, che farà precedere le stringhe di logging da ciò che abbiamo specificato tra apici (nel nostro caso LOG_ICMP ). Con questo comando termina la configurazione di iptables.

Installazione e configurazione di syslog-ng

In questo secondo passaggio andremo a sostituire il server syslog classico con syslog-ng, un server syslog più evoluto che permette una gestione più raffinata dei messaggi di log provenienti da kernel e demoni. Prima di configurare syslog-ng, dobbiamo però fare in modo che i log di iptables non compaiano in console (che in pratica si traduce nella comparsa dei vari log sul monitor del PC), cosa decisamente fastidiosa: ciò è possibile editando il file /etc/sysctl.conf:

nano /etc/sysctl.conf

quindi, dobbiamo decommentare la riga 1 del seguente listato sostituendola con la riga 3:

1
2
3

#kernel.printk = 7 4 1 7
 
kernel.printk = 4 4 1 7

in tal modo, indicando il valore 4 in vece del valore 7, si indica che il logging a console viene abilitato solo per il logging di livello inferiore a 4, avendo indicato noi nello script di iptables che il nostro logging è di valore 4, la console rimarrà immacolata.

AGGIORNAMENTO
Un metodo alternativo per raggiungere lo stesso scopo è quello di editare il file /etc/default/syslog-ng decommentando l’ultima riga, che diventerà:

CONSOLE_LOG_LEVEL=4

al posto di 4, potremo mettere, nel caso, anche un numero inferiore fino ad arrivare a 1. Una volta riavviato il demone di syslog-ng, verrà modificato come visto in precedenza il file kernel.printk per prevenire la visualizzazione sulla console dei log di iptables.
FINE AGGIORNAMENTO

Ora, installiamo syslog-ng con il classico apt:

apt-get install syslog-ng

che non si limita ad installare syslog-ng ma disinstalla anche il classico syslog, di cui va a prendere il posto. A questo punto va configurato syslog-ng per far sì che i log non vadano a finire nei file /var/log/messages, /var/log/kern.log e /var/log/syslog, editando il file /etc/syslog-ng/syslog-ng.conf:

nano /etc/syslog-ng/syslog-ng.conf

dove bisogna aggiungere in fondo al file le seguenti righe:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# configurazione logging di iptables
 
destination df_firewall {
        file("/var/log/iptables.log");
};
 
filter f_firewall {
match("LOG_ICMP ");
};
 
log {
        source(s_all);
        filter(f_firewall);
        destination(df_firewall);
};

Le righe da 3 a 5 servono per parametrizzare il file dei log di iptables, le righe da 7 a 9 rappresentano il criterio con cui viene deciso, da parte di syslog-ng, quando redirigere le stringhe di logging verso il file specificato in precedenza attraverso la condizione

match("LOG_ICMP ")

mentre le righe da 11 a 15 rappresentano la direttiva vera e propria verso syslog-ng per loggare tutto ciò che proviene da iptables contenente la stringa “LOG_ICMP “.

Lasciando le cose in questo modo, il logging verso il file /var/log/iptables.log funziona perfettamente, però i log vengono inviati anche verso i file “canonici” di log del kernel. Per ovviare al problema, bisogna modificare il file /etc/syslog-ng/syslog-ng.conf in modo che syslog-ng non scriva i messaggi provenienti da iptables nei file indicati in precedenza; primo passo, la modifica del filtro f_kern:

1
2
3

filter f_kern { facility(kern); };
 
filter f_kern { facility(kern) and not match("LOG_ICMP "); };

dove la riga numero 1 viene sostituita dalla riga numero 3, così da evitare che le voci di log vadano a finire nel file /var/log/kern.log; il passo successivo riguarda la modifica della voce relativa al filtro f_syslog:

1
2
3

filter f_syslog { not facility(auth, authpriv); };
 
filter f_syslog { not facility(auth, authpriv) and not match ("LOG_ICMP "); };

dove andremo a sostituire la riga numero 1 con la riga numero 3, per impedire che il logging di iptables vada a popolare il file /var/log/syslog. Ora rimane da modificare il filtro f_messages, che da così

filter f_messages {
        level(info,notice,warn)
            and not facility(auth,authpriv,cron,daemon,mail,news);
};

diventa così

filter f_messages {
        level(info,notice,warn)
            and not facility(auth,authpriv,cron,daemon,mail,news)
                and not match ("LOG_ICMP ");
};

modifica che inibisce il logging di iptables nel file /var/log/messages. In tutte e tre le situazioni, abbiamo aggiunto la condizione

and not match ("LOG_ICMP ")

condizione che istruisce syslog-ng ad ignorare, per quel determinato filtro, tutti i log che contengono la stringa “LOG_ICMP “, per cui, se si modifica la configurazione di iptables utilizzando, per il logging, un prefisso diverso da quello indicato (tramite la direttiva log-prefix di iptables), tutte le segnalazioni finiranno nei file “normali” e non nel file /var/log/iptables.log che abbiamo creato.

Configurazione di logrotate

Tenendo le cose così come sono, con l’andare del tempo il file /var/log/iptables.log assumerà dimensioni sempre più grandi, rendendo quindi i log di difficile lettura. La soluzione al problema sta nell’istruire logrotate (che dovrebbe essere già presente in Debian Etch) per routare il nostro file di log personalizzato secondo i criteri che preferiamo. Prima di configurare logrotate, vediamo brevemente come funziona.

Logrotate ha un file di configurazione, /etc/logrotate.conf, in cui sono indicate le opzioni generali di configurazione, ed ha una directory, /etc/logrotate.d, in cui vi sono i file di configurazione riguardanti il logging delle singole applicazioni; questi file di configurazione vengono richiamati dalla direttiva presente nel file /etc/logrotate.conf

# packages drop log rotation information into this directory
include /etc/logrotate.d

Nel nostro caso, dovremo creare un file chiamato iptables nella directory /etc/logrotate.d, quindi editarlo per indicare a logrotate come routare il nostro file:

touch /etc/logrotate.d/iptables
nano /etc/logrotate.d/iptables

Nel file /etc/logrotate.d/iptables andremo ad inserire questo contenuto:

1
2
3
4
5
6
7
8

/var/log/iptables.log {
        weekly
        rotate 4
        compress
        notifempty
        missingok
        endscript
}

Vediamo di esaminare nel dettaglio le varie istruzioni del file: weekly indica che il file di log viene routato con cadenza settimanale, rotate 4 significa che vengono conservati 4 log già routati, compress specifica che i file di log routati vengono compressi, notifempty sta ad indicare a logrotate di non routare il file di log se questo è vuoto, missingok permette a logrotate di non segnalare errori se per qualche motivo il file di log non esiste, endscript indica semplicemente il termine delle istruzioni di configurazione per il file corrente. Per ulteriori informazioni sulle opzioni di logrotate è possibile consultare le pagine man di logrotate oppure gli ultimi due collegamenti nella sezione Link di riferimento di quest’articolo.

Ora non rimane che verificare nel tempo il corretto funzionamento di logrotate.

Link di riferimento

http://tuttodebian.blogspot.com/2008/05/iptables-and-syslog-how-to-log-in.html
http://www.linux.it/~rubini/docs/printk/printk.html
http://openskill.info/infobox.php?ID=779
http://www.uielinux.org/blog/14-usare-linux/87-ubuntu-professionale-usiamo-il-logrotate.html

Facendo riferimento al precedente articolo, che trattava la configurazione degli host virtuali in Apache su un sistema Debian, proseguiamo sulla stessa falsariga e vediamo come configurare in modo opportuno un server FTP che consenta una gestione separata dei diversi siti, impedendo nello stesso tempo agli utenti di girare per il file system e quindi di accedere ad aree della macchina che non competono loro; in questo articolo parlerò di ProFTPD, anche se nell’articolo precedente avevo citato vsftpd, purtroppo, nell’installazione in cui ho in funzione vsftpd, ho avuto alcuni problemi di cui non sono riuscito a capire l’origine, problemi che mi hanno costretto ad utilizzare un altro server FTP, ProFTPD appunto.

Ora dobbiamo configurare in modo opportuno ProFTPD in modo da avere due utenti distinti che gestiscano i due siti creati come descritto nell’articolo precedente, creando due siti FTP virtuali, con l’ausilio di un database dedicato su MySQL; installiamo quindi ProFTPD con il supporto per MySQL:

# apt-get install proftpd proftpd-mysql

Ora dovremo creare il database per ProFTPD, entrando in MySQL col comando:

$ mysql -u root -p

quindi, dopo aver inserito la password, creiamo il database proftpd col comando:

> CREATE DATABASE proftpd;

ed ora, creiamo l’utente MySQL proftpd, al quale diamo le autorizzazioni del caso al database proftpd:

> GRANT SELECT, INSERT, UPDATE, DELETE ON proftpd.* TO ‘proftpd’@'localhost’ IDENTIFIED BY ‘pwdProFTPD’;
> FLUSH PRIVILEGES;

dove, al posto di pwdProFTPD metteremo la password che più ci aggrada.

A questo punto, seguiamo le istruzioni contenute nel preziosissimo tutorial di Howtoforge, che spiega passo passo come realizzare un server FTP che permetta di definire dei virtual host, a cominciare dalle indicazioni su come creare un utente ed un gruppo di sistema per ProFTPD, per poi passare alle istruzioni su come creare le tabelle nel database MySQL riguardanti gli utenti e le ftpquotas (le quote di spazio riservato su disco per ogni utente), dopodiché, a pagina 2 della guida, viene spiegato quali righe aggiungere al file di configurazione /etc/proftpd/proftpd.conf per consentire a ProFTPD di utilizzare un database MySQL come supporto. In particolare, vediamo la riga SQLConnectInfo (in cui vanno inseriti i parametri di connessione al database), la quale, se utilizziamo un database MySQL configurato come descritto in precedenza, va scritta così:

SQLConnectInfo proftpd@localhost proftpd pwdproftpd

Giunti qui, dobbiamo inserire gli utenti nel database MySQL, in particolare nella tabella ftpuser (ho tralasciato volutamente la parte riguardante le quote disco); la guida presente su Howtoforge è fatta molto bene, ma ha il difetto di inserire le password degli utenti in chiaro nella tabella del database, cosa che comporta problemi di sicurezza, per cui, dovremo per prima cosa cambiare una direttiva nel file di configurazione di ProFTPD, per poi utilizzare un’istruzione SQL INSERT diversa da quella riportata su Howtoforge. Il primo passaggio, come detto, consiste nel modificare la direttiva SQLAuthTypes, impostandola in questo modo:

SQLAuthTypes Crypt Plaintext

che significa che le password degli utenti definiti nel database MySQL devono essere criptate, altrimenti l’utente non riuscirà ad autenticarsi su ProFTPD. Ora , dopo aver fatto ripartire il demone proftpd, passiamo all’inserimento vero e proprio degli utenti nel database proftpd in MySQL, in cui dobbiamo prestare attenzione ad indicare la home directory su cui verrà rimbalzato l’utente che si autentica su ProFTPD; in particolare, facendo riferimento all’articolo riguardante l’hosting virtuale con Apache, creeremo un utente chiamato u_webtest con password p_webtest (password insicura, utilizzata per comodità) e home directory /var/www/webtest, quindi creeremo un altro utente chiamato u_webprova con password p_webprova e home directory /var/www/webprova:

> INSERT INTO ftpuser (userid, passwd, uid, gid, homedir, shell, count, accessed, modified) VALUES
> (’u_webtest’, ENCRYPT(’p_webtest’), 2002, 2002, ‘/var/www/webtest’, ‘/sbin/nologin’, 0, ”, ”);

> INSERT INTO ftpuser (userid, passwd, uid, gid, homedir, shell, count, accessed, modified) VALUES
> (’u_webprova’, ENCRYPT(’p_webprova’), 2003, 2003, ‘/var/www/webprova’, ‘/sbin/nologin’, 0, ”, ”);

Da notare che per inserire la password è stata usata la funzione di MySQL ‘ENCRYPT’, la quale utilizza la chiamata di sistema crypt() presente sul sistema operativo, quindi di fatto utilizza lo stesso metodo di cifratura utilizzato da Linux per cifrare le password degli utenti di sistema. Ora, rimangono da impostare i permessi sulle directory dei due siti web, per far sì che gli utenti FTP possano scrivere al loro interno, dando l’autorizzazione in scrittura all’utente ftpuser creato in precedenza:

# chown -R ftpuser:www-data /var/www/webtest
# chown -R ftpuser:www-data /var/www/webprova
# chmod -R 775 /var/www/webtest
# chmod -R 775 /var/www/webprova

Arrivati fin qui, dobbiamo solamente utilizzare un client FTP per testare la funzionalità del nostro server FTP, e, se tutto è andato bene, dovremmo essere pronti per utilizzare il nostro ProFTPD.

Se un server Linux Debian viene utilizzato come server Web, è abbastanza probabile che questo ospiti più siti, ed è piuttosto comune che questi siti vengano gestiti da persone diverse, che debbono avere quindi un accesso FTP dedicato per poter caricare i file del proprio sito, e magari poter avere l’accesso al proprio database MySQL tramite PhpMyAdmin, facendo in modo che gli operatori non vadano a gironzolare su directory o database non di loro competenza.

In questo primo articolo (il prossimo tratterà della configurazione del server FTP vsftpd), darò per scontato che siano già installati (tramite il solito apt) Apache2, PHP5, MySQL; ipotizziamo quindi di dover creare due siti, webtest.it e webprova.it, e creiamo le relative directory:

# mkdir /var/www/webtest
# mkdir /var/www/webprova

Ora, create le directory, dobbiamo configurare gli host virtuali in Apache. Apache2, in Debian, consente la configurazione degli host virtuali inserendo un file di configurazione per ogni host virtuale che si intende creare nella directory /etc/apache2/sites-available, per cui, andremo a creare i due file per i due domini:

# touch /etc/apache2/sites-available/webtest.it
# touch /etc/apache2/sites-available/webprova.it

A questo punto, creati i file vuoti, vanno editati con questi contenuti:

File /etc/apache2/sites-available/webtest.it

NameVirtualHost *:80
<VirtualHost *:80 >
ServerAdmin webmaster@webtest.it
ServerName www.webtest.it
DirectoryIndex index.html index.php
DocumentRoot /var/www/webtest
<Directory "/var/www/webtest">
Order Deny,Allow
Allow from all
Options -Indexes
</Directory>
ErrorLog /var/log/apache2/webtest.it.log
LogLevel warn
CustomLog /var/log/apache2/access.webtest.it.log combined
</VirtualHost>

File /etc/apache2/sites-available/webprova.it

<VirtualHost *:80 >
ServerAdmin webmaster@webprova.it
ServerName www.webprova.it
DirectoryIndex index.html index.php
DocumentRoot /var/www/webprova
<Directory "/var/www/webprova">
Order Deny,Allow
Allow from all
Options -Indexes
</Directory>
ErrorLog /var/log/apache2/webprova.it.log
LogLevel warn
CustomLog /var/log/apache2/access.webprova.it.log combined
</VirtualHost>

Ora i due siti sono configurati con impostazioni "normali", vediamo il loro significato:

NameVirtualHost *:80
Serve per definire su quale interfaccia di rete e su quale porta deve rimanere in ascolto l’host virtuale Apache, in questo caso rimane in ascolto su tutte le interfacce sulla porta 80

<VirtualHost *:80 >
Identifica l’apertura della sezione relativa alla configurazione dell’host virtuale, l’indicazione successiva a VirtualHost (*:80) deve essere identica a quella della direttiva NameVirtualHost

ServerAdmin webmaster@webtest.it
Indica l’indirizzo e-mail dell’amministratore del dominio

ServerName www.webtest.it
Rappresenta il nome FQDN del sito, è fondamentale scrivere bene questa voce altrimenti il nostro sito non sarà visibile

DirectoryIndex index.html index.php
Esprime l’ordine di ricerca di determinate pagine Web rappresentanti la home page quando viene fatta da un browser una richiesta del tipo www.webtest.it/ o www.webtest.it/test/, se in queste directory non esiste una pagina chiamata index.html o index.php (o qualsiasi altro nome file indicato nella direttiva DirectoryIndex), Apache restituirà un errore 403 Forbidden se usiamo la direttiva "Options -Indexes" (come effettivamente faremo), oppure, se questa direttiva non viene utilizzata, visualizzeremo i files presenti nella directory

DocumentRoot /var/www/webtest
Indica la directory in cui sono posizionati i file del nostro sito

<Directory "/var/www/webtest">
Identifica l’inizio della configurazione delle autorizzazioni per la directory del sito

Order Deny,Allow
Allow from all
Queste due righe stanno ad indicare che il sito è visibile a tutti

Options -Indexes
Come indicato in precedenza, questa opzione permette di visualizzare un errore 403 di accesso negato se si digita un indirizzo del tipo www.webtest.it/test/ ed in questa directory non esiste un file chiamato con uno dei nomi file indicati nella direttiva DirectoryIndex; se non si specifica questa opzione, sarà visibile il contenuto dell’intera directory, cosa da evitare.

ErrorLog /var/log/apache2/webtest.it.log
LogLevel warn
CustomLog /var/log/apache2/access.webtest.it.log combined
ErrorLog fornisce un percorso per il file di log contenente le segnalazioni di errore che incontra Apache, mentre LogLevel indica la verbosità delle operazioni di logging attraverso un sistema di livelli, di cui "warn" è uno dei più bilanciati; CustomLog identifica la posizione del file di log che registra gli accessi al sito Web.

Giunti qui, andiamo a creare i file di log che abbiamo specificato nei file di configurazione dei virtual hosts:

# touch /var/log/apache2/access.webtest.it.log
# touch /var/log/apache2/webtest.it.log
# touch /var/log/apache2/access.webprova.it.log
# touch /var/log/apache2/webprova.it.log

dopodiché, bisogna abilitare i siti virtuali, e ciò è possibile tramite il comando a2ensite, il quale crea dei link simbolici nella cartella /etc/apache2/sites-enabled/ che puntano ai file di configurazione creati in precedenza nella cartella /etc/apache2/sites-available/:

# a2ensite webtest.it
# a2ensite webprova.it

ciò è necessario poiché nel file di configurazione di Apache (/etc/apache2/apache2.conf) vi è una direttiva che include i file presenti nella cartella /etc/apache2/sites-enabled/.

Ora non rimane altro che riavviare Apache ed avremo i nostri virtual hosts funzionanti.

Giunti qui, rimane da fare un’unica cosa, cioé installare e configurare PhpMyAdmin per poter gestire il proprio database MySQL tramite sito Web. Per installare PhpMyAdmin, possiamo utilizzare il comando

# apt-get install phpmyadmin

dopodiché, dobbiamo creare un alias su ogni sito sul quale vogliamo rendere disponibile PhpMyAdmin; l’alias si rende necessario poiché l’installazione di PhpMyAdmin viene effettuata nella directory /usr/share/phpmyadmin, per cui, o si fa l’alias, oppure si copia la directory phpmyadmin nella directory del sito, ma ciò non conviene, poiché:

1. è un’operazione che dovremmo ripetere per ogni aggiornamento di PhpMyAdmin
2. nel caso di più host virtuali che utilizzano PhpMyAdmin, dovremmo ripetere la copia per ogni host virtuale che utilizza PhpMyAdmin

per cui, è bene utilizzare un alias per ogni virtual host, che mappi una directory virtuale (ad esempio, /phpmyadmin) per ogni host virtuale che utilizza PhpMyAdmin. Configurare l’alias è molto semplice, prendendo ad esempio i file di configurazione dei due domini citati precedentemente, basta aggiungere questa riga dopo l’istruzione DocumentRoot:

Alias /phpmyadmin /usr/share/phpmyadmin

quindi, dopo aver chiuso e salvato il/i file di configurazione, basta far ripartire Apache per poter utilizzare PhpMyAdmin, la cui configurazione esula dagli scopi di questo articolo; in ogni caso, tenere presente che, se PhpMyAdmin è configurato con un livello di sicurezza ‘cookie’, nome utente e password richiesti per entrare in PhpMyAdmin, non sono altro che gli utenti definiti in MySQL, per cui, bisogna fare attenzione alle autorizzazioni che si assegnano ai vari database, onde evitare che certi utenti possano accedere a database non di loro competenza.

Link di riferimento
Gestione Moduli e Virtual Hosts di Apache2 su Debian e Ubuntu
HowTo: Configurazione dei Virtual Hosts (alias) con Apache2 su Debian ETCH

Uno dei possibili utilizzi dell’Asus eeepc (il nuovo subnotebook di Asus con schermo da 7"), è quello di avere un pratico gingillo da portare sempre con sé e da utilizzare, se necessario, per brevi operazioni di amministrazione su server Linux (tramite ssh) o su server Windows, connettendosi con rdesktop su quei server Windows Server 2003 su cui è abilitato Remote Desktop.

Rdesktop è un’utilità già presente sull’installazione predefinita dell’eeepc, che consente appunto di connettersi ad un qualsiasi computer Windows con attivo il servizio RDP; la particolarità di rdesktop presente su eeepc è che… non funziona. Per essere più precisi, rdesktop non ha alcun problema in sé, ma se lanciamo dal terminale il comando:

$ rdesktop -a 16 -f nomeserver

cercando di connetterci ad un server Windows Server 2003, ci viene presentata la schermata di login dove, se inseriamo nome utente e password, ci butta fuori dando un errore "segmentation fault" nella finestra del terminale.

La ragione di quest’errore, è che, per impostazione predefinita, X.org montato sull’eeepc funziona con una profondità di colore di 16 bit, per cui bisogna modificare quest’impostazione lanciando da terminale il comando:

$ sudo kwrite /etc/X11/xorg.conf

e andando a modificare il valore della voce "DefaultDepth", portandolo da 16 a 24. Salvare il file modificato, quindi riavviare X, ad esempio con la combinazione di tasti (brutale ma veloce) CTRL+ALT+BACKSPACE, e, da una finestra di terminale, dare di nuovo il comando:

$ rdesktop -a 16 -f nomeserver

quindi immettere nome utente e password, ed amministrare il proprio server Windows Server 2003 alla risoluzione di 800×480 pixel, non comodissima ma utilizzabile per periodi non troppo lunghi.