FTP/FTPS unter IIS 10

Das File Transfer Protocol (FTP) und darauf aufbauend das File Transfer Protocol over SSL (FTPS) sind Netzwerkprotokolle zum Übertragen von Dateien. Dieser Blog-Artikel zeigt Euch, wie man unter Windows 2019 mit Hilfe des IIS-Webservers einen FTP/FTPS-Dienst betreiben kann.

Einführung

Das File Transfer Protocol (FTP) ist ein klassisches Netzwerkprotokoll zum Übertragen von Dateien über IP-Netzwerke. Seine Ursprünge lassen sich bis in das Jahr 1971 zurückverfolgen. FTP kann durch Einsatz von TLS abgesichert werden, in diesem Fall spricht man oft von FTPS (FTP over SSL oder auch FTP Secure).

IIS 10 unter Windows 2019 kann auf Wunsch auch als FTP- oder FTPS-Server betrieben werden. Im Folgenden zeige ich Euch, wie das geht und welche Fallstricke es zu beachten gibt. Ganz am Ende werden wir darüber diskutieren, ob der Einsatz FTP/FTPS heute noch eine gute Idee ist (Spoiler: Ist es nicht) und welche Alternativen es für die Dateiübertragung im Internet gibt.

FTP-Dienst installieren

Ich gehe davon aus, dass Du IIS unter Windows 2019 schon installiert hast.

1. Wähle im Server-Manager den Befehl Verwalten > Rollen und Features hinzufügen. Klicke anschließend auf Weiter.

   

2. Klicke erneut auf Weiter.

   

3. Wähle Deinen Server aus und klicke auf Weiter.

   

4. Wähle die Serverrolle FTP-Server unter Webserver (IIS) aus. Die Optionen FTP-Dienst und FTP-Erweiterbarkeit müssen beide angekreuzt sein. Klicke auf Weiter.

   

5. Neue Features benötigen wir nicht. Klicke auf Weiter.

   

6. Bestätige mit Installieren. Die Installation wird gestartet.

   

7. Ist die Installation fertig, kannst Du auf Schließen klicken.

   

Der FTP-Dienst ist einsatzbereit und kann konfiguriert werden.

Firewall einrichten

Eine FTP-Sitzung kannst Du im aktiven oder im passiven Modus betreiben. In beiden Fällen baut ein FTP-Client zunächst eine TCP-Verbindung (den sog. Kontrollkanal) zum FTP-Server auf. Dabei wird standardmäßig der TCP-Port 21 des FTP-Servers benutzt.

Im aktiven Modus sendet der FTP-Client anschließend eine Info über den Kontrollkanal zum FTP-Server, unter welcher IP-Adresse und welchem TCP-Port er Daten vom FTP-Server empfangen möchte. Der FTP-Server baut daraufhin eine zweite TCP-Verbindung (den sog. Datenkanal) zum FTP-Client auf und nutzt dabei die ihm zuvor mitgeteilten Verbindungsdaten.

Im passiven Modus sendet der FTP-Client lediglich eine kurze Anfrage über den Kontrollkanal zum FTP-Server, dass er von ihm eine IP-Adresse und einen TCP-Port bekommen möchte. Mit der Antwort kann der FTP-Client anschließend selber eine TCP-Verbindung zum FTP-Server aufbauen, um den Datenkanal zu eröffnen.

Die beiden Modi unterscheiden sich also vor allem darin, wer den Datenkanal eröffnet, der FTP-Server (aktiv) oder der FTP-Client (passiv).

Der aktive Modus ist nicht zu empfehlen und wird auch eher selten genutzt, da er auf Client-Seite Änderungen in der Firewall erfordert, die in der Regel nicht erwünscht sind.

Beim passiven Modus muss dagegen lediglich die Firewall auf Serverseite angepasst werden. Das gilt selbstverständlich auch für FTP unter IIS:

• Die Windows-Firewall wird automatisch während der Installation des FTP-Dienstes angepasst. Es werden dabei die einkommenden TCP-Ports 21, 990 und 1024-65535 freigeschaltet.

