Filezilla-Server als Alternative zu den FTP-Diensten im IIS

Haben Sie sich auch schon über die mangelnde Funktionalität und die hakelige Konfiguration des in den IIS enthaltenen FTP-Servers geärgert? Würden Sie gern eine komfortablere Alternative einsetzen, die nicht nur mehr Möglichkeiten bietet, sondern auch noch kostenlos ist? Dann lesen Sie bitte weiter…

Seit rund 10 Jahren betreibe ich neben Linux-basierten Managed-Servern auch einige Windows Rootserver. Nicht etwa, weil ich Windows als Webserverplattform so überzeugend fände, sondern vielmehr, weil ich auf der Basis von Microsoft-Produkten programmiere. Den komplexeren Teil meiner Webprojekte erstelle ich auf der Basis von ASP, respektive ASP.NET. Und dies wiederum nicht, weil ich ASP für besser als PHP hielte, sondern schlicht, weil ich auch Desktop-Anwendungen, die interoperabel zu den Office-Produkten aus dem Hause MS sein müssen, erstelle und von daher das Knowhow einfach da ist. Ich bin kein leidensbereiter Glaubenskrieger, sondern gnadenloser Pragmatiker.

Von Beginn an habe ich allerdings bei den Windows-Servern den IIS ausschließlich als Webserver genutzt. Mailserver (obschon prinzipiell Teil der IIS) war lange Zeit Ipswitch iMail (ein ganz schöner preisintensiver Geselle) und ist jetzt MailEnable. Dieser sogar, weil er nur noch zum scriptgesteuerten Versand von Mails benötigt wird, in der kostenlosen Standardedition. Als FTP-Server verwende ich seit Jahren den Filezilla-Server, den ich Ihnen im weiteren Verlauf dieses Artikels näher bringen möchte.

Warum verwende ich nicht den FTP-Server aus den IIS?

Zu Beginn meiner Windows Rootserver-Karriere gab es einen ganz einfachen Grund, der die IIS als FTP-Server disqualifizierte. Bis einschließlich zur Version 5 war der IIS nicht in der Lage, die Basisverzeichnisse einzelner User voneinander zu isolieren. Im Grunde eine vollkommene Unmöglichkeit, wenn man nicht grenzenloses Vertrauen in seine User setzen will. Erst seit der Version 6, also seit Windows Server 2003, ermöglichen es die IIS die FTP-Benutzer voneinander auf verschiedene technische Weisen zu isolieren. Die potenziell sicherste Methode beruht auf der Authentifizierung mittels Active Directory, woran man bereits erkennen kann, dass die Philosophie von Microsoft in Sachen FTP-Zugriff eher auf Intranet-Lösungen, denn auf FTP-Server in the wild abzielt.

Da die Benutzerverwaltung für den FTP-Server Teil der allgemeinen Benutzerverwaltung des OS ist, schlagen Sicherheitslücken im Betriebssystem natürlich nicht nur auf diesen Dienst durch, sondern es entsteht umgekehrt ein erhöhtes Risiko für die Serversicherheit insgesamt. Immerhin ist FTP vor über 30 Jahren gerade als einfaches System für den lesenden und schreibenden Zugriff auf Serversysteme entwickelt worden. FTP ist quasi per definitionem ein Sicherheitsrisiko. Microsoft selber empfiehlt denn auch, wenig verwunderlich, den FTP-Dienst abzuschalten, wenn er nicht unbedingt benötigt wird.

Ein weiteres Manko des FTP-IIS besteht in der Benutzer-Isolation an sich. Zum einen ist diese wenig komfortabel einzurichten, was verschmerzbar ist. Zum anderen jedoch hat die Isolationsmöglichkeit nicht den Benutzer als Ausgangsgröße vor Augen, sondern die FTP-Site. Vereinfacht ausgedrückt: Ich kann einen „isolierten“ Benutzer nur innerhalb einer FTP-Site einrichten, die auch noch einem bestimmten, ms-vorgegebenem Verzeichnisaufbau genügen muss.

