1 11/10/2026 10 min

Installare VSFTPD su Ubuntu 24.04 e 22.04 senza lasciare il servizio esposto a caso

VSFTPD resta una scelta sensata quando serve un server FTP semplice, leggero e prevedibile su Ubuntu 22.04 o 24.04. Il punto non è “installarlo e basta”: FTP porta con sé porte multiple, autenticazione in chiaro se lasciata così com’è, e una superficie d’attacco che va ridotta subito. La strada corretta è: installazione pulita, configurazione minimale, isolamento degli utenti, TLS obbligatorio se il servizio deve essere usato davvero in produzione, e verifica finale con un client reale.

Qui sotto trovi una procedura unica, valida per entrambe le release Ubuntu. Dove cambiano i dettagli, lo segnalo. L’obiettivo è avere un servizio funzionante, testabile e reversibile, senza introdurre settaggi che poi non sai più spiegare al momento del troubleshooting.

1. Installazione del pacchetto e avvio del servizio

Su Ubuntu il pacchetto è nel repository ufficiale, quindi non serve aggiungere PPA o sorgenti esterne. Prima aggiorna l’indice, poi installa il demone e verifica che systemd lo veda correttamente.

sudo apt update
sudo apt install vsftpd
systemctl status vsftpd --no-pager

Se il servizio parte, dovresti vedere uno stato active (running). Se invece compare failed, il primo controllo va fatto su log e sintassi della configurazione, non su ipotesi astratte.

journalctl -u vsftpd -b --no-pager
sudo vsftpd /etc/vsftpd.conf

Il secondo comando è utile per far emergere errori di parsing o direttive incompatibili. Non sostituisce i log, ma accelera molto la diagnosi quando il servizio non sale dopo una modifica.

2. Backup della configurazione prima di toccare il file principale

Prima di modificare /etc/vsftpd.conf, crea una copia. È una banalità che evita di perdere il riferimento quando devi fare rollback in emergenza.

sudo cp /etc/vsftpd.conf /etc/vsftpd.conf.bak.$(date +%F-%H%M)

Se gestisci più server, meglio ancora usare un sistema di versioning dei file di configurazione. Ma anche una copia timestampata è sufficiente per tornare indietro senza improvvisare.

3. Configurazione base consigliata

La configurazione minima sensata dipende da un fatto semplice: vuoi utenti locali che accedano a una home dedicata, oppure un servizio anonimo? In ambito server quasi sempre la risposta corretta è utenti autenticati, accesso limitato e niente scrittura dove non serve.

Apri /etc/vsftpd.conf e imposta una base simile a questa. Le direttive sotto sono orientate a un uso comune: login con utenti di sistema, nessun accesso anonimo, scrittura permessa solo dove serve, e isolamento nella propria area.

listen=NO
listen_ipv6=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
chroot_local_user=YES
allow_writeable_chroot=YES
pam_service_name=vsftpd
user_sub_token=$USER
local_root=/home/$USER/ftp
xferlog_enable=YES
log_ftp_protocol=YES
utf8_filesystem=YES

Due note importanti. La prima: chroot_local_user=YES limita l’utente nella propria root FTP, riducendo il rischio di navigare l’intero filesystem. La seconda: allow_writeable_chroot=YES serve se la directory di root è scrivibile; senza questa direttiva, su molte installazioni moderne il login può fallire. Se puoi, è meglio progettare la struttura directory in modo che la root non sia scrivibile e usare una sottodirectory per gli upload, ma questa è una scelta architetturale, non un obbligo del demone.

Se il server deve ascoltare solo su IPv4, cambia listen_ipv6=NO e listen=YES. Evita di tenere entrambe le modalità attive senza aver verificato come il sistema risolve l’indirizzamento, perché in ambienti misti può creare confusione inutile durante il test.

4. Creare l’area FTP per un utente locale

Il modello più pulito è: utente locale esistente o dedicato, directory home con sottocartella FTP, permessi coerenti e accesso limitato. Questo evita di dare scrittura diretta sulla home, che in molti casi è una cattiva idea operativa.

sudo adduser ftpuser
sudo mkdir -p /home/ftpuser/ftp/upload
sudo chown nobody:nogroup /home/ftpuser/ftp
sudo chmod a-w /home/ftpuser/ftp
sudo chown -R ftpuser:ftpuser /home/ftpuser/ftp/upload

