Aprire il database alla rete è decisamente poco sicuro, ma un tunnel SSH mi offre una alternativa leggera e affidabile. Per implementare il tutto ho usato:

Lato server:

• MySQL
• OpenSSH

Lato client:

• OpenSSH Client (Putty su Windows)
• Gnucash

Tutti questi software girano indifferentemente su piattaforme  Linux, Windows e Mac, il che offre un’ampia flessibilità. Per me che ho a casa un server Linux collegato alla rete il tutto è stato molto semplice, ma non escludo che anche un hosting non troppo costoso offra un supporto sufficiente per implementare il tutto.

Server

La configurazione del server SSH non richiede niente di particolare, se non assicurarsi che il firewall sia correttamente configurato per permettere l’accesso alla porta 22, o qualunque altra voi abbiate impostato. Se volete una sicurezza maggiore consiglio di usare un’autenticazione tramite chiavi, come descritto qui.

Il prossimo passo è creare il database e l’utente che dovrà utilizzarlo. Dato che creeremo un tunnel SSH è anche possibile usare phpMyAdmin da remoto come spiegato ad esempio qui, ma la procedura è così semplice che io decido di farlo da terminale. Dopo aver ottenuto l’accesso al server la sequenza è la seguente:

# mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 4012
Server version: 5.1.49-3 (Debian)

Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2 license

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> create database gnucash;
Query OK, 1 row affected (0.00 sec)

mysql> grant all on gnucash.* to gnucash@localhost identified by 'PASSWORD' with grant option;
Query OK, 0 rows affected (0.12 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.13 sec)

mysql> exit
Bye
#

Il che significa che, dopo aver ottenuto l’accesso come utente root a mysql creo il database gnucash e con il comando GRANT creo direttamente l’utente gnucash, gli assegno i permessi per l’uso del datatbase e imposto la PASSWORD di accesso. Nella documentazione di Gnucash non ho trovato nulla riguardo i permessi necessari all’utente per l’utilizzo del programma, quindi li assegno tutti, anche se probabilmente è possibile limitarli e migliorare la sicurezza dell’accesso.

Client

Prima di avviare Gnucash su un qualsiasi client è necessario creare il tunnel SSH, che si esegue abbastanza semplicemente su qualsiasi piattaforma.

OpenSSH Client (Linux e Mac)

Da un terminale si digita:

# ssh -L 3307:localhost:3306 -i /media/USB/private.key utente@miosito.com

l’opzione -i specifica la posizione della chiave privata per l’autenticazione, se necessaria, che io tengo nella chiavetta USB, mentre con l’opzione -L creo il tunnel fino al mio server che si trova in miosito.com, specificando tre parametri:

3307 è la porta locale a cui mi dovrò collegare per entrare nel tunnel

localhost è l’indirizzo dove è disponibile il server MySQL. Dato che il mio tunnel “esce” sulla stessa macchina l’indirizzo è localhost.

3306 è la porta alla quale collegarmi per accedere al server MySQL

Putty (Windows)

Nella finestra di configurazione di Putty inserisco i seguenti dati:

Session: inserisco l’host name, miosito.com, e la porta del server SSH, 22 o altro.

Connection->Data:  in Login details posso inserire il nome utente per il collegamento SSH, per evitare che mi venga chiesto ogni volta.

Connection->SSH->Auth: specifico la posizione del file contenente la private key per l’autenticazione, se necessaria.

Connection->SSH->Tunnels: in source port inserisco la porta locale di accesso, e in destination inserisco l’indirizzo del server MySQL e la porta di destinazione con la sintassi localhost:3306

Prima di aprire la connessione ho la possibilità, ritornando alla finestra Session, di salvare i parametri della sessione per poterli richiamare senza reinserirli nuovamente. Clicco su Open e dopo aver inserito la password il prompt del terminale mi indicherà che il tunnel è attivo.

Gnucash

Ora posso lanciare Gnucash e aprire un nuovo file indicando come formato dei dati mysql, come host la macchina da cui abbiamo aperto il tunnel e la porta di accesso, nel nostro caso 127.0.0.1:3307, il nome del database, gnucash, il nome dell’utente MySQL, gnucash, e la PASSWORD di accesso. Il programma crea in autmatico tutte le tabelle necessarie a seconda della struttura dei conti da noi indicata.

Come nome di host ho indicato l’indirizzo IP perchè su macchine Linux, per motivi che ignoro, se indico localhost:3307 mi viene restituito un errore e il collegamento abortisce. Su macchine Windows funzionano entrambe le sintassi.

Sono pronto ora per inserire i dati. Ogni volta che vorrò modificarli da qualsiasi posto mi trovi sarà sufficiente aprire il tunnel e da Gnucash aprire il file esistente inserendo gli stessi parametri sopra indicati.

Se utilizzate una chiave privata è sconsigliabile sparpagliarla su tutte le macchine dove lavorate, mentre è pratico e abbastanza sicuro tenerla su una chiavetta USB dove può trovare posto anche Putty, che non necessita di installazione e occupa pochissimo spazio.

Auguro un buon pareggio di bilancio a tutti

Sommario

• Postfixadmin
• Postfix: domini e mailbox virtuali
• Dovecot
• Dovecot LDA
• Horde
• Fetchmail e Gmail server relay

Postfixadmin

È giunto il momento di installare Postfixadmin, che permette di gestire domini virtuali, mailboxes e alias tramite una interfaccia web costruita in PHP. Postifxadmin è pacchettizzato in Debian Etch, quindi l’installazione dei file avviene con un semplice “apt-get install postfixadmin“.

L’operazione successiva è la creazione del database e dell’utente amministratore. È possibile farlo semplicemente con phpMyAdmin, oppure direttamente tramite il prompt di MySQL con i comandi:

CREATE DATABASE postfix;
CREATE USER 'postfix'@'localhost' IDENTIFIED BY 'choose_a_password';
GRANT ALL PRIVILEGES ON `postfix` . * TO 'postfix'@'localhost';

sostituendo gli opportuni valori, ed inserendo poi gli stessi valori nel file di configurazione /etc/postfixadmin/config.inc.php. Nello stesso file, oltre ai dati del database, è necessario cambiare il valore di $CONF['configured'] da false a true per poter inizializzare l’applicazione. Io preferisco avere le varie maidir degli utenti suddivise in directory separate per dominio, per cui imposto:

$CONF['domain_path'] = 'YES';

A questo punto imposto un VirtualHost sul server web che punti alla directory del programma, nel caso di Debian /usr/share/postfixadmin/, dirigo il browser su http://INDIRIZZO_DI_POSTFIXADMIN/setup.php e, dopo la creazione delle tabelle, mi appare una lista di ‘OK’ e il form per la creazione dell’utente amministratore. Lo inserisco e posso eseguire il login.

Postfixadmin offre all’utente la possibilità di impostare gli inoltri automatici dei messaggi e un autorisponditore (Vacation). Mentre il primo è già abilitato, per abilitare il secondo dobbiamo effettuare alcune modifiche.

Creo innanzitutto un utente ed un gruppo vacation, aggiungendo a /etc/passwd la riga:

vacation:*:65501:65501::0:0:Virtual Vacation:/nonexistent:/usr/sbin/nologin

ed a /etc/group la riga:

vacation:*:65501:

Quindi creo una directory di base per l’autorisponditore, vi copio il file vacation.pl, che in Debian si trova in /usr/share/doc/postfixadmin/VIRTUAL_VACATION/, e cambio i permessi di tutto:

# mkdir /var/spool/vacation
# cd /usr/share/doc/postfixadmin/VIRTUAL_VACATION/
# cp vacation.pl /var/spool/vacation/
# chown vacation:vacation -R /var/spool/vacation

Nel file vacation.pl devo inserire gli estremi del database modificando le righe:

my $db_type = 'mysql';
my $db_username = 'postfix';
my $db_password = 'password';
my $db_name     = 'postfix';

ed infine abilitare il modulo modificando nel file
/etc/postfixadmin/config.inc.php le righe:

$CONF['vacation'] = 'YES';
$CONF['vacation_domain'] = 'vacation.nomedominio';

Per far funzionare l’autorisponditore sono necessari tre moduli Perl. Due di questi li posso installare con:

apt-get install libemail-valid-perl libmail-sendmail-perl

mentre il terzo non è incluso nei repository di Debian Etch. È però possibile scaricare il pachetto dai repository di Debian Lenny (testing) ed installarlo senza incontrare problemi di dipendenze con:

# wget http://ftp.it.debian.org/debian/pool/main/libm/libmime-encwords-perl/libmime-encwords-perl_1.010.101-1_all.deb
# dpkg -i libmime-encwords-perl_1.010.101-1_all.deb

