[WORKLOG] - Installazione di un server ftp su Debian 6.0

[frakka]

Questa sarà l'istanza del server che sarà raggiungibile dalla rete internet.
Stò inoltre configurando l'istanza in modo gli utenti siano autenticati con le credenziali locali del server che, ricordo, in assenza di SSL il protocollo ftp trasmette in chiaro. Questo è, quindi, un rischio per la sicurezza del server molto più che potenziale: Personalmente è un configurazione che non metterei mai in esercizio. Un'istanza pubblica con autenticazione sulle credenziali locali senza cifratura è un semplice esercizio, riportato più per completezza che per altri motivi.

I passi da seguire ricalcano esattamente quelli visti per l'istanza locale (la creazione del file di configurazione dell'istanza, la creazione di un utente limitato da associare al servizio, la copia del modulo PAM da utilizzare per l'autenticazione, la creazione del banner e delle liste utente richieste per permettere l'accesso al server e le eventuali jail chroot) con in aggiunta le modifiche da apportare allo script che configura il firewall per permettere l'accesso al server FTP dalla rete pubblica.

Per questa istanza, ho creato i file di configurazione “vsftpd_pubblico.conf” che fornirà la configurazione del server ftp bindato sull'IP 192.168.50.2 del mio server, in quanto è l'interfaccia su cui il router natta le porte in ingresso.

Per creare l'utente ftp_pubblico uso nuovamente i comandi visti in precedenza, che mi mostrano il gruppo cui "ftp" appartiene, creano l'utente e mi mostrano il risultato, per verifica:

root@server:/home/matteo# id ftp
uid=107(ftp) gid=112(ftp) groups=112(ftp)
root@server:/home/matteo# adduser --gid 112 --disabled-password ftp_pubblico
Adding user `ftp_pubblico' ...
Adding new user `ftp_pubblico' (1005) with group `ftp' ...
Creating home directory `/home/ftp_pubblico' ...
Copying files from `/etc/skel' ...
Changing the user information for ftp_pubblico
Enter the new value, or press ENTER for the default
Full Name []:
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n] y
root@server:/home/matteo# id ftp_pubblico
uid=1005(ftp_pubblico) gid=112(ftp) groups=112(ftp)

Non sarebbe neppure male specificare per l'utente una shell fittizia invece che quella standard, tipo "/bin/false" ma è un'operazione che si può fare anche editando a mano come root il file "/etc/passwd", sempre per una questione di maggiore sicurezza.

Creo poi il file "/etc/vsftpd/ftp_pubblico_banner" che conterrà, appunto, il banner da mostrare agli utenti ftp al momento della connessione ed i file con la lista di utenti autorizzati al login e degli utenti costretti all'interno della loro home directory, che questa volta userò.

###############################################################
# File di configurazione completo di tutte le opzioni standard
# previste per vsftpd, corretto con gli eventuali path indicati
# nel file di configurazione previsto di defautl per Debian.
#
# Tutti i campi sono valorizzati con le opzioni predefinite
# come indicate nella manpage del software al 27/11/2011 e
# raggruppate in sezioni.
# Il file così com'e' dovrebbe risultare funzionante, in quanto
# richiama senza alcuna modifica i valori predefiniti di vsftpd.
# Ho fatto riferimento ad un configurazione IPv4, commentando
# i valori che, se non valorizzati, impedirebbero l'avvio del
# server o che risultano mutualmente esclusivi rispetto alla
# configurazione base IPv4 adottata.
################################################################


################################################
### Configurazione del servizio server FTP. #
################################################

### Configurazione di rete del server
## IPv4:
listen=YES
listen_address=192.168.50.2
## IPv6:
listen_ipv6=NO
#listen_address6=(none)

background=YES
listen_port=21

### Modalita' di funzionamento (Attiva/Passiva):
## Attiva
port_enable=NO
connect_from_port_20=NO
ftp_data_port=20
## Passiva
pasv_enable=YES
pasv_min_port=30000
pasv_max_port=31000
pasv_addr_resolve=YES
#pasv_address=(none - the address is taken from the incoming connected socket)

## Opzioni particolari di raro uso
port_promiscuous=NO
pasv_promiscuous=NO

In questa sezione, ho configurato il server per avviarsi in modalità standalone e mettersi in ascolto sulla porta 21 dell'IP 192.168.50.2, che è la mia interfaccia di rete esposta sulla rete pubblica. Per una questione di sicurezza non sarebbe sbagliato cambiare la porta utilizzata per il server ftp: E' poi sufficiente ricordarsi di comunicare agli utenti che il server usa una porta non standard per la connessione. In questa configurazione ho poi attivato la sola modalità passiva per il server ftp, specificando di utilizzare per le connessioni dei client solo il range di porte dinamiche dalla 30000 alla 31000.
Se si vuole valorizzare il parametro "pasv_address" con, ad esempio, un hostname tipo "ftp.miodominio.it" è necessario però che esista la risoluzione inversa nel dns pubblico. In caso contrario, i client riusciranno a stabilire la connessione ma al tentativo di listare la una qualunque directory vengono restituiti fastidiosi e criptici problemi di permessi che possono rendere difficile identificare il problema.

### Account di sistema:
nopriv_user=ftp_pubblico
session_support=YES
pam_service_name=vsftpd_pubblico
run_as_launching_user=NO