Con questa struttura, l’utente entra in /home/ftpuser/ftp ma può scrivere solo in upload. È una soluzione pratica perché separa il punto di atterraggio dal punto di scrittura, riducendo il rischio di errori e semplificando i controlli dei permessi.

Se vuoi una politica più rigida, puoi anche preparare una directory dedicata per ogni utente e assegnare proprietario e gruppi in modo esplicito. In ambienti multiutente conviene documentare la convenzione, altrimenti il troubleshooting sui permessi diventa un giro a vuoto.

5. Attivare TLS: se il servizio passa in rete, FTP in chiaro non basta

Se il server è raggiungibile da una rete non fidata, TLS non è opzionale. FTP senza cifratura trasmette credenziali e contenuti in modo esposto. VSFTPD supporta FTPS, cioè FTP con TLS esplicito, ed è la scelta più realistica in ambienti standard.

Serve un certificato valido. Se hai già una PKI interna o un certificato pubblico, usa quello. Non mettere chiavi private in chiaro nei documenti operativi e non lasciare file leggibili a utenti non privilegiati.

sudo mkdir -p /etc/ssl/vsftpd
sudo chmod 700 /etc/ssl/vsftpd

Inserisci poi in /etc/vsftpd.conf le direttive TLS adeguate al tuo certificato. Esempio con certificato e chiave già disponibili sul server:

ssl_enable=YES
rsa_cert_file=/etc/ssl/certs/vsftpd.crt
rsa_private_key_file=/etc/ssl/private/vsftpd.key
ssl_tlsv1=YES
ssl_tlsv1_1=NO
ssl_tlsv1_2=YES
ssl_tlsv1_3=YES
force_local_logins_ssl=YES
force_local_data_ssl=YES
require_ssl_reuse=NO

Le direttive per TLS vanno lette con pragmatismo. Forzare TLS per login e dati è la base. require_ssl_reuse=NO è spesso necessario per evitare problemi con alcuni client. Se hai client vecchi o integrati in software legacy, testa prima di imporre policy troppo rigide.

6. Porte passive e firewall: il punto che rompe più installazioni di quanto si creda

Molti si fermano al login funzionante e poi scoprono che il listing delle directory o il trasferimento file si blocca. La causa classica è la modalità passiva non allineata al firewall. FTP non usa una singola porta: oltre alla 21, servono porte passive aperte e coerenti con la configurazione.

Imposta un range controllato, ad esempio 40000-40100, e aprilo solo dove serve. Se il server ha un IP pubblico fisso, puoi anche indicarlo esplicitamente.

pasv_enable=YES
pasv_min_port=40000
pasv_max_port=40100
# pasv_address=203.0.113.10

Per UFW su Ubuntu, la regola base è questa:

sudo ufw allow 21/tcp
sudo ufw allow 40000:40100/tcp
sudo ufw status verbose

Se sei dietro NAT o un bilanciatore, pasv_address deve corrispondere all’indirizzo che il client vede dall’esterno. È uno dei casi più frequenti di “si connette ma non trasferisce”. Qui la verifica va fatta con un client remoto vero, non solo dal server stesso.

7. Riavvio, test e lettura dei log

Dopo ogni modifica significativa, riavvia il servizio e controlla lo stato. Non fare tre cambiamenti insieme senza test intermedio: quando qualcosa fallisce, non sai più quale parametro ha rotto cosa.

sudo systemctl restart vsftpd
systemctl status vsftpd --no-pager
journalctl -u vsftpd -n 50 --no-pager

Il test minimo funzionale dovrebbe coprire tre cose: autenticazione, listing directory e upload. Se hai un client FTP grafico, usalo; se preferisci CLI, lftp è più affidabile del vecchio client base per verifiche ripetibili.

sudo apt install lftp
lftp -u ftpuser ftp://127.0.0.1

Una volta dentro, prova almeno ls, put di un file piccolo e get dello stesso file. Se uno di questi passi fallisce, guarda prima i log del demone e poi i permessi filesystem. FTP spesso sembra un problema di rete, ma in realtà è un problema di permessi o di modalità passiva.

8. Hardening essenziale che vale la pena applicare subito

VSFTPD è già abbastanza sobrio, ma non significa che vada lasciato com’è. Ci sono alcuni accorgimenti che riducono il rumore operativo e la superficie esposta.

