Installare e configurare un server FTP su Windows Server 2019

Installare IIS FTP su Windows Server 2019 senza aprire più del necessario

Su Windows Server 2019 il server FTP non è un prodotto separato: si appoggia a IIS e va trattato come un servizio esposto in rete, con le stesse cautele che useresti per un web server. La differenza vera la fanno autenticazione, autorizzazioni NTFS, firewall e scelta tra FTP puro e FTPS. Se imposti male uno di questi punti, il servizio può sembrare attivo ma restare inutilizzabile da client e script.

La regola pratica è semplice: prima fai funzionare il flusso minimo in locale, poi apri l’accesso di rete, infine aggiungi TLS e restrizioni. Saltare i passaggi ti porta quasi sempre a debug confuso: connessione che parte ma non elenca directory, login che funziona in GUI ma non da client automatici, o errori passivi dovuti al firewall.

Classificazione operativa: change controllato, non “click e basta”

Questa è una modifica di configurazione con impatto potenziale sulla superficie d’attacco. Considerala un change controllato: serve una finestra, un punto di rollback e un test da client esterno. Il blast radius tipico è limitato al server e alle porte FTP, ma se usi IP pubblici, NAT o un bilanciatore devi includere anche le regole di rete e i profili firewall.

Stato atteso: un client FTP/FTPS si autentica, vede la home directory assegnata e può trasferire file nella cartella consentita. Stato osservato quando qualcosa non va: servizio “up” ma nessun listing, connessione accettata ma errore di permessi, oppure timeout in modalità passiva.

Prerequisiti minimi e scelta del modello di accesso

Prima di installare il ruolo, decidi tre cose: chi si collega, da dove si collega e se il traffico deve essere cifrato. FTP senza TLS è ancora diffuso in ambienti legacy, ma su Internet è una scelta debole; FTPS esplicito è la strada normale su IIS. Se hai client vecchi o appliance, verifica in anticipo se supportano FTPS e modalità passiva.

Ti servono almeno: un account di servizio o utenti dedicati, una directory dati su disco locale o volume dedicato, e una policy di rete che consenta le porte necessarie. Se usi autenticazione locale, prepara anche il gruppo Windows che gestirà l’accesso. Se invece vuoi limitare l’accesso a una subnet, conviene farlo sia a livello firewall sia, se possibile, lato IIS.

Installazione del ruolo e delle feature IIS FTP

Installa il ruolo con PowerShell o da Server Manager. Da CLI hai più controllo e un log chiaro del change. Il pacchetto minimo include IIS, compatibilità di gestione e le feature FTP. Se manca una di queste parti, il sito FTP non compare o non accetta configurazioni complete.

Comando tipico:

Install-WindowsFeature Web-Server, Web-Mgmt-Console, Web-FTP-Server, Web-FTP-Service, Web-FTP-Ext -IncludeManagementTools

Dopo l’installazione verifica che le feature siano presenti e che il servizio IIS sia operativo:

Get-WindowsFeature Web-FTP* , Web-Server | যেখানে {$_.InstallState -eq 'Installed'}

Se preferisci l’interfaccia grafica, passa da Server Manager → Add roles and features → Web Server (IIS) → FTP Server. La logica non cambia: il punto è non dimenticare il servizio FTP e le estensioni di gestione.

Creare il sito FTP e scegliere la root corretta

Apri IIS Manager, poi crea un nuovo sito FTP puntando a una directory dedicata. Evita di riusare cartelle di sistema o percorsi condivisi con altri servizi: separare i dati semplifica backup, quota e rollback. Un percorso come D:\FTP\site1 o E:\Data\FTP\incoming è molto più gestibile di una cartella dentro C:\inetpub\wwwroot.

Durante la creazione imposta subito il binding sulla porta giusta. In ambiente standard usa la porta 21 per il controllo; se hai vincoli specifici puoi cambiare porta, ma ricordati che molti client e firewall assumono la 21 come default. Scegli anche se partire con FTP anonimo disabilitato: nella pratica, quasi sempre è la scelta giusta.

Se vuoi farlo da PowerShell, puoi usare il modulo IIS. Il vantaggio è avere configurazione ripetibile e documentabile. Un esempio minimale è questo:

Import-Module WebAdministration
New-WebFtpSite -Name 'FTP-Site1' -Port 21 -PhysicalPath 'D:\FTP\site1'

Dopo la creazione controlla che il sito esista e che il binding sia quello atteso:

Get-ChildItem IIS:\Sites | Select-Object Name, State, bindings

Autenticazione: locale, dominio o gruppo dedicato

