Das bewährte File Transport Protocol (FTP) ist ein Urvieh aus der Frühzeit des Internet. Zwar erfüllt es auch heute noch seinen Dienst, wirft aber durch seinen abwegigen Protokollablauf viele Sicherheitsprobleme auf – besonders zusammen mit Firewalls.

Dateien über das Netzwerk kopieren, für diese Aufgabe existiert mit FTP ein altes, aber lebendiges und robustes Protokoll. Es erlaubt den Datenaustausch zwischen Systemen, die sonst völlig inkompatibel zueinander sind. Der wunde Punkt dieses Klassikers ist die Sicherheit: FTP schützt die übertragenen Daten weder vor neugierigen Blicken noch vor Manipulationen. Zudem bereitet es große Schwierigkeiten, in einem Paketfilter korrekte Regeln für das FT-Protokoll zu definieren – ohne einen Blick in die übertragenen Daten ist es praktisch unmöglich.

Wegen seiner Sicherheitsprobleme sollte man FTP eigentlich nur noch in Ausnahmefällen benutzen. Eine Folge der vielen Schwächen ist nämlich, dass Angreifer verstärkt nach anfälligen FTP-Servern suchen oder nach Firewalls, die für FTP fehlerhaft konfiguriert sind. Das erste Sicherheitsproblem von FTP ist die Übermittlung von Benutzername und Passwort im Klartext – Sniffer freuen sich über die mundgerechten Geschenke.

Passwörter im Klartext

Die meisten FTP-Zugriffe sind zwar Downloads als anonymer Benutzer, bei denen der Benutzername »anonymous« oder »ftp« ist und die eigene Mail-Adresse als Passwort dient. In diesen Fällen haben Sniffer meist nichts besonders Interessantes zu holen. Es gibt aber genügend Situationen, in denen dies anders ist. Beispielsweise bieten viele Webspace-Provider einen Upload der Inhalte ausschließlich per FTP an, und dazu muss der User seine Kennung und sein Passwort angeben.

Als zusätzliches Risiko verwenden viele Benutzer ihr Passwort auf mehreren Rechnern und nicht nur beim Provider – durch die Website ist der Eigentümer leicht zu identifizieren. Das Passwort kann nicht nur im “bösen” Internet, sondern auch im “guten” LAN abgefangen werden. Damit sind alle internen Benutzerkonten potenziell gefährdet. Bruce Schneier konstruiert in seinem Buch “Secrets and Lies”[1] solche Szenarien und würzt sie mit Beispielen aus der Praxis. Sie sind eine ernst zu nehmende Bedrohung.

Das zweite Sicherheitsproblem ist die Übermittlung der Daten im Klartext. Für anonyme Zugriffe und den Up- und Download von Webseiten ist dies kein Problem, eine vertrauliche Datenübermittlung zwischen zwei Firmen ist damit aber nicht machbar. Die Daten sind auch nicht gegen Manipulationen geschützt, so dass ein Angreifer durchaus während der Übertragung Trojanische Pferde einfügen kann. Mit Tools wie Netsed[2] ist das sogar recht einfach.

FTP – das etwas andere Protokoll

Das Protokoll hat aber nicht nur selbst Schwächen im Sicherheitsbereich, es stellt auch viele Firewalls vor große Probleme. Das liegt an dem ungewöhnlichen Protokollablauf. FTP arbeitet im Gegensatz zum zustandslosen HTTP in einer Sitzung. Die Sitzung bleibt so lange bestehen, bis der Client sich wieder abmeldet. Bei einem reinen FTP-Client ist das auch offensichtlich. Bei einem Web-Browser ist aber davon nichts zu spüren, er baut einfach mehrere Sitzung auf und wieder ab. Einzig die etwas langsamere Reaktionszeit lässt darauf schließen, dass im Hintergrund mehr Arbeit geleistet wird.

Ein FTP-Client sendet seine Kommandos über einen Kontrollkanal an den Server (siehe Kasten “FTP-Kontrollkanal”). Sobald eine Datei übertragen oder ein Directory-Listing zurückgegeben werden soll, ist aber eine zweite Verbindung erforderlich, der Datenkanal. Über ihn laufen dann die eigentlichen Daten, die Steuerinformation fließen weiterhin über den Kommandokanal.

Zwei Verbindungen: Kommandos und Daten

Kommando- und Datenkanal sind wie jede andere TCP-Verbindung eindeutig gekennzeichnet durch Absenderadresse und Absenderport auf der einen Seite und Zieladresse und Zielport auf der anderen. Absender- und Zieladresse sind die bekannten vierstelligen IP-Nummern wie 19.7.0.42, Absender- und Zielport können zwischen 1 und 65535 liegen. Damit ein Client überhaupt eine Verbindung zu einem Server aufbauen kann, hat man bestimmte Dienste auf bestimmte Ports festgelegt (well-known port), dabei hat FTP die 21 und HTTP die Portnummer 80.

