FTP leeft nog: wanneer SFTP overkill is en FTPS volstaat

De vrijdagse hotfix

Een Nederlands bureau waar we mee werken liep hier vorige maand tegenaan. Vrijdag 16:40, een Magento 1-site op een shared Hetzner-pakket, de checkout slikt al negentig minuten orders zonder ze te verwerken. De engineer die de codebase kende zat in de trein, getetherd, Transmit open, starend naar de spinner. De host bood FTP en FTPS aan. Geen SSH. Geen SFTP. Geen poort 22.

De vraag was niet welk protocol het beste is. De vraag was welk protocol de server überhaupt zou accepteren en welk protocol een getetherde laptop in een tunnel zou overleven. Dat is grofweg de hele FTP-versus-FTPS-versus-SFTP-discussie, zodra je de LinkedIn-stelligheid eruit haalt. De protocollen lossen overlappende problemen op, de servers die je erft bepalen welk probleem je daadwerkelijk hebt, en de verkeerde default kost je een declarabel uur.

Wat SFTP je oplevert

SFTP is geen variant van FTP. Het is het SSH File Transfer Protocol, een aparte spec die toevallig drie letters deelt. Het draait binnen een SSH-sessie op poort 22, gebruikt één kanaal voor zowel control als data, en erft de key-authenticatie, known_hosts-pinning en tunneling van SSH. Op elke server die je volledig beheert is dit de juiste default.

De haak zit in ‘volledig beheert’. Een lange staart aan WordPress-, Joomla- en Magento-installaties draait op pakketten waar de hostingmaatschappij geen shell-accounts uitdeelt. Sommige bieden SFTP aan via een geforceerde internal-sftp-setup zonder shell. Veel niet. De legacy site die je betaald wordt om in leven te houden heeft simpelweg geen poort 22 open voor jou, en de eerste lijn van support vragen om die open te zetten is op zich al een middag werk.

De andere haak is dat SFTP veel heen-en-weer doet over een trage verbinding. Elke read en write is een request-response over het SSH-kanaal. Op een 200ms-link met duizend kleine bestanden voel je dat. Passive-mode FTP en FTPS kunnen het datakanaal vullen met één doorgaande transfer, SFTP kan dat per ontwerp niet.

Waar FTPS zijn nut bewijst

FTPS is FTP plus TLS, gestandaardiseerd in RFC 4217. Het komt in twee smaken die er bij de firewall toe doen.

Explicit FTPS start op de gewone controlepoort 21 in plaintext, voert vervolgens AUTH TLS uit en upgradet. Implicit FTPS start vanaf de eerste byte versleuteld op poort 990. Explicit is wat vrijwel elke moderne shared host daadwerkelijk aanbiedt. Implicit is deprecated, maar duikt nog op bij oudere Plesk- en DirectAdmin-bakken.

Het argument voor FTPS is weinig romantisch. Je host draait al vsftpd of Pure-FTPd. De credentialdatabase, de chroot-regels, de per-user quota, de directory-permissies bestaan al. TLS aanzetten is één configvlag en een certificaat. Een typisch vsftpd-blok aan de serverkant ziet er zo uit:

listen=YES
ssl_enable=YES
force_local_data_ssl=YES
force_local_logins_ssl=YES
ssl_tlsv1_2=YES
ssl_sslv2=NO
ssl_sslv3=NO
require_ssl_reuse=NO
rsa_cert_file=/etc/ssl/private/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.key
pasv_min_port=40000
pasv_max_port=40100

Het paar pasv_min_port en pasv_max_port is het stuk dat bijt. FTP en FTPS gebruiken een apart datakanaal dat de server willekeurig kiest binnen die range. Je firewall moet die range toestaan, en je NAT moet weten hoe hij hem moet vertalen. Doe dat verkeerd en je krijgt 425 Can't open data connection op elke LIST, en de client lijkt ‘prima te verbinden maar nooit files te listen’. Dat is niet je TLS-config, dat is het datakanaal.

Aan de clientkant is een snelle sanity check één regel curl:

curl -v --ssl-reqd --user me:secret \
  ftp://ftp.example.com/wp-content/themes/

Als die de directory afloopt, is het TLS-pad gezond. Blijft hij hangen na PASV, dan zit de passive-range ergens tussen jou en de schijf dicht.

Active versus passive, kort

Active FTP, waarbij de server terug verbindt naar de client op een datapoort, is dood voor iedereen achter NAT, en dat is iedereen. Forceer passive in de client en pin de passive port range op de server vast. Alles wat anders is, wordt een verhaal dat je om 17:00 op vrijdag aan support uitlegt.

Wanneer kale FTP nog te verdedigen valt

Kale FTP over poort 21 stuurt credentials in plaintext over de lijn. Op het open internet is dat onverdedigbaar. Binnen een private VPC, op een build agent die artefacten op een interne mirror dropt die van buiten het subnet onbereikbaar is, kan het en is het soms zelfs te prefereren omdat de firewallconfig één regel is en de throughput onversleutelde lijnsnelheid haalt. We raden het niet aan, we hebben het in vijf jaar tweemaal terecht zien gebeuren, en beide keren kon de operator het netwerk op een bierviltje tekenen.

Hangt je ‘FTP’ aan het publieke internet zonder TLS of SSH eromheen, behandel het als een P1. Het controlekanaal stuurt het wachtwoord in plaintext bij de eerste USER/PASS-uitwisseling. Iedereen op het pad ziet het.

De beslissing in twee regels

Beheer je de server zelf, geef jezelf SFTP en een chrooted user. Het onderstaande Match-block, vastgezet op een groep, is het minimum:

Match Group sftponly
    ChrootDirectory /var/sftp/%u
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no
    PasswordAuthentication no

Beheer je de server niet, en draait de host al FTP, zet dan expliciet FTPS aan, pin de passive port range vast, forceer TLS 1.2 of 1.3, en stop. FTPS is in dat scenario geen compromis. Het is het protocol dat past bij de infrastructuur die je daadwerkelijk hebt, en het stuurt dezelfde bytes door dezelfde TLS als je HTTPS.

Het protocol is niet de interessante keuze. Wat interessant is, is of je editor de version history van het bestand kent, of je save twee klikken van een undo zit, en of de volgende persoon die over een jaar die legacy site opent kan zien wie wat veranderde. Toen we Pier bouwden liepen we hier letterlijk tegenaan, ongeveer een derde van de servers waar onze klanten op verbinden heeft helemaal geen SSH. De fix die er werkelijk toe deed was niet FTPS sneller maken, maar elke save met één toetsaanslag omkeerbaar maken, zodat het protocol eronder ophoudt het enge deel van het werk te zijn.

Het kleinste wat je vandaag kunt doen: open je hostingpanel, zoek de FTP-user op, en controleer of TLS wordt afgedwongen bij login. Zo niet, zet de toggle om. Heeft het panel die toggle niet, dan schrijft de supportmail zichzelf.