La parte più fragile è quasi sempre l’autenticazione. Su IIS puoi abilitare Basic Authentication e disabilitare Anonymous se vuoi controllare chi entra davvero. Se il server è in dominio, gli account AD sono la soluzione più pulita; in workgroup o in ambienti isolati puoi usare utenti locali dedicati.

Non usare account amministrativi per comodità. Crea invece utenti o gruppi con un nome che descriva il ruolo, ad esempio FTP_Users, e assegna solo i permessi necessari. Questo riduce il danno se una credenziale viene compromessa e rende più semplice capire chi ha accesso a cosa.

In IIS Manager apri il sito FTP, vai su FTP Authentication e abilita Basic Authentication. Poi in FTP Authorization Rules aggiungi il gruppo o gli utenti specifici con permessi di lettura o scrittura. Se lasci “all users” o “anonymous” aperto per test, ricordati che quello è solo un test: va chiuso appena il flusso è confermato.

Permessi NTFS: il punto che rompe tutto anche quando IIS è corretto

IIS non basta. Anche se il sito FTP è configurato bene, Windows continuerà a bloccare l’accesso se NTFS non consente lettura o scrittura alla cartella fisica. Il comportamento tipico è un login riuscito seguito da errore su LIST, CWD o STOR. In pratica il client si autentica, ma la directory non è accessibile.

Assegna i permessi in modo esplicito alla cartella root e, se serve, alle sottocartelle. Per una zona upload, spesso bastano Modify o un set più fine di permessi; per una sola area di download, Read & Execute è sufficiente. Non concedere Full Control per abitudine: è quasi sempre eccessivo.

Comandi utili per ispezionare e correggere i permessi:

icacls D:\FTP\site1
icacls D:\FTP\site1 /grant FTP_Users:(OI)(CI)M

Se usi un account di servizio per l’accesso ai file, applica il principio del minimo privilegio anche lì. Una cartella FTP non dovrebbe essere scrivibile da chiunque nel sistema, né condivisa con processi che non c’entrano nulla. Il problema classico è una share o un path ereditato da vecchie installazioni, dove i permessi sembrano “funzionare” solo perché sono troppo larghi.

Firewall e modalità passiva: senza questo il listing spesso fallisce

FTP è ingannevole perché usa una connessione di controllo e poi una o più connessioni dati. Se la modalità passiva non è configurata bene, il client entra ma non riesce a vedere o trasferire i file. Su IIS devi definire un intervallo di porte passive e aprirlo nel firewall di Windows, oltre alla porta di controllo.

Imposta un range ristretto, ad esempio 50000-50100, e apri solo quello. Range enormi complicano troubleshooting e aumentano la superficie esposta. Poi configura il range in IIS a livello server, non solo nel sito, così il comportamento resta coerente.

Esempio di configurazione con netsh per il firewall locale:

netsh advfirewall firewall add rule name="FTP Control 21" dir=in action=allow protocol=TCP localport=21
netsh advfirewall firewall add rule name="FTP Passive Range" dir=in action=allow protocol=TCP localport=50000-50100

In IIS Manager verifica FTP Firewall Support e imposta il range passive. Se il server è dietro NAT, inserisci anche l’IP pubblico o il nome DNS esterno previsto dal client. Questo dettaglio è quello che spesso separa un servizio che funziona in LAN da uno che funziona davvero da Internet.

Abilitare FTPS invece di lasciare traffico in chiaro

Se il servizio esce dalla rete fidata, abilita FTPS esplicito. Su IIS puoi associare un certificato al sito FTP e forzare l’uso di SSL/TLS per il canale di controllo e, se richiesto, per i dati. Il punto non è “mettere un certificato e basta”: il certificato deve avere un nome coerente con quello usato dai client, altrimenti avrai warning, fallimenti di trust o client che rifiutano la connessione.

Per un ambiente interno può bastare un certificato emesso da una CA aziendale. Per esposizione esterna, usa una CA riconosciuta e controlla che il SAN contenga il FQDN realmente usato. Se il client si collega a un nome diverso da quello del certificato, il problema non è “IIS che non va”: è il binding TLS che non corrisponde.

In IIS, apri le impostazioni del sito FTP e assegna il certificato sotto FTP SSL Settings. Seleziona Require SSL se vuoi impedire connessioni in chiaro. Questa è la scelta più coerente in produzione; lasciare “Allow SSL” ha senso solo durante una migrazione controllata.

Test funzionali: prima locale, poi da rete esterna

Il test migliore è progressivo. Prima verifica che il servizio ascolti sulla porta prevista, poi prova il login da localhost o da una macchina della stessa subnet, infine da una rete esterna se il caso d’uso lo richiede. Un errore comune è dichiarare il servizio pronto dopo il solo avvio del sito in IIS: quello non dice nulla su firewall, NAT e passive ports.