Ein Client nimmt eine FTP-Kommando-Verbindung zu einem Server auf, in dem er sich auf seinem Rechner eine freie Portnummer besorgt (über 1023, für niedrigere Ports sind Root-Rechte nötig), seine Adresse und seinen Port als Absender sowie die Serveradresse und Port 21 als Ziel angibt. Ein Server kann dadurch mehrere FTP-Verbindungen gleichzeitig haben, auch zum selben Client, da immer nur die Kombination Absenderadresse und -port plus Zieladresse und -port die Verbindung beschreibt.

Das spezielle Problem für Firewalls liegt nun darin, dass zu einer Kontrollverbindung der Sitzung eine oder mehrere Datenverbindungen gehören, deren genaue Parameter (vor allem die Ports) erst während der Sitzung erzeugt und über den Kontrollkanal ausgetauscht werden. Dabei ist für einen Außenstehenden nicht einmal klar, ob der FTP-Client oder der FTP-Server die Datenverbindungen aufbaut.

Aktives FTP

Abbildung 1: Beim aktiven FTP öffnet der Server den Datenkanal (rot) rückwärts zum Client. Der Client hat ihm vorher über den Kontrollkanal (grün) die IP-Adresse und den Port mitgeteilt.

Ursprünglich gab es nur eine Möglichkeit, die Datenverbindung aufzubauen: Der Client holt sich einen freien Port (größer 1023) und teilt dem Server mit, auf welchem Port er die Verbindung erwartet. Sinnvollerweise heißt dieses Kommando auch »PORT«, gefolgt von der IP-Adresse des Clients und der Portnummer. Die Parameter sind dabei in 8-Bit-Felder aufgeteilt und durch Kommata getrennt.

Das Kommando »PORT 212,45,33,67,5, 45« teilt dem Server mit, dass auf dem Client 212.45.33.67 der Port 5*256 + 45 = 1325 zum Aufbau des Datenkanals bereit ist. Der Server baut dann ausgehend von Port 20 eine Verbindung zum Client auf – mit anderen Worten: Client und Server tauschen die Rollen, außerdem ist hier entgegen allen üblichen Protokollen der Quellport fest vorgegeben (siehe Abbildung 1). Die Daten können dann abhängig von den weiteren Kommandos des Clients in beide Richtungen übertragen werden.

Denkt man sich zwischen Client und Server eine Firewall, werden die historisch bedingten Probleme deutlich. Früher waren Firewalls nicht so schnell und ausgetüftelt wie heute, sondern einfache Paketfilter. Das Protokoll benötigt eigene Filter für Kommandos und Daten, die aber eigentlich zusammengehören. Ein einfacher Paketfilter kann diese jedoch nicht miteinander verknüpfen.

Um FTP-Zugriffe von innen nach außen zuzulassen, muss ein statischer Paketfilter ohne Protokollauswertung nicht nur die ausgehenden FTP-Kommandokanäle erlauben. Hinzu kommen die nach innen gehenden FTP-Datenkanäle, die alle vom Quellport 20 stammen und auf Zielports größer 1023 der zugelassenen Rechner gehen. Auf diesen hohen Ports können durchaus angreifbare Server lauschen, etwa der X-Display-Server. Damit entsteht ein offensichtliches Sicherheitsloch. Probleme stellen sich auch zusammen mit NAT oder Masquerading, weil der Gateway dabei die Absenderadresse der IP-Pakete des Clients verändert, innerhalb des Kontrollkanals aber noch die originalen Adressen stehen.

Es gibt aber noch eine Alternative. Statt das Grundproblem zu lösen und den Datenkanal in den Kommandokanal einzubetten, so dass nur noch eine Verbindung übrig bleibt, ändert diese Variante aber nur die Richtung, in der der Datenkanal aufgebaut wird.

Passives FTP

Abbildung 2: Im passiven FTP-Modus öffnet der Client den Kontroll- und den Datenkanal, beide Verbindungen gehen also in dieselbe Richtung. Die Portnummer für die Datenverbindung teilt der Server dem Client über den Kontrollkanal mit.

Im passiven FTP-Modus öffnet der Client selbst den Datenkanal. Dazu sendet er das Kommando »PASV« an den Server. Der Server holt sich nun eine freie Portnummer (größer 1023) und sendet sie als Return-Code zurück; die Adresse ist dabei so kodiert wie beim »PORT«-Kommando. Nun kann der Client die Verbindung aufbauen, da er die Ziel-Portnummer kennt Abbildung 2).

