Come installare e configurare un server TFTP su Ubuntu 24.04

TFTP su Ubuntu 24.04: quando ha senso e cosa aspettarsi

TFTP è un protocollo minimale: niente autenticazione, niente cifratura, niente fronzoli. Proprio per questo resta utile in contesti molto specifici, soprattutto per bootstrap di apparati di rete, PXE, recovery di firmware e trasferimenti semplici in LAN controllata. Su Ubuntu 24.04 la scelta corretta è trattarlo come un servizio di supporto, non come un file server generico.

La regola pratica è semplice: se devi servire file a dispositivi che non hanno stack completi o che partono in modalità pre-boot, TFTP va bene. Se invece ti serve controllo accessi, audit, integrità forte o esposizione su reti non fidate, cambia tecnologia. TFTP non va esposto su Internet.

Su Ubuntu 24.04 la via più lineare è usare tftpd-hpa, che è leggero, stabile e abbastanza documentato da ridurre gli errori operativi. In questa guida parto dall’installazione minima, poi passo alla configurazione, ai permessi, al firewall e a un controllo finale che ti evita di scoprire i problemi quando un apparato deve fare boot.

Scelta del servizio: tftpd-hpa e directory di lavoro

Su Ubuntu 24.04 il pacchetto più comune è tftpd-hpa. Il suo vantaggio non è la ricchezza di opzioni, ma la prevedibilità: ascolta su UDP 69, serve i file da una directory radice ben definita e si integra bene con systemd.

Prima di installare, conviene decidere dove mettere i file. La scelta classica è /srv/tftp: è chiaro, non si confonde con dati applicativi e comunica subito che quel contenuto è servito da un demone. Evita directory casuali sotto /home o percorsi troppo permissivi.

Se il server deve servire file di boot, organizza già da subito una struttura semplice: una root TFTP con sottocartelle per modello, ambiente o tipo di immagine. Meno livelli inutili, meno errori di path lato client.

Installazione del pacchetto e verifica del servizio

Il primo passo è installare il demone e verificare che systemd lo riconosca. I comandi sono banali, ma conviene sempre verificare stato e unit prima di toccare la configurazione.

Comandi:

sudo apt update
sudo apt install -y tftpd-hpa
systemctl status tftpd-hpa --no-pager

Dopo l’installazione, l’output di systemctl status deve mostrare il servizio attivo o almeno una unit presente e caricata. Se vedi errori di avvio, il passo successivo è leggere i log di systemd prima di fare ipotesi:

journalctl -u tftpd-hpa -b --no-pager

Se il pacchetto non parte al primo colpo, il problema è spesso banale: directory radice inesistente, permessi errati o configurazione sintatticamente valida ma incoerente con il path scelto.

Configurazione base di tftpd-hpa

La configurazione principale di solito sta in /etc/default/tftpd-hpa. Il file definisce opzioni di avvio, directory root e, se serve, utente/gruppo del processo. Prima di editare, fai un backup del file attuale o salva una copia versionata.

sudo cp /etc/default/tftpd-hpa /etc/default/tftpd-hpa.bak.$(date +%F)

Una configurazione base sensata per Ubuntu 24.04 può essere questa:

RUN_DAEMON="yes"
OPTIONS="--secure --create --verbose --address 0.0.0.0:69 --user tftp --group tftp /srv/tftp"

Qui ci sono tre scelte importanti. --secure limita l’accesso alla directory root del server; --create permette la creazione di file, utile in alcuni scenari di provisioning ma da usare solo se serve davvero; --verbose aiuta in fase di test; --address 0.0.0.0:69 fa ascoltare su tutte le interfacce IPv4. Se non vuoi scritture dal client, togli --create.

Nota pratica: non attivare scrittura se il caso d’uso è solo download di immagini. In TFTP il rischio operativo non è teorico: un client male configurato o un dispositivo compromesso può sovrascrivere file se il demone lo consente.