Qui imposto lo username non privilegiato da usare per l'istanza, ed il nome del modulo PAM da utilizzare per l'autenticazione (dato che uso gli utenti locali è ancora solo una copia dell'originale). Lascio attivo il "session_support" che dovrebbe semplificare l'analisi dell'attività degli utenti.

#################################################
### Configurazione funzionalita' del server FTP.#
#################################################

## Attivita' permesse sul server
download_enable=YES
write_enable=YES
ascii_download_enable=NO
ascii_upload_enable=NO
cmds_allowed=ABOR,ACCT,ALLO,AUTH,APPE,CDUP,CWD,DELE,FEAT,HELP,LIST,MDTM,MKD,MODE,NLST,NOOP,OPTS,PASS ,PASV,PBSZ,PROT,PROT+,PORT,PWD,QUIT,REIN,REST,RETR,RMD,RNFR,RNTO,SITE,SIZE,SMNT,STAT,STOR,STOU,STRU, SYST,TYPE,USER
#cmds_denied=(none)

lock_upload_files=YES
async_abor_enable=YES
delete_failed_uploads=YES
mdtm_write=YES

## Impostazioni predefinite per i permessi sui file
## e le directory create sul server via ftp
file_open_mode=0666
anon_umask=077
local_umask=077

## Opzioni particolari di raro uso
one_process_model=NO
setproctitle_enable=NO
tcp_wrappers=NO
use_sendfile=YES

## Opzioni di listing del server:
#ftpd_banner=(none - default vsftpd banner is displayed)
banner_file=/etc/vsftpd/ftp_pubblico_banner
dirmessage_enable=YES
message_file=.message
dirlist_enable=YES
ls_recurse_enable=NO
force_dot_files=NO
use_localtime=YES
hide_ids=YES
text_userdb_names=NO
tilde_user_enable=NO
#deny_file=(none) i.e. {*.mp3,*.mov,.private}
#hide_file=(none) i.e. {*.mp3,*.mov,.private}

In questa sezione ho abilitato il server sia alle operazioni di lettura che di scrittura. Ovviamente solo gli utenti locali saranno abilitati alle operazioni di "write" e ho lasciato le mask invariate in modo che per impostazione predefinita solo l'utente stesso abbia i permessi di lettura sui propri files.
Ho poi attivato anche i "directory message" utili all'amministratore per lasciare avvisi agli utenti...
La lista dei comandi supportati da vsftpd si può ottenere facendo login sul server ed usando il comando "?".


E' davvero una buona idea restringere il range di comandi ai minimi indispensabili. Una descrizione si può trovare su wikipedia, sono davvero parecchi anche se ormai forse non più molto usati. A maggior ragione, se le intezioni dell'amministratore sono di mettere a disposizione il server ftp solo per permettere agli utenti di caricare, scaricare e movimentare files all'interno della propria home directory, i comandi da abilitare sono proprio pochi...
Personalmente ho scelto i comandi da consentire avviando il server, eseguendo un set delle operazioni che voglio permettere e ho poi autorizzato solo i comandi registrati nel log...

################################################
### Configurazione utenti del server FTP. #
################################################

## Utenti abilitati:
anonymous_enable=YES
guest_enable=NO
guest_username=ftp_pubblico
local_enable=YES

## Elenchi di utenti abilitati/esclusi dal server
userlist_enable=YES
userlist_deny=NO
userlist_file=/etc/vsftpd/ftp_pubblico_user_list

secure_email_list_enable=NO
email_password_file=/etc/vsftpd.email_passwords
deny_email_enable=NO
banned_email_file=/etc/vsftpd.banned_emails

max_login_fails=3
delay_failed_login=5
delay_successful_login=0

#user_config_dir=(none)
#user_sub_token=(none)
virtual_use_local_privs=NO

In questa sezione, abilito l'accesso al server sia degli utenti anonimi che degli utenti locali. Per capirci qualcosa, è necessario premettere che per vsftpd non esistono utenti "anonimi" nel vero senso della parola ma solo utenti "non autenticati".
In pratica, è sempre e comunque necessario, al login, inserire un nome utente per l'accesso al server in quanto lasciare il campo vuoto restituisce un errore. Per questi accessi, convenzionalmente si utilizzano gli username "anonymous" e/o "ftp" che vengono riconosciute dal server come login "non autenticate".
E' però necessario che questi account compaiano nel file utilizzato per la lista degli utenti autorizzati all'accesso (nel mio caso "ftp_pubblico_user_list") oppure non compaiano nell'elenco degli utenti cui è negato l'accesso, altrimenti si ottiene sempre un "accesso negato".
Per questo motivo preferisco non utilizzare l'account predefinito "ftp" di Debian come username per le mie istanze, voglio essere sicuro che la cosa non generi confusione e preferisco quindi usare uno username diverso. Anzi, per stare sul sicuro provvedo proprio ad eliminare l'account locale denominato "ftp":

root@server:/etc/vsftpd# userdel ftp
userdel: group ftp is the primary group of another user and is not removed.

Nel file "/etc/vsftpd/ftp_pubblico_user_list", come detto, vengono indicati gli utenti ammessi al login, come nella configurazione precedente. Per abilitare l'accesso "anonimo" quindi, il mio files "ftp_pubblico_user_list" lo preparo così:

# Lista utenti abilitati all'accesso FTP.

# Account da utilizzare per l'accesso anonimo:
anonymous

# Accounts autorizzati al login non anonimo:
matteo
[etc...]

Quindi "anonymous" è utilizzabile per le login non autenticate. Se volessi aggiungere anche "ftp" mi basta inserirlo nel file. Ripeto che stò parlando di uno username convenzionale, non dell'utente locale "ftp" che ho precedentemente eliminato dal server.
Per comodità degli utenti lo specifico nel banner:

****************************************
*** Server FTP sulla rete pubblica ***
****************************************

ATTENZIONE:

****************************************
Tutte le attivita' del server sono
strettamente monitorate.
****************************************

Login anonimo consentito solo come "anonymous"

Valorizzare il parametro "user_config_dir" in questo caso può essere molto utile in quanto permette di indicare una configurazione specifica per utente (potrei, ad esempio, configurare la sessione di uno specifico utente per non avere restrizioni sui comandi ftp) semplicemente copiando le opzioni "user level" del file configurazione in un altro file denominato con il nome utente posto all'interno della directory indicata.

################################################
## Impostazioni valide solo per gli utenti anonimi.
ftp_username=ftp_pubblico
anon_root=/download/ftp
no_anon_password=YES
anon_upload_enable=NO
anon_mkdir_write_enable=NO
anon_other_write_enable=NO
anon_world_readable_only=YES
chown_uploads=NO
chown_username=root
chown_upload_mode=0600

################################################
## Impostazioni valide solo per gli utenti "non anonimi".
#local_root=(none)
chroot_local_user=YES
chroot_list_enable=YES
chroot_list_file=/etc/vsftpd/ftp_pubblico_user_list
passwd_chroot_enable=NO
secure_chroot_dir=/var/run/vsftpd/empty
chmod_enable=YES

Passo finalmente a specificare i permessi per le login anonime sul server. Ho specificato "ftp_pubblico" come account utilizzato da server ftp per interfacciarsi con il filesystem locale. Anche qui vsftpd si dimostra molto protettivo nei confronti del server: Non è consentito utilizzare come "anon_root" una directory che risulti scrivibile quindi il percorso indicato non deve essere scrivibile da "ftp_pubblico", pena il "deny" della login.
Se vogliamo permettere l'upload anonimo è quindi necessario indicare un percorso non scrivibile per "anon_root" ed indicare agli utenti (magari tramite .message) dove effettuare l'upload (ad esempio, la directory "/download/ftp" non deve essere scrivibile da "ftp_pubblico" ma la sottodirectory "/download/ftp/upload_anonimi" può esserlo ed in questa directory gli utenti anonimi possono effettuare le operazioni di scrittura). Ovviamente, permette l'upload anonimo su un server ftp è quanto di più assurdo si possa fare, a meno di situazioni particolari.
Il parametro "no_anon_password" regola semplicemente il fatto che venga o meno richiesta una password per la login non autenticata... Serve a poco, anche perchè è solo un campo fittizio a meno che non si voglia implementare il molto poco sicuro meccanismo basato sulla lista di email.
I 3 parametri successivi regolano poi vari livelli di permessi di write sul server per gli utenti anonimi... Per quanto mi riguarda, deve essere tutto disabilitato. Il parametro "anon_world_readable_only" aumenta poi la sicurezza del server perchè permette agli utenti anonimi di scaricare solo file che risultino leggibili all'utente "ftp_pubblico" utilizzato dal servizio. Quindi impedisce ad una login anonima di scaricare un file su cui non ha i permessi di lettura per forzarlo con calma in un secondo momento...
Non avendo permesso upload da parte di utenti anonimi, i parametri relativi al "chown" non si applicano.

Infine posso specificare i permessi che attribuisco sul server agli utenti locali o, meglio, autenticati.
Se non viene indicato un percorso nel parametro "local_root" gli utenti verrano loggati all'interno della loro home directory. Selezionare il parametro "chroot_local_user" permette di restringere comunque gli utenti locali solo al quella determinata directory. E' utile soprattutto per mantenere separate le aree di lavoro, ma valgono le considerazioni fatte in sede di commento del file di configurazione per le questioni legate alla sicurezza.
Ne consegue, in base alle politiche implementate sul server, la lista degli utenti da restringere o meno nella jail: Avendo specificato come valore per "chroot_local_user=YES" allora, impostando il valore di "chroot_list_enable=YES", nel file "chroot_list_file" posso indicare un'elenco di utenti da non restringere nella jail chroot e che quindi possono esplorare liberamente il filesystem del server. Se invece impostassi il valore di "chroot_list_enable=NO" allora tutti gli utenti locali verrebbero costretti nella jail chroot. Specificando invece come valore per "chroot_local_user=NO", impostando il valore di "chroot_list_enable=YES", nel file "chroot_list_file" dovrei indicare un'elenco di utenti da restringere nella jail chroot e che quindi non possono esplorare liberamente il filesystem del server, mentre settare lo stesso valore a "NO" tutti gli utenti locali sarebbero liberi di esplorare il filesystem del server.

Quanto sopra, ovviamente, compatibilmente con i propri permessi sul filesystem, che rimangono sempre la policy di sicurezza più affidabile.

Il parametro "passwd_chroot_enable" permette, se abilitato con "chroot_local_user ,=YES" di specificare un percorso diverso per la jail chroot di ogni utente locale, derivandone il percorso dal file /etc/passwd. Utile, probabilmente, per configurazioni piuttosto complesse.
Il parametro "secure_chroot_dir" è il percorso di una directory vuota, preferibilmente non scrivibile dall'utente ftp, utilizzata quando non è necessario un accesso al filesystem da parte del servizio ftp... lo ammetto, non capisco l'utilità di un servizio ftp senza accesso al filesystem ma evidentemente un motivo di sarà... Il parametro indicato è il valore di default di Debian, diverso da quello previsto da vsftpd.
Infine il parametro "chmod_enable" permette l'uso del comando "SITE CHMOD" sul server ftp. Si applica solo agli utenti locali per un'ovvia questione di sicurezza ma ho disabilitato sia "SITE" che "CHMOD" tra i comandi utilizzabili sul server quindi comunque il suo funzionamento è annullato a monte. Lo lascio abilitato per evitare interferenze con eventuali configurazione "per-utente" che potrei andare a specificare in un secondo momento.

#################################################
### Configurazione supporto SSL del server FTP. #
#################################################
...

Anche stavolta rimando a più tardi questa sezione.

###############################################
### Configurazione del logging del server FTP.#
###############################################
## Formato dei log
xferlog_enable=YES
vsftpd_log_file=/var/log/vsftpd_pubblico.log
xferlog_std_format=YES
xferlog_file=/var/log/vsftpd_pubblico.xferlog
syslog_enable=NO

## Contenuto del log
log_ftp_protocol=YES
dual_log_enable=YES

## Workaround ad un particolare bug sui sistemi Solaris.
no_log_lock=NO

###############################################
### Timeout del server. #
###############################################
accept_timeout=60
connect_timeout=60
idle_session_timeout=300
data_connection_timeout=300

###############################################
### Throttling del server. #
###############################################
local_max_rate=0
anon_max_rate=0
max_clients=0
max_per_ip=0
trans_chunk_size=0

#########################################################################
# Questa opzione si applica solo alle build non-PAM. Non e' il mio caso.#
# check_shell=YES #
#########################################################################

Infine, il logging del server. Anche qui preferisco mantenere il doppio log anche se una volta trovata un configurazione stabile e definitiva può essere utile disabilitare il parametro "log_ftp_protocol" in quanto scrive veramente un sacco di roba... Mantengo il doppio logging, con il parametro "dual_log_enable" e specifico i due files in cui salvare le registrazioni, disabilitando la scrittura nel log di sistema con il parametro "syslog_enable=NO".
Nel file "vsftpd_pubblico.xferlog" vengono registrati solo i trasferimenti avvenuti via ftp, nel file "vsftpd_pubblico.log" anche i comandi ftp finchè questa registrazione non viene disabilitata.


In ultimo devo aggiungere le seguenti righe al mio script di generazione del firewall, per aprire le porte necessarie. Faccio riferimento sempre allo script utilizzato nel thread di installazione del server, ringraziando di nuovo l'autore del tool di generazione dello script.
Nella sezione iniziale "Load Modules", in cui vengono impostati i moduli di del kernel da caricare per il funzionamento del firewall, aggiungo o decommento le righe:

# The ftp nat module is required for non-PASV ftp support
/sbin/modprobe ip_nat_ftp

# the module for full ftp connection tracking
/sbin/modprobe ip_conntrack_ftp

Il primo è necessario per le connessioni in modalità attiva, per la modalità passiva che ho implementato non dovrebbe essere indispensabile.

Infine devo aprire le porte utilizzate nella chain "INPUT", sia la porta di "listen" (21, se non modificata) che le porte usate per il trasferimento dei files.
In modalità attiva la porta di trasferimento è la porta 20, se non modificata o se il parametro "connect_from_port_20" è stato impostato a "YES") mentre in modalità passiva c'è da specificare un range (consigliato) oppure da aprire tutto il range di porte dinamiche (di massima è preferibile evitare).

