FTP-Passivmodus: Firewall blockiert Verzeichnisauflistung

Warum sich FTP anmeldet, aber die Verzeichnisauflistung hängt

Der passive FTP-Modus funktioniert an einer Firewall nicht, weil FTP zwei TCP-Verbindungen und nicht nur eine verwendet. Die Verbindung zu Port 21 überträgt die Anmeldung und die Befehle. Deshalb werden Benutzername und Passwort akzeptiert, und die Firewall-Konfiguration scheint korrekt zu sein. Für die erste ls wird anschließend eine zweite Verbindung über einen anderen Port benötigt. In der Firewall ist diese Verbindung nicht erlaubt. Daher wartet der Client, bis ein Timeout auftritt.

Die Lösung besteht aus einem festen Portbereich für diese Datenverbindungen und einer Firewall-Regel, die denselben Bereich erlaubt. Ein Server hinter NAT (Network Address Translation) benötigt eine zusätzliche Einstellung, damit er die richtige Adresse bekannt gibt. Früher übernahmen Connection-Tracking-Helfer diese Aufgabe. Das tun sie heute nicht mehr. Sie sollten den Grund kennen, bevor Sie eine ältere Anleitung übernehmen.

Der Steuerkanal und der Datenkanal

FTP (File Transfer Protocol) ist in RFC 959 spezifiziert und älter als NAT und Stateful Firewalling. Eine Sitzung öffnet eine Steuerverbindung zum TCP-Port 21 und hält sie während der gesamten Sitzung offen. Befehle werden als Klartext übertragen. Antworten bestehen aus einem dreistelligen Code und einer Textzeile. Diese Verbindung überträgt niemals Dateiinhalte.

Jede Datenübertragung verwendet eine eigene TCP-Verbindung: eine für eine Verzeichnisauflistung (LIST), eine für jeden Download (RETR) und eine für jeden Upload (STOR). Die Verbindung wird geöffnet, einmal verwendet und anschließend geschlossen. Die Authentifizierung erfolgt vollständig über den Steuerkanal. Ein unterbrochener Datenpfad äußert sich daher immer gleich: Die Anmeldung ist erfolgreich, anschließend hängt der Vorgang. Wenn der Client eine 230-Antwort ausgibt und danach bei der Auflistung stehen bleibt, liegt das Problem am Datenkanal und nicht an den Zugangsdaten.

Aktiver Modus: Der Server verbindet sich zurück zum Client

Im aktiven Modus wählt der Client einen Port aus, überwacht ihn und teilt dem Server mit, wohin dieser die Verbindung herstellen soll:

PORT 192,168,1,50,195,80

Die ersten vier Zahlen sind die IP-Adresse des Clients. Die letzten beiden Zahlen geben den Port als zwei Bytes an: 195 * 256 + 80 = 50000. Der Server stellt die Datenverbindung anschließend von seinem eigenen Port 20 zum Port 50000 des Clients her.

Aus Sicht des Clients ist diese Verbindung eingehend und nicht angefordert, sodass eine Client-Firewall sie verwirft. Befindet sich der Client hinter einem Heimrouter, ist die in dem Befehl PORT angegebene Adresse eine private Adresse, die der Server überhaupt nicht erreichen kann. Der aktive Modus ist der Grund für den Ruf von FTP, häufig nicht zu funktionieren.

Passiver Modus: Der Client öffnet beide Verbindungen

Im passiven Modus wird die Datenverbindung umgekehrt aufgebaut. Der Client sendet PASV, und der Server antwortet mit einer eigenen Adresse und einem eigenen Port:

227 Entering Passive Mode (203,0,113,10,195,80)

Die Codierung ist identisch. Der Client verbindet sich also mit 203.0.113.10 über Port 50000. Der Client öffnet nun beide Verbindungen. Deshalb funktioniert der passive Modus hinter einem NAT auf der Clientseite, und deshalb fordert jeder aktuelle Client ihn zuerst an.

Das Problem ist nicht verschwunden, sondern hat sich verlagert. Die unaufgeforderte eingehende Verbindung trifft nun auf Ihrem Server ein, und zwar auf einem hohen Port, der sich bei jeder Übertragung ändert. Diese Firewall gehört Ihnen, also liegt das Problem nun bei Ihnen.

