Installare e configurare vsftpd su AlmaLinux 8

Installare vsftpd su AlmaLinux 8 senza lasciare il servizio esposto

Su AlmaLinux 8 la scelta non è solo “far partire FTP”, ma decidere quanto spazio dare al protocollo e come limitarne l’impatto. vsftpd resta una delle soluzioni più snelle per un server FTP classico, ma va trattato come servizio di supporto: utile per trasferimenti mirati, non come canale primario se hai già SFTP o un sistema di deploy più moderno.

La differenza pratica, in produzione, la fanno tre cose: autenticazione, isolamento degli utenti e cifratura. Se salti questi punti, il servizio funziona lo stesso, ma stai solo spostando il problema.

Installazione dei pacchetti e avvio del servizio

La base è semplice. Aggiorna i metadati, installa il demone e verifica che il servizio systemd sia presente e abilitabile all’avvio.

sudo dnf update -y
sudo dnf install -y vsftpd
sudo systemctl enable --now vsftpd
sudo systemctl status vsftpd --no-pager

Il controllo che interessa davvero non è solo “active (running)”, ma anche l’assenza di errori in journal. Se il servizio non parte, il primo posto da guardare è:

sudo journalctl -u vsftpd -b --no-pager

Su AlmaLinux 8, se il pacchetto è integro e la porta 21 non è già occupata da altro, il servizio dovrebbe salire senza interventi ulteriori. Se non succede, il conflitto più comune è una configurazione errata o una policy SELinux troppo permissiva o incoerente, non il demone in sé.

Configurazione minima sensata in `vsftpd.conf`

Il file principale è ` /etc/vsftpd/vsftpd.conf `. Prima di toccarlo, fai una copia di backup. Se poi introduci un errore, il rollback deve essere banale.

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

Per un setup base ma non ingenuo, la configurazione tipica parte da questi parametri:

anonymous_enable=NO
local_enable=YES
write_enable=YES
chroot_local_user=YES
allow_writeable_chroot=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
pam_service_name=vsftpd
listen=YES
listen_ipv6=NO

Il punto più delicato è `chroot_local_user=YES`. Serve a confinare gli utenti locali nella propria home, riducendo il rischio di navigazione fuori dal perimetro previsto. Su versioni recenti, però, se la directory di root dell’utente è scrivibile direttamente, vsftpd può bloccare l’accesso senza `allow_writeable_chroot=YES`. Questa opzione risolve il sintomo, ma non è una scusa per lasciare tutto scrivibile: meglio costruire una struttura con una directory di upload separata, non con la home interamente aperta.

Un esempio più pulito è questo: home non scrivibile, sottodirectory dedicata ai file.

sudo mkdir -p /home/ftpuser/upload
sudo chown root:root /home/ftpuser
sudo chmod 755 /home/ftpuser
sudo chown ftpuser:ftpuser /home/ftpuser/upload

In questo modo l’utente resta confinato nella propria area, ma può scrivere nella sottocartella autorizzata. È una scelta molto più difendibile rispetto a una home interamente modificabile.

Utenti locali, accesso dedicato e gestione dei permessi

Se il servizio deve servire solo alcuni account, conviene lavorare con utenti locali specifici e non con account generici. Crea l’utente, imposta shell non interattiva se non serve login SSH e definisci una password robusta o un flusso di provisioning coerente con la tua policy interna.

sudo useradd -m -d /home/ftpuser -s /sbin/nologin ftpuser
sudo passwd ftpuser

Se l’utente deve solo depositare file, la shell ` /sbin/nologin ` riduce la superficie d’attacco. Non è una barriera assoluta, ma evita accessi interattivi inutili. Se invece devi consentire anche operazioni di manutenzione via SSH, separa gli account: uno per FTP, uno amministrativo, con privilegi diversi.

Per ambienti con più utenti conviene valutare una lista di esclusione o un gruppo dedicato. vsftpd supporta controlli più fini, ma prima di complicare la policy verifica che il modello base regga: autenticazione locale, directory isolate, permessi coerenti e logging attivo.

Attivare FTPS: la parte che non andrebbe mai rimandata

FTP in chiaro espone credenziali e contenuti. Se il servizio attraversa reti non totalmente fidate, la protezione minima è FTPS esplicito. Non è elegante come SFTP dal punto di vista operativo, ma se devi restare su vsftpd è la strada corretta.

Serve un certificato valido. Può essere un certificato pubblico oppure interno, ma deve essere gestito come un asset sensibile: niente chiavi in chiaro in documenti, backup non protetti o condivisioni improvvisate.

sudo openssl req -x509 -nodes -days 365 -newkey rsa:3072 \
  -keyout /etc/pki/tls/private/vsftpd.key \
  -out /etc/pki/tls/certs/vsftpd.crt

Poi aggiungi i riferimenti in `vsftpd.conf`:

ssl_enable=YES
rsa_cert_file=/etc/pki/tls/certs/vsftpd.crt
rsa_private_key_file=/etc/pki/tls/private/vsftpd.key
force_local_data_ssl=YES
force_local_logins_ssl=YES
ssl_tlsv1=YES
ssl_tlsv1_1=NO
ssl_tlsv1_2=YES
ssl_tlsv1_3=YES
ssl_ciphers=HIGH

Se il client FTP non supporta FTPS esplicito, il problema non è del server: è un limite del client o della sua configurazione. In quel caso conviene cambiare client, non abbassare il livello di sicurezza del server solo per compatibilità storica.

Firewall, porte passive e perché il servizio “va su” ma non si connette