Io ho attivato la sola modalità passiva e indicato il range da 31000 a 32000 e quindi nel mio firewall devo aggiungere/modificare le seguenti sezioni:

# FTP Server

# FTP Server (Control)
$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 21 -j ACCEPT

# FTP Client (Data Port for non-PASV transfers)
#$IPT -A tcp_inbound -p TCP -s 0/0 --source-port 20 -j ACCEPT

# Passive FTP
#
# With passive FTP, the server provides a port to the client
# and allows the client to initiate the connection rather
# than initiating the connection with the client from the data port.
# Web browsers and clients operating behind a firewall generally
# use passive ftp transfers. A general purpose FTP server
# will need to support them.
#
# However, by default an FTP server will select a port from the entire
# range of high ports. It is not particularly safe to open all
# high ports. Fortunately, that range can be restricted. This
# firewall presumes that the range has been restricted to a specific
# selected range. That range must also be configured in the ftp server.
#
# Instructions for specifying the port range for the wu-ftpd server
# can be found here:
# http://www.wu-ftpd.org/man/ftpaccess.html
# (See the passive ports option.)
#
# Instructions for the ProFTPD server can be found here:
# http://proftpd.linux.co.uk/localsite...nked/x861.html

$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 31000:32000 -j ACCEPT

Ora che la configurazione del server è completa, creo la directory "/download/ftp/" e ne stabilisco i permessi a livello filesystem.
I permessi da assegnare sono molto diversi sulla base della configurazione del server, difficile trovare una configurazione che vada bene per tutti. I requisiti da soddisfare sono la sola lettura da parte dell'utente utilizzato per il servizio ftp che gestisce le login anonime ed i permessi di scrittura per l'utente o gli utenti che dovranno effettuare l'upload dei file per renderli disponibili (nelle proprie home directory gli utenti locali hanno già i permessi di scrittura).

Nel mio caso, voglia che il servizio ftp renda disponibile l'accesso anonimo ad un directory che si trova all'interno di una share samba. In questo modo, tramite samba da un pc connesso in rete posso pubblicare files e directory sul server ftp semplicemente copiandoli nella share Windows.
La directory di pubblicazione è, appunto, "/download/ftp/" e "/download/" il percorso delle directory sul filesystem condivisa via samba. Perchè la directory ftp sia scrivibile dalla LAN via samba è necessario che l'utente con cui samba scrive sul filesystem abbia i permessi di scrittura mentre gli utenti che il servizio ftp presenta come anonimi dovranno avere solo i permessi di lettura ed, eventualmente, esecuzione.

Sempre rifacendomi alla configurazione del mio serverino, l'utente con cui samba scrive sul filesystem è "guest" mentre l'utente utilizzato dal servizio FTP appartiene al gruppo "ftp".

root@server:/download# mkdir /download/ftp
root@server:/download# ls -al ftp
total 4
drwxr-xr-x 2 root root 6 Dec 26 17:43 .
drwxr-xrwx 11 root root 4096 Dec 26 17:43 ..
root@server:/download# chown -R guest:ftp /download/ftp/
root@server:/download#ls -al /download/ftp/
total 4
drwxr-xr-x 2 guest ftp 6 Dec 26 18:00 .
drwxr-xrwx 11 root root 4096 Dec 26 18:00 ..

[EDIT del 13/04/2013]
Aggiornata l'istruzione cmds_allowed.

[frakka]

Un'altra possibilità offerta da vsftpd è l'utilizzo di utenze virtuali. Cosa significa?
In sostanza, gli utenti virtuali sono delle login autenticate (che possono quindi essere assimilate agli utenti locali e facilmente tracciate) ma che non trovano riscontro tra gli utenti di sistema. In questo modo, è possibile aggiungere un utente al server ftp senza dover creare un utente linux ma semplicemente inserendo la login nella sorgente delle credenziali ed, eventualmente, autorizzandolo all'accesso.
Un altro vantaggio è la non trascurabile possibilità di mettere in piedi un servizio ftp abilitato all'upload di files che non necessiti della trasmissione (sempre in chiaro, lo ricordo) delle credenziali di uno o più utenti del server: In questo modo, le login di vsftpd si svincolano completamente dagli utenti di sistema, permettendo di aumentare ulteriormente il livello di sicurezza del server.

In sostanza, grazie alla compatibilità con il sistema PAM, vsftpd offre la possibilità di autenticare le login al server verso qualunque sistema di autenticazione compatibile per cui sia configurato un modulo PAM. Linux PAM (o Linux Pluggable Authentication Modules) sono un insieme di librerie che operano come ponte tra le applicazioni ed i sistemi di autenticazione: L'interazione avviene grazie a degli script piuttosto semplici che permettono però di realizzare sistemi di autenticazione anche complessi che vanno dal leggere le credenziali di un utente da un semplice file di testo alla lettura dei dati biometrici, come impronte digitali o struttura della retina, anche integrati tra loro.
L'enorme vantaggio, è che se un'applicazione è "PAM-compliant" per passare dalle credenziali memorizzate nel file di testo alla lettura della retina è sufficiente aggiungere o modificare qualche riga dentro uno script di testo per ottenere le credenziali dalla nuova sorgente, senza dover riscrivere l'applicazione. E' quindi possibile realizzare un'infrastruttura integrata anche complessa, magari con una directory LDAP o addirittura un server Active Directory, e configurare il server ftp per leggere da questa sorgente le credenziali utente, oppure da un database MySQL o da qualunque altra sorgente dati per cui esista un modulo PAM.

vsftpd è "PAM-compliant" ed il modulo utilizzato per l'integrazione con PAM è lo script indicato nel file di configurazione con il parametro "pam_service_name" nel file di configurazione. Per cambiare, quindi il sistema di autenticazione verso cui vsftpd verifica le credenziali utente, è sufficiente andare ad operare su questo script per indicare la nuova sorgente da utilizzare.
Nel mio caso, per ora mi interessa poter indicare come sorgente per gli account utente in un file di testo con una password cifrata, in modo che non sia leggibile in chiaro e che sia facilmente gestibile. Nel prossimo futuro anche un'integrazione LDAP o con Active Directory potrebbe essere interessante ma per ora non mi serve. Il concetto è comunque lo stesso.

Per realizzare questa integrazione, diamo uno sguardo a quanto riportato nelle FAQ di vsftpd:

Q) Help! Does vsftpd support virtual users?
A) Yes, via PAM integration. Set "guest_enable=YES" in /etc/vsftpd.conf. This has the effect of mapping every non-anonymous successful login to the local username specified in "guest_username". Then, use PAM and (e.g.) its pam_userdb module to provide authentication against an external (i.e. non-/etc/passwd) repository of users.
Note - currently there is a restriction that with guest_enable enabled, local users also get mapped to guest_username. There is an example of virtual users setup in the "EXAMPLE" directory.

In base a quanto indicato, l'unica modifica da fare in vsftpd è abilitare gli utenti guest ed indicare lo username con cui il servizio ftp si deve presentare al filesystem. La manpage avvisa però che, per una limitazione che in verità ritengo piuttosto utile, se vengono abilitati gli utenti "guest" tutte le login non anonime al server vengono mappate sullo username specificato nel parametro "guest_username". Non sarà quindi più possibile accedere al server ftp come utente "locale" ma solo come utente anonimo o guest.
Il contro è che un amministratore, accendendo con le proprie credenziali locali, ha molto più libertà di manovra rispetto a qualunque altro utente. Il pro è che in questo modo si possono slegare completamente le login del servizio ftp da quelle del server, guadagnando molto in sicurezza.