EPSV (erweiterter passiver Modus, RFC 2428) beruht auf derselben Idee, verwendet aber eine übersichtlichere Antwort:

229 Entering Extended Passive Mode (|||50000|)

Die Antwort enthält keine Adresse. Der Client verwendet erneut die Adresse, die er bereits für die Steuerverbindung nutzt. Dadurch funktioniert der Modus über IPv6, und eine ganze Klasse von NAT-Fehlern entfällt. Im Handbuch von curl steht, dass curl normalerweise EPSV vor PASV versucht. Der Port wird weiterhin zur Laufzeit ausgewählt. EPSV ändert daher nichts an Ihren Firewall-Regeln.

Warum eine normale Firewall-Regel den Datenkanal nicht freigeben kann

Weil die Portnummer beim Erstellen der Regel noch nicht feststeht. Der Server wählt sie für jede Übertragung neu. In der Standardkonfiguration dokumentiert vsftpd pasv_min_port und pasv_max_port als 0, also „jeden Port verwenden“. Dadurch kann die Datenverbindung jeden Port über 1023 erreichen. sudo ufw allow 21/tcp erlaubt den Steuerkanal und nichts anderes. Genau diese Konfiguration führt zu einer funktionierenden Anmeldung und einer nicht funktionierenden Verzeichnisauflistung. Falls das Konzept eines Dienstes, der auf einem festen Port lauscht, noch unklar ist, erklärt wie Ports und Listening-Sockets unter Linux funktionieren die Grundlagen.

Eine zustandsbehaftete Firewall verfolgt Verbindungen. Der Kernel kann eine neue Verbindung als RELATED einer bestehenden Verbindung zuordnen. Für FTP muss dazu jedoch ein Dienst den Steuerdatenstrom lesen und den Port aus einer 227- oder PORT-Zeile extrahieren. Standardmäßig übernimmt das niemand.

Warum der FTP-Connection-Tracking-Helper keine geeignete Lösung mehr ist

Das Kernelmodul nf_conntrack_ftp wird in älteren Anleitungen empfohlen. Es liest den unverschlüsselten Steuerkanal, ermittelt den angekündigten Port und registriert eine Erwartung. Dadurch wird die Datenverbindung zugelassen, ohne dass eine Regel ihren Port nennen muss. Seit der Veröffentlichung dieser Anleitungen haben sich vier Dinge geändert.

Die automatische Helper-Zuweisung ist deaktiviert und kann in aktuellen Kerneln nicht wieder aktiviert werden. Der Kernel hat sie 2016 standardmäßig deaktiviert. Pablo Neira Ayusos Commit „netfilter: remove nf_conntrack_helper sysctl and modparam toggles“ vom August 2022 entfernte anschließend den Schalter vollständig. Als Begründung wurde angegeben: „users now have to rely on explicit conntrack helper configuration via ruleset.“ Das nf_conntrack_helper-sysctl ist in Linux 5.19 vorhanden und ab Linux 6.0 nicht mehr verfügbar. Die Dokumentation zu den Conntrack-sysctls des Kernels führt es ebenfalls nicht mehr auf. Das Laden des Moduls allein bewirkt nichts.

Sie können prüfen, welchen Kernel Sie verwenden. Führen Sie sysctl net.netfilter.nf_conntrack_helper aus. Eine Antwort sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_helper: No such file or directory bedeutet, dass der Kernel keine automatische Helper-Zuweisung mehr besitzt, die aktiviert werden könnte. Wenn stattdessen eine Zahl zurückgegeben wird, verwenden Sie einen Kernel älter als 6.0. Der Schalter ist noch vorhanden, und sein Standardwert ist 0.

Auch die Firewall-Frontends haben diese Funktion als veraltet markiert. man ufw-framework auf Ubuntu 24.04 bezeichnet die IPT_MODULES-Zeile in /etc/default/ufw als veraltet: „Unconditional loading of connection tracking modules (nf_conntrack_*) in this manner is deprecated“. Außerdem wird ergänzt, dass Helper-Regeln „must be managed in via the RULES FILES“. firewalld dokumentiert AutomaticHelpers in firewalld.conf als „Deprecated. This option is ignored and no longer used.“ Einen Helper zuzuweisen bedeutet jetzt, manuell eine explizite Regel mit dem Ziel CT zu schreiben. Das ist aufwendiger als die unten beschriebene Lösung und funktioniert nicht mehr, sobald Sie TLS aktivieren. iptables und nftables unter Ubuntu beschreibt, wo diese Regeln tatsächlich abgelegt werden.

