Summary

  • FTP handelte Befehle über eine Steuerverbindung aus und übertrug Dateien über eine separate Datenverbindung.
  • RFC 1579 verwendete das vorhandene PASV, um die Initiierung der zweiten Verbindung umzudrehen: Clientseitige Filter ließen sich leichter passieren, dafür musste der Server eingehende Datenports annehmen.

Eine FTP-Sitzung konnte „sende diese Datei“ sagen, ohne die Datei über die Befehlsverbindung zu übertragen. Diese Trennung gehörte zum Protokolldesign. Daraus folgte ein praktisches Problem: Eine erfolgreiche Anmeldung und eine positive Antwort auf RETR garantierten noch keine übertragenen Bytes. FTP musste eine zweite TCP-Verbindung in der vorgesehenen Richtung herstellen.

Die 1985 veröffentlichte Spezifikation RFC 959 trennte einen Steuerprozess für Befehle und Antworten von Datenprozessen für Übertragungen. Im üblichen Modell öffnete der Client die Steuerverbindung zum Server, meist auf Port 21. Vor der Übertragung konnte er mit PORT seine eigene Adresse und einen Port zum Lauschen melden. Der Server leitete anschließend die Datenverbindung zurück zum Client ein. Da der Datensocket getrennt vom Steuerkanal war, musste eine Firewall, die den ersten zuließ, den zweiten nicht ebenfalls passieren lassen.

Das Protokoll kannte schon eine andere Betriebsart. Mit PASV bat der Client den Datenprozess des Servers, auf einem Nicht-Standardport zu lauschen. Der Server nannte Adresse und Port; der Client öffnete die Datenverbindung dorthin. Die Datei lief weiterhin über eine zweite Verbindung, nur der Initiator änderte sich. Der passive Modus war also lange vor seiner Empfehlung als Firewall-Umgehung im Protokoll vorhanden.

1994 entsprach die Praxis nicht immer dem ursprünglichen Standardverhalten. Steven Bellovin schrieb in RFC 1579, dass damalige Clients oft für jede Übertragung eine neue Datenverbindung öffneten, zur Vermeidung der TCP-TIME-WAIT-Wartezeit einen neuen Port wählten und ihn mit PORT bekanntgaben. Für einen Paketfilter sah das wie ein eingehender Aufruf an einem unvorhersehbaren Port aus. Firewalls ließen häufig ausgewählte eingehende Dienste zu und blockierten diese Verbindung, selbst wenn die Anmeldung über den Steuerkanal gelungen war.

RFC 1579 empfahl Herstellern, FTP-Clients einschließlich Gopher-Proxyagenten auf PASV statt PORT umzustellen. Dann wurde die Datenverbindung vom Client ausgehend geöffnet. Für die Firewall des Nutzers war es leichter, eine vom Client gestartete ausgehende Verbindung zu erlauben, als einen unerbetenen eingehenden Aufruf an einen zufälligen Clientport anzunehmen. Das Memo verlangte keine Protokolländerung: Der Befehl existierte bereits, und vor jedem Transfer fand in beiden Modi ein ähnlicher Austausch statt.

Die Lösung verlagerte die schwierige Grenze, statt sie zu beseitigen. Im passiven Modus musste der Server eingehende Verbindungen an den für Übertragungen gewählten Ports annehmen. RFC 1579 räumte ein, dass dadurch auf der Serverseite ein Firewall-Problem entstehen konnte. Das Argument war organisatorisch: Es gebe weniger Server als Clients, und Betreiber könnten den Datenportbereich einschränken. Das war ein Vorschlag, wo die Angriffsfläche verwaltet werden sollte, kein Beleg dafür, dass alle Server oder Firewalls ihn übernommen hatten.

Normative Texte helfen dabei, eine geforderte Fähigkeit von verbreitetem Verhalten zu unterscheiden. RFC 1123 schrieb 1989 vor, dass FTP-Server PASV implementieren müssen, und erläuterte die Antwort, merkte aber zugleich an, dass deren Format nicht ausreichend vereinheitlicht war. RFC 1579 berichtete später von mindestens zwei unabhängig modifizierten Clients. Keines der Dokumente misst, wie viele Nutzer oder Standorte den Modus wechselten. Die Aufzeichnung von 1994 belegt eine Empfehlung und einige Implementierungen, keine allgemeine Umstellung.

FTP hatte zwei betriebliche Oberflächen. Der Steuerkanal transportierte Zugangsdaten, Befehle und Antworten; der Datenkanal transportierte Verzeichnislisten oder Dateien. Eine Antwort wie „Datenverbindung wird geöffnet“ war nicht die Datei, und eine erfolgreiche Anmeldung bewies keinen abgeschlossenen Transfer. Für die Fehlersuche mussten beide Sockets verfolgt und die vorgesehene Verbindungsrichtung an beiden Enden geklärt werden.

Die Lehre von RFC 1579 ist enger als „Firewalls machten FTP kaputt“. Das Protokoll bot bereits eine Wahl der Initiierungsrichtung für die Datenverbindung. Paketfilter machten diese Wahl betrieblich folgenreich. PASV erlaubte den Verbindungsstart von der Seite, deren Firewall die Verbindung eher zuließ, während Serverbetreiber einen begrenzten Bereich eingehender Ports verwalten mussten. Das Protokoll blieb gleich; der betriebliche Aufwand wechselte den Ort.

Sources