• Den TCP-Port 21 für den Kontrollkanal kennen wir schon.

• Der TCP-Port 990 ist für verschlüsselte FTPS-Verbindungen reserviert.

• Für den passiven Modus muss ein TCP-Portbereich freigeschaltet werden, der zwischen 1024 und 65535 liegen darf.

• Solltest Du eine externe Firewall einsetzen, dann musst Du die entsprechenden TCP-Ports dort manuell freischalten.

Der FTP-Dienst selbst besitzt ein Feature namens FTP-Firewallunterstützung. Dort legt man fest, auf welchen TCP-Ports der FTP-Dienst im passiven Modus erreichbar ist. Die Vorgabe ist 0-0. Das bedeutet, es wird der standardmäßige dynamische TCP-Portbereich benutzt werden. Unter Windows 2019 ist das der Portbereich von 49152 to 65535.

Wem das nicht behagt, der kann die Einstellung natürlich anders konfigurieren. Ein beliebter Portbereich für FTP ist z.B. 41000-41099.

Eine erste FTP-Site einrichten

Eine FTP-Site wird standardmäßig über eine IP-Adresse und eine Port-Nummer adressiert. Der Standardport für FTP ist 21. Da wir uns IP-Adressen schlecht merken können, definieren wir eine Domäne, die auf unsere IP-Adresse auflöst. In unserem Beispiel ist dies die Domäne download.beispiel.de.

Wir wollen jetzt eine simple FTP-Site zum Download von Dateien anlegen:

1. Öffne den IIS-Manager und klicke in der linken Navigation mit der rechten Maustaste auf den Eintrag Sites. Das Kontextmenü öffnet sich, klicke dort auf FTP-Site hinzufügen.

   

2. Trage jetzt einen Namen und den Dateiordner für die Dateiablage ein. Name und Pfad sind hier nur beispielhaft, sie können auch anders lauten. Klicke auf Weiter.

   

3. Übernimm die Standardeinstellungen der nächsten Dialogseite und klicke auf Weiter.

   

4. Wähle jetzt Anonym als Authentifizierung, Anonyme Benutzer als Zugriffsregel und kreuze die Option Lesen unter Berechtigungen an. Klicke auf Fertigstellen.

   

Du hast nun eine öffentliche FTP-Site mit Leserecht eingerichtet, d.h. jeder kann unter

ftp://download.beispiel.de

Dateien herunterladen und durch die Verzeichnisse unterhalb der Dateiablage navigieren. Dazu benötigt man einen FTP-Client. Zwei populäre Open-Source-Beispiele unter Windows wären:

• FileZilla
• WinSCP

Beide Anwendungen erlauben Dir es, über eine grafische Oberfläche eine Verbindung zu einem FTP-Server aufzubauen, durch die Ordnerstruktur zu navigieren, Dateien hoch- und herunterzuladen sowie elementare Dateioperationen (Löschen, Umbenennen etc.) auszuführen.

Möchtest Du das Navigieren in der Ordnerstruktur unterbinden, dann kannst Du unter IIS eine FTP-Anforderungsfilterung definieren.

1. Wähle im IIS-Manager Deine FTP-Site aus und mach anschließend in der linken Absicht einen Doppelklick auf das Symbol FTP-Anforderungsfilterung.

2. Wähle die Registerkarte Befehle aus und füge nacheinander die folgenden FTP-Befehle über die Aktion Befehl ablehnen hinzu:

   • NLST
   • LIST

Das Ergebnis sieht dann so aus:

Was haben wir gemacht? Der FTP-Standard definiert zwei Befehle (LIST und NLST), die jeweils den Inhalt eines Verzeichnisses an einen FTP-Client zurücksenden. Beide Befehle werden ab sofort geblockt. Ein FTP-Client kann jetzt nur noch Dateien herunterladen, wenn der Nutzer die vollständige URL weiß.

FTP und Virtual Host