Inwiefern ist Filezilla anders?

Filezilla-Server ist ein kompaktes Progrämmchen mit nur wenigen Einstellmöglichkeiten, die jedoch den FTP-IIS mühelos in den Schatten stellen. Es ist einfach zu installieren und ebenso einfach zu konfigurieren. Da keine Einbindung in die Benutzerverwaltung des Betriebssystems stattfindet, schlagen dortige Sicherheitsprobleme nicht auf Filezilla durch, vice versa.

Das Killerargument ist jedoch, dass Filezilla mit dem Benutzer im Vordergrund an die Sache herangeht. Jeder Benutzer kann Zugriff auf beliebig viele Verzeichnisse nehmen und Basisverzeichnisse (Homedirectories) müssen nicht unter einem gemeinsamen Root liegen, wie im IIS. Durch diese Flexibilität ermöglicht der Filezilla-Server die Definition aller denkbaren FTP-Zugriffskonstrukte. Sogar dem Datenbankprogrammierer Müller geben wir mit Filezilla einen Zugriff auf das Datenbankverzeichnis des Servers, das selbstverständlich aus Sicherheitsgründen völlig außerhalb der Webserver-Hierarchie liegt und dessen Inhalt vollständig per System-DSN verfügbar ist. Nicht auszudenken, was passierte, wenn man den Müller an die Website-Daten ließe oder umgekehrt den Grafiker an die Datenbanken. Der Oberadministrator bekommt einen Komplettzugriff auf das Hauptverzeichnis der Daten-Festplatte und Praktikant Schulte wird auf das Bilderverzeichnis begrenzt, in das er Illustrationen für den CMS-Content hochladen darf. Bislang bin ich auf noch keine Zugangskombination gestoßen, die ich mit Filezilla nicht hätte anbieten können.

Wenn ich jetzt Ihr Interesse an Filezilla geweckt haben sollte, lesen Sie einfach weiter. Im Folgenden erläutere ich kurz, aber ausreichend, denn das Programm ist leicht durchschaubar, Installation und Konfiguration. Haben Sie Bedenken, ob Filezilla auch für Ihren Windows-Server das Richtige ist, möchte ich Sie ermutigen, ihn einfach mal auszuprobieren. Er ist innerhalb von fünf Minuten installiert und konfiguriert und bei Nichtgefallen genauso schnell wieder weg. Für die Testdauer müssen Sie natürlich den FTP-IIS kurzzeitig deaktivieren, was aber ebenso mit zwei Klicks wieder rückgängig gemacht ist.

Eine Zielgruppe habe ich noch vergessen. Nämlich all diejenigen unter Ihnen, die einen FTP-Server aufsetzen wollen, aber kein Windows-Server-Betriebssystem einsetzen. Auch für Sie ist das Produkt interessant, denn Filezilla setzt kein Server-OS voraus, sondern läuft mit der gleichen Funktionalität auch unter Windows Vista, XP und 2000. Dann brauchen Sie nur noch einen Account bei DynDNS, den entsprechenden Updater, sowie eine Portfreigabe in Ihrer Fritzbox und schon sind auch Sie ready to go.

Installation und Konfiguration des Filezilla-Server

Nachdem Sie sich das nur rund 2,5 MB Installationspaket von der Projektsite heruntergeladen haben, starten Sie es mit einem beherzten Doppelklick. Auch wenn die Installation nur wenig Interaktion verlangt, lohnt es sich, nicht einfach gewohnheitsmäßig auf Next zu klicken, obschon die Default-Einstellungen durchweg sinnvoll gewählt sind. Alle Eiligen dürfen also ruhig durchklicken…

Im Normalfall werden Sie wohl eher keinen Wert auf den Sourcecode legen, so dass Sie diese Standardauswahl in der Tat einfach mit „Next“ bestätigen können. Als nächstes treffen Sie die Auswahl, ob auf dem Server das Interface gestartete werden soll, sobald sich ein User anmeldet. Diese Einstellung ist im Grunde Geschmackssache. Soll das Interface nicht automatisch starten, was der Auswahl „Start manually“ gleichkäme, kann man allerdings auch nicht verfolgen, was der per FTP angemeldete User auf dem Server gerade anstellt. Möglicherweise möchte man dies aber, natürlich nur bei Homeservern, doch wissen. Ich installiere standardmäßig die erste Auswahl.

