Vorsicht: Rant
Ich hasse FTP — die Warze unter den Dateiübertragungsprotokollen. Ich hasse es wirklich, leidenschaftlich und abgrundtief. Es ist ein veraltetes, unsicheres, umständliches, schlecht designtes Protokoll und es gibt so gut wie keine vernünftigen Implementierungen. Die Clients haben fast alle grauenvolle User Interfaces, sind langsam und gelegentlich auch noch instabil. Auf der Serverseite sieht es auch nicht viel besser aus, das meiste was es da gibt ist weder schnell noch schlank und selbst wenn es das ist ist es fast immer unsicher. (Wir verwenden als FTP-Server-Software übrigens vsftpd, der wenigstens in dem Ruf steht sicher zu sein und den man sich auch nicht so leicht unsicher konfigurieren kann. Lieber wäre uns aber, wenn wir einfach darauf verzichten könnten. Das beste FTP ist kein FTP.)
FTP überträgt alle Passwörter im Klartext, die etwas besser gesicherte Erweiterung FTPS (FTP mit SSL) gibt es zwar schon seit einer halben Ewigkeit, wird aber immer noch längst nicht von jedem genutzt und den meisten Clients kann man auch nicht oder nur schwer beibiegen, daß sie auf gar keinen Fall Passwörter im Klartext übermitteln sollen. Selbst wenn FTPS die Passwörter (oder genauer gesagt den gesamten Kommandokanal) verschlüsselt, verschlüsselt es dann aber nicht die übertragenen Dateien (den Datenkanal), die bei sehr vielen Webanwendungen aber wiederum Klartextpasswörter z.B. für MySQL-Datenbanken enthalten. „Secure“ FTP hat den gleichen Fehler, nur daß es statt SSL halt SSH benutzt um den Kommandokanal zu verschlüsseln, in jedem Fall verschlüsselt es nicht die übertragenen Dateien. Und über das Firewalling von FTP möchte ich gar nicht schreiben, da würde ich mir die Tastatur unter den Fingern zerlegen vor lauter in den Tastenanschlag einfließendem Ärger.
Ich kann auch nicht verstehen, wieso FTP immer noch eingesetzt wird. Ich weiß, daß viele Leute nur so auf die Dokumente auf ihren Webservern zugreifen können, aber ich weiß halt auch, daß enorm viele Programme auch Support für das SSH File Transfer Protocol (SFTP, nicht zu verwechseln mit „Secure“ FTP) oder sogar Secure CoPy (SCP) mitbringen und ich weiß auch daß es mit Putty und sshfs und noch ein paar anderen Programmen (deren Namen mir gerade nicht mehr einfallen) wirklich bequeme Methoden gibt Daten sicher zu übertragen. Es gibt auch haufenweise Anleitungen dazu, die Hälfte davon offenbar von entnervten Admins geschrieben, die sich große Mühe geben die Leute dazu zu bewegen doch bitte endlich kein FTP mehr zu benutzen. Und Webhostinganbieter die kein SSH anbieten, sondern nur FTP… gut ich arbeite bei einem Webhostinganbieter der genau das aus gutem Grund nicht tut, insofern ist es naheliegend, daß ich davon nichts halte, trotzdem: FTP ist sowas von alt und überholt, wenn ein Anbieter nichts neueres zu bieten hat, dann ist sein Angebot es einfach nicht wert. Einen Zahnarzt der außer Zähne ziehen keine neueren Lösungen zu bieten hat, würde man bei Zahnschmerzen ja auch nicht bevorzugt aufsuchen.
Warum FTP immer noch so weit verbreitet ist, will mir einfach nicht in den Kopf. Ich finde das schlimm. Es ärgert mich, daß ich mich mit dem Mist auseinandersetzen muß, es ärgert mich das ich dafür Support leisten muß. (Was nicht heißt, daß ich mich im Ungang mit solchen Supportanfragen dann nicht zusammenreiße und trotzdem schnell und freundlich weiterzuhelfen versuche. Den Ärger spare ich mir dann für Momente wie diesen hier auf.) Es ärgert mich, daß unsere Kunden sich damit rumquälen müssen. FTP soll endlich verschwinden. Telnet ist doch auch weitgehend verschwunden, warum dann nicht FTP?
So, nachdem ich mir nun Luft gemacht habe, kommen wir zum eigentlichen Thema:
Mein Kollege Matthias sprach mich neulich an, weil bei einem Kunden ein Problem mit einem Backup aufgetreten war. Offenbar dauerte das Runterladen der Backups per FTP sehr lange. Matthias hat das Problem auch sofort reproduzieren können und so wußten wir gleich, daß die Downloads nicht einfach lange dauerten, sondern im Gegenteil ganz normal funktionierten, aber vor Beginn jedes einzelnen Downloads eine Wartezeit von 30 Sekunden eingelegt wurde.
Kurze Erklärung des Setups: Die Backups liegen auf einem Backupserver, von wo aus wir sie per NFS auf dem Webserver den der Kunde nutzt einbinden, wobei NFS das Verzeichnis mit den Backups nur im Read-Only-Modus holt. Schreibzugriffe aufs Backup sind also vom Webserver aus nicht möglich.
Deswegen dachte ich auch im ersten Moment, daß die Verzögerung wohl eher daher rühren wird, daß entweder NFS irgendwie gestört ist oder der Backupserver zum Zeitpunkt der Downloads zu viel zu tun hatte. Der Backupserver hatte aber zu dem Zeitpunkt an dem mein Kollege und ich das testeten gerade nichts zu tun und NFS hat auch durchaus funktioniert. Wenn ich dieselben Dateien per SCP runtergeladen habe, dann gab es keine Verzögerung.
Ich habe also etwas in den Logs gestöbert und schließlich diese Einträge in /var/log/messages gefunden:
Feb 14 10:01:59 helium kernel: statd: server localhost not responding, timed out
Feb 14 10:01:59 helium kernel: lockd: cannot monitor 82.98.87.73
Feb 14 10:01:59 helium kernel: lockd: failed to monitor 82.98.87.73
(Am Rande sei hier mal angemerkt, daß das Deuten der Logausgaben von NFS eine arkane Kunst ist die ich — wie 99% der Nutzer und Entwickler von NFS — nicht beherrsche. In der Regel kann ein und diesselbe Logausgabe von NFS für mindestens ein Dutzend verschiedene Fehlerursachen stehen und in beinahe allen Fällen enthält der genaue Text der im Log landet inhaltlich keine sachdienlichen Hinweise zur Problemlokalisierung. Obendrein muß man bei NFS schon dankbar sein, wenn es überhaupt Logausgaben gibt. Mit anderen Worten ist das Logging von NFS das absolut allerletzte, wie wohl jeder der schonmal NFS Fehler debuggt hat und dazu im Internet nach Lösungen suchen mußte sofort bestätigen wird. Diese Logausgabe hier verdient besondere Erwähnung, weil sie ausnahmsweise in der Tat direkt etwas mit dem Problem zu tun hat und vergleichsweise leicht zu deuten ist. Genießt es, sowas sieht man nicht allzu oft.)
Davon auf die Spur gebracht hatte ich bald die Ursache des Problems ausgemacht und gelöst: FTP versucht hier einen Lock auf die Datei zu legen und da dies nicht funktioniert, wartet es auf einen Timeout und kopiert die Datei dann trotzdem. — Warum auch immer. Ich hätte ja ein anderes Verhalten erwartet, aber gut. Bleibt nur noch die Frage, warum FTP hier versucht einen Lock zu erlangen, denn es handelt sich ja um ein Read-Only gemountetes Verzeichnis. Eine ohnehin nur lesbare, aber nicht schreibbare Datei zu locken ist weitgehend sinnfrei. Wie auch immer, die Lösung war recht einfach:
chkconfig nfslock on; service nfslock start
Ich gestehe gerne ein, daß ich nfslock von Anfang an hätte laufen lassen sollen, da es prinzipiell für einen geordneten NFS-Betrieb schon dazu gehört. Mea culpa. Aber ich weigere mich zu begreifen, warum FTP hier einen Lock erreichen will. Ein Lock ist dafür gedacht, damit niemand anderes schreibend auf die Datei zugreift, für Lesezugriffe ist das gar nicht gedacht. Ich möchte an der Stelle nocheinmal darauf hinweisen, daß dieses Problem nicht auftritt, wenn ich diesselbe Datei lokal kopiere oder per SSH oder HTTP runterlade. Im Grunde hat mich FTP hier auf einen Konfigurationsfehler den ich bei NFS gemacht hatte hingewiesen und ich bin dafür auch dankbar — nur bin ich halt auch mittlerweile unfähig etwas über FTP zu sagen ohne mich erstmal ausgiebig über FTP an sich aufzuregen.
Gut, da ich es jetzt eh schonmal nachrecherchiert habe, kann ich mein Wissen hier ja nochmal teilen: Wenn man ein CentOS 5 nur als NFS Client benutzen möchte, dann sollte man den Dienst nfslock laufen lassen (geht aber in vielen Fällen auch ohne). Wenn man NFSv4 verwendet und auf’s ID Mapping wert legt, sollte man zusätzlich rpcidmapd laufen lassen. Wenn man NFSv4 verwendet und authentifizieren oder verschlüsseln möchte, dann sollte man zusätzlich rpcgssd laufen lassen. Wenn man mit CentOS 5 einen NFS Server betreiben möchte, dann muß man die Dienste portmap und nfs laufen lassen (die in dieser Reihenfolge zu starten sind). Auch hier brauch man bei NFSv4 für ID Mapping rpcidmapd, für Authentifikation und Verschlüsselung braucht man aber rpcsvcgssd statt rpcgssd.
Zum Abschluß noch ein weiterer Seitenhieb auf NFS. Beim Lesen der Manpage von rpc.lockd bin ich vor Lachen fast vom Stuhl gefallen, sowas schwammiges und uninformatives ist mir lange nicht mehr untergekommen:
The rpc.lockd program starts the NFS lock manager (NLM) on kernels that don’t start it automatically. However, since most kernels do start it automatically, rpc.lockd is usually not required. Even so, running it anyway is harmless.
Na dann ist ja alles klar.
Update 05.04.2022:
„Moritz von smartminded“ – oder besser gesagt, der dahinterstehende Crawler – hat festgestellt, dass wir in obigem Blogpost das „Amazon Seller Tool Helium 10“ erwähnt hätten und bietet uns eine „Kooperation“ an, wenn wir einen von smartminded erstellten Artikel verlinken, der „die besten Helium 10 Alternativen vorstellen“ soll. Nicht irreführen lassen: Auch wenn der Titel dies nahelegt, so beschäftigt sich jener Artikel erstmal vornehmlich mit Helium 10 selbst und bemerkt: „Eines der besten Tools ist jedoch Helium 10“. Aber da uns 50€ für eine Verlinkung angeboten wurden, dachten wir uns: Die nehmen wir mit. Dass ein Artikel vom Februar 2011 in einem in 2014 eingestellten Blog im Jahr 2022 vielleicht nicht mehr soviel Relevanz hat… das ist ja nicht unser Problem, wenn jemand dennoch für einen Link bezahlen möchte. Hier nun also:
„Hier findest du die besten Helium 10 Alternativen.“
Natürlich nur echt mit rel="nofollow", wie das für bezahlte Links so üblich ist. Danke für den Fuffi!
Pfui Deiwel, sowas macht FTP? Ich glaube, den Wenigstens ist das alles bewusst, geschweige denn sie haben Lust und Zeit, sich mit solchen Themen auseinanderzusetzen. Aber kommen wir zum praktischen Teil: Welche Alternative sollte man nutzen (und welche kann man nutzen, wenn man bei dem Webhostinganbieter Kunde ist, für den Du arbeitest)? 😉
Also eigentlich sollte bekannt sein, daß FTP unverschlüsselt ist, zumindest sollten kompetente IT-ler es wissen und darauf ggf. hinweisen. Ansonsten kann man sich schnell schlau machen. Wenn ich nach „ftp insecure“ google heißt gleich das erste Ergebnis bei mir „FTP is totally insecure“, bei „ftp security“ ist das erste Ergebnis der Wikipedia-Artikel und da heißt es direkt: „FTP was not designed to be a secure protocol—especially by today’s standards—and has many security weaknesses“. Das ist auch der Grund, warum FTP in machen Firmen-Umgebungen nicht erlaubt und nicht verfügbar ist — damit eben keine Klartextpasswörter durch’s WLAN und über die Kabel gehen. Man weiß nie wer mitliest.
Die besten Alternativen heißen SCP und SFTP. Beides geht mit gängigen SSH-Programmen wie OpenSSH oder putty, es gibt auch spezialisierte Programme wie WinSCP. Unter Linux und MacOS X ist auch sshfs eine Option, das benutzt im Hintergrund SFTP, stellt das ganze aber so dar als hätte man es mit einem lokal angeschlossenen Laufwerk zu tun (WebDAV macht etwas ganz ähnliches, nur läuft es halt über HTTP und nicht über SSH). Ich muß allerdings gestehen, daß ich sshfs unter MacOS X schon ewig nicht mehr zu tun hatte. Dort gibt es aber auch noch Cyberduck und ein paar andere Programme. Ein Freund der viel Webentwicklung macht hat mir glaubhaft versichert, daß die ernst zu nehmenden Programme in diesem Bereich (insbesondere das teure von der Firma die sich nach Lehm benannt hat) alle SFTP unterstützen und die meisten auch mit SSH-Pubkeys umgehen können.
So oder so: Der Platinstandard für Kommandozielenzugriff und Dateiübertragung heißt SSH. Wo das nicht möglich ist, kann man auf WebDAV über HTTPS ausweichen. (Von Leuten die mit Windows Servern geschlagen sind weiß ich, daß das auf ihrer Plattform das Mittel der Wahl ist, auch wenn man OpenSSH wohl auch dort mit ein paar Klimmzügen zum Laufen bekommt.)
standardmässig führt eine centos installation (hier gerade mit 5.5 durchgeführt) automatisch die richtige konfiguration der notwendigen nfs dienste durch. scheinbar sass bei euch doch wieder „das“ problem vor dem bildschirm um es kaputtzukonfigurieren/minimalwahn.
ftp schlecht? ich find ftp super!
ich kann von jedem client und aus jedem dorf in afrika zur not etwas herunterladen und bin arbeitsfähig. und es ist einfach zu programmieren/einzubinden. nach der übertragung werden dann die daten abgeholt/verschoben/woanders was gemacht.
die daten kann man sicherer/besser vorher/nacher verschlüsseln/entschlüsseln. zumal momentan nachrichten wie diese http://www.heise.de/security/meldung/FBI-Backdoor-in-IPSec-Implementierung-von-OpenBSD-1153180.html nicht das vertrauen in die vergügbaren verschlüsselungen stärken.
Auf unseren „Minimalwahn“ sind wir im Allgemeinen durchaus ein bisschen stolz … 😉 Und einen NFS-Locking-Daemon zu installieren, wenn man eben gerade – weil eh alles readonly ist – kein Locking braucht, erschien halt erstmal wenig sinnvoll.
Die Argumente, die du dafür bringst, dass FTP super sei … die treffen doch genauso auch auf SFTP zu: Einfach zu programmieren, einfach anzuwenden.
Das Argument mit dem Daten vorher/nachher verschlüsseln erschließt sich mir nicht. Wenn ich (vorher) verschlüsselte Daten über eine unverschlüsselte FTP-Verbindung übertrage, gehen ja immer noch meine Zugangsdaten unverschlüsselt durchs Netz, womit ich potentiell unberechtigten Dritten Zugriff auf meinen Account verschaffe.
Die Nachricht über die potentielle Backdoor in der IPsec-Implementierung stärkt ohne Frage das Misstrauen in Verschlüsselung allgemein. Zu hoffen wäre, dass dies ein Signal für umfangreichere Audits darstellt. Mir ist aber die Folgerung nicht klar, wieso es dann besser sein sollte, die Daten vorher zu ver- und nachher zu entschlüsseln – eine Backdoor in einer Crypto-Implementierung kann ja schließlich genauso auch in den Tools stecken, die du lokal für die Verschlüsselung vor der Übertragung verwendest. Aufgrund der beschriebenen Problematik dann aber auch gleich das gesamte „Prinzip Verschlüsselung“ in Frage zu stellen, finde ich dann schon etwas übertrieben – Sicherheit ist schließlich kein „ganz oder gar nicht“. Vielleicht ist mein Anspruch ja auch nur, meine Daten z.B. vor den Augen eines Mitbewerbers zu schützen, und der bliebe ja immer noch erfüllt, selbst wenn das FBI eine Möglichkeit zur Entschlüsselung hätte (was unerfreulich genug wäre).
Auf einer Standard CentOS-Installation sind haufenweise Dienste aktiviert, die wir nicht brauchen. Die werden abgeschaltet weil man a) Fehler in Diensten die man nicht benutzt auch nicht bemerkt, b) auf Sicherheitslücken in solchen Diensten nicht achtet da man sie ja nicht benutzt und c) so der Systemstart verkürzt und die Belegung von Systemresourcen reduziert werden kann. Bei diesem Host wurde NFS nach der Installation erstmal komplett abgeschaltet. Als es später gebraucht wurde, ist das Fehlen von nfslock nicht aufgefallen, weil das Einhängen des betreffenden Verzeichnisses per NFS und der Zugriff darauf ja funktioniert haben — monatelang. Der Fehler ist nur durch das Zusammenspiel von FTP und NFS aufgefallen, ergo würde nfslock auf diesem System in der Tat nicht benötigt werden, wenn man dort kein FTP einsetzen würde. Obendrein fällt auf, daß selbst die Manpage von rpc.lockd nicht gerade klar ansagt, ob man nfslock denn nun braucht oder nicht.
Lücken im IPsec Stack von OpenBSD haben nichts mit OpenSSH zu tun, OpenSSH benutzt kein IPsec und die Verschlüsselung die bei IPsec zum Einsatz kommt ist von den reinen Algorithmen mal abgesehen sehr stark verschieden von der bei SSH genutzten. IPsec ist dafür berüchtigt, daß es komplex und schwer zu implementieren ist — anders als SSH. Man könnte auch auf den kaputten Pseudozufallsgenerator in OpenSSL bei Debian vor ein paar Jahren verweisen, aber OpenSSH nutzt auch kein OpenSSL. Vor solchen Sicherheitslücken ist man aber letztlich nie absolut sicher, selbstverständlich auch bei OpenSSH nicht. Hieraus zu schließen, Transportverschlüsselung wäre generell unnötig, bedeutet jedoch das sprichwörtliche Kind mit dem Bade auszuschütten.
Daß FTP einfach zu implementieren sei, ist für mich kein Argument. Telnet wäre noch einfacher zu implementieren, aber das macht es nicht besser. Von Telnet mal abgesehen wäre eine weitere Alternative zu FTP WebDAV über HTTPS, was ebenfalls recht leicht zu implementieren sein dürfte.
Die Erfahrung, daß FTP von überall auf der Welt aus funktioniert teile ich nicht. FTP ist bekannt für sein schlechtes Zusammenspiel mit Firewalls und Tunneln. Versuch mal aktives FTP hinter einer herkömmlichen Firewall und einem Router mit NAT zu benutzen. Oder wenn Du Herausforderungen schätzt: Versuch mal in Asien hinter mehreren, geketteten NATs irgendeine Form von FTP zu benutzen.
Verzichtet man wie bei FTPS auf die Verschlüsselung der Datenübertragung und vermeidet dann das übertragen von Passwörtern in Dateien, bleibt das Problem, daß man oftmals zum Zeitpunkt der Datenübertragung nicht weiß, ob man gerade sensible Daten überträgt oder nicht, oftmals stehen Klartextpasswörter in Configs ohne daß man das ahnt (wer hat schon den Quellcode einer typischen Webanwendung komplett gelesen?). Bei reinem FTP bleibt wie mein Kollege anmerkte das Problem, daß auch Name und Passwort mit denen sich dann jeder der das mitsnifft auf dem erschnüffelten Account einloggen kann. Ein Sniffer muß sich noch nichtmal die Mühe machen die geschnüffelten Pakete noch zu decodieren oder zu dekomprimieren, denn FTP läuft über reines ASCII im Klartext, das Passwort steht dann schon deutlich lesbar im tcpdump.
Für alle, die verwirrt sind, gibt es in der englischen Wikipedia einen schönen Abschnitt, der die verschiedenen „Secure“-Implementierungen aufführt. Um das kurz zusammenzufassen: