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

[frakka]

Il protocollo FTP (File Transfert Protocol) è uno dei più antichi e longevi protocolli dell'era internet: La prima specifica è stata definita dal MIT all'inizio degli anni 70 ma ha subito continue migliorie ed evoluzioni per correggere i bachi riscontrati e implementare nuove funzionalità e caratteristiche di sicurezza.
Il protocollo originale infatti prevedeva, ad esempio, che tutte le trasmissioni (dati e credenziali) avvenissero in chiaro, caratteristica che rendeva semplice l'intercettazione e la conseguente compromissione di credenziali utente del server. Nelle versioni più recenti, l'implementazione della cifratura SSL per proteggere dati e credenziali (modalità che prende il nome di FTPS) e modalità di trasmissione meno sensibili alla presenza di un firewall lato client (passive mode).

Il protocollo nasce quando i files scambiati tra computer erano notevolmente più piccoli ma le connessioni anche più lente ed instabili: Quando l'idea di spedire come allegato ad una mail un video da 150Mb era ancora assurda anche per il più rintronato degli utenti, il protocollo FTP permetteva la creazione e gestione di filesystem remoti condivisi, introducendo alcune funzionalità importanti con il resume dei download interrotti, la possibilità di creare o eliminare file o directory sullo storage remoto e di navigare nel filesystem del server.
Per accedere ad un server ftp, la maggior parte dei sistemi operativi mettono a disposizione strumenti da riga di comando integrati ma sono disponibili anche client grafici o plugin per i principali browser che rendono l'uso di questi storage molto comodo e semplice per tutti: Il protocollo rimane quindi una validissima alternativa all'uso improprio delle e-mail per lo scambio di files tra utenti, rendendo molto più semplice il backup ed il restore dei files scambiati con questo sistema, piuttosto che come allegati a messaggi di posta elettronica.

Il protocollo FTP utilizza due connessioni TCP separate per gestire i comandi e lo scambio di istruzioni tra server e client. Il canale di controllo per i comandi è tipicamente in ascolto sulla porta 21 del server. Lo scambio effettivo di dati avviene su un'altra porta TCP e l'instaurazione di questo canale di comunicazione può seguire due modalità:
- In un canale dati di tipo attivo il client apre una porta tipicamente random (> 1023), tramite il canale comandi rende noto il numero di tale porta al server e attende che esso si connetta. Una volta che il server ha attivato la connessione dati al client FTP, quest'ultimo effettua il binding della porta sorgente alla porta 20 del server FTP.
- In un canale dati di tipo passivo il server apre una porta tipicamente random (> 1023), tramite il canale comandi rende noto il numero di tale porta al client e attende che esso si connetta.
Fonte: Wikipedia
Questo implica la necessità di gestire le porte del firewall in modo diverso a seconda che si scelga di implementare un ftp attivo, passivo o entrambi. La modalità passiva solitamente crea meno problemi in presenza di un firewall lato client, cosa piuttosto frequente sui moderni router ADSL usati per le connessioni domestiche a banda larga ma stranamente non è quasi mai la modalità predefinita e qualche client ha ancora difficoltà nel gestire questo sistema.

A quanto ho potuto capire, la soluzione che garantisce la maggiore compatibilità con i client è differenziare: Per un server FTP che deve servire una LAN è probabilmente meglio prevedere un server FTP attivo, per una server FTP che deve servire client sulla WAN è forse meglio configurare il server FTP in modalità passiva ed impostare server e firewall per operare solo all'interno in uno specifico range di porte dinamiche.
Qui è possibile trovare un'interessante spiegazione.

I server FTP disponibili sono molti e tutti con diverse caratteristiche. Non sono un esperto, la mia esperienza nell'uso e gestione di questo strumento è piuttosto ridotta, quindi quando ho dovuto scegliere un server ftp da installare nel mio serverino ho fatto una ricerca, letto qualche parere ed esaminato le varie feature rese disponibili dalle varie implementazioni e scelto quella che più mi stuzzicava.


01_ vsFTPd.

02_ Il file di configurazione.

02.1_Le opzioni disponibili per il file di configurazione. 1/2
02.2_Le opzioni disponibili per il file di configurazione. 2/2

03_ Server FTP in ascolto sulla rete locale.

04_ Server FTP sull'interfaccia pubblica con utenti anonimi e locali.

05_ Server FTP sull'interfaccia pubblica con utenti anonimi e virtuali.

06_ Server FTPS o FTP over SSL.

07_ Riassumendo.

08_ Fail2ban (Rimando a quanto scritto per un altro post).

• 8.1_ Fail2ban: fail2ban.conf
• 8.2_ Fail2ban: jail.conf
• 8.3_ Fail2ban: jail.local
• 8.4_ filter.d/
  • vsftpd-log.conf
  • vsftpd-xferlog.conf

[frakka]

Visitando la homepage di vsftpd, non si può non rimanere impressionati: Questa implementazione GPL del protocollo ftp vanta le migliori credenziali che si possano presentare: E' praticamente adottato da tutte le maggior distribuzioni linux per i propri server ftp, si presenta come una delle più performanti, stabili e sicure implementazioni di FTP per Unix, è ancora costantemente sviluppata e aggiornata e la lista (non esaustiva) delle feature comprende tutte le più sciccose funzionalità che si possano desiderare.
Per avere un elenco esaustivo di tutte le possibili opzioni e configurazioni supportate da vsFTPd è necessario consultare la manpage del server.

Per installare vsFTPd su debian è sufficiente lanciare, da root o tramite sudo, il comando

apt-get install vsftpd

Nel momento in cui scrivo, la versione che viene installata è la "2.3.2-3+squeeze2", una delle ultime release. Come punto di partenza per il sistema, considero il serverino che ho installato in precedenza, il worklog è quello riportato qui.

Una possibilità interessante di vsftpd è la possibilità di avviare istanze multiple: E' possibile infatti avviare un processo del demone ftp vincolato ad un singolo IP della macchina ed ognuno di questi processi può avere una configurazione diversa e indipendente dagli altri.
Sotto questo aspetto, l'implementazione di vsFTPd che viene fatta in RedHat/CentOS è molto più "facile" dell'implementazione che si trova in Debian: Su RedHat e derivate, infatti, è sufficiente creare dei file ".conf" all'interno della directory /etc/vsftpd/ che lo script di init avvia un'istanza per ogni file di configurazione che trova, senza dover fare altro.
A quanto ho potuto vedere, Debian purtroppo non prevede questa possibilità. Se si vuole implementarla è necessario togliere lo lo script di init del demone vsftpd dall'avvio automatico al boot ed inserire manualmente una linea all'interno dello script rc.local che avvii un'istanza di vsftpd per ogni specifico file di configurazione con una sintassi del tipo