In ultimo dobbiamo definire il servizio vacation e fare in modo che i messaggi indirizzari al domino vacation.nomedominio vi siano girati. Per fare questo aggiungo al file /etc/postfix/master.cf le righe:

vacation    unix  -       n       n       -       -       pipe
  flags=Rq user=vacation argv=/var/spool/vacation/vacation.pl -f ${sender} -- ${recipient}

creo poi un file /etc/postfix/transport contenente la riga:

vacation.nomedominio        vacation:

compilo il database con:

#postmap /etc/postfix/transport

ed aggiungo a /etc/postfix/main.cf la riga:

transport_maps = hash:/etc/postfix/transport

Il tutto è ora pronto a funzionare, ma per utilizzarlo devo modificare la configurazione di Postfix.

Postfix: domini e mailbox virtuali

Per fare in modo che Postfix veda i domini virtuali creati da Postfixadmin devo aggiungere le seguenti righe in /etc/postfix/main.cf:

virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf
virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains_maps.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
virtual_mailbox_base = /home/mail
virtual_uid_maps = static:6000
virtual_gid_maps = static:6000

che indicano rispettivamente gli indirizzi delle mappe del database, l’indirizzo della directory dove verrannno create le mailbox virtuali, e l’utente e gruppo proprietari delle mailbox. L’utente e il gruppo devono esistere nel file /etc/passwd:

vmail:x:6000:6000::/home/mail:/bin/sh

e in /etc/group:

vmail:x:6000:

e devo creare la directory con i giusti permessi

# mkdir /home/mail
# chown vmail:vmail /home/mail

Le mappe sono file di testo composti come segue:

mysql_virtual_alias_maps.cf:

user = postfix
password = password
hosts = 127.0.0.1
dbname = postfix
table = alias
select_field = goto
where_field = address

mysql_virtual_domains_maps.cf:

user = postfix
password = password
hosts = 127.0.0.1
dbname = postfix
table = domain
select_field = description
where_field = domain

mysql_virtual_mailbox_maps.cf:

user = postfix
password = password
hosts = 127.0.0.1
dbname = postfix
table = mailbox
select_field = maildir
where_field = username

Ora sono pronto a inserire, tramite l’interfaccia di Postfixadmin, il mio primo dominio virtuale e i relativi alias e mailboxes. Dopo averlo riavviato Postfix è pronto a ricevere mail per gli account impostati. Posso testare il tutto in locale con telnet:

# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 nomemacchina.nomedominio ESMTP Postfix (Debian/GNU)

ehlo nomemacchina.nomedominio
250-nomemacchina.nomedominio
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

mail from:<jimmi@server.com>
250 2.1.0 Ok

rcpt to:<jimmi@nomedominio>
250 2.1.5 Ok

data
354 End data with <CR><LF>.<CR><LF>

prova mail
.
250 2.0.0 Ok: queued as 718BE15DF78

quit
221 2.0.0 Bye
Connection closed by foreign host.

Se tutto è a posto troverò la mail nell’Inbox dell’utente.

Dovecot

Passo ad occuparmi ora del server IMAP. Anche Dovecot è pacchettizato da Debian, e si installa con:

apt-get install dovecot-imapd dovecot-pop3d

È possibile attivare facilmente i server imap, imaps, pop3 e pop3s aggiungendo a /etc/dovecot/dovecot.conf:

protocols = imap imaps pop3 pop3s

ed eventualmente modificando le sezioni dedicate nello stesso file. Per fare in modo che Dovecot utilizzi le mailbox virtuali modifico seguenti righe di
/etc/dovecot/dovecot.conf:

mail_location = maildir:/home/mail/%d/%n
auth default {
mechanisms = plain login
passdb sql {
args = /etc/dovecot/dovecot-mysql.conf
}
userdb sql {
args = /etc/dovecot/dovecot-mysql.conf
}
user = postfix
client {
path = /var/spool/postfix/private/auth
mode = 0660
user = postfix
group = postfix
}
}

La sezione “client” serve per abilitare l’autenticazione SASL in postfix, che si attiva aggiungendo le seguenti righe in /etc/postfix/main.cf:

smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth

Per ottenere i dati dell’utente dal database aggiungo poi il file
/etc/dovecot/dovecot-mysql.conf:

driver = mysql
password_query = SELECT password FROM mailbox WHERE username = '%u'
user_query = SELECT maildir, 6000 AS uid, 6000 AS gid FROM mailbox WHERE username = '%u'
connect = host=127.0.0.1 port=3306 dbname=postfix user=postfix password=password default_pass_scheme = CRYPT

Al riavvio di Dovecot se tutto funziona posso leggere le seguenti righe nei log:

dovecot: 2008-07-13 19:40:42 Info: Dovecot v1.0.rc15 starting up
dovecot: 2008-07-13 19:40:43 Info: auth-worker(default): mysql: Connected to 127.0.0.1 (postfix)

Dovecot LDA

Dovecot fornisce anche un programma per la consegna dei messaggi agli utenti virtuali, chiamato Dovecot Local Delivery Agent, che può sostituire virtual fornito dal Postfix, con alcune funzionalità aggiuntive, come l’indicizzazione delle mailbox, l’utilizzo di quote utente e di Sieve tramite appositi plugin. Per abilitarlo devo aggiungere al file /etc/dovecot/dovecot.conf le righe:

protocol lda {
..
  # UNIX socket path to master authentication server to find users.
  #auth_socket_path = /var/run/dovecot/auth-master
}
auth default {
..
  socket listen {
    # Note that we're setting a master socket. SMTP AUTH for Postfix uses client sockets.
    master {
      path = /var/run/dovecot/auth-master
      # Auth master socket can be used to look up userdb information for
      # given usernames. This probably isn't very sensitive information
      # for most systems, but still try to restrict the socket access if possible.
      mode = 0600
      user = vmail # User running deliver
      group = vmail # Or alternatively mode 0660 + deliver user in this group
    }
  }
..
}

Posso ora aggiungere il servizio in Postfix, aggiungendo a
/etc/postfix/master.cf:

dovecot   unix  -       n       n       -       -       pipe
    flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${recipient}

e indicargli di utilizzarlo inserendo in /etc/postfix/main.cf le righe:

virtual_transport = dovecot
dovecot_destination_recipient_limit = 1

Con queste impostazioni deliver, che funziona da utente non privilegiato, genera un errore. Per evitarlo nella mailing list di Dovecot consigliano di impostare deliver a SUID con il comando:

# chmod u+s /usr/lib/dovecot/deliver

Riavvio Dovecot e Postfix, e alla prima ricezione posso trovare nei log qualcosa di simile a questo:

server postfix/pipe[23496]: 23FD715DF87: to=<utente@nomedominio>, relay=dovecot, delay=0.4, delays=0.07/0.02/0/0.31, dsn=2.0.0, status=sent (delivered via dovecot service)

Horde

Manca ora l’ultimo pezzo, l’interfaccia web per gli utenti tramite Horde, un framework con numerosi moduli in PHP. Anche questa applicazione è pacchettizzata da Debian, e l’installazione è banale se si seguono le indicazioni del Wiki.

Installo per primo il framework con:

# apt-get install horde3

abilito un VirtualHost che punti alla sua directory, aggiungendo ad esempio in /etc/apache2/sites-available/default:

Alias /horde3 /usr/share/horde3
Options FollowSymLinks
AllowOverride Limit
deny from all
allow from TUO_IP

che mi permetterà di accedere localmente, e inizializzo il database. Quest’ultima operazione può avvenire da riga di comando con:

#gunzip < /usr/share/doc/horde3/examples/scripts/sql/create.mysql.sql.gz | mysql -u MYSQL_ADMIN -p

Avendo cura di modificare in create.mysql.sql.gz i dati di accesso dell’amministratore di Horde. Fatto ciò puntando il browser su http://nomemacchina.nomedominio/horde3 compare la maschera iniziale di Horde. Per il debug di eventuali problemi posso puntare il browser su: http://nomemacchina.nomedominio/horde3/test.php

La configurazione di Horde3 avviene creando nelle directory sotto /etc/horde/horde3 i file config.php e config.php.bak con maschera dei permessi 777, configurando poi tramite intefaccia web le opzioni nella maschera in Amministrazione-->Impostazione-->Horde, salvando e riportando i permessi dei due file a 644 e 700 rispettivamente.

Per un corretto funzionamento è indispensabile impostare correttamente i parametri nelle maschere Database, Authentication e Preference System

Horde mette a disposizione, tra gli altri, i seguenti moduli:

• IMP – Cliente Webmail
• Ingo – Filtro per le mail
• Turba – Gestione rubrica
• Kronolith – Calendario
• Nag – Gestione attività
• Mnemo – Gestione note
• Passwd – Gestione password
• MIMP – Interfaccia per dispositivi mobili