TLS beendet diese Möglichkeit. Ein Helper funktioniert, indem er den Steuerkanal als Text liest. Wird dieser Kanal verschlüsselt, sieht der Helper nur Chiffretext und kann den Port nicht ermitteln. Dafür gibt es keine Lösung. Das ist auch richtig so: Eine Netzwerkkomponente, die Ihren Steuerkanal lesen kann, kann auch Ihr Passwort lesen.

Einen passiven Portbereich auf dem Server festlegen

Jeder FTP-Server kann so konfiguriert werden, dass er seine passiven Ports aus einem von Ihnen festgelegten Bereich auswählt. Die Namen der Optionen unterscheiden sich. Lesen Sie daher die Dokumentation des tatsächlich verwendeten Servers.

vsftpd in /etc/vsftpd.conf:

pasv_enable=YES
pasv_min_port=30000
pasv_max_port=30099

pasv_enable ist bereits standardmäßig auf YES gesetzt. Die beiden Portoptionen haben standardmäßig den Wert 0. Damit gilt das oben beschriebene Verhalten „beliebigen Port verwenden“. Wenden Sie die Änderung mit sudo systemctl restart vsftpd an. Prüfen Sie anschließend mit systemctl status vsftpd, ob der Dienst wieder läuft. vsftpd verweigert den Start bei einer Konfigurationszeile, die es nicht analysieren kann, statt sie zu ignorieren. Wenn der Neustart fehlschlägt, lesen Sie journalctl -u vsftpd -n 20 nach der 500 OOPS:-Zeile, die die gerade eingegebene Option nennt.

ProFTPD in proftpd.conf:

PassivePorts 30000 30099

ProFTPD dokumentiert hierfür keinen Standardwert. Ohne diese Direktive wählt der Kernel den Port aus. Die ProFTPD-Dokumentation weist außerdem darauf hin, dass der Server auf einen vom Kernel zugewiesenen Port ausweicht und eine Meldung protokolliert, wenn kein Port aus Ihrem Bereich frei ist. Ein zu kleiner Bereich führt daher gelegentlich zu Fehlern, statt kontrolliert fehlschlagen zu können. Das ist deutlich schwieriger zu diagnostizieren. Verwenden Sie nicht privilegierte Ports ab 1024.

Pure-FTPd verwendet das Flag -p first:last. In man pure-ftpd wird es als „Nur Ports im Bereich von first bis last einschließlich für Downloads im passiven Modus verwenden“ dokumentiert. Dadurch wird „pure-ftpd mit Paketfiltern kompatibler“. Gepackte Builds binden dieses Flag normalerweise in eine Konfigurationsdatei ein. Lesen Sie daher die Dokumentation Ihrer Distribution zum Dateinamen, statt ihn zu erraten.

Wie viele Ports benötigen Sie? Einen pro gleichzeitig aktiver Datenverbindung. Ein geschlossener TCP-Port bleibt einige Minuten lang in TIME_WAIT, bevor er wiederverwendet werden kann. Planen Sie daher ein Mehrfaches des erwarteten Spitzenwerts ein. Ein Bereich mit 100 Ports reicht für einige Benutzer bequem aus. Ein stark ausgelasteter öffentlicher Server benötigt deutlich mehr. vsftpd ist hier weniger tolerant als ProFTPD: Der Quellcode versucht einige zufällige Ports innerhalb des Bereichs. Wenn alle belegt sind, beendet vsftpd die Sitzung mit 500 OOPS: vsf_sysutil_bind, statt einen Port außerhalb des Bereichs zu verwenden. Bei beiden Servern führen zu kleine Bereiche zu fehlgeschlagenen Übertragungen, wenn die Auslastung am höchsten ist.

Wo sollte der Bereich liegen? Führen Sie zuerst sysctl net.ipv4.ip_local_port_range aus. Auf einem unveränderten Ubuntu-System lautet der Wert 32768 60999. Er bezeichnet die Ports, die der Kernel für ausgehende Verbindungen vergibt. Ein passiver Bereich innerhalb dieses Fensters kann mit einer ausgehenden Verbindung kollidieren, die den Port bereits verwendet. Legen Sie den Bereich daher darunter fest. 30000 bis 30099 sind auf einem Standardsystem frei. Prüfen Sie Ihr eigenes System, statt diesem Wert zu vertrauen.