In sostanza, le uniche modifiche da apportare al file di configurazione sono nella sezione "Configurazione utenti del server FTP.":

################################################
### Configurazione utenti del server FTP. #
################################################

## Utenti abilitati:
anonymous_enable=YES
guest_enable=YES
guest_username=ftp_pubblico
local_enable=YES

## Elenchi di utenti abilitati/esclusi dal server
userlist_enable=YES
userlist_deny=NO
userlist_file=/etc/vsftpd/ftp_pubblico_user_list

secure_email_list_enable=NO
email_password_file=/etc/vsftpd.email_passwords
deny_email_enable=NO
banned_email_file=/etc/vsftpd.banned_emails

max_login_fails=3
delay_failed_login=5
delay_successful_login=0

#user_config_dir=(none)
user_sub_token=$USER
virtual_use_local_privs=YES

Si tratta di abilitare il parametro "guest_enable" e valorizzare il parametro "guest_username" con l'utente desiderato. Non ci sarebbe bisogno di fare altro (se non intervenire sul modulo PAM) ma occorre fare alcune considerazioni: Che differenza c'è tra un utente anonimo ed un utente virtuale, in questa configurazione?
Sostanzialmente nessuna.
L'utente virtuale deve superare una login non prevista per l'utente anonimo ma, superata questa fase, i due utenti si presenteranno al sistema con le stesse identiche abilitazioni e limitazioni. Avendo indicato nel parametro "guest_username" lo stesso username utilizzato per mappare gli utenti anonimi, gli utenti virtuali si troveranno soggetti alle stesse limitazioni di accesso e scrittura in quanto vsftpd di default li gestisce come login anonime.

A questo proposito, il parametro "virtual_use_local_privs" funziona da discriminante: Abilitando questa opzione, agli utenti virtuali vengono applicate le abilitazioni e limitazioni previste per gli utenti locali, ripristinando quella differenziazione che ne giustifica l'implementazione. Rimane ovviamente il fatto che un utente virtuale è sconosciuto al filesystem e gli utenti ftp interagiscono con il sistema sempre e comunque presentandosi al sistema come l'utente indicato in "guest_username", con le limitazione in lettura e scrittura che ne conseguono e che sono implicite.
Eventualmente, impostare anche uno username diverso da quello utilizzato per le login anonime e lasciare a "0077" il valore di "local_umask", permetterebbe di ottenere un livello di separazione tra le due utenze praticamente equivalente quello ottenuto usando utenti anonimi e veri utenti "locali", anche indicando per la root di entrambe le login lo stesso percorso di filesystem.

Un altro dettaglio da tenere in considerazione è che gli utenti virtuali non hanno una home directory preimpostata che il sistema può utilizzare, ad esempio, come punto di accesso dopo il login dell'utente. A questo punto si ovvia valorizzando il parametro "user_sub_token", che fornisce una discriminate che il sistema può utilizzare. Ad esempio impostando "user_sub_token=$USER" e valorizzando il parametro "local_root=/download/ftp/$USER" si ottiene che l'utente virtuale "frakka" avrà la sua home directory impostata in "/download/ftp/frakka" (che deve esistere prima del login utente, vsftpd non la crea da sè) che potrà essere utilizzata come se fosse la home directory di un utente locale.

A questo punto, è necessario spiegare a vsftpd e PAM che sistema devono utilizzare per parlarsi. Come detto, è possibile utilizzare un'infinità di sistemi di autenticazione: A me ora interessa che PAM sia in grado di validare le richieste provenienti da vsftpd utilizzando un file di testo contenente username e password degli utenti che voglio autorizzare.
La libreria PAM che svolge la funzione di utilizzare un file di testo come sorgente dati su Debian si installa con il pacchetto "libpam-pwdfile" (su RedHat questa libreria non esiste pacchettizzata e deve essere compilata ed installata da sorgente).

root@server:/home/matteo# apt-get install libpam-pwdfile
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
libpam-pwdfile
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 15.5 kB of archives.
After this operation, 77.8 kB of additional disk space will be used.
Get:1 Index of /debian/ squeeze/main libpam-pwdfile amd64 0.99-4 [15.5 kB]
Fetched 15.5 kB in 0s (20.7 kB/s)
Selecting previously deselected package libpam-pwdfile.
(Reading database ... 58461 files and directories currently installed.)
Unpacking libpam-pwdfile (from .../libpam-pwdfile_0.99-4_amd64.deb) ...
Setting up libpam-pwdfile (0.99-4) ...
root@server:/home/matteo#

Ora non resta che spiegare a vsftpd quale modulo PAM interrogare per validare gli utenti che richiedono l'accesso. Questo si fà modificando il modulo PAM indicato nel parametro "pam_service_name" del file di configurazione. Si può modificare il file esistente o crearne uno nuovo, contenente solo le seguenti indicazioni:

#%PAM-1.0
auth required pam_pwdfile.so pwdfile /etc/vsftpd/ftp_pubblico_userdb
account required pam_permit.so

Chiaramente il mio database utenti sarà "/etc/vsftpd/ftp_pubblico_userdb". Il file è un semplice file di testo, che deve essere leggibile solo da root (o tramite sudo!) e che viene creato e popolato ricorrendo ad un semplice utility che sul mio sistema è già installata: htpasswd (credo venga installata come dipendenza di apache). Questa utility permette di archiviare le password cifrandole, in modo che non risultino mai in chiaro, come ulteriore misura di sicurezza.


L'utility usa la seguente sintassi:

# htpasswd -b file_che_contiene_le_password username password>

oppure

# htpasswd file_che_contiene_le_password username

Nel primo caso la password deve essere inserita nel comando che aggiorna il file, nel secondo caso verrà richiesto di inserirla due volte dopo aver premuto "invio". Per usare questa sintassi il file deve già esistere: Esso può essere creato con il semplice "nano" oppure con il comando "touch".
Per togliere un utente dal file delle password posso commentare con il classico "#" la riga relativa (utile per sospensioni temporanee) oppure usare il comando:

# htpasswd -D file_che_contiene_le_password username

per cancellarlo proprio dall'elenco.
Attenzione solamente al fatto che htpasswd non chiede conferme e non dà molti riscontri quindi è facile commettere errori se non si fà molta attenzione.

In alternativa è possibile anteporre a tutti gli argomenti il parametro "-c" che ha la funzione di creare il file. La sintassi diventa quindi:

# htpasswd -c file_che_contiene_le_password username
# htpasswd -c -b file_che_contiene_le_password username password

Attenzione però che usare il parametro "-c" sovrascrive un eventuale file già esistente azzerandone tutto il contenuto (facendo fuori, quindi, tutto l'elenco di utenti e password!) come detto senza richiedere alcuna ulteriore conferma ne avvisare in alcun modo di quanto accaduto.

Il contenuto del file si presenta in questo modo:

matteo:HNDXghTNuDTRA
paperino:LNX4nuEpmX4gM
pluto:7Fy8jRzbTHX2k
pippo:8VDvrS6tjBgqw
matteo@miodominio.it:kllb7seX2O8EU

Apportate le modifiche al modulo PAM, al file di configurazione, generato e popolato il file delle password e riavviato vsftpd, il server ftp è ora pronto per accettare login da utenti virtuali.

Perchè un utente virtuale possa però fare login sul server ftp così configurato, è necessario:
1_ Che il suo username e la relativa password si trovino nel file delle password;
2_ Che il suo username si trovi nella lista degli utenti abilitati al login (o non si trovi nella lista degli utenti cui il login è vietato);
3_ Che esista una home directory in cui l'utente di può loggare (ricordo che vsftpd non la crea da solo).



P.S:
Facendo qualche test, mi sono accorto che con un piccolo escabotage è possibile virtualizzare non necessariamente tutto l'utente ma solo la password: In pratica di tratta di eseguire l'intera procedura qui descritta senza però abilitare il parametro "guest_enable" nel file di configurazione di vsftpd. In questo modo, sono riuscito a loggarmi sul server come utente locale ma usando la password riportata nel file virtuale. In effetti è logico, cambiando il modulo di autenticazione ovviamente vsftpd chiede a PAM di interrogare il file degli utenti virtuali e non il file con le password di sistema.
Con questo sistema, l'utente deve comunque esistere tra gli utenti della macchina host, non è sufficiente che sia inserito nel file delle password. Deve inoltre essere definita una home directory a livello di sistema, non è sufficiente valorizzare il parametro "local_root" con un percorso unico per tutti gli utenti locali.

E' da verificare, ma potrebbe essere utile per usare utenti locali senza dover trasmettere via ftp la password di sistema.

[frakka]

Fin dall'inizio di questo thread, ho messo l'accento sul fatto che il protocollo FTP prevede la trasmissione in chiaro di dati e credenziali, fatto che costituisce un rischio per sicurezza del server, soprattutto nel caso vengano utilizzare le credenziali degli utenti locali.
La soluzione a questa "mancanza" del protocollo FTP è data dalle sue revisioni più recenti, con il supporto alla trasmissione cifrata di dati e credenziali tramite il protocollo SSL. Questa funzionalità deve ovviamente essere supportata sia dal server (ed il supporto c'è) che dal client (questo invece è più problematico).

Q) Does vsftpd support SSL / TLS based encryption?
A) Yes, as of v2.0.0, this is supported for the control and data connections (hurrah). You need a build of vsftpd with this support enabled, and then you need to activate the ssl_enable setting. NOTE there are security considerations with this support. Please make sure to read the ssl_enable section in the vsftpd.conf.5 man page thoroughly before using.