Tutti questi moduli sono presenti nei repository Debian ad eccezione di MIMP, che può essere facilmente installato per Debian con le seguenti operazioni:

# wget http://ftp.horde.org/pub/mimp/mimp-h3-1.1.tar.gz
# tar -xvzf mimp-h3-1.1.tar.gz
# mv mimp-h3-1.1/config /etc/horde/mimp
# mv mimp-h3-1.1 /usr/share/horde3/mimp
# cd /usr/share/horde3/mimp
# ln -s /etc/horde/mimp config

La configurazione dei vari moduli avviene, analogalmente a quella del framework, in tre operazioni:

• Creo nelle directory sotto /etc/horde/[nomemodulo] i file config.php e config.php.bak con maschera dei permessi 777
• Configuro e salvo tramite intefaccia web le opzioni nella maschera in Amministrazione-->Impostazione-->[nomemodulo]
• Cambio i permessi dei due file a 644 e 700 rispettivamente.

Ovviamente le operazioni dovranno essere ripetute per ogni modulo.

Oltre alle impostazioni più banali possono essere importanti le seguenti impostazioni per i vari moduli:

Horde

Maschera General:

- Determines how we generate full URLs (for location headers and such)

Assume that we are using SSL and always generate https URLs

- What port number is the webserver running on?

443

Questo mi serve perchè la mia webmail è disponibile su una connessione criptata https

Maschera Authentication:

- What backend should we use for authenticating users to Horde?

Let a Horde application handle authentication

- The application which is providing authentication

imp

Queste due scelte permettono di autenticarsi con le credenziali create in Postfixadmin ed effettualre il Login una sola volta anzichè dover inserire due volte i dati per leggere la posta. In questo caso è importante creare un utente amministratore e inserire il suo nome nella prima casella.

IMP

Modifico il file /etc/horde/imp4/servers.php inserendo i dati del o dei server mail. Nel file originale sono contenuti diversi esempi, ricordatevi di commentare o cancellare quelli non necessari.

Nel file /etc/horde/imp4/mime_drivers.php modifico la linea:

$mime_drivers['imp']['html']['inline'] = true;

Questo mi permette di vedere in linea le mail composte in HTML, anche se non meriterebbero È una scelta giustamente sconsigliata, ma altrimenti le mail HTML vengono formattate in modo impossibile da leggere.

Ingo

Nel file /etc/horde/ingo1/backends.php specifico quale backend utilizzare per i filtri. Le scelte possibili sono null (applica le regole su richiesta), o regole per Maildrop, Procmail o Sieve. La scelta più semplice è:

/* IMAP Example */
$backends['imap'] = array(
    'driver' => 'null',
    'preferred' => 'example.com',
    'hordeauth' => true,
    'params' => array(),
    'script' => 'imap',
    'scriptparams' => array()
);

Anche in questo caso le altre scelte vanno commentate o cancellate.

Turba

Nel file /etc/horde/turba2/sources.php specifico quale backend utilizzare. Per utilizzare MySQL la configurazione tipica è:

$cfgSources['localsql'] = array(
    'title' => _("My Address Book"),
    'type' => 'sql',
    'params' => array_merge($conf['sql'], array('table' => 'turba_objects')),
    'map' => array(
        '__key' => 'object_id',
        '__owner' => 'owner_id',
        '__type' => 'object_type',
        '__members' => 'object_members',
        '__uid' => 'object_uid',
        'name' => 'object_name',
        'email' => 'object_email',
        'alias' => 'object_alias',
        'homeAddress' => 'object_homeaddress',
        'workAddress' => 'object_workaddress',
        'homePhone' => 'object_homephone',
        'workPhone' => 'object_workphone',
        'cellPhone' => 'object_cellphone',
        'fax' => 'object_fax',
        'title' => 'object_title',
        'company' => 'object_company',
        'notes' => 'object_notes',
        'pgpPublicKey' => 'object_pgppublickey',
        'smimePublicKey' => 'object_smimepublickey',
        'freebusyUrl' => 'object_freebusyurl'
    ),
    'search' => array(
        'alias',
        'email'
    ),
    'strict' => array(
        'object_id',
        'owner_id',
        'object_type',
    ),
    'export' => true,
    'browse' => true,
    'use_shares' => true,
);

ed è inoltre necessario creare la tabella in MySQL, utilizzando il comando:

# mysql -u MYSQL_ADMIN -p DATABASE < /usr/share/doc/turba2/examples/scripts/sql/turba_objects.mysql.sql

Kronolith

Se si sceglie il driver SQL è necessario creare la tabella con il comando:

# mysql -u MYSQL_ADMIN -p DATABASE < /usr/share/doc/kronolith2/examples/scripts/sql/kronolith.mysql.sql

Nag

Se si sceglie il driver SQL è necessario creare la tabella con il comando:

# mysql -u MYSQL_ADMIN -p DATABASE < /usr/share/doc/nag2/examples/scripts/sql/nag.sql

Passwd
Nel file /etc/horde/passwd3/backends.php ho modificato le linee:

driver' => 'sql',
'params' => array(
'phptype'    => 'mysql',
'hostspec' => '127.0.0.1',
'port' => '3306',
'protocol' => 'tcp',
'username'   => 'postfix',
'password'   => 'password',
'encryption' => 'crypt-md5',
'database'   => 'postfix',
'table'      => 'mailbox',
'user_col'   => 'username',
'pass_col'   => 'password',
'show_encryption' => false)

Per poter modificare la password nel database creato da Postfixadmin.

Fetchmail e Gmail server relay

Vi sono altri due add-ons non strettamente collegati alla configurazione di un server mail ma molto utili specialmente per server fatti in casa.

Fetchmail

È un ottimo programma per ritirare mail da server POP3 o IMAP e consegnarla al server locale. Sia Postfixadmin che Horde hanno dei plugin che gestiscono fetchmail in modi leggermente diversi. Con Horde l’utente inserisce i dettagli del server remoto e scarica la posta mentre è collegato, mentre con Postfixadmin in base ai dati inseriti dall’amministratore nel database vengono creati dei file ~/.fetchmailrc al volo che possono essere usati inserendo in crontab lo script fetchmail.pl.

Purtroppo entrambi hanno due limitazioni che me ne impediscono l’utilizzo: non implementano Freepops e non permettono l’uso di autenticazioni SSL. Freepops è un programmino che permette di scaricare le mail diretamente dalla webmail, aggirando la limitazione all’uso del server POP per gli abbonamenti free adottato, ad esempio, da Libero e Inwind. L’uso del protocollo SSL è indispensabile invece per scaricare mail dai server di Gmail o Autistici/Inventati.

La versione di Fetchmail pacchettizzata da Debian ci permette di avviare il programma in modalità demone con il tipico script /etc/init.t/fetchmail. Il pacchetto di Freepops purtroppo fa riferimento ad una versione troppo datata e non più funzionante, e bisogna quindi installare la versione offerta dai Backports. Una volta installati entrambi avremo il demone freepopsd in ascolto alla porta 2000 (di default), e possiamo modificare il file /etc/fetchmailrc aggiungendo le sezioni relative ai vari server. Alcuni utilizzi tipici sono:

Server POP3

poll SERVER_POP with proto pop3 auth password
user "NOMEUTENTE.REMOTO" there
with password "password"
is NOMEUTENTE.LOCALE here options fetchall

Server che richiedono Freepops

poll SERVER_POP with proto pop3 port 2000
user "NOMEUTENTE.REMOTO" there
with password "password"
is NOMEUTENTE.LOCALE here options fetchall

Server Gmail

poll SERVER_POP with proto pop3 port 995
user "NOMEUTENTE.REMOTO" there
with password "password"
is NOMEUTENTE.LOCALE here options ssl sslcertck fetchall

Gmail Server Relay

Normalmente le mail spedite da un server casalingo con IP dinamico vengono rifiutate per motivi di sicurezza, e si è quindi costretti ad usare un server che vi faccia da relay, che vi permetta cioè di spedire mail attraverso il suo servizio. Vi dovesse capitare di non avere a disposizione un relay, o di volerne utilizzare uno alternativo, potete usufruire del servizio offerto da Gmail, il quale però richiede un’autenticazione sicura via SSL. Per implementarla aggiungo o modifico le seguenti righe di /etc/postfix/main.cf:

smtpd_tls_CAfile = /etc/postfix/cacert.pem
smtpd_tls_cert_file=/etc/postfix/gmail.pem
smtpd_tls_key_file=/etc/postfix/gmail.key
smtpd_sasl_application_name = smtpd
smtp_tls_per_site = hash:/etc/postfix/smtp_tls_per_site
smtp_use_tls=yes
smtp_tls_CAfile = /etc/postfix/cacert.pem
smtp_tls_cert_file=/etc/postfix/gmail.pem
smtp_tls_key_file=/etc/postfix/gmail.key
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
relayhost = [smtp.gmail.com]:587