Disabilita ciò che non serve davvero: utenti anonimi, scrittura globale, accessi inutili. Se il servizio è solo interno, limita il firewall agli IP del segmento autorizzato. Se è pubblico, monitora i tentativi di login e valuta rate limit o meccanismi di protezione a monte, ad esempio tramite firewall o fail2ban.

Un controllo utile è verificare che il demone ascolti solo sulle interfacce previste:

ss -ltnp | grep vsftpd

Se compare su un indirizzo non atteso, la configurazione di ascolto va rivista subito. Anche qui, il principio è semplice: meno esposizione, meno possibilità di errori laterali.

9. Scenario di troubleshooting rapido quando qualcosa non funziona

Se il servizio non risponde, ragiona per layer. Prima verifica DNS e reachability se il nome host è coinvolto. Poi controlla il socket locale, quindi il firewall, quindi il demone, poi i permessi e infine la modalità passiva. È un ordine banale, ma evita di perdere tempo su dettagli secondari.

Tre controlli che danno subito segnale:

sudo systemctl is-active vsftpd
sudo tail -n 50 /var/log/syslog
sudo journalctl -u vsftpd -b --no-pager

Se vedi errori di autenticazione, controlla account e shell dell’utente. Se vedi errori di trasferimento, controlla porte passive e NAT. Se vedi 500 OOPS o errori simili, il problema è spesso nei permessi o in una direttiva incompatibile con la struttura directory scelta.

10. Rollback pulito se la modifica non regge

Quando qualcosa si rompe dopo una modifica, il rollback deve essere immediato e senza inventare rimedi creativi. Ripristina la configurazione salvata, riavvia il servizio e verifica di nuovo lo stato. Se hai cambiato firewall o certificati, annulla anche quelli in modo coerente.

sudo cp /etc/vsftpd.conf.bak.YYYY-MM-DD-HHMM /etc/vsftpd.conf
sudo systemctl restart vsftpd
systemctl status vsftpd --no-pager

Se il rollback non basta, il problema non è più “VSFTPD non parte”, ma la combinazione tra configurazione, permessi e rete. A quel punto conviene ripartire dall’ultima configurazione funzionante e reinserire un solo cambiamento alla volta, con test dopo ogni passo.

11. Configurazione di esempio completa per un caso comune

Se vuoi un punto di partenza concreto, questa base copre un’installazione tipica con utenti locali, chroot, TLS e porte passive. Adattala al tuo contesto prima di metterla in produzione.

listen=NO
listen_ipv6=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
chroot_local_user=YES
allow_writeable_chroot=YES
user_sub_token=$USER
local_root=/home/$USER/ftp
pam_service_name=vsftpd
xferlog_enable=YES
log_ftp_protocol=YES
utf8_filesystem=YES
ssl_enable=YES
rsa_cert_file=/etc/ssl/certs/vsftpd.crt
rsa_private_key_file=/etc/ssl/private/vsftpd.key
force_local_logins_ssl=YES
force_local_data_ssl=YES
ssl_tlsv1_2=YES
ssl_tlsv1_3=YES
require_ssl_reuse=NO
pasv_enable=YES
pasv_min_port=40000
pasv_max_port=40100

Questa configurazione non è “universale”, ma è abbastanza pulita da funzionare in molti casi reali senza eccessi. Se il server è dietro NAT, aggiungi la parte passiva con l’IP corretto. Se devi integrare utenti virtuali o mapping più complessi, cambia il design: non forzare VSFTPD oltre il caso d’uso per cui è più adatto.

12. Cosa controllare dopo il go-live

Dopo l’attivazione, controlla almeno tre aspetti: accessi riusciti, errori nei log e coerenza delle porte aperte. Se il servizio è esposto fuori dalla LAN, aggiungi anche un controllo periodico del certificato TLS e una revisione dei tentativi falliti.

In pratica, i segnali utili sono questi: systemctl status vsftpd deve restare green, i log non devono mostrare errori di chroot o handshake TLS, e un client esterno deve riuscire a fare listing e upload senza timeout. Se uno di questi tre punti fallisce, non considerare il servizio pronto.

Con Ubuntu 22.04 e 24.04 il lavoro non cambia molto: cambia soprattutto il contesto in cui lo metti. In rete locale puoi essere più permissivo; su Internet devi trattarlo come un servizio esposto, quindi TLS, firewall stretto, logging e rollback pronto. Il resto è rumore operativo.