Starting of vsftpd version 2.0.0, SSL / TLS support is provided.

The SSL / TLS support provides the ability to encrypt FTP logins and subsequent commands, as well as the data transfers themselves. The encyption will, for example, stop the stealing of sensitive passwords via network snooping. By default, SSL support is disabled both at compile time and at runtime. Before considering enabling / using SSL support, there are some security considerations:

- Only enable SSL if absolutely necessary. Enabling SSL will allow attackers to make use of any security problems in the OpenSSL libraries. Note that the OpenSSL libraries are a large quantity of code and have had the occasional security problem in the past. For example, your server might use virtual users to control access to non-sensitive download content. In this case, the passwords might not be worth securing with SSL.

- After enabling SSL, consider restricting access to an SSL enabled server where feasible. For example, only the internal network might need access.

vsftpd supporta già da qualche versione la cifratura SSL sia della trasmissione delle credenziali che dei dati. E' necessario che vsftpd sia compilato con questo supporto abilitato ma la build di default ancora prevede questo supporto disabilitato sia a livello di compilazione che di esecuzione.
Il supporto a SSL infatti ha un rovescio della medaglia e non è la soluzione finale a tutti i problemi di un server ftp: Una connessione SSL, effettivamente, riduce o annulla il rischio che i dati e le credenziali degli utenti siano rubate intercettando il traffico di rete ma introduce altre considerazioni importanti. Infatti, se ci mette al riparo da una nota mancanza del protocollo FTP, implementare questa funzionalità espone ai problemi di sicurezza che potrebbe avere la libreria OpenSSL: E' una libreria complessa e già in passato ha presentato problemi occasionali.
Inoltre le operazioni di cifra e decifra non gratis, ne in termini di prestazioni ne in termini di mantenimento dei certificati SSL. Per avere una qualche utilità, la logica vorrebbe che i certificati non fossero autofirmati ma acquisiti da Certification authority riconosciute e che non li rilasciano gratis... Inoltre, la corretta implementazione lato server è inutile se anche il client non supporta correttamente questa tecnologia. A questo proposito, ci sono alcuni comandi specifici necessari per il corretto funzionamento delle sessioni SSL che devono essere implementati, se si è previsto di restringere il set di comandi autorizzati sul server. Con il precedente metodo dell'analisi dei log, ho individuato i seguenti comandi: AUTH, PBSZ e PROT

La manpage di vsftpd propone, anche in questo caso, una oculata gestione degli accessi al contenuto come la soluzione migliore: Ad esempio, non ha senso attivare SSL su un server per il quale è abilitato il solo download anonimo, o usare SSL per proteggere un server che usa le credenziali locali per accedere a files di scarsa importanza quando basterebbe magari implementare utenze virtuali. O, ancora, un server che assolutamente necessiti di SSL per proteggere le credenziali degli utenti che vi si connettono esclusivamente da una rete locale potrebbe non essere messo in ascolto sull'interfaccia pubblica...



Fatte le opportune considerazioni, per attivare il supporto SSL in vsftpd è necessario agire su queste parti del file di configurazione:

#################################################
### Configurazione supporto SSL del server FTP. #
#################################################

## Attivazione del supporto SSL
ssl_enable=NO
debug_ssl=NO
implicit_ssl=NO
require_ssl_reuse=YES
strict_ssl_read_eof=NO
strict_ssl_write_shutdown=NO

Il parametro "ssl_enable" abilita o meno il supporto a SSL che permette la cifratura sia del canale dati che del canale di controllo. Perchè il supporto SSL funzioni è necessario che sia abilitato nel file di configurazione ma anche che vsftpd sia stato compilato con questo supporto abilitato.
Il parametro "debug_ssl", se abilitato, scrive la diagnostica SSL nel log di vsftpd.
Il parametro "implicit_ssl", se abilitato configura vsftpd per attendersi solo comunicazioni SSL, compreso l'iniziale handshake. In pratica questo parametro stabilisce se il server è un server esclusivamente SSL (enabled) oppure se supporta anche connessioni "explicit SSL" o tradizionali (non cifrate). In tal caso è necessario un secondo processo in ascolto. Lo standard prevede che un server ftp con SSL implicito tenti di avviare le connessioni sulla porta 990, quindi se è stata indicata la porta 21 questa dovrà essere specificata anche nella configurazione del client. Per la connessione SSL esplicita, invece, l'avvio della sessione cifrata avviene dopo il contatto iniziale che avviene comunque sulla porta 21.
Il parametro "require_ssl_reuse" forza la connessione dati a verificare che la "master secret" o chiave di cifratura usata per la connessione dati sia la stessa utilizzata per la connessione di controllo e quindi che sia la connessione di controllo che la connessione dati avvengano verso lo stesso interlocutore. Anche se sembra effettivamente una logica indispensabile, questo requisito manda in palla molti client e spesso deve essere disabilitato.
Infine, i parametri "strict_ssl_read_eof" e "strict_ssl_write_shutdown" sono sono altri due controlli di sicurezza che impongono che sia le operazioni di lettura che di scrittura di un file siano completate all'interno della connessione SSL e non terminate dall'interruzione delle stessa. A rigor di logica, è un'altra di quelle cose fondamentali per garantire l'integrità di una connessione ma, a quanto pare, pochi o addirittura nessun client supportano queste funzionalità.

## Protocollo SSL in uso e caratteristiche
ssl_tlsv1=YES
ssl_sslv3=NO
ssl_sslv2=NO
ssl_ciphers=DES-CBC3-SHA
rsa_cert_file=/etc/ssl/private/vsftpd.pem
#rsa_private_key_file=(none)
#dsa_cert_file=(none - an RSA certificate suffices)
#dsa_private_key_file=(none)

I parametri "ssl_tlsv1", "ssl_sslv3" e "ssl_sslv2" indicano, nell'ordine preferenziale i protocolli SSL permessi per la connessione. Il protocollo ssl_tlsv1 è il preferibile, nel caso siano tutti supportati.
Il parametro "ssl_ciphers" indica quali sono gli algoritmi di cifratura che vsftpd autorizza per la connessione. E' importante perchè permette di escludere eventuali protocolli che abbiano evidenziato problemi di sicurezza.
Il parametro "rsa_cert_file" deve essere valorizzato con il percorso del file .pem contenente il certificato tipo RSA da utilizzare per cifrare la connessione. La chiave SSL deve essere inclusa nel certificato, oppure deve essere indicata nel file che valorizza il parametro "rsa_private_key_file". Allo stesso modo, il parametro "dsa_cert_file" deve essere valorizzato con il percorso del file contenente il certificato tipo DSA da utilizzare per cifrare la connessione. La chiave SSL deve essere inclusa nel certificato, oppure deve essere indicata nel file che valorizza il parametro "dsa_private_key_file".
DSA ed RSA sono due diversi algoritmi di cifratura e portano allo stesso risultato. vsftpd suggerisce di utilizzare RSA per una serie di motivi, tra cui il fatto che DSA è nato per la firma piuttosto che per la cifratura e risulta piuttosto lento nelle fasi di decifra e verifica del certificato mentre RSA risulta più veloce nelle fasi di decodifica. Inoltre, DSA è stato sviiluppato dal governo americano e, a voler fare i pignoli, è sottoposto ad una serie di restrizioni per l'uso al di fuori dei confini americani, in particolare verso determinati paesi. Non c'è quindi motivo di usare DSA piuttosto che RSA nella situazione che stò analizzando.

## Validazione dei client
ssl_request_cert=YES
require_cert=NO
validate_cert=NO
#ca_certs_file=(none)

Il parametro "ssl_request_cert" configura vsftpd per chiedere al client che si connette un certificato SSL: non è detto che il client ne disponga ma non dovrebbe essere un problema a meno che il parametro "require_cert" non sia abilitato (e che quindi il client disponga di un certificato client da presentare) e che tale certificato sia validabile, se previsto dal valore del parametro "validate_cert". Questa configurazione esclude tutti i certificati autofirmati, dato che un certificato self-signed non ottengono un "validate" corretto.
Il parametro "ca_certs_file" indica il percorso della chiave SSL che dovrebbe validare i certificati ricevuti dai clients.

## Utenti autorizzati all'uso di SSL
allow_anon_ssl=NO
force_anon_data_ssl=NO
force_anon_logins_ssl=NO
force_local_data_ssl=YES (non anonimi)
force_local_logins_ssl=YES