creo il file /etc/postfix/sasl_passwd, vi aggiungo le righe:

# Contents of sasl_passwd
#
[smtp.gmail.com]              NOMEUTENTE@gmail.com:PASSWORD

e lo compilo con:

# postmap /etc/postfix/sasl_passwd

Infine, se non li possiedo già, creo il mio certificato auto firmato con i seguenti passaggi:

# /usr/local/ssl/misc/CA.pl -newca
  CA certificate filename (or enter to create)
   Making CA certificate ...
  Generating a 1024 bit RSA private key
  .......++++++
  ...................++++++
  writing new private key to './demoCA/private/cakey.pem'
  Enter PEM pass phrase: password
  Verifying - Enter PEM pass phrase: password
  -----
  You are about to be asked to enter information that will be incorporated
  into your certificate request.
  What you are about to enter is what is called a Distinguished Name or a DN.
  There are quite a few fields but you can leave some blank
  For some fields there will be a default value,
  If you enter '.', the field will be left blank.
  -----
  Country Name (2 letter code) [US]:IT
  State or Province Name (full name) [Pennsylvania]:Italia
  Locality Name (eg, city) []:Bergamo
  Organization Name (eg, company) [Internet Widgits Pty Ltd]:Casa
  Organizational Unit Name (eg, section) []:Server
  Common Name (eg, YOUR name) []:nomemacchina.nomedominio
  Email Address []:mioindirizzoposta
  Please enter the following 'extra' attributes
  to be sent with your certificate request
  A challenge password []:
  An optional company name []:
  Using configuration from /usr/lib/ssl/openssl.cnf
  Enter pass phrase for ./demoCA/private/cakey.pem:password
  ...
  # openssl req -new -nodes -subj '/CN=nomemacchina.nomedominio/O=Casa/C=IT/ST=Italia/L=Bergamo/emailAddress=mioindirizzoposta' -keyout gmail.key -out gmail.req -days 3650
  # openssl ca -out gmail.pem -infiles gmail.req
  Using configuration from /usr/lib/ssl/openssl.cnf
  Enter pass phrase for ./demoCA/private/cakey.pem:password
  ...

Al riavvio di Postfix dovrei poter inviare messaggi tramite Gmail, che risulterà dai log con un messaggio di questo tipo:

Jul 25 11:36:52 server postfix/smtp[28745]: 8C31415DF79: to=<pippo@pippo.com>, relay=smtp.gmail.com[64.233.183.109]:587, delay=6.5, delays=0.0 5/0.05/3.8/2.7, dsn=2.0.0, status=sent (250 2.0.0 OK 1216978613 i4sm31861110nfh.1)

Questo documento, scritto a quattro mani con Manuel, spiega come configurare un server di posta in modo da avere nel proprio sistema utenti, sia reali sia virtuali, che possono accedere tramite interfaccia web alle loro caselle e-mail, con protezione da virus, worm e spam.

Sommario

• Introduzione
• Postfix: configurazione di base
• Amavisd-new, Spamassassin, ClamAV
• Postgrey
• Postfix e i suoi controlli anti-UCE

Introduzione

Per utente virtuale si intende qualcuno che non ha un account fisico sulla macchina (non c’è alcun suo riferimento nel file /etc/passwd) ed esiste solo per il sistema di posta. La gestione di questi utente avviene tramite interfaccia web e i loro dati sono registrati su un database SQL.

I mezzi scelti per conseguire lo scopo sono:

• Postfix 2.3.8
  
• Amavisd-new 2.4.2
• Clamav 0.93.1
• Spamassassin 3.2.3
• Postgrey 1.27
• Postfixadmin 2.2.0
• Dovecot 1.0
  
• Horde 3.1.3
  
• Fetchmail 6.3.6
  

Per questa installazione ho inoltre utilizzato:

• Apache 2.2.3
• MySQL 5.0.32
• PHP 4.4.4

la cui configurazione va però oltre gli scopi di questo howto. Tutti questi software sono stati installati partendo dai pacchetti offerti dalla distribuzione Debian Etch. Le principali fonti di ispirazione sono stati un howto precedentemente scritto da Manuel, Howtoforge, i wiki di Dovecot, Horde, Debian e Debian Administration.

Postfix: configurazione di base

Prima di procedere all’installazione di Postfix occorre assicurarsi che la propria macchina sia FQDN, cioè abbia un nome corretto (per intenderci, al comando hostname deve rispondere qualsiasi cosa che non sia localhost o localhost.localdomain). Per questo occorre impostare il nome macchina e settare il file /etc/hosts correttamente.

I principali file di configurazione sono due: main.cf in cui stanno tutti i parametri della parte MTA e master.cf in cui stanno i parametri del demone, ed entrambi si trovano in /etc/postfix.

Il main.cf ha moltissime opzioni (potete trovare qui un elenco completo); vediamo le più importanti (che vanno modificate rispetto al default):

# questa sezione riguarda le mail 'rimbalzate' :
# si specifica cosa notificare e a quale account

soft_bounce = no
notify_classes = resource, software, bounce, policy, protocol
2bounce_notice_recipient = postmaster

myhostname = nomemacchina.nomedominio
mydomain = nomedominio

# qui si dice a postfix da quali interfacce
# accettare posta

inet_interfaces = all

# myorigin è il dominio che viene aggiunto alle mail inviate
# dagli utenti locali, mentre mydestination è l'elenco dei
# domini che postfix identifica come locali. NON vanno
# elencati qui i domini virtuali.

myorigin = $myhostname
mydestination = $myhostname

# mynetworks è importantissimo: si deve settare in maniera
# corretta altrimenti si può diventare degli open-relay: in
# questa situazione chiunque da internet può usare il nostro
# postfix per inviare posta e si rischia la blacklist
# (e quindi essere di fatto tagliati fuori in partenza)
# un buon test di open-relay sul proprio MTA è questo:
# $telnet relay-test.mail-abuse.org

mynetworks = 127.0.0.0/8, ip.della.rete
relay_domains = $mydestination

# qui abbiamo indicato alcune 'mappe' necessarie per il
# funzionamento dell' MTA. Si noti che hash: indica che
# quella mappa deve essere messa sotto forma di
# database Berkeley (vedremo poi come).

alias_maps = hash:/etc/postfix/aliases
alias_database = hash:/etc/postfix/aliases
sender_canonical_maps = hash:/etc/postfix/sender_canonical

per ora il master.cf non va toccato.

Sono da controllare anche il file aliases e il sender_canonical.

Nel file aliases ci sono i riferimenti ai vari utenti e serve per decidere chi è il destinatario delle mail: va modificato specificando a chi va recapitata la posta di root, solitamente l’utente di ‘manutenzione’ che utilizzate nel vostro sistema (non usate root per queste cose, vero?). Ad ogni modifica del file aliases deve seguire il comando:

# postalias /etc/postfix/aliases

per aggiornare il database aliases, che viene scritto nel file aliases.db.

Attenzione perché può esistere anche un file /etc/aliases: è quello che utilizza sendmail, e per il nostro sistema di posta non serve (ogni modifica a quel file risulta ininfluente).

Il sender_canonical invece serve per tradurre gli account degli utenti locali in indirizzi di posta elettronica. Una volta modificato occorre dare:

# postmap /etc/postfix/sender_canonical

se tutto è ok si può far partire postfix e testarlo con:

# telnet 127.0.0.1 25
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
220  ESMTP Postfix

Amavisd-new, Spamassassin, ClamAV

La configurazione che ho effettuato fino ad ora è sufficiente per un valido, robusto e sicuro sistema di posta. Purtroppo però si sente sempre più l’esigenza di proteggere da virus e spam gli utenti: in prima battuta non ci si pensa, ma se un nostro cliente ha un virus che invia mail a raffica la cosa si ripercuote anche su di noi, sovraccaricando il nostro MTA e rischiando di farlo finire in qualche black-list da cui è poi difficile uscire…

Amavisd-new è una delle versioni demone di amavis-perl; gli aspetti più interessanti sono:
- un’ottima integrazione con postfix
- può utilizzare diversi software antivirus (anche più di uno sulla stessa macchina)
- può invocare direttamente spamd (il demone di spamassassin) e

Sia Spamassassin che ClamAV devono essere costantemente aggiornati per essere efficaci, cosa che non è sempre garantita con i repository di Debian. Per questa ragione è consigliabile scaricarli dai repository di volatile, aggiungendo a /etc/apt/sources.list la riga:

deb http://ftp2.de.debian.org/debian-volatile sarge/volatile main

per installare il tutto eseguo da riga di comando:

# apt-get update
# apt-get install amavisd-new spamassassin clamav clamav-daemon clamav-freshclam zoo unzip bzip2 unzoo nomarch lzop pax