Creazione della directory e permessi corretti

La directory radice deve esistere e deve essere leggibile dal servizio. Se hai scelto un utente dedicato, allinea ownership e permessi in modo coerente. Un setup minimale e leggibile è questo:

sudo mkdir -p /srv/tftp
sudo chown -R tftp:tftp /srv/tftp
sudo chmod -R 0755 /srv/tftp

Con questi permessi il server può leggere i file e i client possono scaricarli, ma non scrivere. Se ti serve upload, devi ripensare la policy e limitare ancora di più il perimetro di rete e i file system path coinvolti.

Carica un file di test nella root:

echo test | sudo tee /srv/tftp/test.txt > /dev/null
sudo ls -l /srv/tftp/test.txt

Il file deve risultare visibile con ownership coerente e permessi leggibili. Se già qui qualcosa non torna, non andare oltre: il problema è locale e non di rete.

Riavvio del servizio e controllo del listener UDP

Dopo la modifica della configurazione, riavvia il servizio e verifica che stia ascoltando davvero sulla porta 69 UDP. Senza questo controllo rischi di confondere un problema di firewall con un demone non partito.

sudo systemctl restart tftpd-hpa
sudo systemctl status tftpd-hpa --no-pager
sudo ss -lunp | grep ':69'

Nel caso corretto, ss deve mostrare un socket in ascolto su udp porta 69. Se non compare nulla, torna ai log di journald e controlla che il percorso della root sia corretto e accessibile.

Firewall: aprire solo ciò che serve

TFTP usa UDP 69 per la fase iniziale, ma poi i trasferimenti possono coinvolgere porte UDP effimere negoziate dal server. Questo è il punto che spesso crea confusione quando il servizio “sembra vivo” ma il client fallisce a metà trasferimento.

Se usi UFW, apri la porta 69/UDP almeno dalla rete di gestione o dalla subnet dei client legittimi. Esempio:

sudo ufw allow from 192.168.10.0/24 to any port 69 proto udp
sudo ufw status numbered

Se hai un firewall più rigido o una policy perimetrale, devi verificare anche il comportamento sulle porte UDP di ritorno. In molti ambienti la soluzione migliore è mettere TFTP in una VLAN di provisioning separata e limitare i client per subnet, non per singolo host.

Se il tuo scenario richiede aperture più ampie, documenta il motivo e il perimetro. TFTP non va trattato come un servizio “innocuo” solo perché è vecchio e semplice.

Test pratico dal client

Il test migliore è sempre quello più semplice: scaricare un file noto dalla root del server. Su un client Linux puoi usare tftp oppure atftp. Se il pacchetto non c’è, installalo sul client di test, non sul server di produzione solo per comodità.

tftp 192.168.10.20
get test.txt
quit

Se il file arriva correttamente, il path root e i permessi sono a posto. Se il client si connette ma non scarica, guarda subito i log del server e il firewall. Se non riesce nemmeno a parlare con il server, il problema è più a monte: rete, routing, ACL o IP errato.

Per un controllo più esplicito puoi usare anche una trace di rete:

sudo tcpdump -ni any udp port 69

Questo ti dice se il pacchetto arriva davvero al server. È un test molto più utile del classico “il servizio è attivo quindi dovrebbe funzionare”. In TFTP la differenza tra servizio up e trasferimento valido può stare tutta nella rete.

Accesso controllato e hardening minimo

La sicurezza di TFTP non si risolve con l’autenticazione, perché il protocollo non la prevede. Si lavora per riduzione della superficie d’attacco: subnet ristrette, host dedicati, filesystem pulito, nessuna scrittura se non indispensabile, e niente esposizione fuori dalla rete di provisioning.

Un approccio pratico è separare il server TFTP dal resto dei servizi. Se gira sulla stessa macchina di altri demoni, non concedergli directory condivise con contenuti applicativi. Una root come /srv/tftp con file statici riduce il rischio di errori di permesso e di contaminazione del contenuto.