Denselben Bereich in der Firewall öffnen

ufw schreibt einen Bereich mit einem Doppelpunkt. Im Handbuch steht, dass ein Bereich oder eine Liste „auch verwendet werden kann, um mehrere Ports anzugeben; in diesem Fall ist das Protokoll erforderlich“:

sudo ufw allow 21/tcp
sudo ufw allow 30000:30099/tcp
sudo ufw status verbose

ufw status verbose sollte nun beide Einträge anzeigen. Derselbe Befehl ohne /tcp wird mit einer Fehlermeldung abgelehnt, die tcp oder udp verlangt, weil ufw nicht rät. ufw-Regelsyntax auf einem VPS behandelt die übrigen Fälle.

firewalld schreibt den Bereich mit einem Bindestrich und benötigt anschließend einen Reload:

sudo firewall-cmd --permanent --add-service=ftp
sudo firewall-cmd --permanent --add-port=30000-30099/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

--add-service=ftp öffnet 21/tcp und fordert den ftp-Helper an, den die mitgelieferte Servicedefinition bezeichnet. Der passive Bereich wird dadurch nicht geöffnet. Allein damit befinden Sie sich daher wieder genau am Ausgangspunkt. firewalld-Zonen und -Dienste auf einem VPS liefert den größeren Zusammenhang.

Direktes nftables innerhalb Ihrer input-Chain:

tcp dport { 21, 30000-30099 } accept

Eine weitere Firewall darf nicht übersehen werden: Die meisten Provider betreiben außerhalb des Betriebssystems eine Netzwerk-Firewall im Control Panel. Wenn die Regeln auf dem Server korrekt aussehen und weiterhin keine Pakete eintreffen, öffnen Sie denselben Bereich auch dort.

Geben Sie dem Server seine öffentliche Adresse bekannt, wenn er hinter NAT steht

Führen Sie ip -4 addr show auf dem Server aus. Wenn die Adresse auf dem Interface der Adresse entspricht, mit der sich Clients verbinden, überspringen Sie diesen Abschnitt. Wenn das Interface eine private Adresse (10.x, 172.16 bis 172.31.x, 192.168.x) hat und die Plattform eine öffentliche Adresse darauf abbildet, kennt der Server seine eigene öffentliche Adresse nicht. vsftpd dokumentiert den Standardwert für pasv_address als „the address is taken from the incoming connected socket“. Daher enthält die 227-Antwort die private Adresse, und der Client wird an ein Ziel verwiesen, das er nicht erreichen kann.

FileZilla benennt diesen Fall genau:

Server sent passive reply with unroutable address. Using server address instead.

FileZilla korrigiert die Adresse und setzt den Vorgang fort. Viele andere Clients tun das nicht. Sie verbinden sich mit 10.0.0.5 und warten ohne Ergebnis.

Auch curl verbirgt das Problem. Das ist relevant, wenn curl für Ihren Test verwendet wird. Im Handbuch steht, dass --ftp-skip-pasv-ip „is enabled by default (added in 7.74.0)“. Daher ignoriert curl die Adresse in der 227-Antwort und verwendet erneut die Adresse der Steuerungsverbindung. Eine Übertragung, die mit curl funktioniert, kann aus genau diesem Grund in einem grafischen Client trotzdem fehlschlagen.

Legen Sie die Adresse explizit fest. vsftpd verwendet dafür pasv_address=203.0.113.10 sowie pasv_addr_resolve=YES (Standardwert NO), wenn Sie stattdessen einen Hostnamen angeben möchten. ProFTPD verwendet MasqueradeAddress. Dieser Parameter akzeptiert eine Adresse, einen DNS-Namen oder einen Interfacenamen. Pure-FTPd verwendet -P. Dieser Parameter ist für den Fall dokumentiert, dass „the server is behind a masquerading (NAT) box“. EPSV vermeidet das gesamte Problem, weil seine Antwort kein Adressfeld enthält. Darauf können Sie sich jedoch nicht verlassen, weil der Client entscheidet, welchen Befehl er sendet.

Was sich durch TLS ändert