Eine wesentliche Konfigurationsmöglichkeit ergibt sich im folgenden Schritt. Sie müssen entscheiden, ob Filezilla als Windows-Dienst installiert und mit Windows gestartet werden oder ob Filezilla zwar als Dienst, aber nicht automatisch gestartet werden soll. Ein Relikt aus vergangenen Betriebssystemarchitekturen dürfte die dritte Möglichkeit, den Filezilla-Server nicht als Dienst zu installieren, sondern per Autostart-Eintrag als normale Anwendung zu starten, sein.

Ist die Installation gelaufen, wird im Standard das Filezilla-Interface gestartet. Hier haben Sie die Möglichkeit, sich auch mit entfernten Filezilla-Servern zu verbinden. Sie benötigen die Adresse des Remoteservers, sowie das hoffentlich dort vergebene Passwort. Da zur Nutzung dieser Option allerdings auf dem Remotesystem zusätzlich der Port 14147 geöffnet werden muss, empfehle ich diese Vorgehensweise nicht. Jeder offene Port stellt ein zusätzliches Sicherheitsrisiko dar. Verbinden Sie sich per Remote-Desktop-Verbindung mit Ihrem Windows-Rootserver und starten das Filezilla-Interface dann dort lokal. Das ist nicht langsamer, sicherer und die Remote-Desktop-Verbindung haben Sie ohnehin.

Um jetzt den Server sinnvoll in Betrieb zu nehmen, ist es erforderlich, mindestens einen User zu definieren. Haben Sie eine Vielzahl unterschiedlicher User anzulegen, mag es für Sie Sinn machen, zunächst eine oder mehrere Gruppen mit den jeweiligen Zugangsparametern anzulegen und hernach lediglich noch die neuen User den schon vorhandenen Gruppen zuzuordnen. Da der User die Berechtigungsstruktur der Gruppe übernimmt, spart man sich auf diese Weise einiges an Klickarbeit und vermeidet Fehler. Außerdem schlagen spätere Änderungen an der Gruppendefinition automatisch auf alle User durch. Da die Gruppendefinition prinzipiell zur Userdefinition identisch ist, zeige ich hier lediglich die Neuanlage eines Benutzers.

Dieser Vorgang ist nahezu selbsterklärend und unterliegt auch nur wenigen Schritten. Hat man per „Add“ einen Usernamen hinzugefügt, kann man das Konto aktivieren (Enable Account) und ein Passwort vergeben. Verwalter großer User-Mengen notieren sich noch etwas unter Description (Der Picklige aus der Cafeteria zum Beispiel). Interessant mag an dieser Stelle noch der Hinweis auf die Möglichkeit sein, Secure-FTP zu erzwingen (Force SSL for user login). Sind Sie bis hierhin gekommen, sind Sie schon fast durch. Jetzt legen Sie unter „Shared Folders“ noch fest, welche Zugangsberechtigungen und -möglichkeiten der neue Benutzer bekommen soll.

Das zuerst angelegte Verzeichnis wird als Homedirectory, also Startpunkt des Benutzers auf dem FTP-Server definiert, kann aber nach Anlage weiterer Pfade ducrh Klick auf „Set as home dir“ leicht wieder geändert werden. Zu jedem Pfad besteht die Möglichkeit, genau vorzugeben, was der Benutzer darin machen können dürfen soll. Sie entscheiden, ob er Dateien lesen, schreiben, löschen oder erweitern (wichtig bei abgebrochenen Uploads) können soll. Auch bei den Verzeichnisrechten differenzieren Sie nach „Erstellen“, „Löschen“, „Inhalte auflisten“, sowie über die Anwendung dieser Rechtekonstruktionen auf etwaige Unterverzeichnisse.