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

# Fail2Ban configuration file
#
# Author: Cyril Jaquier
#
# $Revision: 728 $
#

[Definition]

# Option: failregex
# Notes.: regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
# Values: TEXT
#
failregex = \[.+\] FAIL LOGIN: Client "<HOST>"\s*$                                                
                   \[.+\] CONNECT: Client "<HOST>"\s*$
# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

Ho adottato per questo file la regex prevista di default, con una modifica. Ho rimosso la regex "vsftpd(?:\(pam_unix\))?(?:\[\d+\])?:.* authentication failure; .* rhost=(?:\s+user=\S*)?\s*$" ed ho aggiunto "\[.+\] CONNECT: Client ""\s*$".

Questa aggiunta è rischiosa: Tutti i client che si collegano ad un server ftp provocano un registrazione del tipo

CONNECT: Client "124.227.190.252"

che viene matchata dalla regex.
In pochi però provocano più registrazioni di questo tipo in pochissimo tempo: Nel file jail.local ho impostato valore di "maxretry" per la jail "[vsftpd-log]" di "10" e, dato che il findtime predefinito è di "300" secondi, da quello che ho potuto vedere finora tutti gli IP che hanno provocato più di 10 "CONNECT" in meno di 5 minuti sono riconducibili a scanner. Lo stesso bot di Google non fà mai più di uno o due "CONNECT" nel findtime configurato, mentre uno scanner/bot ne può fare anche diverse decine.

Vediamo come va...

[frakka]

In questo log vsftpd registra le operazioni di trasferimento dati, upload e download.

Il filter che ho adottato per questo log è il seguente:

# Fail2Ban configuration file
#
# Author: Matteo Fracassetti
#
# $Revision: 001 $
#

[Definition]

# Option: failregex
# Notes.: regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
# Values: TEXT
#
failregex = \d+ <HOST> \d+ [(?:\|\/)\.+]{3,}.*$
            \d+ <HOST> \d+ .*etc.*passwd .*$
            \d+ <HOST> \d+ .*boot.ini .*$
# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

Praticamente tutte le regex sono ispirate alle registrazioni che ho trovato sempre generate da uno scanner o, più probabilmente, un bot relative a tentativi vari di accesso al file /etc/passwd o ad un file "boot.ini"...
La prima in particolare, dovrebbe matchare la presenza di due o più ripetizioni della sequenza di caratteri costituita da una o più "\" oppure una o più "/" seguite da uno o più "."

Sun Aug 19 22:53:56 2012 1 83.139.194.70 0 /etc/passwd a _ o a  ftp 0 * i
Sun Aug 19 22:53:57 2012 1 83.139.194.70 0 /..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\etc/passwd a _ o a  ftp 0 * i
Sun Aug 19 22:53:59 2012 1 83.139.194.70 0 /../\../\../\../\../\../\../\../\../\../\../\../\etc/passwd a _ o a  ftp 0 * i
Sun Aug 19 22:54:00 2012 1 83.139.194.70 0 /..\/..\/..\/..\/..\/..\/..\/..\/..\/..\/..\/..\/etc/passwd a _ o a  ftp 0 * i
Sun Aug 19 22:54:02 2012 1 83.139.194.70 0 /..///..///..///..///..///..///..///..///..///..///..///..///etc/passwd a _ o a  ftp 0 * i
Sun Aug 19 22:54:03 2012 1 83.139.194.70 0 /etc/passwd a _ o a  ftp 0 * i
Sun Aug 19 22:54:05 2012 1 83.139.194.70 0 /../\/../\/../\/../\/../\/../\/../\/../\/../\/../\/../\/../\/etc/passwd a _ o a  ftp 0 * i
Sun Aug 19 22:54:06 2012 1 83.139.194.70 0 /./.././.././.././.././.././.././.././.././.././.././.././../etc/passwd a _ o a  ftp 0 * i
Sun Aug 19 22:54:08 2012 1 83.139.194.70 0 /etc/passwd a _ o a  ftp 0 * i
Sun Aug 19 22:54:09 2012 1 83.139.194.70 0 /.\..\.\..\.\..\.\..\.\..\.\..\.\..\.\..\.\..\.\..\.\..\.\..\etc/passwd a _ o a  ftp 0 * i
Sun Aug 19 22:54:11 2012 1 83.139.194.70 0 /../../../../../../../../../../../../etc/passwd a _ o a  ftp 0 * i
Sun Aug 19 22:54:13 2012 1 83.139.194.70 0 /etc/passwd a _ o a  ftp 0 * i
Sun Aug 19 22:54:15 2012 1 83.139.194.70 0 /\..\..\..\..\..\..\..\..\..\..\..\..\etc/passwd a _ o a  ftp 0 * i
Sun Aug 19 22:54:16 2012 1 83.139.194.70 0 /.../etc/passwd a _ o a  ftp 0 * i
Sun Aug 19 22:54:18 2012 1 83.139.194.70 0 /.../etc/passwd a _ o a  ftp 0 * i
Sun Aug 19 22:54:23 2012 1 83.139.194.70 0 /....../etc/passwd a _ o a  ftp 0 * i
Sun Aug 19 22:54:24 2012 1 83.139.194.70 0 /\.../etc/passwd a _ o a  ftp 0 * i
Sun Aug 19 22:54:26 2012 1 83.139.194.70 0 /...\etc/passwd a _ o a  ftp 0 * i
Sun Aug 19 22:54:27 2012 1 83.139.194.70 0 /..../etc/passwd a _ o a  ftp 0 * i
Sun Aug 19 22:54:29 2012 1 83.139.194.70 0 /C:\etc/passwd a _ o a  ftp 0 * i