Se ti serve un minimo di audit, usa i log del servizio e conserva una copia della configurazione. Non è un sistema di logging ricco, ma almeno ti permette di ricostruire quando è cambiato il path, quale utente viene usato e se il demone è stato riavviato.

Troubleshooting rapido quando il client non scarica

Quando qualcosa non funziona, conviene seguire sempre la stessa sequenza: raggiungibilità di rete, ascolto del demone, permessi sui file, firewall, poi comportamento del client. Saltare direttamente al tuning è quasi sempre tempo perso.

1. Verifica il listener: ss -lunp | grep ':69'. Se non c’è, il problema è sul servizio.
2. Verifica i log: journalctl -u tftpd-hpa -b --no-pager. Se vedi errori su directory o permessi, correggi quelli.
3. Verifica la root: ls -l /srv/tftp e presenza del file test.
4. Verifica il traffico: tcpdump -ni any udp port 69. Se non arriva nulla, è rete o firewall.
5. Verifica il client: path richiesto, maiuscole/minuscole, timeout e supporto TFTP del dispositivo.

Un errore frequente è confondere il nome file richiesto dal client con quello reale sul server. TFTP non fa magie: se il device chiede boot.img e sul server hai Boot.img, su sistemi sensibili al case il trasferimento fallisce.

Configurazione più robusta per ambienti di provisioning

Se il server TFTP serve PXE o immagini di recovery, conviene strutturarlo con sottodirectory e file ben nominati. Non mettere tutto in root. Esempio: /srv/tftp/pxelinux.0, /srv/tftp/boot/, /srv/tftp/vendor/. La logica deve essere leggibile anche da chi interviene mesi dopo.

In molti casi il TFTP non è l’unico tassello: DHCP indica al client dove trovare il bootloader, TFTP lo serve, poi il bootloader passa a HTTP o ad altri protocolli più robusti. Questa architettura è preferibile perché limita il ruolo di TFTP alla fase iniziale, dove fa quello che sa fare meglio.

Se stai preparando un ambiente di provisioning, documenta almeno tre cose: IP del server, directory root, file iniziale richiesto dal client. Senza questi dati, ogni troubleshooting diventa un giro a vuoto.

Backup, ripristino e manutenzione ordinaria

Il backup di un server TFTP è leggero ma va fatto bene: configura il servizio, salva il file /etc/default/tftpd-hpa, conserva la struttura di /srv/tftp e annota le regole firewall. In caso di restore, il problema non è tanto il volume dei dati quanto la coerenza tra configurazione e contenuto.

Per la manutenzione ordinaria controlla periodicamente tre punti: spazio disco, stato del servizio e integrità dei file serviti. Anche se TFTP è semplice, un disco pieno o un file rimosso per errore ti blocca esattamente nel momento peggiore, cioè durante un recovery.

df -h /srv/tftp
systemctl is-active tftpd-hpa
find /srv/tftp -maxdepth 1 -type f -ls

Se vuoi essere più rigoroso, conserva un inventario dei file serviti con checksum. Non è obbligatorio in ogni scenario, ma è utile quando le immagini cambiano spesso e vuoi sapere subito se il file sul server è quello giusto.

Conclusione operativa: pochi pezzi, ma messi bene

Un server TFTP ben fatto non è complicato: pacchetto corretto, directory root chiara, permessi stretti, firewall coerente e test dal client. La qualità del risultato dipende più dall’ordine operativo che dal numero di opzioni. Se il servizio serve apparati di rete o ambienti PXE, la semplicità è un vantaggio solo quando è accompagnata da disciplina.

Su Ubuntu 24.04, tftpd-hpa copre bene il caso d’uso classico. Il resto lo fanno la rete, i permessi e il controllo dei file pubblicati. Se questi tre elementi sono puliti, il server TFTP resta una componente affidabile e facile da mantenere.