FTPS ist FTP über TLS (Transport Layer Security). Der Client verbindet sich wie gewohnt mit Port 21 und sendet AUTH TLS, um den Steuerkanal zu sichern. Anschließend sendet er PROT P, um auch den Datenkanal zu verschlüsseln. Bei einfachem FTP wird das Passwort als lesbarer Text über das Netzwerk übertragen. Wenn Sie FTP weiterhin benötigen, verwenden Sie FTPS. vsftpd wird mit ssl_enable ausgeliefert, das standardmäßig auf NO gesetzt ist.

Daraus ergeben sich zwei Folgen. Kein Connection-Tracking-Helper kann funktionieren. Das ist derselbe Punkt aus der umgekehrten Perspektive. Außerdem zeigt sudo tcpdump -nAi any 'tcp port 21' nicht mehr die 227-Antwort an. Wenn Sie wissen müssen, welche Adresse und welchen Port der Server angekündigt hat, lesen Sie stattdessen das servereigene Log und nicht den Netzwerkverkehr.

Testen der Änderung von außen

Führen Sie diese Befehle auf einem anderen Computer aus. Wenn Sie vom Server selbst testen, umgehen Sie die Firewall, die Sie gerade korrigieren möchten.

sudo ss -ltnp | grep :21
curl -v --disable-epsv --user ftpuser:secret ftp://example.com/
nc -vz example.com 30000

ss sollte zeigen, dass der FTP-Daemon auf Port 21 lauscht. Im passiven Portbereich lauscht im Leerlauf nichts, weil diese Sockets für eine Übertragung erstellt und danach geschlossen werden.

--disable-epsv zwingt curl auf den PASV-Pfad. Dieser Pfad macht das Adressproblem sichtbar. Die Ablaufverfolgung gibt zuerst die Antwort des Servers und anschließend die Adresse und den Port aus, die curl verwendet:

< 227 Entering Passive Mode (203,0,113,10,117,52)

117 * 256 + 52 = 30004 liegt innerhalb des angegebenen Bereichs. Eine private Adresse in dieser Zeile bedeutet, dass pasv_address nicht gesetzt ist. Ein Port außerhalb Ihres Bereichs bedeutet, dass der Server die Konfigurationsänderung nicht eingelesen hat. Prüfen Sie daher, ob Sie die Datei bearbeitet haben, die der laufende Dienst verwendet.

nc beantwortet die Firewall-Frage allein. Ein sofortiges Connection refused bedeutet, dass das Paket den Server erreicht hat, dort aber nichts lauschte. Das ist bei einem passiven Port im Leerlauf das korrekte Ergebnis: Ihre Regel funktioniert. Wenn die Verbindung hängt, bis nc aufgibt, wurde das Paket still verworfen. Die Ursache ist eine Firewall, entweder auf dem Server oder im Panel Ihres Providers. Diese Unterscheidung entspricht der in bei SSH abgelehnt gegenüber Timeout beschriebenen und gilt für jeden Port.

Sollten Sie weiterhin FTP verwenden?

Für neue Anwendungen: nein. SFTP (SSH File Transfer Protocol) läuft innerhalb einer einzelnen SSH-Verbindung über Port 22. Es gibt keinen zweiten Kanal, keinen passiven Portbereich, keine NAT-Einstellung und keinen zusätzlichen abzusichernden Daemon, weil OpenSSH diese Funktion bereits bereitstellt. sftp user@example.com funktioniert auf einem System, auf dem Sie überhaupt keinen Dateiübertragungsdienst konfiguriert haben. Um jemandem ausschließlich Dateien bereitzustellen, verwendet sshd_config zusammen mit ForceCommand internal-sftp und ChrootDirectory. Dieses Verzeichnis muss root gehören und darf für den Benutzer nicht beschreibbar sein. Andernfalls verweigert sshd die Sitzung und protokolliert eine bad ownership or modes for chroot directory-Zeile.