Passo quindi alla configurazione. È necessario abilitare ClamAV e Spamassassin in /etc/amavis/conf.d/15-content_filter_mode, che dovrà avere questo aspetto:

use strict;

# You can modify this file to re-enable SPAM checking
# through spamassassin and to re-enable antivirus checking.

#
# Default antivirus checking mode
# Uncomment the two lines below to enable it back
#

@bypass_virus_checks_maps = (
   \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re);

#
# Default SPAM checking mode
# Uncomment the two lines below to enable it back
#

@bypass_spam_checks_maps = (
   \%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);
1;  # ensure a defined return

ed è consigliabile aggiungere la riga

$pax='pax';

nel file /etc/amavis/conf.d/50-user. Normalmente le impostazioni di default contenute in /etc/amavis/conf.d/20-debian_defaults non devono essere modificate. Riavvio i demoni con:

/etc/init.d/amavis restart
/etc/init.d/clamav-daemon restart
/etc/init.d/clamav-freshclam restart

e posso proseguire nella configurazione di Postfix. Per fare in modo che le mail vengano inoltrate al demone di amavisd-new aggiungo le seguenti righe a /etc/postfix/main.cf:

content_filter = amavis:[127.0.0.1]:10024
receive_override_options = no_address_mappings

e poi aggiungo le seguenti in /etc/postfix/master.cf:

amavis unix - - - - 2 smtp
        -o smtp_data_done_timeout=1200
        -o smtp_send_xforward_command=yes

127.0.0.1:10025 inet n - - - - smtpd
        -o content_filter=
        -o local_recipient_maps=
        -o relay_recipient_maps=
        -o smtpd_restriction_classes=
        -o smtpd_client_restrictions=
        -o smtpd_helo_restrictions=
        -o smtpd_sender_restrictions=
        -o smtpd_recipient_restrictions=permit_mynetworks,reject
        -o mynetworks=127.0.0.0/8
        -o strict_rfc821_envelopes=yes
        -o receive_override_options=\
        no_unknown_recipient_checks,no_header_body_checks
        -o smtpd_bind_address=127.0.0.1

Faccio ripartire postfix e con “netstat -tap” vedo Postfix (master) in ascolto sulle porte 25 (smtp) e 10025 e amavisd-new sulla porta 10024. Dopo aver spedito o ricevuto alcune e-mail posso verificare il funzionamento di tutto nei log.

ClamAV non ha solitamente bisogno di alcuna impostazione particolare. Il demone freshclam provvederà a tenere sempre aggiornato il database dei virus. Debian durante l’installazione crea già gli utenti e i gruppi necessari. Sarà sufficiente aggiungere l’utente clamav al gruppo amavis e riavviare i demoni con i comandi:

# adduser clamav amavis
# /etc/init.d/amavis restart
# /etc/init.d/clamav-daemon restart
# /etc/init.d/clamav-freshclam restart

Spamassassin è un software scritto in Perl in grado di identificare e bloccare la posta indesiderata (chiamata spam, UCE – unsollicited commercial e-mail oppure anche UBE – unsollicited bulk e-mail) con una buona accuratezza tramite una serie di test euristici sugli headers e sul corpo della mail.

Come impostazioni di base, è richiesto a Spamassassin di raggiungere un punteggio pari a 6.3 per identificare la mail come spam; io ho abbassato la soglia fino a 5 impostando in /etc/spamassassin/local.cf:

required_score           5.0

e fino ad ora non mi è mai capitato che abbia bloccato una mail che non fosse spam, ed ha lasciato passare alcune e-mail che invece lo erano. Ovviamente non si può garantire un’ accuratezza del 100% perché si rischierebbe di stringere troppo i controlli ed avere troppi falsi positivi.

A questo punto per Debian modifico il file /etc/default/spamassassin con:

ENABLED=1

Ed avvio il demone:

# /etc/init.d/spamassassin start

Una delle caratteristiche più utili di Spamassassin sono i filtri “bayesiani” che filtrano le mail sulla base di sequenze di caratteri che compaiono spesso nello spam, e che vengono abilitati in /etc/spamassassin/local.cf dalle righe:

# Enable the Bayes system
use_bayes               1

bayes_path /var/lib/amavis/.spamassassin/bayes

# Enable Bayes auto-learning
bayes_auto_learn              1

la seconda riga dice dove si trova il database, l’indirizzo è quello della configurazione standard di Debian, e l’ultima attiva l’autoapprendimento, che inizierà al riavvio Spamassassin. Per fargli apprendere più velocemente è possibile dargli in pasto delle directory contenenti spam o mail “pulite”, loggandosi come utente amavis e dando i comandi:

sa-learn --spam -C /var/lib/amavis/.spamassassin/ --showdots [directorySPAM]
sa-learn --ham -C /var/lib/amavis/.spamassassin/ --showdots [directoryHAM]

Per tenere le regole sempre aggiornate posso scaricare periodicamente i file configurazione (rules, scores, etc.) inserendo in crontab una riga tipo:

0 4 * * * sa-update && /etc/init.d/spamd restart

È anche possibile aggiungere a Spamassassin moduli come Razor2, Pyzor, DCC, ma questo va un poco oltre lo scopo di questo howto, quindi vi rimando alla documentazione specifica.

Postgrey

I filtri tipo greylist sono uno dei recenti metodi di lotta allo SPAM, e si basano sul fatto che la maggior parte degli spammer inviano i messaggi attraverso server che non gestiscono una coda per la ritrasmissione dei messaggi falliti. Quando una mail viene ricevuta per la prima volta viene registrata la tripletta server/mittente/destinatario e viene respinta con un messaggio 450 di errore temporaneo. I server di cui sopra non riproveranno, mentre un server regolare dovrebbe riprovare l’invio dopo qualche minuto, quando il nostro server, dopo aver verificato la tripletta, lo accetterà. Questo provoca un ritardo nella ricezione di tutte le e-mail, ma evita la ricezione di gran parte dello spam.

Debian mette a disposizione Posgrey, che implementa una greylist in Postfix. L’installazione si esegue come sempre con:

# apt-get install postgrey

dopo l’installazione trovo il demone in ascolto sulla porta 60000, come posso verificare con:

# netstat -anp | grep 60000
tcp        0      0 127.0.0.1:60000         0.0.0.0:*               LISTEN     18478/postgrey.pid

Per fare in modo che Postfix usi il demone devo aggiungere la seguente riga in /etc/postfix/main.cf, tra le “smtpd_recipient_restrictions”:

check_policy_service inet:127.0.0.1:60000

Controllando il log posso vedere il tutto funzionare alla prima ricezione

Postfix e i suoi controlli anti-UCE

Postfix prevede la possibilità di effettuare un certo numero di test sulle mail in transito: è possibile controllare gli headers e il corpo del messaggio, mittenti e i destinatari, parti mime ed allegati. Lo svantaggio è che tutto questo causa un forte appesantimento del sistema di posta, e l’accuratezza non è molto elevata (c’è il rischio di avere molti falsi positivi e falsi negativi).

Nel main.cf possiamo specificare questi controlli (che sono una piccola parte rispetto a quelli disponibili):

# vengono specificate le tavole con cui confrontare le mail
# in transito. Se sul vostro sistema è installato pcre è
# consigliabile utilizzare questo al posto delle regexp per
# questioni di velocità.
#header_checks = regexp:/etc/postfix/header_checks
#body_checks = regexp:/etc/postfix/body_checks
header_checks = pcre:/etc/postfix/header_checks
body_checks = pcre:/etc/postfix/body_checks

# si controlla la parte mime degli headers del messaggio
#mime_header_checks = regexp:/etc/postfix/mime_header_checks
mime_header_checks = pcre:/etc/postfix/mime_header_checks

# si richiede che chi si collega al nostro server smtp
# invii un helo/ehlo (alcuni spammer non lo fanno...)
smtpd_helo_required = yes

# il controllo lo si può fare sul mittente, sul destinatario
# o sul recipient (che è l'ultimo ad essere specificato
# nella mail) è preferibile fare il controllo sul recipient e
# non sul sender per poter avere il maggior numero di
# informazioni sulla mail che viene bloccata e’ anche
# possibile inserire, tra i vari server che mantengono le
# black-list, la riga reject_rbl_client dnsbl.sorbs.net,
# Il problema e’ che in questo database sono elencati
# alcuni server smtp italiani molto usati, tra i quali quello
# di libero ed alcuni di telecom italia...
#smtpd_client_restrictions =
#smtpd_sender_restrictions =
smtpd_recipient_restrictions =  permit_mynetworks,
                                check_sender_access hash:/etc/postfix/access,
                                check_recipient_access hash:/etc/postfix/access,
                                check_client_access hash:/etc/postfix/access,
                                reject_invalid_hostname,
                                reject_non_fqdn_sender,
                                reject_unknown_sender_domain,
                                reject_unauth_destination,
                                reject_rhsbl_client blackhole.securitysage.com,
                                reject_rhsbl_sender blackhole.securitysage.com,
                                reject_rbl_client bl.spamcop.net,
                                reject_rbl_client l1.spews.dnsbl.sorbs.net,
                                reject_rbl_client dul.spews.dnsbl.sorbs.net,
                                reject_rbl_client sbl-xbl.spamhaus.org,
                                reject_rbl_client combined.njabl.org