vsftpd /etc/vsftpd/configurazione.conf

Ma perchè affrontare questa cosa? Qual'è l'utilità di poter utilizzare istanze multiple?
Usando istanze indipendenti del demone ftp posso, ad esempio, creare sull'interfaccia di rete pubblica del mio server un'istanza FTP configurata per essere molto restrittiva, che accede al mio filesystem solo presentandosi come utente non privilegiato e molto limitato, in cui gli utenti autorizzati al login sono diversi e completamente svincolati dagli utenti di sistema. In questo modo, anche la compromissione delle credenziali di un utente del servizio ftp non fornisce le credenziali di un account di sistema ad un potenziale intruso. Questo è un aspetto da non sottovalutare, soprattutto per un servizio che, a meno di non implementare anche la cifratura SSL della connessione, trasmette in chiaro dati e credenziali.
Parallelamente, posso configurare sulla scheda di rete affacciata verso la rete locale un'istanza ftp meno restrittiva, i cui utenti sono gli utenti di sistema e che può servire principalmente per gli usi interni di un ufficio. Al limite, questa istanza potrebbe essere addirittura anonima in lettura e scrittura ma è una cosa che non piace molto in generale.

Se una sola istanza del daemon è sufficiente, si può iniziare direttamente la configurazione dell'istanza e avviare il server. Se, come nel mio caso, si vuole invece avviare istanze multiple come prima cosa devo togliere dall'avvio automatico tramite init il daemon con il comando

sudo update-rc.d vsftpd remove

Un'alternativa comoda per gestire i runlevel di avvio è il comando chkconfig. Non è installato di default, quindi è necessario installarlo preventivamente con il comando:

sudo apt-get install chkconfig

Lo trovo un pò più comodo... Il comando per togliere vsftpd dalla sequenza di boot tramite init-script diventerebbe:

sudo chkconfig vsftpd off

e per verificare che tutto sia andato come previsto:

sudo chkconfig --list | grep -i vsftpd

che dovrebbe restituire qualcosa del genere:

vsftpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off

Effettivamente, forse non è indispensabile togliere vsftpd dalla sequenza di boot tramite init... Basterebbe forse configurare l'istanza avviata da init per uno specifico IP e l'altra avviarla come mi appresto a fare ma per una questione di uniformità preferisco così.

Comunque a questo punto è necessario che qualche altro sistema si occupi di avviare il server ftp al boot del sistema: L'unica soluzione che ho trovato, consiste nell'inserire delle righe nel file "/etc/rc.local", prima della righa "exit 0", una per ogni istanza del server che si vuole avviare.

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

vsftpd /etc/vsftpd/vsftpd_locale.conf
vsftpd /etc/vsftpd/vsftpd_pubblico.conf

exit 0

A questo punto, dato che non c'è uno script di init che avvia il processo, l'unico modo che ho trovato per arrestarlo è killarlo: Con questo comando ottengo una lista dei processi attivi, filtrata per il comando "vsftpd". Si vede chiaramente come il processo sia avviato dall'utente root e quale sia il PDI da killare, in base al file di configurazione con cui il server è stato avviato:

matteo@server:~$ ps -C vsftpd -f
UID PID PPID C STIME TTY TIME CMD
root 2052 1 0 Dec17 ? 00:00:00 vsftpd /etc/vsftpd/vsftpd_locale.conf
matteo@server:~$

Verificando a quale file di configurazione fà riferimento il mio server ftp, posso terminare il processo associato al PID con il comando:

matteo@server:~$ sudo kill 2052

[frakka]

Inizialmente pensavo di limitarmi a commentare il file di configurazione previsto di default da Debian: La trattazione completa del file di configurazione di vsftpd è lunga, complessa e, probabilmente, fuori dalla mia portata.
Ho iniziato poi a prendere giù dalla manpage tutte le opzioni disponibili nel file di configurazione e a riportarle in modo da avere un file di configurazione completo di tutte le opzioni, anche se valorizzate con i valori di default e le correzioni necessarie per l'ambiente di Debian. A questo punto però tanto vale finire il lavoro e sperare che, in caso di errori, qualcuno sia così disponibile da correggermi.

Quella che segue, è la trasposizione di tutte le opzioni disponibili ad oggi nella manpage di vsftpd, raggruppate secondo un ordine che a me pare logico e valorizzate con le impostazioni di default suggerite dallo sviluppatore, ho apportato solo le citate correzioni necessarie per il funzionamento su debian.
Così com'è il file dovrebbe avviare un'istanza assolutamente di default di vsftpd e per comodità l'ho riportato anche in due allegati al post: uno con le correzioni a l'altro nudo e crudo come uscirebbe dalla manpage.

################################################################
# File di configurazione completo di tutte le opzioni standard
# previste per vsftpd, corretto con gli eventuali path indicati
# nel file di configurazione previsto di default 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.
################################################################

Quindi: Ho preso tutte le voci elencate nella manpage di vsftpd e le ho riassunte in due files, uno nudo e crudo e l'altro integrato delle correzioni necessarie per vsftpd su Debian. Ovviamente, farò riferimento a quest'ultima versione.

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

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

background=NO
listen_port=21

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

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

### Account di sistema:
nopriv_user=nobody
session_support=NO
pam_service_name=vsftpd
run_as_launching_user=NO