Sun Aug 19 22:53:56 2012 1 83.139.194.70 0 /boot.ini a _ o a  ftp 0 * i
Sun Aug 19 22:53:57 2012 1 83.139.194.70 0 /..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\boot.ini a _ o a  ftp 0 * i
Sun Aug 19 22:53:59 2012 1 83.139.194.70 0 /../\../\../\../\../\../\../\../\../\../\../\../\boot.ini a _ o a  ftp 0 * i
Sun Aug 19 22:54:00 2012 1 83.139.194.70 0 /..\/..\/..\/..\/..\/..\/..\/..\/..\/..\/..\/..\/boot.ini a _ o a  ftp 0 * i
Sun Aug 19 22:54:02 2012 1 83.139.194.70 0 /..///..///..///..///..///..///..///..///..///..///..///..///boot.ini a _ o a  ftp 0 * i
Sun Aug 19 22:54:03 2012 1 83.139.194.70 0 /boot.ini a _ o a  ftp 0 * i
Sun Aug 19 22:54:05 2012 1 83.139.194.70 0 /../\/../\/../\/../\/../\/../\/../\/../\/../\/../\/../\/../\/boot.ini a _ o a  ftp 0 * i
Sun Aug 19 22:54:06 2012 1 83.139.194.70 0 /./.././.././.././.././.././.././.././.././.././.././.././../boot.ini a _ o a  ftp 0 * i
Sun Aug 19 22:54:08 2012 1 83.139.194.70 0 /boot.ini a _ o a  ftp 0 * i
Sun Aug 19 22:54:09 2012 1 83.139.194.70 0 /.\..\.\..\.\..\.\..\.\..\.\..\.\..\.\..\.\..\.\..\.\..\.\..\boot.ini a _ o a  ftp 0 * i
Sun Aug 19 22:54:12 2012 1 83.139.194.70 0 /../../../../../../../../../../../../boot.ini a _ o a  ftp 0 * i
Sun Aug 19 22:54:13 2012 1 83.139.194.70 0 /boot.ini a _ o a  ftp 0 * i
Sun Aug 19 22:54:15 2012 1 83.139.194.70 0 /\..\..\..\..\..\..\..\..\..\..\..\..\boot.ini a _ o a  ftp 0 * i
Sun Aug 19 22:54:16 2012 1 83.139.194.70 0 /.../boot.ini a _ o a  ftp 0 * i

Non è decisamente perfetta, matcha delle occorrenze che non capisco... Ad esempio, impostando a "{2,}" il valore delle ripetizioni minime delle occorrenze rilevate venivano matchate anche queste righe:

Sun Aug 19 22:51:38 2012 1 83.139.194.70 0 /.forward a _ o a  ftp 0 * i
Sun Aug 19 22:51:38 2012 1 83.139.194.70 0 /.rhosts a _ o a  ftp 0 * i

Questi match scompaiono se si porta a il valore a 3 ma non ho ancora capito perchè...

E poi devo trovare il modo di matchare anche questo:

Sun Aug 19 22:53:45 2012 1 83.139.194.70 0 /..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f/etc/passwd a _ o a  ftp 0 * i
Sun Aug 19 22:53:45 2012 1 83.139.194.70 0 /..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f/boot.ini a _ o a  ftp 0 * i