Jetzt muss der Paketfilter beim Client keine eingehenden Verbindungen mehr zulassen, auch Masquerading oder NAT sind möglich. Die Hauptsorge des Firewall-Administrators ist weg – und ein neues Problem entstanden. Um FTP-Zugriffe von außen nach innen zuzulassen, muss der Paketfilter Verbindungen von Ports größer 1023 zu Ports größer 1023 zulassen. Damit entsteht das gleiche Problem wie im aktiven Modus, nur trifft es jetzt die Firewall auf Seite des Servers und nicht mehr die beim Client.

Doppel-Herz

Abbildung 3: Durch die Kombination von aktivem und passivem Modus kann der Client Dateien direkt zwischen zwei Servern übertragen: Server A arbeitet im passiven Modus, Server B im aktiven.

Durch die Kombination von aktivem und passivem Modus wird ein weiteres Szenario möglich (siehe Abbildung 3): Ein Client kann zwei Server steuern und einen Dateitransfer direkt von Server A zu Server B veranlassen. Er meldet sich zunächst auf beiden Servern an und sendet an Server A ein »PASV«-Kommando. Die Parameter aus der Antwort schickt er als »PORT«-Kommando an Server B. Daraufhin baut B den Datenkanal zu A auf. Je nach Richtung der gewünschten Datenübertragung setzt der Client die Kommandos »STOR« (Store, Abspeichern) oder »RETR« (Retrieve, Abholen) ein.

Schon dies kleine Beispiel, das übrigens auch in RFC 959 besprochen wird, zeigt, dass das Protokoll im Sicherheitsbereich noch einige böse Überraschungen bereithalten könnte.

Firewall-Dilemma

RFC 1579 kommt im Februar 1994 zu dem Schluss, dass eigentlich beide Varianten für Firewalling nicht optimal sind. Die Autoren dieses RFCs halten passives FTP aber für das kleinere Übel und empfehlen, es bevorzugt zu nutzen. Dummerweise ist laut RFC 959 passives FTP nur optional und nicht zwingend vorgeschrieben, so dass man aktives FTP weiterhin unterstützen muss. Erst RFC 1123 legt passives FTP für Internet-Server zwingend fest und macht keine Aussage mehr zu aktivem FTP. RFC 959 ist aber der bekanntere Standard und der kleinste gemeinsame Nenner, an den sich alle halten.

Die Verwirrung ist komplett, wenn auf der Firewall eine Protokollumsetzung zwischen Aktiv- und Passiv-Modus notwendig wird oder kontextorientierte Paketfilterregeln für den Datenkanal eingefügt und entfernt werden müssen. Linux selbst erledigt diese Aufgaben mit einem Kernelmodul, das die notwendigen Änderungen automatisch vornimmt. Es gibt aber auch die Möglichkeit, mit Proxies auf Benutzerlevel zu arbeiten. Diese können dann beispielsweise auch nach Viren suchen.

Die vollständige Implementierung aller Kombinationen von aktivem und passivem FTP ist aber nicht trivial und daher fehleranfällig, Abbildung 4 deutet an, wie komplex die Zusammenhänge und Abläufe dabei werden können. Das Kernel-Modul war in der Vergangenheit sogar selbst das Ziel eines Angriffs.

Es stellt sich die Frage, ob FTP vollständig ersetzt werden kann. Für den normalen Internet-Download ist es nicht dringend erforderlich, HTTP kann genauso zuverlässig Daten herunterladen, HTTPS kann es sogar verschlüsselt. Für die Übertragung von vertraulichen Dateien sollte man sowieso ausschließlich SCP oder verschlüsselte E-Mails verwenden.

Abbildung 4: Eine Firewall mit transparentem FTP-Proxy kann zwischen aktivem und passivem Modus übersetzen, ohne dass Client oder Server dies bemerken. Die Grafik stellt auf beiden Teilabschnitten beide Alternativen (aktiv oder passiv) zusammen dar.

Brauchen wir FTP noch?

Meist stößt man bei Nicht-Linux-Benutzern mit diesen Forderungen auf einiges Unverständnis – aber in der Windows-Welt sorgt ja auch beispielsweise Putty für Klarheit. Bleiben die Webspace-Provider. Um sie dazu zu bewegen, auch andere Upload-Möglichkeiten als FTP anzubieten, könnte die Abstimmung mit den Füßen Wunder bewirken.

Es gibt kaum Einsatzbereiche, in denen sich FTP noch nicht ablösen ließe. Die Datenkonvertierung und Migration von einer alten Systemarchitektur auf eine neue ist eine der möglichen Ausnahmen. Es wird aber Zeit, sich langsam von einem alten und guten Freund zu verabschieden. Sein Kumpel Telnet wartet bereits auf ihn. (fjl)

telnet server 21