Unsere FTP-Site agiert momentan unter einer Catch-All-Adresse, d.h. alle FTP-Anfragen, die unter der IP-Adresse des Windows Servers eingehen, werden automatisch zu unserer FTP-Site weitergeleitet.

Wir möchten jetzt eine zweite FTP-Site einrichten. Dazu müssen wir die eingehenden FTP-Anfragen irgendwie unterscheiden und zur jeweils richtigen FTP-Site weiterleiten. Leider ist das nicht so einfach.

Zum besseren Verständnis der Problematik werfen wir einen kurzen Blick auf das HTTP-Protokoll.

Verwaltet ein Webserver mehrere Websites parallel, so stellt sich auch hier die Frage der korrekten Weiterleitung von HTTP-Anfragen. Die Lösung ist das Virtual Host-Konzept. Dabei wird jeder Website ein oder mehrere Hostnamen (z.B. www.beispiel.de) zugewiesen. Kommt eine neue HTTP-Anfrage rein, so kann der Webserver aus dem HTTP-Kopf der Anfrage den Parameter Host auslesen. Dieser Parameter ist eine Pflichtangabe und spezifiziert den Domänennamen und optional den TCP-Port des Zielservers. Mit dieser Information kann der Webserver nun korrekt weiterleiten (man nennt das auch Routing).

FTP ist aber leider nicht HTTP. Das ursprüngliche FTP-Protokoll kennt keinen Virtual Host, und das bedeutet, man kann nicht so ohne weiteres mehrere FTP-Sites parallel betreiben, zumindest dann nicht, wenn beide eine Bindung zur gleichen IP-Adresse und zum gleichen TCP-Port haben.

Da dies unbefriedigend ist, hat man nachträglich zwei Konzepte eingeführt, die dies doch ermöglichen sollen:

1. Der FTP HOST Command for Virtual Hosts ist ein neuer, zusätzlicher FTP-Befehl, der es FTP-Clients ermöglichen soll, einem FTP-Server mitzuteilen, auf welcher virtuelle Host es denn sein soll.

2. Die Kombination von Hostname und Benutzername bei der FTP-Authentifizierung (also z.B. download.beispiel.de|admin statt nur admin) erlaubt es, die Virtual Host-Information bei der Anmeldung mit zu übertragen, ohne Einführung eines zusätzlichen FTP-Befehls.

Beide Konzepte werden von IIS ab Version 7 unterstützt. Sie sind allerdings nicht perfekt:

• Der HOST-Befehl muss nicht nur vom FTP-Server, sondern auch vom FTP-Client unterstützt werden. Nicht alle FTP-Clients tun dies. Beispielsweise besitzt WinSCP eine Unterstützung für HOST, FileZilla aber nicht.

• Die Kombination von Hostname und Benutzername bei der FTP-Authentifizierung funktioniert nicht beim Einsatz von FTPS, da die TLS-Verschlüsslung bereits vor der Anmeldung einsetzt.

Mit diesen Informationen im Hinterkopf werden wir jetzt versuchen, eine zweite FTP-Site einzurichten.

Eine zweite FTP-Site einrichten

Wir wollen diesmal eine FTP-Site einrichten, bei der man auch Dateien hochladen kann. Da das nicht jeder machen darf, wollen wir die Nutzung der FTP-Site nur auf Administratoren beschränken.

1. Öffne den IIS-Manager und füge wie gewohnt eine neue FTP-Site hinzu.

2. Trage einen anderen Namen und Dateiordner für die Dateiablage ein. Auch hier sind alle Angaben nur beispielhaft. Klicke auf Weiter .

   

3. Wähle die Option Virtuelle Hostnamen aktivieren aus und trage unter Virtueller Host den neuen Hostnamen upload.beispiel.de ein. Klicke danach auf Weiter.

   

4. Wähle jetzt Standard als Authentifizierung und Bestimmte Rollen oder Benutzergruppen aus. Tippe den Namen der Windows-Administrationsgruppe ein. Kreuze die Optionen Lesen und Schreiben unter Berechtigungen an und klicke auf Fertigstellen.

   