Infine, questi ultimi parametri definiscono quali utenti del server sono abilitati o meno ad utilizzare connessione SSL. Il parametro "allow_anon_ssl" autorizza o meno le login anonime all'uso di SSL, mentre le due coppie di parametri successive definiscono se le login devono essere o meno costrette all'uso della connessione SSL per la trasmissione dei dati (data) e/o delle credenziali (logins). In questo caso, la distinzione è tra login anonime (anon) e tutte le altre (local).


A questo punto è necessario ottenere il certificato da indicare nel parametro "rsa_cert_file". Ovviamente avere un certificato "vero" sarebbe meglio ma per fare qualche test va benissimo un certificato autorfirmato, che posso generare con openssl.
Il primo passo è generare la chiave privata (RSA Private Key, eventualmente da indicare nel parametro "rsa_private_key_file"). Per farlo, indichiamo ad openssl il tipo di certificato (genrsa), la cifratura da utilizzare (-des3), il nome del file in cui salvare (-out nomefile) e la lunghezza della chiave da utilizzare per il certificato (ho usato 2048 ma per scopi di test basterebbe pure 512... Per un uso reale una chiave da almeno 1536 dovrebbe essere un buon compromesso).

matteo@server:/etc/vsftpd# openssl genrsa -des3 -out ftp-server.key 2048

Il processo genera un pò di numeri casuali e chiede una password per generare la chiave. Per i miei test, "Nexthardware" andrà più che bene. Al termine, il file ftp-server.key conterrà qualcosa del genere:

----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,2FBCB35A622DEF96

1KW+qJb6alZjVbezzSq2sRBOiBg8SjEpBT9G9QkUW5G9IvsYsXZQKEhCvj77oiFq
hTOkPeYMPOhC5WnPVkF2dKbeXErsKuGvwy11cxqvW2WLcEpu6gxCrBk4wnX7/sQl
BixAX6GJWJOGEfsS6+eHoUWOo7dBDk+BKPoqQZcC7dmNmicPeQLo8vkEvMl0zcTg
vD8TY/5TEfALFKtI43+EjjbJ38jKae3tCEDf7uy3OwctSarjIJ8kqpaeFYreBf//
FHHf23skX4n98X44S2R5p4VXS1RYzeX2dOWD1LQEPt6GD+2KUwjHig0bYiFo4vFs
lWT9lQHKMqq5+oU5wLW/7FaM+R242X4SMcjHZqPeg0Pi1YDGdkY2jrIKB6atYGpr
IDUzJBofuNNeZNLL/FvnUBacrylRb1mLXspTXINqwNMRMMGJ8I5rAz3vLRIDMhmr
K941bOgAB7Y7BZCHsfAOnAeOgXKrVkS5881JT9LjuD+03m5Ij/Yt1bEBaN7gwj3S
q0wdxoePtDpKQT1FQ605kFDoNP7Vfrc+VnkfBU+G4SKsauLUBQUbrdqwJsW82VcK
GFuPcXkeau1hrK6Oq8LQcsidEqOuutfCpFTfRETO8fh0j1bbO5MjtjoJVrOIdfyy
t+zBNfXH1K9t0PSKJlj76SuRGiqL4oAnbUsY23Jf9qO2YP4o+OzNo7YPTFXHr4/D
dEJ8teLiXVAW2tKoVytZD4H370HjRhZKFwa3IHrW2L1UF7pCF5u7fecHIfn2PrdY
nb7fplr8XNv+ncmdVRfPK1to3ZMePMNU6X7voQhSzP2P3oruIO0gVpIxGfSTcGlb
rISguPvWh9Uy0ySAHu2wPCyHeZ7X6yEIYfpc3NRyBS7fts3je1CsQKEpifIZcBc/
Pav/6NDeeYJ2CGu4+2sO27FtW4NRh+U1AKetq1AuAw/Aw3TXM+Qf8v/TZBuhNuj7
Sdw58Cfb/9TNkdNz6MhUv38n4QIiwgX0MO3+Uw3/Us9GY/EQFWS0bxLGesS8QFk5
uVtbBm27or44vTMppbUVbOs6s3Dri/njYwq0/bakOE/An7bhSiZc4Tmb4IhwznZj
VyUBvcWUD/O+lJg2vrA2n+4/lQgtknoDcutqFIZ5iQvspM3f6FgCMi27KHeLuk19
VQpgD90lru5MGVQ0J88umjpqsM26SCclcwkCo6+UNE+gxNSFaqgIMbJeJjq1uuMb
4K87MvolH+bkhYOv1G4dAcOiBWP1n3xhcjB3ScygCZokFtyE6WSONqLq8pAKrdx+
4HYp1Www6d90HsnIqVCrg+Wx+kIoz2XxqFQ3hzEiH0FxQ6tJ0OYZomGIBf0eHL+i
ePNDIW/icvVnrbryPXISyPzggIAZ9j+m8cFdyJWNKE3vW9ZxWA2sYp2PnluLTCgi
pWQlE1U3vMUlAQDmEediiCieejuSti6SNkskCFz/BeswU2DtZctJEwiVwGCPVu+a
Wlacg+J6pvYGFbeZsPb+gQ5q0aHUukbEY9u/TSP4MDZoSx7UIANLVqF5X78wLs9r
bWUx1DQI4BYVUDCKjC3U+wb8yby04esK9ZpIFEb2qGvZwoQSOZEhFQ==
-----END RSA PRIVATE KEY-----

Il secondo passo è generare la richiesta di certificato (CSR - Certificate Signing Request) che dovremmo presentare all'autorità di certificazione perchè ci rilasci il certificato firmato. Ovviamente questa autorità di certificazione dovrebbe essere un ente verificato...
Il comando chiede la password inserita a protezione della chiave generata in precedenza (Nexthardware) e pone alcune semplici domande che andranno a completare i campi compilati nel certificato. Occorre prestare particolare attenzione al campo "Common Name (eg, YOUR name) []:" deve essere compilato il FQDN del server che utilizzerà il certificato, altrimenti avremo un warning che ci avvisa che il sito dispone di un certificato il cui nome non corrisponde. Dato che stò usando l'istanza sulla LAN per testare la configurazione dovrò inserire "ftp.fracassetti.lan"

matteo@server:~$ openssl req -new -key ftp-server.key -out ftp-server.csr
Enter pass phrase for ftp-server.key:
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) [AU]:IT
State or Province Name (full name) [Some-State]:Bologna
Locality Name (eg, city) []:Calcara di Crespellano
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Nexthardware
Organizational Unit Name (eg, section) []:Nexthardware Staff
Common Name (eg, YOUR name) []:ftp.fracassetti.lan
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Il che generara il file ftp-server.csr:

-----BEGIN CERTIFICATE REQUEST-----
MIIC2DCCAcACAQAwgZIxCzAJBgNVBAYTAklUMRAwDgYDVQQIEwdCb2xvZ25hMR8w
HQYDVQQHExZDYWxjYXJhIGRpIENyZXNwZWxsYW5vMRUwEwYDVQQKEwxOZXh0aGFy
ZHdhcmUxGzAZBgNVBAsTEk5leHRoYXJkd2FyZSBTdGFmZjEcMBoGA1UEAxMTZnRw
LmZyYWNhc3NldHRpLmxhbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AL3M5KnWKbiE/9/h3ZSnyXHopUyvWJ8dL5SNulYoWDQ8pEVUvErt8eREP4f8tK7Z
wdj1G1CGsW4JniBkADofW2PT3DifuTyo9lvF8YEG9Mba5wKZ+wdv9cx9R5ZDs7LJ
MmgnwAmr4Aa5LR0zlzQu4CZu67e7rch/IzYUzMJaPRwCcFxDMwLAhvW1y7QtTvrg
6leTpy2aG8g7sJx21NbPPJPDVU5CvrJBbFlfWVW3zxmsuaWzgQJSYM7J4Xg2e/Y0
PUMNmL8YceZyCK2fpNQ630t8J5mTV7ykym0i2/Aq+9HSvgTE3FkEJ5BgNhbmC8mx
iUissETauPhf0fAOOWDlO/cCAwEAAaAAMA0GCSqGSIb3DQEBBQUAA4IBAQBLRTCw
dX+9IIivbqfgWhIKsiABKx12xineh69SDzHVNwSprE3cEI+YYvghPAzmC3XZhpHf
rmIBpmpeEpw5da7f88HQhH4G9AFw0KMSlw3tYdKtbiTBRdDCd+bFkpndwN0UEzaW
Yv9amzhlBT9KDzN4BCgjM1bK2hVlSn3A+27u7epDVMO5TC0HgkSaH+w+kR6ilQ7a
mSV0VTOdE8qHedWgEQNAb5jyjhbUc64Q86dRdXQotJBvrz1quwOkZDxzhO8SU8tv
Pj2QSBWW8PECOkkyTd5ngCTp/1iaAW995oP5vPnIaMff6sH3u7OqGPXn70h6LTNN
6YU/N/Qe+4KphrD+
-----END CERTIFICATE REQUEST-----