FTP ist weiterhin sinnvoll, wenn die Gegenstelle nicht geändert werden kann. Scanner und Multifunktionsdrucker werden mit Firmware ausgeliefert, die ausschließlich FTP unterstützt. Labor- und Industrieanlagen laufen häufig mit einem festen Image, das niemand erneut zertifizieren wird. Geschäftspartner stellen einen FTPS-Ablageort bereit und fügen für einen einzelnen Lieferanten kein weiteres Protokoll hinzu. In diesen Fällen ist der passive Bereich zusammen mit der passenden Firewall-Regel die gesamte Konfiguration. Verwenden Sie dabei FTPS statt einfachem FTP. Das Zwei-Kanal-Design stammt aus einer Entscheidung von 1980. Es war bereits in RFC 765 beschrieben, fünf Jahre bevor RFC 959 es weiterführte. Heute wird es in einer Welt eingesetzt, die bei seiner Entwicklung nicht absehbar war. Diese Geschichte wird in der Geschichte der Dateiübertragungsprotokolle behandelt.

FAQ

Warum meldet sich FTP an, bleibt aber bei der Verzeichnisauflistung hängen?

Die Anmeldung verwendet nur die Steuerverbindung auf Port 21, die Ihre Firewall zulässt. Für die Verzeichnisauflistung ist eine zweite TCP-Verbindung über einen anderen Port erforderlich. Diese Verbindung wird blockiert. Legen Sie auf dem FTP-Server einen Bereich für passive Ports fest und öffnen Sie denselben Bereich in der Firewall. Danach wird die Verzeichnisauflistung abgeschlossen. Eine hängende Verzeichnisauflistung ist ein Problem des Datenkanals, niemals ein Passwortproblem.

Welche Ports muss ich für den passiven FTP-Modus öffnen?

Port 21 für den Steuerkanal sowie den Bereich, den Sie für passive Datenverbindungen konfiguriert haben. Es gibt keinen Standardbereich, weil Sie ihn selbst festlegen. Ein Bereich wie 30000 bis 30099 funktioniert. Dimensionieren Sie ihn für die maximale Anzahl gleichzeitiger Übertragungen und halten Sie ihn vom ausgehenden Portbereich des Kernels frei. Diesen Bereich können Sie mit sysctl net.ipv4.ip_local_port_range auslesen. Wenn Ihr Provider in seinem Control Panel eine Netzwerk-Firewall betreibt, öffnen Sie denselben Bereich auch dort.

Benötige ich nf_conntrack_ftp weiterhin?

Nein. Auf einem aktuellen Kernel können Sie sich außerdem nicht darauf verlassen. Die automatische Zuweisung von Helpern ist standardmäßig deaktiviert. Seit Linux 6.0 wurde der Schalter net.netfilter.nf_conntrack_helper entfernt. Daher meldet sysctl, dass die Datei nicht existiert. Das Handbuch von ufw bezeichnet das bedingungslose Laden dieser Module als veraltet. firewalld ignoriert AutomaticHelpers vollständig. Ein Helper muss den Steuerkanal außerdem als Klartext lesen. Daher funktioniert er nicht mehr, sobald Sie FTPS aktivieren. Legen Sie stattdessen einen Bereich für passive Ports fest.

Warum meldet mein FTP-Client, dass die passive Antwort eine nicht routbare Adresse enthält?

Der Server hat auf PASV mit der Adresse geantwortet, die er auf seiner eigenen Schnittstelle sieht. Diese Adresse ist privat. Das geschieht, wenn die Plattform eine öffentliche Adresse auf eine private Adresse abbildet. Legen Sie die öffentliche Adresse explizit fest: pasv_address in vsftpd, MasqueradeAddress in ProFTPD oder -P in Pure-FTPd. FileZilla umgeht das Problem, indem es die Adresse wiederverwendet, zu der bereits eine Verbindung besteht. Es protokolliert dann "Using server address instead". Deshalb funktionieren einige Clients trotz der fehlerhaften Konfiguration, während andere hängen bleiben.

Sollte ich FTPS oder SFTP verwenden?

Verwenden Sie SFTP für alles, was Sie an beiden Enden kontrollieren: Es verwendet eine Verbindung über SSH auf Port 22, erfordert keinen zusätzlichen Datenkanal und läuft bereits. FTPS ist FTP über TLS. Daher bleiben das Zwei-Kanal-Design und alle damit verbundenen Firewall-Probleme erhalten. Wählen Sie FTPS, wenn die Gegenseite kein anderes Protokoll unterstützt. Verwenden Sie kein unverschlüsseltes FTP über das Internet, weil das Passwort als lesbarer Text über das Netzwerk übertragen wird.