Du hast jetzt eine zusätzliche FTP-Site mit Lese- und Schreibrecht eingerichtet, für deren Zugriff eine Anmeldung als Mitglied der Administratorengruppe Deines Windows Servers notwendig ist. Bitte beachte: Dem Benutzernamen bei der Anmeldung muss der virtuelle Hostname vorangestellt werden (also z.B. upload.beispiel.de|Administrator).

FTPS konfigurieren

Unsere zwei FTP-Sites laufen, haben jedoch noch einen großen Makel. Die Verbindung zwischen FTP-Client und FTP-Server ist nicht verschlüsselt. Das wollen wir ändern.

Wie schon in der Einleitung erwähnt, kann FTP durch Einsatz von TLS abgesichert werden (FTPS). Die benötigten TLS-Zertifikate unterscheiden sich nicht von denen, die wir im Kontext von HTTPS benötigen. Insbesondere können wir die kostenlose TLS-Zertifikate von Let’s Encrypt einsetzen. Eine ausführliche Einführung in das Thema IIS-Websites und Let’s Encrypt findest Du in diesem Blog-Artikel.

Wie werden auch hier wieder den ACME-Client Windows ACME Simple (WACS) nutzen, eine Open Source-Kommandozeilenanwendung, mit der man bei Let’s Encrypt neue TLS-Zertifikate erfragen kann.

1. Starte WACS als Administrator und wähle die Option Create certificate (full option), also M.

   

2. Wähle die Option Manual input, also 2. Tippe anschließend den Hostnamen download.beispiel.de ein und bestätige mit der Eingabetaste.

   

3. Wähle jetzt immer die angebotenen Standardoptionen aus bestätige jeweils mit der Eingabetaste. Bei der Frage Which installation step should run first? wähle die Option 2 für FTPS aus:

   

4. Jetzt musst Du nur noch die gewünschte FTP-Site auswählen und bei den restlichen Fragen die Standardantwort übernehmen.

   

Sind alle Fragen beantwortet, kommuniziert WACS mit Let’s Encrypt und erfragt ein TLS-Zertifikat für die Domäne download.beispiel.de. Für Deine FTP-Site unter upload.beispiel.de machst Du das ganze noch einmal.

Deinen beiden FTP-Sites werden jeweils ein TLS-Zertifikat zugewiesen, und diese werden automatisch alle 55 Tage erneuert. WACS erstellt dazu eine neue Aufgabe in der Windows-Aufgabenplanung.

Jetzt wollen wir das Ganze natürlich testen:

Da wir zwei FTP-Sites mit FTPS aktiviert haben, können wir eine Weiterleitung mittels virtuellem Hostnamen in der Anmeldung nicht nutzen, denn die TLS-Verschlüsselung beginnt schon vor der Authentifizierung und zu diesem Zeitpunkt muss bereits klar sein, um welchen virtuellen Hostnamen es sich handelt. Andernfalls schlägt die Domänenvalidierung fehl. Bleibt also nur die explizite Versendung des HOST-Befehls vom FTP-Client, da dieser vor Beginn der TLS-Verschlüsseluing versendet wird. Und das bedeutet, ein Test mit FileZilla würde fehlschlagen:

Connection failed.
Local policy on server does not allow TLS secure connections.

Ein Test mit WinSCP sollte aber funktionieren:

1. In unserem Beispiel müsste die Verbindungsdaten unter WinSCP so aussehen:

   

2. Unter Advanced Site Settings und dort unter FTP musst Du die unterste Option auf On stellen.

   

Noch ein paar Anmerkungen:

• Möchte man mehrere FTP-Sites ohne zwingende HOST-Unterstützung betreiben, könnte man die globalen SSL-Einstellungen für FTP nutzen und dort ein Wildcard-Zertifikat auswählen. Das setzt allerdings voraus, dass alle Domänen, echte Unterdomänen derselben Stammdomäne sind. Benötigt man nur eine FTPS-Site, kann man auch ein normales TLS-Zertifikat nutzen. In beiden Fällen nimmt der IIS immer dieses TLS-Zertifikat, wenn er mangels Informationen nicht entscheiden kann, welches er sonst nehmen soll.