Infine la richiesta così ottenuta va sottoposta all'autorità che rilascia il certificato. Per autofirmare il certificato possiamo usare il comando seguente, che genera il certificato "ftp-server.crt" nel formato "x509" derivato dalla richiesta di certificato valido per 365 giorni contenuta nel file ftp-server.csr, firmato con la chiave contenuta nel file ftp-server.key:

matteo@server:~$ openssl x509 -req -days 365 -in ftp-server.csr -signkey ftp-server.key -out ftp-server.crt
Signature ok
subject=/C=IT/ST=Bologna/L=Calcara di Crespellano/O=Nexthardware/OU=Nexthardware Staff/CN=ftp.fracassetti.lan
Getting Private key
Enter pass phrase for ftp-server.key:

Ovviamente ci viene richiesta la password per la decifra della nostra chiave privata, altrimenti non sarebbe possibile leggerne il contenuto.

Ora è però necessaria un'ulteriore operazione, perchè vsftpd sembra richiedere i certificati in formato PEM piuttosto che crt. Purtroppo una conversione diretta non è possibile ma openssl ci viene incontro con un doppio passaggio, passando per il formato DER:

matteo@server:~$ openssl x509 -in ftp-server.crt -out ftp-server.der -outform DER
matteo@server:~$ openssl x509 -in ftp-server.der -inform DER -out ftp-server.pem -outform PEM

Non conosco la differenza tra un certificato PEM,DER o crt... Dovrebbe limitarsi alla tecnologia usata per la cifratura o poco più...

Tirando le somme:

#################################################
### Configurazione supporto SSL del server FTP. #
#################################################
## Attivazione del supporto SSL
ssl_enable=YES
debug_ssl=YES
implicit_ssl=YES
require_ssl_reuse=YES
strict_ssl_read_eof=NO
strict_ssl_write_shutdown=NO

## Protocollo SSL in uso e caratteristiche
ssl_tlsv1=YES
ssl_sslv3=NO
ssl_sslv2=NO
ssl_ciphers=DES-CBC3-SHA
rsa_cert_file=/etc/vsftpd/SSL/ftp-server.pem
rsa_private_key_file=/etc/vsftpd/SSL/ftp-server.key
#dsa_cert_file=(none - an RSA certificate suffices)
#dsa_private_key_file=(none)

## Validazione dei client
ssl_request_cert=YES
require_cert=NO
validate_cert=NO
#ca_certs_file=(none)

## Utenti autorizzati all'uso di SSL
allow_anon_ssl=NO
force_anon_data_ssl=NO
force_anon_logins_ssl=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES

Ho usato le impostazioni sopra riportate per testare il mio server FTP. La configurazione funziona correttamente sia che si usi la forma implicita che la forma esplicita. Dato che questa configurazione è stata applicata all'istanza locale, non ho applicato SSL alle login anonime in primo luogo perchè credo sia un non-sense, in secondo luogo perchè in questa istanza locale le login anonime sono disabilitate.

Per applicare SSL sull'istanza pubblica, a mio parere può avere senso adottare la modalità esplicita: Senza cambiare altri parametri, con le login anonime attivate queste utilizzeranno una connessione in chiaro, le login "local" che invece scambiano delle credenziali, passeranno sotto SSL sia per la trasmissione dati che per le credenziali.

Possiamo quindi aggiustare il nostro file di configurazione come necessario ed avviare vsftpd con il solito comando:

vsftpd /etc/vsftpd/vsftpd_locale_SSL.conf

Ovviamente ci viene richiesta la password di accesso alla chiave privata. Purtroppo è un vincolo che non si può aggirare a meno di lasciare la chiave privata decifrata: E' un rischio di sicurezza ma è l'unico modo per far si che un server ftp con SSL possa ripartire automaticamente dopo, ad esempio, un reboot del server senza che un operatore sia presente ad inserire la password. Per de-cifrare la chiave, posso usare il comando:

root@server:/etc/vsftpd/SSL# openssl rsa -in ftp-server.key -out ftp-server-nopass.key

A questo punto, mi viene chiesto di inserire la password e, nel file "ftp-server-nopass.key" viene salvata la mia chiave privata decifrata, è quindi sufficiente indicare questo file nel parametro "rsa_private_key_file" per poter avviare il server con il supporto SSL e senza ulteriori richieste.




[EDIT:]
Oggi ho avuto alcuni problemi con il download di file tramite FTPS. La connessione è stata correttamente stabilita ma al tentativo di download di un file il server ha iniziato a riportare problemi con cifratura utilizzata. Ogni successivo tentativo di connessione su FTPS falliva, riportando errori nel protocollo.
Mettendo in debug SSL, i log di vsftpd registravano quanto segue:

Wed Jan 18 19:28:38 2012 [pid 2] DEBUG: Client "xxx.xxx.xxx.xxx", "SSL_accept failed: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher"

Non ho trovato alcuna documentazione in merito sul sito di vsftpd ma googolando ho trovato un sito che riportava una diversa sintassi per il parametro che indicata la cifratura da utilizzare:

#Some ciphers you can use:
#RC4-MD5,RC4-SHA,AES128-SHA,AES256-SHA
#Use AES256-SHA if you are paranoid
ssl_ciphers=AES256-SHA

Usando "ssl_ciphers=AES128-SHA" il problema è scomparso e il server sembra ora funzionare nuovamente in modo corretto.

[frakka]

Alla fine di tutto il percorso, credo di aver ormai capito quale può essere una configurazione che fà al caso mio. Implemento la sola istanza sulla rete pubblica, per ora mi basta questa tanto lato LAN il contenuto delle share sarà gestito via Samba.

Il file di configurazione sotto riportato, avvia un server ftp ipv4 in ascolto sulle porte standard, avviato in background al boot. Il server è abilitato alla sola modalità passiva, con il range delle porte dinamiche impostato da 31001 a 32000.
L'account non privilegiato usa l'utenza denominata "ftp_pubblico" ed il server si autentica verso il modulo PAM "vsftpd_virtual" che legge da un file di testo le password. Implementerò solo le password virtualizzate, abilitando la login degli utenti locali.

Il server è abilitato sia al download che all'upload, solo di tipo binario e solo con un set di comandi ristretto.

Gli utenti anonimi sono abilitati in chiaro e potranno effettuare solo download dei files contenuti nella directory indicata come loro home directory, tutte le operazioni di scrittura sono negate. Non sono abilitati gli utenti virtuali.
Gli utenti locali hanno la loro home directory nel livello superiore previsto per gli utenti anonimi, i permessi sono stabiliti dal filesystem. L'autenticazione avviene però sulle password memorizzate in un file di testo in modo che non siano mai trasmesse credenziali valide per l'accesso al sistema se non via ftp. Di default, tutti gli utenti locali sono chrootati all'interno della home indicata, con le eccezioni previste.

Il server utilizza SSL in modalità esplicita ma non per tutto: L'idea è di passare sotto SSL solo le login delle utenze locali (tutte) ed i trasferimenti dati relativi ai soli utenti locali "amministratori" per cui esista una eccezione al chroot e che potrebbero quindi far transitare anche dati non esclusivamente destinati al download pubblico, tutto il resto gira in chiaro.
In questo modo, gli utenti anonimi possono collegarsi al server ftp come se fosse un normale server in chiaro, solo gli utenti locali devono configurare il client per usare il server FTP con TLS in modalità esplicita, diversamente viene negata la login.
Per farlo, ho provato ad utilizzare una configurazione specifica per utente (che non avevo ancora trattato) che permetta di specificare che anche il traffico "data" deve essere passato sotto SSL.
Infine, per quanto riguarda il logging, ho abilitato i due log separati, a regime senza la registrazione di tutto il protocollo FTP ed il debug:

################################################################
# File di configurazione completo di tutte le opzioni standard
# previste per vsftpd, corretto con gli eventuali path indicati
# nel file di configurazione previsto di defautl per Debian.
#
# Tutti i campi sono valorizzati con le opzioni predefinite
# come indicate nella manpage del software al 27/11/2011 e
# raggruppate in sezioni.
# Il file così com'e' dovrebbe risultare funzionante, in quanto
# richiama senza alcuna modifica i valori predefiniti di vsftpd.
# Ho fatto riferimento ad un configurazione IPv4, commentando
# i valori che, se non valorizzati, impedirebbero l'avvio del
# server o che risultano mutualmente esclusivi rispetto alla
# configurazione base IPv4 adottata.
################################################################


################################################
### Configurazione del servizio server FTP. #
################################################

### Configurazione di rete del server
## IPv4:
listen=YES
listen_address=192.168.50.2
## IPv6:
listen_ipv6=NO
#listen_address6=(none)

background=YES
listen_port=21

### Modalita' di funzionamento (Attiva/Passiva):
## Attiva
port_enable=NO
connect_from_port_20=NO
ftp_data_port=20
## Passiva
pasv_enable=YES
pasv_min_port=31001
pasv_max_port=32000
pasv_addr_resolve=YES
pasv_address=ftp.miodominio.it