Uno degli errori più frequenti è aprire la sola porta 21 e dimenticare le passive. Il risultato è subdolo: il login può anche riuscire, ma il listing directory o il trasferimento falliscono. Per FTP moderno, soprattutto dietro NAT o firewall stateful, le passive sono la regola.

Definisci un range dedicato e rendilo esplicito in vsftpd:

pasv_enable=YES
pasv_min_port=30000
pasv_max_port=31000

Apri poi le porte nel firewall di AlmaLinux 8. Se usi firewalld, la verifica è immediata e reversibile.

sudo firewall-cmd --permanent --add-service=ftp
sudo firewall-cmd --permanent --add-port=30000-31000/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Se il server è dietro un NAT, devi anche dichiarare l’IP pubblico nel parametro corretto, altrimenti il client riceve indirizzi privati inutilizzabili. In quel caso usa:

pasv_address=IP_PUBBLICO_O_DNS

Questa è una delle cause più comuni di “connessione ok ma trasferimento no”. Il demone ascolta, il firewall sembra a posto, ma il canale dati viene negoziato verso l’indirizzo sbagliato.

SELinux: quando il blocco non è il firewall

Su AlmaLinux 8 SELinux è parte del gioco. Disattivarlo per “far funzionare tutto” è la scorciatoia sbagliata. Prima verifica i contesti e gli audit, poi correggi in modo mirato.

Se gli utenti devono caricare file in directory fuori dalla home standard o in percorsi gestiti da web server, i contesti possono bloccare scrittura e lettura. Controlla gli AVC recenti:

sudo ausearch -m avc -ts recent
sudo journalctl -t setroubleshoot --no-pager

Se il problema riguarda una directory personalizzata, può servire etichettarla correttamente. Esempio tipico per una directory di upload condivisa con il web server:

sudo semanage fcontext -a -t public_content_rw_t '/srv/ftp(/.*)?'
sudo restorecon -Rv /srv/ftp

Se `semanage` non è disponibile, manca il pacchetto di gestione policy; non improvisare con `setenforce 0` come soluzione stabile. Se devi fare un test temporaneo, trattalo come una verifica di diagnosi, non come configurazione finale, e riporta subito lo stato precedente dopo aver isolato la causa.

Verifica operativa: non fermarti a “il servizio è attivo”

La prova vera è un flusso completo: connessione, autenticazione, listing, upload, download, chiusura sessione. Se uno di questi passaggi fallisce, il servizio è solo parzialmente funzionante.

ftp -inv 127.0.0.1

Per un test più utile, usa un client compatibile con FTPS e verifica sia il canale di controllo sia quello dati. In alternativa, un controllo sintetico lato server ti dice se la porta è in ascolto:

sudo ss -ltnp | grep :21
sudo ss -ltnp | grep 30

Il primo comando conferma la porta di controllo, il secondo intercetta eventuali range passivi in ascolto o eventuali conflitti. Se non vedi il range configurato, non è detto che vsftpd sia rotto: spesso il client non ha ancora forzato una sessione che apra il canale dati.

Controlla anche i log applicativi. Su molte installazioni troverai evidenza utile nel journal di systemd o nei log di autenticazione del sistema. Il punto non è collezionare log, ma associare il sintomo al layer: autenticazione, policy, rete o filesystem.

Un profilo di configurazione pronto per produzione leggera

Se vuoi un profilo iniziale ragionevole, usa questo approccio: utenti locali, nessun anonimo, chroot, FTP esplicito solo se necessario, passive range definito, logging attivo e SELinux coerente. È una base più robusta di molte installazioni “funzionanti” ma fragili.

anonymous_enable=NO
local_enable=YES
write_enable=YES
chroot_local_user=YES
allow_writeable_chroot=YES
xferlog_enable=YES
xferlog_std_format=YES
use_localtime=YES
listen=YES
listen_ipv6=NO
pasv_enable=YES
pasv_min_port=30000
pasv_max_port=31000
ssl_enable=YES
force_local_data_ssl=YES
force_local_logins_ssl=YES

Questo profilo non è universale. Se il server deve gestire molti utenti, ambienti multi-tenant o directory condivise con il web server, vanno rivisti permessi, contesti SELinux e magari anche il modello di autenticazione. Ma come punto di partenza è pulito e difendibile.

Manutenzione, aggiornamenti e rollback

Un FTP server non si configura una volta sola. Va tenuto sotto controllo come qualsiasi servizio esposto. Aggiorna il pacchetto con la normale finestra di manutenzione, controlla le note di rilascio del repository e conserva sempre una copia della configurazione precedente.

sudo cp -a /etc/vsftpd/vsftpd.conf /etc/vsftpd/vsftpd.conf.pre-change
sudo systemctl restart vsftpd
sudo journalctl -u vsftpd -n 50 --no-pager

Se qualcosa si rompe dopo una modifica, il rollback corretto è semplice: ripristina il file precedente, riavvia il servizio e verifica connessione e login. Se hai toccato anche firewall o SELinux, annulla solo le modifiche introdotte in quel cambio, non tutto l’assetto di sicurezza.

In pratica: vsftpd su AlmaLinux 8 è facile da installare, ma vale la pena configurarlo come componente controllato e non come servizio lasciato a sé. FTP in chiaro, porte passive dimenticate e SELinux ignorato sono i tre modi più rapidi per trasformare un setup “banale” in un problema operativo. Se invece parti da isolamento, FTPS e verifiche reali, il servizio resta prevedibile e gestibile.