• Mehr zum Thema FTP-Sicherheit findest Du im im RFC FTP Security Considerations.

Die Zukunft von FTP/FTPS

Mit der Version 88 von Google Chrome wurde die Unterstützung für FTP standardmäßig deaktiviert. Ab Version 91 soll die gesamte FTP-Code-Basis entfernt werden. Die Motivation dahinter:

• FTP ist ein ungeschütztes Netzwerkprotokoll, die Variante FTPS wurde unter Chrome nie implementiert.
• FTP im Browser wird kaum noch genutzt.

Aus ähnlichen Gründen hat auch Mozilla Firefox nachgezogen.

Kurzum, öffentliche Downloads per FTP sind keine gute Idee mehr. Bleibt noch FTP/FTPS als Basis für den Dateiaustausch im geschlossenen Benutzerkreis. Diese Nutzungsart wird es sicherlich noch sehr lange geben, vor allem im Kontext von Altsystemen, aber für den Aufbau einer neuen Infrastruktur heißt der Rat eindeutig: Wenn’s irgendwie geht, kein FTP oder FTPS mehr!

Der Anwendungsfall “Dateiübertragung” bleibt natürlich und es stellt sich die Frage nach Alternativen:

• HTTP bzw. HTTPS: Öffentliche Datei-Downloads kann man am besten per HTTP bzw. HTTPS bereitstellen. Dafür braucht man keine neue Erweiterung, man richtet unter IIS einfach eine neue Website ein (oder nutzt eine bestehende) und legt darunter die gewünschten Dateien ab. Dieser Blog-Artikel beschreibt die Konfiguration von HTTPS unter IIS 10.

• WebDAV: Möchte man auch Datei-Uploads ermöglichen, dann kann man die WebDAV-Erweiterung von IIS nutzen. WebDAV (Web-based Distributed Authoring and Versioning) ist ein Netzwerkprotokoll zur Dateiübertragung auf Basis von HTTP. WebDAV erweitert HTTP um zusätzliche Anfrage-Methoden und ermöglicht so eine Funktionalität, die derer von FTP ähnlich ist. Man richtet wie gewohnt in IIS eine neue Website ein und kann dann unter dem Symbol “WebDAV-Autorisierungsregeln” die WebDAV-Unterstützung aktivieren und weiter im Detail konfigurieren. Da WebDAV auf HTTP aufbaut, klappt das Ganze auch problemlos mit HTTPS.

• SFTP: SFTP (Secure File Transfer Protocol) ist ein Netzwerkprotokoll zur sicheren Dateiübertragung über SSH (Secure Shell). Als Teil von OpenSSH ist es integraler Bestandteil von Linux. OpenSSH ist seit einiger Zeit auch unter Windows verfügbar. Dieser Blog-Artikel beschreibt Installation, Konfiguration und Nutzung von OpenSSH/SFTP unter Windows 2019.

• Freigegebene Ordner/VPN: Innerhalb eines Intranets können Dateiübertragungen auch ganz normal über freigegebene Ordner getätigt werden, bei Einsatz eines VPN (Virtual Private Network) auch ortsunabängig. Ein VPN ist ein nach außen hin geschlossenes Netzwerk, das die Infrastruktur eines öffentlichen Netzwerks (in der Regel das Internet) zur Kommunikation nutzt.

One more thing

Warum habe ich diesen Artikel überhaupt geschrieben, wo FTP/FTPS sich doch so langsam aber sicher aus dem Mainstream verabschiedet? Nun, es ist wie mit gefährdeten Sprachen. Man möchte verhindern, dass das Wissen über sie unwiderruflich verschwindet. Genauso ist es hier auch. Wir nutzen FTP seit einiger Zeit nicht mehr aktiv, wollten aber das Wissen über Installation und Konfiguration in diesem Blog-Artikel konservieren. Vielleicht kann noch jemand davon profitieren.