Dalla manpage, possiamo vedere che se il parametro "listen" è abilitato, vsftpd va in esecuzione in "standalone mode", il che significa (riassumendo molto malamente) che il demone non deve essere avviato come "servizio di sistema" dallo script di init ma lanciato come eseguibile a sè stante, magari anche inserito in uno script al boot ma non da init. E' il mio caso, dato voglio usare proprio questa modalità per gestire le istanze multiple.
Questo parametro gestisce il processo associato ad una connessione su IPv4, se ci serve il socket IPv6 è necessario abilitare il parametro "listen_ipv6" e disabilitare "listen" dato che queste due opzioni sono mutualmente esclusive. Se si vogliono, quindi, utilizzare entrambi i socket è necessario utilizzare due istanze diverse, configurate una per IPv4 e l'altra per IPv6.
I parametri "listen_address" e "listen_address6" indicano al server di mettersi in ascolto solo su uno specifico indirizzo IP (rispettivamente IPv4 e IPv6) ed è necessario esplicarli nel momento in cui si desiderano mettere in esecuzione più istanze.
Il parametro "background" è esplicativo: Se abilitato il task va in esecuzione in background (ma solo in "listen mode") e libera la riga di comando della consolle che lo esegue. Di default non è abilitato ma lo dovrà essere nel momento in cui si andrà ad utilizzare il server come "servizio".
Il parametro "listen_port" indica su quale porta il server ftp deve mettersi in ascolto. Il valore predefinito per il protocollo ftp è la porta 21.
Segue poi la modalità di funzionamento del server ftp: Come detto, è possibile scegliere tra la modalità attiva o la modalità passiva o anche attivarle entrambe. I parametri "port_" si riferiscono alla modalità attiva, i parametri "pasv_" a quella passiva, vsftpd sembra consigliare la modalità passiva, come scelta preferenziale.
Per entrambe le modalità ci sono i parametri "enable", cui seguono delle opzioni specifiche per la modalità. Per la modalità attiva è possibile specificare la porta su cui effettuare le connessioni dati (la "20" è il valore adottato storicamente. Può essere cambiato alcuni client potrebbero avere problemi, nel qual caso si può impostare il parametro "connect_from_port_20" a "YES"). Per la modalità passiva, è possibile specificare il range di porte dinamiche da utilizzare per la connessione dei client (min e max, in modo da agevolare con convivenza con i firewall lato server) e due opzioni, credo più che altro estetiche, usate da vsftpd per mostrare il nome host piuttosto che un indirizzo IP in fase di connessione del client in modalità passiva.
In ultimo, è possibile definire l'account utente con cui il servizio ftp si presenta al server per l'autenticazione degli utenti ed al filesystem, principalmente in caso di utenti anonimi. Il parametro "nopriv_user" indica appunto un account utente assolutamente senza privilegi da utilizzare per vsftpd e la manpage sconsiglia, di mantenere "nobody" ma di crearne uno ad hoc. Il parametro "session_support" indica il modo in cui vsftpd di relaziona con il sistema di autenticazione di Linux "PAM" (Pluggable Authentication Module): Se abilitato dovrebbe rendere più semplice il logging degli utenti, se disabilitato vsftpd richiede ancora meno privilegi per funzionare. Il "pam_service_name" è il nome del modulo pam utilizzato per autenticare gli utenti, è specifico della distribuzione e su debian ha un valore predefinito diverso da quello configurato in vsftpd quindi deve essere esplicitato.
L'opzione "run_as_launching_user" esegue il server FTP con le credenziali dell'utente che lancia il comando di start del server che non coincide necessariamente con il "nopriv_user". Meglio lasciare disabilitato perchè un uso non completamente consapevole, espone il server a gravi rischi di sicurezza inoltre impedisce altre funzionalità come il chroot degli utenti.

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

## Attivita' permesse sul server
download_enable=YES
write_enable=NO
ascii_download_enable=NO
ascii_upload_enable=NO
#cmds_allowed=(none)
#cmds_denied=(none)

lock_upload_files=YES
async_abor_enable=NO
delete_failed_uploads=NO
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

Questi parametri definiscono cosa il server ftp è abilitato a fare: Un server FTP può essere abilitato in upload, download o entrambe le modalità, con diverse modalità di trasmissione dei dati. In generale, il protocollo ftp nella sua forma completa e non regolamentata permette di creare, modificare o eliminare da remoto file o directory su tutto il filesystem del server.
I primi parametri sono auto-esplicativi: "download_enable" permette di specificare se è possibile o meno scaricare files dal server ftp, il parametro "write_enable" specifica se è possibile o meno effettuare via ftp operazioni di scrittura sul filesystem, quindi creazione, eliminazione e rinomina di files e directory.
Questo, indipendentemente dai permessi specifici dell'utente connesso al server quindi anche un utente che si connetta come "root" su un server "write_enable=NO" non potrà effettuare operazioni di scrittura.
Ovviamente ha senso abilitare il write nelle situazioni più "trusted" o quelle in cui è possibile risalire al responsabile di una determinata operazione, decisamente sconsigliabile per un ftp anonimo o inutile e pericoloso se l'FTP deve solo fornire accesso al download di files...
Segue poi il supporto a quello che si chiama "ASCII mangling": E' una modalità di trasferimento dati "legacy", ancora implementata soprattutto per questioni di compatibilità. A quanto ho capito, il trasferimento di dati in modalità ASCII comporta alcuni rischi di sicurezza, anche se vsFTPd dovrebbe essere in grado di predire questi problemi quindi è bene che rimanga tutto disabilitato, salvo necessità contrarie.
I parametri "cmds_allowed" e "cmds_denied" permettono di specificare un elenco separato da virgole che riporta quali comandi previsti dal protocollo FTP sono abilitati sul server e quali sono negati. I due comandi sono correlati in quanto se è abilitato "cmds_allowed" tutti i comandi non specificati sono "denied" mentre se è specificato "cmds_denied" tutto quello che non è specificato come vietato è permesso. I due comandi non sono però mutualmente esclusivi in quanto è possibile specificare entrambi i parametri. In questo scenario, però un comando non elencato viene vietato in quanto non elencato tra gli "allowed" e, in caso di sovrapposizione, la negazione ha sempre precedenza quindi tanto vale specificare solo i comandi "allowed".
Il parametro "lock_upload_files" effettua un lock sui files interessati da operazioni di upload e download in modo che i files in upload (write lock) non possano essere modificati in modo concorrente da più utenti ed i files in download (shared read lock) non possano essere eliminati o modificati mentre un utente li stà scaricando.
Il parametro "async_abor_enable" è un comando supportato dal server che, se non abilitato, potrebbe portare al crash di alcuni client in caso di annullamento del trasferimento di dati. L'opzione predefinita è, comunque, "NO".
Il parametro "delete_failed_uploads", chiaramente, elimina automaticamente tutti i file caricati sul server che si siano interrotti prima del completamento.
Il parametro "mdtm_write" permette l'aggiornamento dell'ora di modifica di un files, quando necessario.

Seguono poi tre parametri che gesticono i permessi applicati di default ai files ed alle directory creati via ftp. In pratica, le mask indicate in questi parametri lavorano per sottrazione: Il ragionamento che stà alla base di questa logica sembra complesso e perverso ma, con un pò di pratica, fila. Premetto che in tutte e tre le voci lo "0" iniziale indica che il valore numerico indicato è un valore espresso in forma ottale. In assenza dello "0" vsftpd tratta i valori numerici come interi in base 10, evento che la guida di vsftpd indica come un errore grave. I valori di queste 3 voci devono quindi sempre iniziare per "0", anzi in molte guide o in altre trattazioni, questi valori vengono riportati con uno "0" aggiuntivo (quindi 0077 o 0022), che rende in effetti più semplice allineare il calcolo che segue ma la guida ufficiale li riporta così e funziona correttamente in entrambi i modi quindi ho deciso di allinearmi alla versione della manpage.
La manpage riporta la seguente spiegazione:

file_open_mode
    The permissions with which uploaded files are created. Umasks are applied on top of this value. You may wish to change to 0777 if you want uploaded files to be executable.

    Default: 0666

Nelle faq troviamo poi questo trafiletto che aiuta a capire il funzionamento della mask:

Q) Help! Uploaded files are appearing with permissions -rw-------.
A1) Depending on if this is an upload by a local user or an anonymous user, use "local_umask" or "anon_umask" to change this.
 For example, use "anon_umask=022" to give anonymously uploaded files permissions -rw-r--r--.

Che significa?
Assumiamo di aver creato un nuovo files tramite un upload ftp. Con il valore "file_open_mode" non specificato nel file di configurazione (come nella configurazione di default su Debian) il nuovo files verrà creato con i permessi previsti dal valore di default di questa opzione e quindi "666" (ricordo che lo "0" iniziale indicale solo che si tratta di un valore numerico in forma ottale e non un intero decimale!).
Leggiamo gli esempi di seguito in verticale, per colonne:

- file_open_mode=0666 e local_umask=077 (default di vsftpd)
6 - 0 = 6
6 - 7 = 0
6 - 7 = 0

Come riportato a metà di questo post, il codice 6-6-6 riportato nella colonna a sinistra identifica i permessi di lettura e scrittura sul file per "user", "group" e "others" su un file. Sottraiamo la mask di vsftpd della colonna centrale e otteniamo il permesso risultante sul file, 6-0-0 che significa, appunto "-rw-------" come nel caso indicato dalla FAQ.

- file_open_mode=0666 e local_umask=022.
6 - 0 = 6
6 - 2 = 4
6 - 2 = 4

Applicando lo stesso procedimento alla mask "022", otteniamo 6-4-4 che corrisponde, appunto, a "-rw-r--r--".
In questo modo, un file creato via FTP risulterà sempre non eseguibile, a meno di non intervenire manualmente sui permessi. Se si vuole che i files di cui viene fatto l'upload possano poi essere eseguiti, è necessario intervenire prima di tutto sul parametro "file_open_mode" settando come valore "0777" e poi sul parametro "local_umask" oppure "anon_umask" in modo da ottenere come risultato una forma ottale che imposti gli attributi desiderati per gli utenti locali o anonimi.

Infine, il parametro "one_process_model" si applica solo ai vecchi kernel 2.4, il parametro "setproctitle_enable" mostra informazioni sulle sessioni correnti nell'elenco dei processi di sistema, "tcp_wrappers" richiede che vsftpd sia stato compilato con il suppporto a questa funzione e ci siya una variabile d'ambiente specificata per veicolare determinate connessione in ingresso, ed il parametro "use_sendfile" permette l'uso da parte di vsftpd di alcune "system call".

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

Questi parametri definiscono alcuni aspetti del server ftp relativi alla sicurezza ed altri relativi più che altro a questioni "estetiche".
I parametri "ftpd_banner" ed "banner_file" sono dei messaggi che il server mostra agli utenti nel momento in cui si connettono al server ftp. Messaggi corti possono essere indicati come "ftpd_banner", messaggi più lunghi e articolati possono essere indicati in un semplice file di testo indicato nel parametro "banner_file". Analogamente, anche i parametri "dirmessage_enable" e "message_file" regolano messaggi mostrati dal server agli utenti, in questo caso però relativi a specifiche directory: Con i messaggi abilitati la prima volta che, nel corso di una stessa sessione, un utente ftp entra in una directory in cui il server trova il file indicato nel parametro "message_file", il contenuto viene mostrato all'utente. Il valore di default trattandosi del nome di un file su Unix, indica un file nascosto con denominato "message". L'utente, in pratica, vede il messaggio solo la prima volta che nel corso della stessa sessione, entra nella directory in cui è stato posto il file ".message" (volendo, agendo sulla possibilità di specificare configurazioni per-utente, è anche possibile creare messaggi che vengono mostrati solo a determinati utenti e non ad altri).
I parametri "dirlist_enable" e "ls_recurse_enable" regolano la possibilità di eseguire comandi che elencano tutto il contenuto di una directory: Si può vietare completamente l'uso oppure impedirne solo l'uso in modalità ricorsiva che potrebbe comportare, se usato con siti molto grandi, problemi di prestazioni del server.
Il parametro "force_dot_files" stabilisce se i files il cui nome inizia per "." devono essere mostrati o meno: Come detto in precedenza, su Unix il "." davanti al nome di un file indica un file nascosto quindi impostare il parametro a YES ne forza la visualizzazione.
Il parametro "use_localtime" forza il server a mostrare data ed ora dei files contenuti usando l'ora locale mentre l'impostazione predefinita prevede di usare l'ora di Greenwich (GMT).
I parametri "hide_ids" ed "text_userdb_names" attivano invece funzionalità di sicurezza: "hide_ids" E' un mascheramento del vero nome dell'utente/gruppo cui appartengono i files e le directory presenti sul server e, se abilitato, utente e gruppo vengono sempre mostrati come "ftp". Il parametro "text_userdb_names" invece, se abilitato, mostra i nomi utente ed il nome del gruppo in formato testuale (mostrando cioè lo username od il groupname "leggibile") piuttosto che solo il corrispondente valore numerico che viene usato di default per una questione di prestazioni.
Il parametro "tilde_user_enable" interessa più che altro i client da riga di comando, in quanto permette al server di risolvere i percorsi espressi come il simbolo "~" seguito dallo username o dal nome di un file o una directory.
In ultimo, possiamo obbligare il server ftp a negare ad ogni costo l'accesso a determinati percorsi del filesystem o a determinati tipi di file valorizzando il parametro "deny_file" con delle espressioni regolari che diano delle corrispondenze. E' preferibile usare i permessi sul filesystem per negare o meno determinati accessi perchè l'implementazione di queste espressioni regolari è molto semplificata ma può risultare utile. Ogni regola però deve essere attentamente testata perchè ci sono delle limitazioni e possono esserci risultati inattesi. Questa funzionalità si completa con il parametro "hide_file" che ha solo lo scopo di impedire gli elementi che hanno delle corrispondenze nelle espressioni regolari indicate vengano mostrati nell'elenco dei files o delle directory presenti sul server. Questo però non nega in alcun modo l'accesso al files o alla directory quindi indicando ad esempio il percorso esteso sul filesystem è possibile accedere comunque ai files nascosti dal parametro.
Anche per questo motivo, è preferibile usare i permessi sul filesystem del server per gestire in maniera sicura le restrizioni di accesso.