# non è esattamente un controllo anti-UCE, ma se ci sono
# utenti non più attivi che ricevono e-mail valide può essere
# utile avvisare il mittente che l’indirizzo non è più
# valido, ed eventualmente comunicare il nuovo indirizzo.
relocated_maps = hash:/etc/postfix/relocated

Vediamo più da vicino queste mappe (e come si compilano): alcune sono di tipo hash ed altre di tipo pcre (o regexp). Per quelle di tipo hash occorre dare il comando postmap prima di riavviare postfix per aggiornare il database, mentre per le altre basta solamente riavviare il demone postfix.

/etc/postfix/body_checks (pcre o regexp)

la forma in cui devono essere messe le regole è:

/pattern/      AZIONE	MOTIVAZIONE

Tra pattern, azione e motivazione ci deve essere almeno uno spazio; per questioni di chiarezza visiva mi piace impaginare il file utilizzando vari [tab] in maniera da avere tutto incolonnato.

Un esempio di body_checks è:

# il testo che vogliamo intercettare va messo tra / /, e può
# contenere spazi. La clausola REJECT indica il rifiuto del
# messaggio (ce ne sono altre: OK, WARN, ecc..)
# [A10] è un codice univoco che utilizzo io per capire quale
# testo ha causato il rifiuto del messaggio (utile ad
# esempio per testare le regole) il mittente riceverà in
# questo caso un messaggio di bounce con la motivazione:
# [A10] Your email had spam-like body contents.
# Si può leggere il file sample-pcre-body.cf.

/sono spammer/ 	REJECT [A10] Your email had spam-like body contents.

si può anche andare sul complicato utilizzando le espressioni regolari:

# così io impedisco il recapito di mail con allegati dei file aventi
# estensioni che fanno supporre  la presenza di virus; come visto
# prima si può mettere un testo dopo il reject che spiega la
# motivazione e suggerisce di zippare l'allegato per poterlo inviare.

/name=".*\.(com|exe|bat|cmd)"/            REJECT [1] Filetype not permitted, please ZIP them
/name=".*\.(hta|vb[esx]|wsf|wsh|js|jse)"/ REJECT [2] Filetype not permitted, please ZIP them
/name=".*\.(shb|shs|lnk|chm|pif|scr)"/    REJECT [3] Possible virus attachment
/^TVqQAAMAAAAEAAAA\/\/8AALgAAAAAAAAAQAAA/ REJECT [4] Possible virus attachment

/etc/postfix/header_checks (pcre o regexp)

la forma è la medesima di body_ckecks, ma in questo caso dobbiamo specificare gli headers:

# si lavora ad esempio sul programma con cui è stata creata
# la mail, sul soggetto, ma ci si può sbizzarrire...

/^X-Mailer: Floodgate/  REJECT [A19] Spam-like header contents.
/^Subject: .*Super Viagra/  	REJECT [B09] Spam-like Subject.

# possiamo anche bloccare mittenti e destinatari, in modo molto
# similare a quel che fa /etc/postfix/access
# per maggiori informazioni si veda il file sample-pcre-header.cf

/^From:.*utente@dominio*$/      	REJECT This account sends spam.
/^To:.*utente@dominio.locale*$/ 	REJECT This account isn't active.

/etc/postfix/mime_header_checks (pcre o regexp)

è una tavola specifica per le estensioni mime, che possono sfuggire ai controlli sul body e sugli headers; la sintassi è del tutto simile ai due file precedenti.
Io utilizzo clausole molto simili a questa:

# blocco i file .pif (e allo stesso modo qualsiasi file con
# estensione pericolosa).

/name=[^>]*\.pif/ 			REJECT Files .pif may contain viruses.

/etc/postfix/access (hash)

Come detto, serve specificamente per intercettare mittenti o destinatari indesiderati.
La sintassi prevede 3 categorie su cui effettuare i confronti: un utente ben determinato, un certo utente di qualsiasi dominio o tutti gli utenti di un certo dominio.

Ad esempio:

# occorre specificare il codice e la risposta che postfix restituisce
# al mittente. Nei primi due casi andiamo in match su indirizzi e-mail
# completi nel terzo esempio il confronto lo si fa sull’utente e nel
# quarto sul dominio per altre informazioni man 5 access
# oppure sample-pcre-access.cf

utente1@dominio1  			550 You are a spammer!
pippo@dominio2				550 This account is no longer active
utente@      				550 Your email comes from a blacklisted address
dominio      				550 Your email comes from a blacklisted domain

Il file access e’ anche importante per effettuare delle whitelist sugli indirizzi da accettare, anche se provengono da utenti, domini o indirizzi IP elencati in qualche black-list.

In particolare dobbiamo, nel rispetto delle RFC, accettare qualsiasi cosa indirizzato alla casella postmaster ed eventualmente alla abuse.

Quindi inseriamo:

postmaster@nomedominio		OK
abuse@nomedominio		OK

Se qualche nostro utente vuole ricevere posta da utenti in BL, possiamo elencare qui i mittenti specifici o l’intero dominio di appartenenza:

utente@dominioinbl		OK
dominioinbl			OK

Continua…

Ecco i pdf delle presentazioni:

Le distribuzioni Linux (di Marco Salvi)

Linux dalle origini allo spazio (di Antonio Milesi)

Networking sicuro (di Marco Balduzzi)

Wikipedia e Mediawiki: il progetto e la piattaforma (di Ermanno Novali)

Alla scoperta delle Espressioni Regolari (di Flavio Castelli)

Ecco cosa potete scaricare:

Sicurezze e False Sicurezze – Un confronto aperto tra modelli “free” e “proprietari” (di Stefano Zanero)

Introduzione alla programmazione in ambiente GNU/Linux con particolare riferimento al linguaggio C (di Marco Balduzzi)

La crittografia al servizio di Linux, conservare in maniera sicura i propri dati (di Flavio Castelli)

Introduzione alle distribuzioni (di Marco Salvi)

E-learning & Opensource (di Samuele E. Locatelli)

Compilazione del Kernel Linux 2.6.x (di Ermanno Novali)

La sfida dell’Open Source (di Roberto “Jimmi” Franceschini)

Buona lettura!

Di che si tratta? Riporto dal sito, traduzione mia:

Si tratta di Tagsistant (o anche tagfs), che “utilizza FUSE per interfacciarsi con il kernel, usando un albero del filesystem nativo per immagazzinare le informazioni. Dentro quest’area del filesystem è presente una directory “archivio” che contiene file e un database SQLite che ne descrive le tag (“etichette”, implementate come altre directory).
Mettere una tag ad un file significa di fatto aggiungere nel database l’indicazione dell’etichetta associata al file stesso.
Tagsistant si occupa di rendere questa operazione automatica, senza importunare l’utente, quando un nuovo file viene creato, attraverso la sua copia o il suo spostamento tra le directory. (Questo significa che creare un link simbolico o copiare integralmente un file è di fatto la stessa cosa per Tagsistant).”

A questa pagina è possibile rendersi meglio conto di come il sistema funzioni attraverso una demo interattiva.

Gli argomenti trattati spaziano in molteplici settori, eccovi un elenco dei documenti disponibili per il download:

• una panoramica su Linux e sulle distribuzioni (di Marco Salvi);
• GIMP, il celebre software di manipolazione di immagini (di Samuele E. Locatelli);
• GUI – le interfacce grafiche per i sistemi Linux (di Giuseppe Ravasio);
• gli strumenti per le scienze messi a disposizione dal movimento Open Source (di Samuele E. Locatelli);
• OpenOffice.org, la suite open per la produttività (di Antonio Milesi);
• una panoramica sul Kernel Linux (di Luca Amigoni);
• La samba ballata da Mr. Linux (di Gabriele Galliani);
• la sicurezza nei sistemi Linux (di Marco Balduzzi);
• un server proxy open source: Squid (di Marco Morosini);
• WxWindows: un framework per realizzare applicazioni con interfaccia utente nativa (di Marco Cavallini);
• Un pinguino in salotto – Linux su console (di Flavio Castelli).

Buona lettura!

Acquisti

Dopo alcune ricerche in rete mi sono deciso per la seguente configurazione:

• Scheda madre: Intel D201GLY2A
• Case: Mini-Box M300
• RAM: Kingston 1GB 533MHz DDR2
• Hard Disks: n. 2 Samsung M5S HM160HI
• Alimentazione: Mini-Box picoPSU 120 + Sintel 8500mA 12Vcc

Per recuperare i materiali necessari ho dovuto farmi un ampio giro tra i negozi on-line, con risultati discordanti. Se non altro l’esperienza mi ha permesso di stilare una mini classifica che riporto di seguito:

Super, compro ancora!

• CarTFT.com
• Totalmodding
• Sintel

Onesto

• SmartPrice

Inaffidabile

• Mini-ITX

Da scampare come la peste

• Wireshop

Assemblare l’hardware

Dopo tre giorni ricevo dal sito tedesco il case, la mobo e l’alimentatore PicoPSU, la qual cosa mi fa sperare in una rapida conclusione. In realtà gli ultimi componenti mi arriveranno dopo quasi quattro settimane, durante le quali ho il tempo di pentirmi di alcune scelte:

• Il case M300, che ho scelto per le ridotte dimensioni, permette di alloggiare solo ventole da 40 mm, spesso rumorose. Case leggermente più alti permettono di alloggiare ventole da 80 mm, molto più silenziose e facili da reperire.
• La PicoPSU che ho scelto richiede un alimentatore con tensione fissa da 12V, mentre la maggior parte degli alimentatori per portatili in commercio partono da un minimo di 15V. Per pochi euro in più potevo avere il modello che accetta tensioni fino a 25V
• La mobo della Intel è buona ed economica, ma consuma leggermente di più rispetto alle VIA, circa 10W, e richiede una seconda alimentazione tramite uno spinotto tipo ATX4P. Questo causa maggior calore da dissipare e la necessità attaccare al PicoPSU uno sdoppiatore con un adattatore di non facile reperimento.

A parte queste note l’assemblaggio non ha riservato grosse sorprese. Il case, anche se di dimensioni ridotte, si è rivelato adatto allo scopo. Dopo aver cercato inutilmente di avere da Wireshop l’adattatore per ATX4P, mi sono deciso a costruirmelo in casa recuperando la spinetta da un vecchio alimentatore ATX. Ho inoltre scoperto che in molti adattatori in commercio le spine di alimentazione SATA agganciano i cavi in comodissimi attacchi a baionetta che rendono semplice la sostituzione di spine MOLEX eventualmente esistenti.

Dopo alcune settimane di ricerca infruttuosa di un alimentatore per portatili con uscita 12VCC mi sono deciso a comprarne uno dalla Sintel, che mi ha servito in maniera impeccabile. Peccato che il mattino dopo abbia trovato ben due alimentatori equivalenti alla metà del prezzo: la legge di Murphy non lascia scampo.

L’ulltimo scoglio che ho dovuto superare è stata la rumorosità: purtroppo la ventolina della CPU montata dalla Intel è discretamente rumorosa, e la dimensione di 40 mm non lascia molte chances. Totalmodding offre diverse ventole adatte, ma purtroppo il primo tentativo con quella più lenta e silenziosa porta la temperatura della CPU sopra i settanta gradi. Installo quindi il modello più veloce e la temperatura si assesta intorno ai sessanta gradi, anche se l’apparecchio non è silenzioso come speravo.

Installare il software

Il mio gioiellino è ora pronto. I servizi che ho intenzione di attivare sono:

• RAID1 e backup incrementale
• Accesso remoto via SSH e VNC
• Server stampa e scansione
• Server di posta con imap e webmail
• Disk sharing con Samba
• Server LAMP
• Client MLDonkey

Ovviamente il tutto eseguito con software libero disponibile tramite GNU/Linux, e la scelta della distribuzione casca senza ripensamenti su Debian stable, che offre da diversi anni gli stessi servizi sul predecessore. Le maggiori fonti di ispirazione per tutte le configurazioni sono stati il wiki di Debianizzati e Debian Administration Resources.

Kernel e RAID1

Dopo l’installazione dei soli pacchetti di base e l’aggiornamento con un repository internet, la prima operazione che ho eseguito è stata la compilazione di un kernel monolitico, ovviamente alla maniera Debian. Qui potete trovare il .config da me utilizzato per la bisogna.

Purtroppo mi sono accorto che i sensori di temperatura di questa scheda, relativamente nuova, non sono supportati dal kernel della stable, quindi ho dovuto scaricare il sorgente del kernel 2.6.22 dai backports e applicare una patch per poter visualizzare le temperature con lm-sensors.

L’operazione successiva è stata la creazione del RAID1: anche in questo caso Debianizzati mi è venuto in aiuto con una guida semplice e dettagliata. ed in poco tempo il sistema è funzionante.

Servizi interni

Solo a questo punto ho iniziato l’installazione dei programmi aggiuntivi che mi servivano, badando bene ad evitare l’installazione di pacchetti inutili.

Per prima cosa ho installato OpenSSH e abilitato una console seriale. Questo mi ha permesso di eliminare definitivamente tastiera e monitor e proseguire l’installazione comodamente collegato dal mio portatile, o anche dal lavoro durante la pausa pranzo. La console seriale mi permette inoltre di intercettare ed eventualmente correggere eventuali problemi in fase di boot senza ricollegare le periferiche.

Modificando gli script di Mike è molto semplice abilitare un backup incrementale giornaliero o settimanale. Calibrando opportunamente la frequenza e le directory interessate riesco a far stare in 5 GB un backup delle cose importanti (SO, configurazioni, Mail e sito web) fino ad un mese indietro.

La configurazione di un server mail con fetchmail, postfix, procmail e uw-imaps è banale seguendo uno qualsiasi dei molti howto che si possono trovare in rete. Il Quick&Easy Configuration HOWTO di Antonio Fragola, nonostante sia datato, rimane uno dei documenti più adatti allo scopo. L’obiettivo è scaricare la posta dai vari account internet distribuendola nelle varie caselle degli utenti, i quali possono accedere ad esse sul server con qualunque client vogliano usare.

Le note particolari della mia installazione sono l’utilizzo di Freepops per accedere alle mail di inwind e libero, la cui versione aggiornata deve essere scaricata dai repository dei backports, e l’utilizzo di Clamav dai repository ‘volatile‘, come suggerito da Debian Administration.

Installando CUPS e SANE posso avere sia la stampante che lo scanner funzionanti e disponibili anche per i client in rete. Ovviamente devo spiegare ai demoni quale rete servire, e ai client da quale server ascoltare.

Configurando Samba con LDAP la gestione degli utenti del dominio viene molto semplificata, ed anche gli eventuali client Windows si sentono come a casa loro.

Servizi sul web

Posso ora passare ai servizi aperti sul web. A pochi minuti dall’installazione MLDonkey comincia allegramente a scaricare e condividere con altri peer le mie cartelle condivise. Devo avere l’accortezza di aprire sul router le porte corrispondenti ai protocolli che intendo usare: eDonkey, Gnutella, FastTrack, Bittorrent e quant’altro.

L’installazione dei server LAMP e la relativa configurazione è cosa veloce seguendo i consigli di Debianizzati; una volta concluso mi basta copiare gli archivi di WordPress, eseguire un ripristino del database, abilitare il sito su apache ed il mio blog fa bella mostra di se su internet.

Anche l’installazione e la configurazione di OpenVPN si è rivelata abbastanza semplice, seguendo la guida di Debian Administration. In questo modo da qualunque parte mi trovo posso accedere in modo sicuro ai servizi della mia rete, inclusa l’interfaccia web di MLDonkey.

La ciliegina finale è stata l’abilitazione di una webmail con Squirrelmail accessibile su una connessione sicura dal web, sulla cui configurazione ho scritto un’altro manualetto disponibile sul blog del BGLug VS.

Conclusioni

Dieci anni fa non avrei preso sul serio chiunque mi avesse detto che con poco più di trenta watt e una scatoletta grande come un’autoradio si potesse realizzare tutto questo. Oggi questo l’ho fatto io, con il supporto di molti sconosciuti che scrivono software libero ed aiutano gli utenti con manuali e mailing lists.

Mio padre, tra i tanti buoni consigli che mi ha dato, mi ripeteva sempre “Nessuno fa niente per niente”. Ora posso dire: “Papà ti sbagli!”. C’è un sacco di gente là fuori che fa delle cose per il solo gusto di farle bene, ed è felice di condividerle con chiunque condivida la loro passione. Voglio ringraziare quindi tutte queste persone, e spero che queste mie pagine possano dare un piccolo contributo a tutto ciò.