## Opzioni particolari di raro uso
port_promiscuous=NO
pasv_promiscuous=NO

### Account di sistema:
nopriv_user=ftp_pubblico
session_support=YES
pam_service_name=vsftpd_virtual
run_as_launching_user=NO


#################################################
### Configurazione funzionalita' del server FTP.#
#################################################

## Attivita' permesse sul server
download_enable=YES
write_enable=YES
ascii_download_enable=NO
ascii_upload_enable=NO
cmds_allowed=ABOR,APPE,AUTH,CDUP,CWD,DELE,FEAT,HELP,LIST,MKD,MDTM,NLST,NOOP,PASS,PASV,PBSZ,PROT,PWD, OPTS,QUIT,RMD,RNFR,RNTO,RETR,SIZE,STOR,SYST,TYPE,USER
#cmds_denied=(none)

lock_upload_files=YES
async_abor_enable=YES
delete_failed_uploads=YES
mdtm_write=YES

## Impostazioni predefinite per i permessi sui file
## e le directory create sul server via ftp
file_open_mode=0666
anon_umask=077
local_umask=077

## Opzioni particolari di raro uso
one_process_model=NO
setproctitle_enable=NO
tcp_wrappers=NO
use_sendfile=YES

## Opzioni di listing del server:
#ftpd_banner=(none - default vsftpd banner is displayed)
banner_file=/etc/vsftpd/ftp_pubblico_banner
dirmessage_enable=YES
message_file=.message
dirlist_enable=YES
ls_recurse_enable=NO
force_dot_files=NO
use_localtime=YES
hide_ids=YES
text_userdb_names=NO
tilde_user_enable=NO
#deny_file=(none) i.e. {*.mp3,*.mov,.private}
#hide_file=(none) i.e. {*.mp3,*.mov,.private}


################################################
### Configurazione utenti del server FTP. #
################################################

## Utenti abilitati:
anonymous_enable=YES
guest_enable=NO
guest_username=ftp_pubblico
local_enable=YES

## Elenchi di utenti abilitati/esclusi dal server
userlist_enable=YES
userlist_deny=NO
userlist_file=/etc/vsftpd/ftp_pubblico_user_list

secure_email_list_enable=NO
email_password_file=/etc/vsftpd.email_passwords
deny_email_enable=NO
banned_email_file=/etc/vsftpd.banned_emails

max_login_fails=3
delay_failed_login=5
delay_successful_login=0

user_config_dir=/etc/vsftpd/ftp_pubblico_userconfig
#user_sub_token=(none)
virtual_use_local_privs=YES

################################################
## Impostazioni valide solo per gli utenti anonimi.
ftp_username=ftp_pubblico
anon_root=/download/ftp
no_anon_password=YES
anon_upload_enable=NO
anon_mkdir_write_enable=NO
anon_other_write_enable=NO
anon_world_readable_only=YES
chown_uploads=NO
chown_username=root
chown_upload_mode=0600

################################################
## Impostazioni valide solo per gli utenti "non anonimi".
local_root=/download/
chroot_local_user=YES
chroot_list_enable=YES
chroot_list_file=/etc/vsftpd/ftp_pubblico_chroot_list
passwd_chroot_enable=NO
secure_chroot_dir=/var/run/vsftpd/empty
chmod_enable=YES


#################################################
### Configurazione supporto SSL del server FTP. #
#################################################

## Attivazione del supporto SSL
ssl_enable=YES
debug_ssl=NO
implicit_ssl=NO
require_ssl_reuse=YES
strict_ssl_read_eof=NO
strict_ssl_write_shutdown=NO

## Protocollo SSL in uso e caratteristiche
ssl_tlsv1=YES
ssl_sslv3=NO
ssl_sslv2=NO
ssl_ciphers=AES128-SHA
rsa_cert_file=/etc/vsftpd/SSL/server-ftp.pem
rsa_private_key_file=/etc/vsftpd/SSL/server-ftp.key
#dsa_cert_file=(none - an RSA certificate suffices)
#dsa_private_key_file=(none)

## Validazione dei client
ssl_request_cert=YES
require_cert=NO
validate_cert=NO
#ca_certs_file=(none)

## Utenti autorizzati all'uso di SSL
allow_anon_ssl=NO
force_anon_data_ssl=NO
force_anon_logins_ssl=NO
force_local_data_ssl=NO
force_local_logins_ssl=YES


###############################################
### Configurazione del logging del server FTP.#
###############################################
## Formato dei log
xferlog_enable=YES
vsftpd_log_file=/var/log/vsftpd_pubblico.log
xferlog_std_format=NO
xferlog_file=/var/log/vsftpd_pubblico.xferlog
syslog_enable=NO

## Contenuto del log
log_ftp_protocol=NO
dual_log_enable=YES

## Workaround ad un particolare bug sui sistemi Solaris.
no_log_lock=NO

###############################################
### Timeout del server. #
###############################################
accept_timeout=60
connect_timeout=60
idle_session_timeout=300
data_connection_timeout=300

###############################################
### Throttling del server. #
###############################################
local_max_rate=0
anon_max_rate=0
max_clients=0
max_per_ip=0
trans_chunk_size=0

#########################################################################
# Questa opzione si applica solo alle build non-PAM. Non e' il mio caso.#
# check_shell=YES #
#########################################################################

Il server ftp si avvia sempre da root (a meno che non intervengano complesse operazioni di configurazione ulteriori): sempre per una questione di sicurezza sarebbe bene applicare i permessi "400" (solo lettura, solo per il proprietario che nel mio caso è root, se dovesse cambiare il permesso va adeguato di conseguenza) a tutti i file di configurazione utilizzati, soprattutto se si decide di lasciare la chiave privata senza password. Si possono applicare ricorsivamente a tutta la directory, nel mio caso con il comando:

sudo chmod -R 400 /etc/vsftpd

Ho valorizzato questa volta il parametro "user_config_dir" che indica a vsftpd il percorso dover andare a leggere le eventuali configurazioni specifiche per utente. Queste configurazioni devono essere salvate in un file che ha il nome dell'utente (locale o virtuale) all'interno della directory indicata: ad esempio, il file "/etc/vsftpd/ftp_pubblico_userconfig/frakka" conterrà i parametri specifici da applicare a questo utente. Ovviamente non è possibile indicare in questo file impostazioni che vengono applicate prima del login (ip di ascolto, porte ) ma molte altre cose possono essere customizzate (ad esempio, l'applicazione o meno di SSL per la connessione dati), inoltre queste impostazioni vengono lette al login dell'utente quindi non è necessario riavviare il server ftp per applicarle.
Ad esempio, ho creato il file "/etc/vsftpd/ftp_pubblico_userconfig/frakka" contente le seguenti istruzioni:

#########################################################
# Configurazione specifica per utente. #
#########################################################

# Utente: frakka

file_open_mode=0777
local_umask=077

# Questi ".message" vengono mostrati solo a questo utente
message_file=.message-frakka

force_dot_files=YES
hide_ids=NO
text_userdb_names=YES
local_root=/home/$USER

force_local_data_ssl=YES

In questo modo, l'utente locale "frakka" ha i permessi per fare upload di files eseguibili, viene loggato nella sua home directory di sistema, gli vengono mostrati i file nascosti e il vero proprietario:gruppo di appartenenza, in formato leggibile. Inoltre il sistema gli mostra solo i messaggi a lui indirizzati (per contro, non vede più neppure i messaggi pubblici ma non dovrebbe essere un grosso problema).
Inoltre, per questo utente è richiesta la connessione SSL sia per la login (default del server) che per il canale dati.


[EDIT 18 gennaio 2012]
Modificato il valore del parametro "ssl_ciphers=AES128-SHA"

[EDIT 24 Febbraio 2012]
Mi sono accorto di un errore, che in effetti dovrebbe essere quasi ovvio: Creando un utente virtuale omonimo ad un utente locale, è vero che con la configurazione "per utente" che ho indicato sopra riesco a loggarmi nella mia home di sistema ma è altrettanto vero che il servizio ftp si presenta al sistema con l'utente non privilegiato indicato nella configurazione e non mi è quindi permessa alcuna modifica all'interno della mi home directory.
Nel mio caso mi stà bene potermi loggare usando lo stesso username di sistema ma per poter scrivere nella mia home directory è necessario aggiungere nella configurazione specifica per l'utente un diverso parametro "guest_username": Usando la configurazione sotto riportata solo la mia sessione si presenta al filesystem con il mio username e posso scrivere nella mia home directory, anche se per il login ho usato la password indicata nel file di testo invece di quella di accesso al server.

#########################################################
# Configurazione specifica per utente. #
#########################################################

# Utente: frakka

file_open_mode=0777
local_umask=077

guest_username=frakka

# Questi ".message" vengono mostrati solo a questo utente
message_file=.message-frakka

force_dot_files=YES
hide_ids=NO
text_userdb_names=YES
local_root=/home/$USER

force_local_data_ssl=YES

[frakka]

Come al solito, ogni parere o eventuale segnalazione di errori/omissioni sono ben graditi.