[frakka]

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

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

## Elenchi di utenti abilitati/esclusi dal server
userlist_enable=NO
userlist_deny=YES
userlist_file=/etc/vsftpd.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=1
delay_successful_login=0

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

E finalmente si arriva alle opzioni che specificano al server quali sono gli utenti abilitati.
In questa sezione ci sono 3 parametri "enable" ma esistono sostanzialmente solo due tipologie di login: "anonimo" e "non anonimo".
Se il parametro "anonymous_enable" è attivato, è permesso l'accesso al server senza verifica delle credenziali utente. Questo non significa che non vengano richieste, semplicemente non vengono verificate. Inoltre, in questa modalità, anche l'uso delle username "ftp" oppure "anonymous" è considerato e trattato sempre come un accesso anonimo.
Se il parametro "guest_enable" è attivato, tutte le login non anonime sono considerate "guest" e devono trovare un riscontro nel sistema di autenticazione scelto. Un volta verificate, le login "guest" vengono rimappate, per l'interazione con il filesystem, sulle credenziali dell'utente indicato nel parametro "guest_username".
In ultimo abbiamo il parametro "local_enable" che è un particolare tipo di accesso "guest" che cerca sempre il riscontro della login nel file "/etc/passwd" in modo da validare gli utenti di sistema per l'accesso al server ftp. Questo parametro deve comunque essere abilitato ogni volta che si vuole permettere una login non anonima, anche per validare degli utenti virtuali piuttosto che gli utenti reali del server.

Seguono poi tre parametri "userlist" con i quali è possibile indicare il comportamento del server rispetto ad uno specifico elenco.
Se il parametro "userlist_enable" è attivato, il vsftpd carica la lista di utenti indicata nel file definito dal parametro "userlist_file". Come trattare questi utenti, dipende dal parametro "userlist_deny": Se è settato su "YES" allora gli utenti contenuti nella lista sono gli utenti a cui è negato l'accesso al server ftp, se è settato su "NO" allora a tutti gli utenti è negato l'accesso al server FTP a meno che non esplicitamente inclusi nell'elenco. Questa lista agisce sia sugli utenti locali che virtuali e l'eventuale negazione dell'accesso avviene prima della richiesta password, in modo da evitare l'inutile trasmissione (ricordo che avviene in chiaro) della password di un utente.

E' poi prevista la possibilità di implementare un sistema di "quasi anonimato": Come detto, anche in caso di login anonimo le credenziali vengono richieste anche se non verificate. I quattro parametri che seguono servono per fornire un elenco di password utilizzate per consentire l'accesso al server senza una vera e propria autenticazione.
Se il parametro "secure_email_list_enable" è abilitato, il server carica un elenco di password contenute (una per riga, senza spazi bianchi) nel file indicato dal parametro "email_password_file" (di default il file etc/vsftpd.email_passwords) e solo queste password possono essere utilizzate per effettuare un login anonimo. Parallelamente, è possibile attivare il parametro "deny_email_enable" in modo che il sistema carichi dal file indicato dal parametro "banned_email_file" (di default il file etc/vsftpd.banned_emails) un elenco di password cui è negato il login...
E' un sistema di protezione a bassissima sicurezza, utilizzabile solo per mettere in piedi velocemente un sistema di autenticazione veloce per contenuti di bassa criticità.

Il parametro "max_login_fails" ovviamente indica dopo quanti tentativi di login falliti la sessione di autenticazione deve venire chiusa dal server ed i due parametri successivi impostano il ritardo, in secondi, tra due tentativi successivi a seguito di un login fallito ("delay_failed_login") e dopo quanti secondi deve essere concesso l'accesso al server a seguito di un login riuscito ("delay_successful_login"). Aumentare il valore di timeout a seguito di login falliti può essere d'aiuto per contrastare tentativi di brute forcing, integrando con sistemi di Intrusion detection e/o analisi automatica dei log.

Infine, vengono definiti alcuni parametri che permettono di definire delle configurazioni specifiche per utente. Ovviamente non è possibile definire in questo modo delle opzioni lato server, che vengono cioè applicate prima della login dell'utente come l'ip di ascolto, i log del server, le restrizioni imposte ma molti altri parametri possono essere definiti creando, nel percorso indicato dal parametro "user_config_dir" un file di configurazione di vsftpd con il nome usato per il login dell'utente. Ad esempio, valorizzando il parametro "user_config_dir=/etc/vsftpd_user_conf", al login dell'utente "matteo" vsftpd caricherà per la sua sessione la configurazione indicata nel file "/etc/vsftpd_user_conf/matteo".
Il parametro "user_sub_token" utilizzato in congiunzione con gli utenti virtuali permette, basandosi su un template, di creare automaticamente alcuni percorsi come, ad esempio, una home directory per gli utenti virtuali. Il funzionamento è semplice da capire con un esempio: Se nella configurazione di vsftpd imposto la root del server ftp per tutti i login non anonimi come "local_root=/var/ftp/$USER" e setto il parametro "user_sub_token=$USER" allora la home directory per l'utente virtuale (o meglio: non anonimo) "frakka" che si collega al server ftp sarà "/var/ftp/frakka".

L'ultimo parametro "virtual_use_local_privs" specifica se agli utenti virtuali (intese come tutte le login non anonime che non trovano riscontro tra gli utenti locali ma che vengono autenticate in altro modo) devono essere applicate le configurazione previste per gli utenti anonimi o quelle previste per gli utenti locali (e quindi gli utenti presenti in /etc/passwd): Dipende sostanzialmente dalla configurazione del server e dagli utenti che saranno serviti: solitamente le configurazioni applicate alle login anonime risultano più restrittive, in particolare in termini di permessi "write".

Nelle due sezioni che seguono, vengono definite le citate restrizioni da applicare agli utenti anonimi e locali (o, meglio, non anonimi in generale).

################################################
## Impostazioni valide per gli utenti anonimi.
ftp_username=ftp
#anon_root=(none)
no_anon_password=NO
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