Controlla l’ascolto con:

netstat -ano | findstr :21

Da un client, con un test minimale puoi usare:

ftp 192.0.2.10

Meglio ancora, se usi FTPS, prova con un client che mostri chiaramente il negoziato TLS e l’errore preciso. FileZilla, WinSCP o un client da script con log verboso ti fanno risparmiare tempo rispetto a un semplice “non si connette”. Cerca questi segnali: autenticazione OK, directory listing OK, upload di un file piccolo OK, download OK. Se uno di questi fallisce, il punto debole è già abbastanza chiaro.

Log da guardare quando qualcosa non torna

Quando il servizio sembra up ma i client falliscono, i log contano più dell’interfaccia. I punti da controllare sono i log di IIS FTP, il Visualizzatore eventi e, se usi firewall o antivirus di terze parti, i loro log. Su Windows Server i log IIS sono spesso sotto C:\inetpub\logs\LogFiles, ma il percorso può cambiare in base alla configurazione del sito.

Nel Visualizzatore eventi cerca errori legati a IIS, FTP, Schannel e autenticazione. Un errore Schannel durante FTPS, per esempio, punta spesso a certificato, protocollo o cipher non compatibile. Un 530 in FTP di solito richiama autenticazione o autorizzazioni; un 550 richiama molto spesso NTFS o directory non accessibile.

Se vuoi una verifica rapida lato server, usa questi controlli:

Get-Service ftpsvc
Get-WinEvent -LogName Application -MaxEvents 20 | Select-Object TimeCreated, Id, ProviderName, Message

Problemi tipici e come isolarli in pochi minuti

Se il client non si connette affatto, verifica prima DNS, porta 21 e firewall. Se il login riesce ma il listing fallisce, guarda passivo, NTFS e policy di autorizzazione. Se funziona in LAN ma non da fuori, il sospetto principale è NAT, range passive o IP pubblico non dichiarato correttamente. Se FTPS fallisce solo con alcuni client, il problema è spesso compatibilità TLS o certificato.

La falsificazione rapida delle ipotesi è questa: una curl o un client FTP con log verboso ti dice subito se la porta è raggiungibile; un controllo di icacls chiarisce i permessi; un test con un range passive ristretto e aperto correttamente separa il firewall dal resto. In meno di cinque minuti puoi quasi sempre restringere il problema a uno di questi tre livelli.

Esempio di test veloce da una macchina remota:

Test-NetConnection 192.0.2.10 -Port 21

Se questo passa ma il client FTP no, il problema è più in alto: autenticazione, policy o modalità passiva. Se fallisce già qui, non perdere tempo con IIS: la rete non sta arrivando al server.

Rollback rapido e manutenzione

Ogni change su FTP deve avere rollback semplice. Il rollback minimo è disabilitare il sito FTP in IIS, revocare le regole firewall aggiunte e ripristinare i permessi NTFS precedenti se li hai modificati. Se hai toccato solo il sito, il blast radius resta basso; se hai cambiato certificati o policy globali, annota esattamente cosa hai alterato prima di tornare indietro.

Prima del deploy definitivo salva uno snapshot della configurazione IIS o almeno esporta il sito. In alternativa, documenta i valori critici: porta di controllo, range passive, modalità SSL, autenticazione abilitata, gruppo autorizzato e percorso fisico. Sono i punti che servono davvero in caso di ripristino.

Per la manutenzione ordinaria, controlla spazio disco, crescita dei log e scadenza del certificato. Un FTP che funziona oggi può smettere di funzionare domani per un motivo banale come un volume pieno o un certificato scaduto. La differenza la fa la verifica periodica, non la speranza che il servizio “resti su”.

Configurazione consigliata da portare in produzione

La configurazione più robusta, nella maggior parte dei casi, è questa: IIS FTP con autenticazione Basic, Anonymous disabilitato, FTPS esplicito obbligatorio, permessi NTFS minimi sul path dedicato, range passive ristretto, firewall aperto solo sulle porte necessarie e accesso limitato per gruppo. È una base sobria, leggibile e facile da mantenere.

Se devi esporlo su Internet, aggiungi monitoraggio su porta 21, controllo del certificato e alert sullo spazio disco. Se invece il servizio serve solo sistemi interni, valuta comunque FTPS e restrizione per subnet. FTP in chiaro resta una scorciatoia che costa poco all’inizio e molto quando devi fare troubleshooting o audit.

Assunzione operativa: i passaggi sopra sono pensati per un server Windows Server 2019 standard con IIS installato, accesso amministrativo locale e una directory dati dedicata già disponibile.