File Transport Protocol

2005 LANsys Connectivity index last update:13.03.2006

File Transport Protocol (FTP)

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.

Erster Vorläufer: RFC 114 (April 1971)
Aktuelle Fassung: RFC 959 (Oktober 1985)
Letzte Erweiterung: RFC 2773 (Februar 2000)
FTP gehört zu den am meisten genutzten Diensten im Internet
Viele Sicherheitsprobleme
Besonders problematisch im Zusammenspiel mit Firewalls

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.

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 FTP (remote host to remote host)

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.

All explanations and entries from this domain sites are regarded available
as internal purposes, if these appear useful for you and it made of it use,
then happens this at own risk. with use of the entries and possible damage from it,
any warranty is completely excluded.