Il parametro "ftp_username" indica il nome utente che sarà usato dal server ftp per le relazioni col filesystem necessarie a gestire le rischieste degli utenti anonimi: File, directory, permessi verranno gestiti come se ad operare su di loro sia l'utente indicato da questo parametro. Immediatamente dopo il login il server tenta di portare l'utente all'interno della direcotry definita dal parametro "anon_root", se definito.
Il parametro "no_anon_password" permette di evitare che il server richieda la password per il login anonimo, permettendo di fatto l'accesso diretto senza richiesta di login.
Il parametro "anon_mkdir_write_enable" permette agli utenti anonimi di creare directory sul filesystem remoto a condizione che il server ftp permetta le operazioni di scrittura e che l'utente definito dal parametro "ftp_username" abbia i permessi di scrittura nel percorso. Questo parametro è però limitato alla sola creazione: il parametro "anon_other_write_enable" definisce se, oltre all'upload ed alla creazione di directory, gli utenti anonimi devono essere abilitati anche alle operazioni di rinomima ed eliminazione.
Un altro parametro che definisce una limitazione per gli utenti anonimi è "anon_world_readable_only". La definizione della manpage è scritta in modo poco chiaro ma, da quello che posso capire, permette agli utenti anonimi il download dei soli files che hanno i permessi di lettura abilitati per tutti gli utenti.
Infine, ci sono 3 parametri che definiscono un'azione automatica che il server può eseguire sui files caricati dagli utenti anonimi, il "chown". Le operazioni definite da questi parametri, se "chown_uploads" è abilitato, cambiano automaticamente il proprietario dei files uploadati da un utente anonimo dal valore definito nel parametro "ftp_username" al parametro "chown_username". L'utente definito da "chown_username" può essere un qualunque utente di sistema ma Debian sconsiglia di usare "root", anche se è il valore predefinito di vsftpd.
L'ultimo parametro cambia i permessi che vengono applicati ai files uploadati dagli utenti anonimi dal valore risultante dalla mascheratura dei parametri "file_open_mode" e "anon_umask" impostati per il server con il valore definito in "chown_upload_mode". Onestamente mi sembra un'operazione ridondante ma se hanno implementato questa funzionalità un motivo ci sarà pure...

################################################
## Impostazioni valide per gli utenti locali.
#local_root=(none)
chroot_local_user=NO
chroot_list_enable=NO
chroot_list_file=/etc/vsftpd.chroot_list
passwd_chroot_enable=NO
secure_chroot_dir=/var/run/vsftpd/empty
chmod_enable=YES

Analogamente a quanto visto prima, questa sezione si applica invece agli utenti che effettuano una login in generale "non anonima".
E' possibile definire, per gli utenti non anomimi, una direcotry specifica in cui far arrivare gli utenti immediatamente dopo il login con il parametro "local_root". Questo è utile soprattutto nel caso di utenti virtuali, che quindi non hanno una directory home sul filesystem ma possono ottenerla con la combinazione del paramentro "user_sub_token" (Esempio: local_root=/var/ftp/$USER)
Seguono poi tre parametri che permettono di rinchiudere gli utenti "non anonimi" all'interno di una jail chroot: In pratica li si costringe a rimanere all'interno della home directory definita per l'utente, senza la possibilità di andare a spasso per il filesystem del server.
Come detto in precedenza, un utente che si connetta con le credenziali locali di "root" su un server ftp abilitato in scrittura può accedere, leggere, modificare ed eliminare qualunque files presente sul filesystem del server, situazione che si presta a macelli immani.
La manpage riporta però un warning che accenna ad un'implicazione di sicurezza importante soprattutto per quegli utenti locali che hanno accesso al server in upload e ad una shell di comandi, consigliando di abilitare questa funzione solo se si è assolutamente consapevoli delle conseguenze.
La FAQ riporta questa spiegazione:

Q) Help! What are the security implications referred to in the "chroot_local_user" option?
A) Firstly note that other ftp daemons have the same implications. It is a generic problem.
The problem isn't too severe, but it is this: Some people have FTP user accounts which are not trusted to have full shell access. If these accounts can also upload files, there is a small risk. A bad user now has control of the filesystem root, which is their home directory. The ftp daemon might cause some config file to be read - e.g. /etc/some_file. With chroot(), this file is now under the control of the user. vsftpd is careful in this area. But, the system's libc might want to open locale config files or other settings...

In pratica, il (non troppo grave) rischio è che un utente malintenzionato che sia imprigionato nella propria chroot ma dotato di un accesso shell, possa costringere il server ftp a leggere dei falsi files di configurazione, facendoli passare per i veri files di sistema impostati dall'amministratore.
Questo problema non si presenta per un utente non costretto all'interno di una jail chroot: L'utente potrà forse vedere tutto l'albero del filesystem del server ma (se si tratta infatti di un utente non autorizzato) il tentativo di fare l'upload di un file di configurazione fasullo dovrebbe fallire in quanto sul server esiste già, probabilmente, un file omonimo con accesso limitato nel percorso di sistema o comunque l'utente non dovrebbe avere i permessi di lettura, scrittura e modifica su un percorso contenente file di configurazione del sistema.
Ovviamente, se un malintenzionato si logga al server ftp con le credenziali di root oppure se sul server tutto il filesystem ha permessi 777 (è un assurdo!), l'unica speranza è che il malintenzionato abbia pietà. Ma contro questo non c'è sistema di sicurezza al mondo che possa mettere al riparo...
La soluzione, come al solito, è un'attenta gestione dei permessi utente, sia per il server ftp che a livello di sistema.
L'azione di questi tre parametri può anche essere invertita: Le configurazioni possibili sono sostanzialmente due:

chroot_local_user=NO
chroot_list_enable=YES
chroot_list_file=/etc/vsftpd.chroot_list

In questa configurazione come impostazione predefinita non è imposta alcuna jail per gli utenti non anonimi ma è possibile attivare, tramite il parametro "chroot_list_enable" un elenco di utenti definito nel parametro "chroot_list_file" che devono essere ristretti.

chroot_local_user=YES
chroot_list_enable=YES
chroot_list_file=/etc/vsftpd.chroot_list

In alternativa, questa combinazione permette di attivare per tutti gli utenti non anonimi la jail chroot ed eventualmente di attivare, sempre tramite il parametro "chroot_list_enable" un elenco di utenti definito sempre dal parametro "chroot_list_file" che non devono essere ristretti e possono esplorare liberamente il filesystem del server (sempre compatibilmente con i propri permessi utente!!).
Gli ultimi tre parametri di questa sezione permettono di definire altre opzioni, il cui utilizzo è piuttosto specifico. La prima, definita dal parametro "passwd_chroot_enable" permette di derivare, direttamente dall'indicazione della home directory riportata nel file /etc/passwd, l'eventuale percorso in cui creare la jail chroot per il singolo utente locale. La seconda, definita dal parametro "secure_chroot_dir" è un directory vuota, in cui l'utente ftp non ha neppure i permessi di scrittura. L'opzione predefinita in Debian è diversa da quella prevista da vsftpd e quindi deve essere esplicitato però questa directory è usata solo quando non c'è necessità di concedere a vsftpd l'accesso al filesystem... Ma allora a cosa serve un servizio ftp?? Boh...
L'ultimo parametro permette agli utenti locali di usare un comando, specifico del protocollo ftp, che gli permette di cambiare i permessi sui files cui hanno accesso in scrittura direttamente attraverso la connessione ftp. Questa opzione esiste solo per gli utenti "non anonimi" e si attiva con il parametro "chmod_enable".