L’Asus EeePC 701 è un portatile a basso costo di casa Asus. Nato come progetto per le scuole medie, si è rivelato poi come uno dei prodotti più famosi della Asus degli ultimi tempi: la sua potenza ridotta (processore da 600MHz, 512Mb di RAM, da 2 a 8 Gb di memoria a stato solido e schermo da 7 pollici) è ben compensata dal suo costo (299 Euro) e dalle sue dimensioni ridotte (225x165x21). L’EeePC monta una distribuzione Linux di default, Xandros, personalizzata in modo da essere facile da usare e da gestire senza troppe limitazioni. Putroppo Xandros non è standard, ragion per cui in questa guida tratteremo l’installazione di qualsiasi distribuzione Ubuntu-based su EeePC.

Ingredienti:

• EeePC
• Lettore CD/DVD esterno (è comunque utile recuperarne uno, in quanto l’EeePC non ha lettore CD)
• Qualsiasi periferica di archiviazione di massa da 2Gb o superiore (solo nel caso in cui non procederete all’eliminazione di Xandros dalla memoria interna)
• Questo file da questo progetto su una chiave usb o altro.

Cominciamo:

La prima cosa da fare è salvare eventuali dati presenti sull’EeePC: vi consiglio di farlo anche se avete deciso di installare tutto su una chiavetta o una scheda SD. Poi bisogna considerare il tipo di installazione che vogliamo fare: interna o esterna. Considerate che la memoria interna è da 2Gb, 4Gb o 8Gb: può bastare per il solo sistema, limita parecchio l’installazione di nuovi programmi ma fornisce una velocità maggiore. Diversamente, l’installazione su periferica esterna preserva Xandros (ripristinabile comunque grazie al CD che trovate nella confezione) e offre una ampiezza del disco limitata solo dall’ampiezza del vostro portafogli ma può presentare limiti di velocità e può essere scomoda per via del lettore di schede che rimane sempre occupato in caso di installazione su SD oppure di un eventuale chiave USB che deve rimanere sempre inserita. Io ho optato per l’installazione su disco interno. Qualsiasi sia la vostra scelta, l’unica modifica da fare sarà forse solo il GRUB, ma riprendermo questo tra poco.

• Per prima cosa collegate il lettore CD esterno con dentro la vostra distribuzione *ubuntu preferita, nel mio caso una Kubuntu 7.10, e l’eventuale periferica di massa su cui andrete ad installare;
• all’avvio del computer premete [Esc] che vi mostrerà il menù di boot e scegliete il lettore CD. Vedrete la schermata di boot e scegliete Installazione. In questa guida non tratteremo l’installazione di Ubuntu, ma potrete consultarne una qui, in quanto potrete procedere all’installazione come un normalissimo PC. Se la bassa risoluzione dello schermo vi dà problemi con le finestre sicuramente vi sarà utile sapere che tenendo premuto il tasto [Alt ] potete trascinare le finestre in quasi tutti i windows manager moderni. Installate Ubuntu dove più vi aggrada e riavviate.
• Se l’installazione parte senza problemi saltate questo punto. In caso contrario, è probabile che GRUB abbia un riferimento sbagliato sulla partizione da avviare. Quando esce il conto alla rovescia premete [Esc], selezionando la prima riga che vi mostra premete [E] e ancora [E] sula riga che inizia con “root”. A questo punto dovreste poter modificare la linea: quello che ci interessa è il paramentro “(hd0,0)”. Cancellatelo fino ad avere “(hd” e premete [TAB]: la riga vi mostrerà alcune opzioni. Sceglietene una continuando il completamento con [TAB] e premete [B] per avviare, provate finchè non trovate quella giusta.
• A sistema avviato loggatevi e copiate il file sulla scrivania, decomprimetelo e aprite una shell tramite il vostro terminale preferito. Entrate nella directory del file decompresso prima e battete

  sudo ./install all
  

  Inserite la vostra password e attendete che abbia finito: questo script installa vari moduli e fa alcune modifiche a dei file (leggete il README all’interno se siete curiosi). A questo punto riavviate e il vostro sistema dovrebbe funzionare alla perfezione: Wi-Fi, webcam, audio etc etc…

Il consiglio che vi do è di sostituire eventuali programmi come OpenOffice con alternative più leggere (AbiWord per esempio) oppure di sfruttare, dove potete, servizi di webapps come GoogleDocs che vi permettono di non occupare spazio prezioso. Soprattuto vi consiglio di ridurre i font a 8 per tutto il sistema se i vostri occhi ve lo permettono… Buon diverimento sul vostro sistema e benvenuti nel mondo OpenSource se per voi è la prima volta…

Niente a che vedere con cups, che scopre per i fatti suoi tutti gli altri server cups presenti nella rete e concede agli utenti locali di stampare su tutte le stampanti condivise senza installare drivers. Semplicemente perché non servono.Cups infatti gestisce i lavori di stampa con Postscript, indipendentemente dal linguaggio effettivamente utilizzato dalla stampante; sarà poi compito del server collegato fisicamente alla stampante di tradurre il flusso Postscript in un linguaggio comprensibile per la stampante.

Di conseguenza, al fine di permettere ad un sistema windows di stampare verso cups, bisogna “imporgli” di usare un driver che traduca il flusso di stampa GDI di windows in un flusso Postscript. Faremo questo inviando un driver Postscript (magari quello usato di default su windows, oppure quello del progetto cups) quando il client richiede a samba il driver di stampa.

Prerequisiti:

• samba (configurato e funzionante)
• cups (idem, magari con una stampante condivisa)
• uno o più client windows da cui stampare

Configurazione di samba:

Se cups è installato e funzionante, normalmente (nelle distro moderne) samba presenta già le stampanti condivise da cups. In ogni caso riepilogo qui le direttive che devono essere presenti nel file /etc/samba/smb.conf:

[global]   load printers = yes   printing = cups   printcap name = cups[printers]   comment = Tutte le stampanti   path = /var/spool/samba   browseable = no   public = yes   guest ok = yes   writable = no   printable = yes   printer admin = paolo[print$]   path = /usr/share/cups/drivers   guest ok = no   browseable = yes   read only = yes   write list = paolo

Giusto per fare chiarezza: la sezione [global] deve abilitare la stampa tramite cups, la sezione [printers] definisce il file di spool, mentre la sezione [print$] definisce uno share (o condivisione, che dir si voglia) contenente i drivers delle stampanti. Infatti ogni server windows che condivide una o più stampanti, possiede uno share nascosto (cioè il cui nome finisce per $) preposto alla condivisione dei driver delle stampanti. Da notare che questo share è in sola lettura, ma ci serve un utente (paolo in questo caso) con i diritti di scrittura, in modo da caricare i drivers. L’utente ha anche il permesso di amministrare le stampanti. Il percorso indicato, invece, punta direttamente ai drivers di cups.

Attenzione: prima di ogni modifica a smb.conf fate sempre una copia.

Attenzione2: dopo ogni modifica a smb.conf, eseguite:

testparm

che validerà le vostre modifiche.

Attenzione3: dopo ogni modifica a smb.conf, riavviate il servizio, altrimenti la modifica non sarà effettiva. Per riavviare samba:

sudo /etc/init.d/samba restart

Attenzione4: ricordatevi che l’utente (paolo) deve esistere sul vostro sistema, e deve avere una password riconosciuta da samba. Per impostare la password in samba:

sudo smbpasswd paolo

e inserite una password decente.

Ottenere i drivers:

Difficilmente troverete sul vostro sistema linux le dll che vi servono per i driver Postscript Bisogna quindi scaricarli da qui. Decomprimete, entrate nella directory appena creata e date un

sudo make install

Attenzione: su alcune distro potreste aver bisogno del pacchetto “libcupsys2-dev” per installare questi driver.

Ora vi servono i drivers Postscript di windows, colti direttamente da un sistema “volontario”: cercate in \windows\system32\spool\drivers\w32x86. Da qualche parte troverete i seguenti files:

ps5ui.dllpscript5.dllpscript.hlpscript.ntf

copiateli in /usr/share/cups/drivers e modificate i nomi: convertiteli in minuscolo.

Configurazione di cups:

Supporremo qui di avere un server cups installato e funzionante, con almeno una stampante condivisa.L’utente (paolo) dovrà almeno temporaneamente poter scrivere sulla directory /usr/share/cups/drivers. Per cui:

sudo chmod 777 /usr/share/cups/drivers

Potrete ripristinare i permessi in seguito. Ora viene la magia:

sudo cupsaddsmb -H localhost -U paolo -a -v

con questo chiediamo a cups di pubblicare i driver delle stampanti condivise sul server “localhost” utilizzando l’utente “paolo” per accedere in lettura/scritttura alla condivisione “print$” (quella di default per i drivers di stampa di windows). Facciamo ripartire samba e cups, giusto per gradire…

sudo /etc/init.d/samba restartsudo /etc/init.d/cupsys restart

E ora, dal client windows, accedete al server e aprite una stampante, i drivers dovrebbero caricarsi automagicamente!