#################################################
### 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

## 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)

## 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 (non anonimi)
force_local_logins_ssl=YES

Queste sezione configura quella che è forse la feature più recente aggiunta al protocollo FTP: La cifratura SSL della comunicazione.
Di questa però, ne parliamo in un altro momento...

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

## Contenuto del log
log_ftp_protocol=NO
dual_log_enable=NO

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

In questa sezione è riportata la configurazione del logging di sistema. Per un server privato, una volta completato il setup iniziale magari poco importa ma per un server pubblico i log sono fondamentali. vsftpd prevede tue tipologie di log: La registrazione in un formato standard e l'altra nel formato proprio di vsftpd. Il vantaggio principale del formato standard è che è analizzabile senza particolati accorgimenti da tutti i tool e rimane compatibile con i predenti sistemi di statistica, l'altro non necessariamente, anche se dovrebbe essere più leggibile.
Il parametro "xferlog_enable" mantiene il log nel formato standard, con una registrazione dettagliata di upload e download. Il percorso di default del log di vsftpd è il file /var/log/vsftpd.log ma può essere cambiato valorizzando il parametro "vsftpd_log_file", molto utile in caso di istanze multiple, per separare i vari log.
Il file di log, come detto, può essere scritto nel formato standard o nel formato proprio di vsftpd: Il parametro "xferlog_std_format" stabilisce proprio questo e, se abilitato, scrive il log in formato standard mentre di default usa il logging di vsftpd. Se si scegli di scivere il log in formato standard, allora il percorso predefinito per il file di log diventa il valore del parametro "xferlog_file" che di default è /var/log/xferlog.
Il parametro "syslog_enable" stabilisce se i log di vsftpd nel devono essere rediretti, usando il formato di vsftpd, invece che nei file di log separati verso il normale log di sistema. Può avere la sua utilità per server molto poco usati ma credo sia preferibile un log separao, come da valore predefinito.
Il parametro "log_ftp_protocol" è poi una sorta di log esteso: registra tutte le richieste al server e le relative risposte. Molto utile per il debug ma su server piuttosto grossi rischia di generare log enormi. La manpage cita una relazione con l'opzione "xferlog_std_format"... Il mio inglese fà schifo ma anche quello dell'autore non scherza: Onestamente non capisco cosa voglia dire. Credo che sia la possibilità di registrare nel log in formato vsfptd quello che normalmente viene registrato solo nel log in formato standard.
Il parametro "dual_log_enable" mantiene in parallelo i due formati di log, standard e xferlog. Utile soprattutto per capire i pro e contro dei due sistemi per poi scegliere il più consono.
L'ultimo parametro "no_log_lock" è un workaround adottato per alcuni problemi rilevati su piattaforma solaris, altrimenti deve rimanere sempre disabilitato.

###############################################
### 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 #
#########################################################################

In queste ultime sezioni sono riportate le opzioni disponibili per la gestione delle connessioni e delle prestazioni del server, con le eventuali limitazioni impostabili per IP, numero di client, tipologia di utenti

[frakka]

Ma qual'è l'utilità di creare un server ftp sulla propria rete locale?
Effettivamente, salvo esigenze particolari, non molta. La maggior parte delle operazioni eseguibili via ftp in una piccola rete locale sono fattibili tranquillamente via samba, usando una comoda share di rete se configurata ad hoc.
Nel mio caso specifico, i grafici del nostro ufficio usano la funzione ftp integrata nella suite adobe per fare l'upload sul server web dei siti direttamente dai loro Mac, quindi si può usare lo stesso strumento (ftp) sia per gli upload dalla rete pubblica che dalla rete locale.
Più che altro, quella sulla rete locale è un'istanza a basso rischio intrusione, usabile per testare la configurazione e le modifiche soprattutto per quanto riguarda i permessi utente prima di riportarle sull'altra istanza in servizio sull'interfaccia pubblica senza provocare continue interruzioni di servizio.

Per questa istanza, ho creato i file di configurazione “vsftpd_locale.conf” che fornirà la configurazione del server ftp bindato sull'IP 192.168.100.150 sulla mia rete locale. La configurazione di questa istanza è molto basilare e senza particolari limitazioni essendo, appunto, ristretta alla sola rete locale.

Perchè la configurazione risulti funzionante, sono necessarie alcune azioni preventive. In primis, dovrò creare l'utente di sistema "ftp_locale" (che sarà comunque un utente con pochi o nessun privilegio) con cui il servizio ftp si presenta al sistema. Per comodità lo assegno allo stesso gruppo dell'utente "ftp" già esistente sul sistema.
Potrei anche usare l'utente creato di default da Debian ma creando un utente specifico per istanza posso creare un'ulteriore separazione, in quanto i processi si presentano al sistema con account utente diversi.

Per creare l'utente ho usato i seguenti comandi, che mi mostrano il gruppo cui "ftp" appartiene, creano l'utente e mi mostrano il risultato, per verifica:

matteo@server:/etc$ id ftp
uid=107(ftp) gid=112(ftp) groups=112(ftp)
matteo@server:/etc$ sudo adduser --gid 112 --disabled-password ftp_locale
Adding user `ftp_locale' ...
Adding new user `ftp_locale' (1004) with group `ftp' ...
Creating home directory `/home/ftp_locale' ...
Copying files from `/etc/skel' ...
Changing the user information for ftp_locale
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
matteo@server:/etc$ id ftp_locale
uid=1004(ftp_locale) gid=112(ftp) groups=112(ftp)

Dato che voglio utilizzare un banner un pò più carino da mostrare piuttosto che un semplice messaggio, creo il file "/etc/vsftpd/ftp_locale_banner" che conterrà, appunto, il banner da mostrare agli utenti ftp al momento della connessione:

matteo@server:/etc$ sudo mkdir /etc/vsftpd/
matteo@server:/etc$ sudo touch /etc/vsftpd/ftp_locale_banner
matteo@server:/etc$ sudo nano /etc/vsftpd/ftp_locale_banner
**************************************
**** Server FTP sulla rete locale ****
* *
* Tutte le attivita' del server sono *
* strettamente monitorate. *
**************************************

Ora non mi serve ma per completezza creo il file "/etc/vsftpd/ftp_locale_chroot_list" (anche se per ora sarà vuoto) che conterrà gli eventuali utenti su cui esistono (o meno!) delle restrizioni chroot con il comando:

matteo@server:/etc$ sudo touch /etc/vsftpd/ftp_locale_chroot_list

ed il file "/etc/vsftpd_locale_user_list"da cui il server leggerà invece l'elenco degli utenti abilitati all'accesso e che dovrà quindi contenere almeno un nome utente.

matteo@server:/etc$ sudo touch /etc/vsftpd/ftp_locale_chroot_list

In ultimo, copio il modulo autenticazione pam di default in una copia denominata "vsftpd_locale". Non è necessario, ma dato che dovrò modificare una copia dello stesso file per autenticare gli utenti sull'istanza affacciata sulla rete pubblica, tanto vale copiare quello di default in una copia che sia esplicativa dell'istanza cui si riferisce...

matteo@server:/etc$ sudo cp /etc/pam.d/vsftpd /etc/pam.d/vsftpd_locale

################################################################
# 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 cosi' 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.150.1
## IPv6:
listen_ipv6=NO
#listen_address6=(none)

background=YES
listen_port=21

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

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

Questa sezione configura l'istanza in modalità standalone e per l'esecuzione in backuground, in ascolto sulla porta 21 dell'IP 192.168.150.1
Ho attivato sia la modalità attiva che passiva, in modo che il client scelga quella che preferisce. Non ho necessità di fare particolari configurazioni sul firewall perchè le porte sulla rete interna sono aperte quindi non ho necessità di indicare un range utilizzabile per la modalità passiva.

### Account di sistema:
nopriv_user=ftp_locale
session_support=YES
pam_service_name=vsftpd_locale
run_as_launching_user=NO

Qui indico solo il nome l'account utente da utilizzare per l'istanza e il nome del modulo pam da utilizzare per l'autenticazione 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=(none)
#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=0777
anon_umask=077
local_umask=022

## 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_locale_banner
dirmessage_enable=YES
message_file=.message
dirlist_enable=YES
ls_recurse_enable=NO
force_dot_files=YES
use_localtime=YES
hide_ids=NO
text_userdb_names=YES
tilde_user_enable=NO
#deny_file=(none) i.e. {*.mp3,*.mov,.private}
#hide_file=(none) i.e. {*.mp3,*.mov,.private}

In questa sezione, viene abilitato il server sia al download di files che all'upload (o, meglio, alle operazioni di "write"), solo in "binary mode" in quanto la modalità ASCII è disabilitata.
Settando il parametro file_open_mode a 0777 permetto ai files che verranno uploadati sul server di essere eseguiti, compatibilmente con la mask specifica per login. Lascio la "anon_umask" a 077 anche perchè non abiliterò gli utenti anonimi e imposto la local_umask a 022, default di vsftpd. I questo modo, dopo l'upload i permessi applicati ai files saranno "755".
Indico poi il percorso del file contente il banner, abilito i messaggi per le directory, la visualizzazione dei files nascosti e la visualizzazione del vero username del proprietario dei files, in formato leggibile con la combinazione dei parametri hide_ids e text_userdb_names.

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

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

## Elenchi di utenti abilitati/esclusi dal server
userlist_enable=YES
userlist_deny=NO
userlist_file=/etc/vsftpd_locale_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=1
delay_successful_login=0

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

###################################################
## Impostazioni valide solo per gli utenti anonimi.
ftp_username=ftp_locale
#anon_root=(none)
no_anon_password=NO
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=NO
chroot_list_enable=NO
chroot_list_file=/etc/vsftpd_locale_chroot_list
passwd_chroot_enable=NO
secure_chroot_dir=/var/run/vsftpd/empty
chmod_enable=YES

Non ho abilitato ne gli utenti anonimi ne gli utenti guest, quindi gli unici utenti abilitati al login sono quelli che possono essere autenticati verso il files /etc/passwd del sistema.
Impostando "userlist_enable=YES" e "userlist_deny=NO" ottengo che solo gli utenti esplicitamente riportati nel file /etc/vsftpd_locale_user_list possono autorizzati ad accedere al server: Personalmente preferisco sempre negare per impostazione predefinita. Invertendo il valore del parametro "userlist_deny" la lista diventa automaticamente un elenco di utenti a cui è negato l'accesso mentre è consentito a tutti gli altri utenti locali.
Non avendo specificato un percorso per la root degli utenti locali, al login l'utente si troverà all'intero della propria home directory sul server. Se è necessario restringerlo a quel percorso è possibile attivare la jail chroot, altrimenti potrà esplorare il filesystem del server come consentito dai propri permessi utente.

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

Per ora non interessa.

###############################################
### Configurazione del logging del server FTP.#
###############################################
## Formato dei log
xferlog_enable=YES
vsftpd_log_file=/var/log/vsftpd_locale.log
xferlog_std_format=YES
xferlog_file=/var/log/vsftpd_locale.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 #
#########################################################################

Di questa sezione, mi interessa ora solo il logging.
Questa configurazione crea e mantiene separatamente due diversi file di log, rispettivamente nei files "/var/log/vsftpd_locale.log" e "/var/log/vsftpd_locale.xferlog". Nessuna attività del server ftp viene registrata nel log di sistema, tutto finisce in questi due files.
Con "tutto" intendo proprio "tutto": Avendo scelto di abilitare anche "log_ftp_protocol" nel log "/var/log/vsftpd_locale.log" vengono registrati tutti i comandi scambiati tra il server e tutti i client, usando il formato di logging di vsftpd. E' molto utile per il debug e per farsi un'idea di quali comandi devono essere autorizzati nel caso si voglia restringere ulteriormente il server ma il log cresce molto, è consigliabile disabilitarlo una volta testata a dovere la configurazione.
Nel secondo log "/var/log/vsftpd_locale.xferlog" vengono invece registrati solo i trasferimenti occorsi via ftp, nel formato compatibile con altri server ftp e gli strumenti di analisi tradizionale. Particolarmente utile per tenere traccia dell'attività del server e degli utenti.

Testo la configurazione lanciando il comando:

matteo@server:/etc/vsftpd$ sudo vsftpd /etc/vsftpd/vsftpd_locale.conf

E questo è il risultato:

[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.