PF Einstellung - Explizites FTP über TLS funktioniert nicht

PaulAtreides

Well-Known Member
Ich habe eine OpenBSD Firewall mit Clienten die über NAT ans Internet angebunden sind. Bisher hat der Verbindungsaufbau zu FTP Servern immer funktioniert. Jetzt wo mein Provider auf TLS umgestellt hat funktioniert es leider nicht mehr. Woran kann es liegen?

Das sind meine Einstellungen für FTP in der pf.conf

tcp_services = "{ ftp-data, ftp, ssh, smtp, smtps, domain, pop3, auth, http, https, pop3s, imap, imaps}"
pass proto tcp from $local_net to port $tcp_services

# FTP Proxy
anchor "ftp-proxy/*"
pass in quick inet proto tcp from $local_net to port ftp divert-to 127.0.0.1 port 8021

Beim Verbindungsaufbau mit Filezilla erhalte ich folgende Fehlermeldung:

Status: Verbinde mit X.X.X.X:21...
Status: Verbindung hergestellt, warte auf Willkommensnachricht...
Status: Initialisiere TLS...
Fehler: GnuTLS-Fehler -110: The TLS connection was non-properly terminated.
Status: Server hat die TLS-Verbindung nicht ordnungsgemäß geschlossen
Status: Verbindungsversuch fehlgeschlagen mit "ECONNABORTED - Verbindung abgebrochen".
Fehler: Herstellen der Verbindung zum Server fehlgeschlagen
Status: Nächsten Versuch abwarten...
Status: Auflösen der IP-Adresse für XXXXXXXXXXXXXX
Status: Verbinde mit X.X.X.X:21...
Status: Verbindung hergestellt, warte auf Willkommensnachricht...
Antwort: XXXXXXXXXXXX FTP server ready
Befehl: AUTH TLS
Antwort: 234 AUTH TLS successful
Status: Initialisiere TLS...
Fehler: GnuTLS-Fehler -110: The TLS connection was non-properly terminated.
Status: Server hat die TLS-Verbindung nicht ordnungsgemäß geschlossen
Status: Verbindungsversuch fehlgeschlagen mit "ECONNABORTED - Verbindung abgebrochen".
Fehler: Herstellen der Verbindung zum Server fehlgeschlagen
 
Ich hätte spontan vermutet das der FTP-Proxy mit SSL nicht mehr funtkioniert.

Bietet der Provider nicht ein etwas weniger historisches Protokoll das man nutzen könnte (SFTP über SSH zb) ?
 
Oh spannend, das scheint bei denen an den ssh zugang geknüpft zu sein, das ist keineswegs überall so.

Man mag mich hier korrigieren, aber müsste der ftp-proxy nicht das ssl aufbrechen?

Laut der Anleitung steht das dort auch so:


"Since ftp-proxy acts as a man-in-the-middle, it breaks explicit FTP TLS connections (RFC 4217)."

(Ich halte es für ... schwierig ... das hosteurope nur dieses uralte Protokoll anbietet und sich vermutlich nur jetzt durch DSGVO & Co. dazu genötigt fühlt zumindest TLS zu fordern, das klingt nach ziemlich alten, stark müffelnden Hosting-Strukturen - ich würde mir jemand anderen suchen tbh.)
 
Bietet der Provider nicht ein etwas weniger historisches Protokoll das man nutzen könnte (SFTP über SSH zb) ?
Wenn man größere Datenmengen zu übertragen hat, ... könnte man ja testen welches Protokoll performanter/leistungsfähiger/schneller ist, SFTP über SSH oder explizit FTP TLS?
Code:
SFTP vs. FTPS
BTW: Ist FTPS weniger sicher als HTTPS?
 
Wenn man größere Datenmengen zu übertragen hat, ... könnte man ja testen welches Protokoll performanter/leistungsfähiger/schneller ist, SFTP über SSH oder explizit FTP TLS?

Relevant dürfte früher die CPU-Last gewesen sein, aber die Frage ist glaub ich lange gelöst. FTP mit diesem ganzen port-rumgebastel ist einfach "durch". Es besteht ne realistische chance das es insb. aber nicht nur auch mit CG-NAT z.B. nicht funktioniert.

SFTP vs. FTPS
[/code]
BTW: Ist FTPS weniger sicher als HTTPS?

Das würde ich nicht beurteilen wollen, ist aber auch nicht die Frage. Die Frage ist "Ist es ein Protokoll das mit aktuellen nat-lösungen funktioniert." Offenbar nicht.
(Und ich glaube, das lässt sich auch nicht so leicht lösen da ein Proxy eigentlich systemisch immer das TLS aufbrechen müsste an der stelle.)

/edit: EIne möglichkeit wäre auf nat zu verzichten.

Du könntest z.B. die Verbindung vom router aufbauen, oder schauen ob der client als auch hosteurope eine öffentliche ipv6 adresse für das ftp-gedöns haben, dann könnte man auch auf den helper verzichten, evtl. muss man irgendwo noch ipv6 forcieren.
 
Aktives FTP klappt bei NAT idr nicht, es sei denn irgendwelche "NAT Helper magic" macht liest das FTP Protokoll mit und macht Ports auf. Bei TLS geht das natürlich nicht mehr.
Passiv sollte auch mit NAT klappen.

FTP über TLS hat auch 2 Modi, einmal wird nur der Steuerungskanal verschlüsselt und die Nutzdaten unverschlüsselt übertragen, einmal werden beide Kanäle verschlüsselt. Letzteres gabs auch damals - was ich mich erinnere - immer nur über aktives FTP, aber ob das eine technische Notwendigkeit ist weiß ich nicht.

Auf jedenfall ist FTP hoffnungslos Veraltet, und wenn mir ein Provider nicht sowas wie SSH oder s3 zur verfügung stellt, wär ich da schnell weg, wer weiß was da sonst noch so lauert.
 
Erzähl dies mal den Leuten, die Webcams betreiben und FTP nutzen um die Bilder automatisch hochzuladen.
Sicher ist es veraltet, für bestimmte Anwendungszwecke aber nach wie vor geeignet.

Rob

Der Anwendungsfall hier ist aber Management eines Cloudspaces.
Die Aufnamen von Webcams - ich nehme an es geht hier um Überwachung - müssen übrigends verschlüsselt übertragen und gespeichert werden - zumindest in Ö, ich musste mich mal damit auseinander setzten. Auch da ist FTP also alles andere als geegnet, ja es gibt FTP over TLS mit aktivertem verschl. Datenport, aber da gibts deutlich einfacheres zu konfigurieren und warten.
 
Auch da ist FTP also alles andere als geegnet, ...
Aber dafür ist es geeignet:
Code:
:~$ wget -4 -c ftp://mirror.hs-esslingen.de/pub/OpenBSD/7.4/amd64/miniroot74.img
--2024-01-18 15:24:41--  ftp://mirror.hs-esslingen.de/pub/OpenBSD/7.4/amd64/miniroot74.img
           => »miniroot74.img«
Auflösen des Hostnamen »mirror.hs-esslingen.de (mirror.hs-esslingen.de)«... 129.143.116.10
Verbindungsaufbau zu mirror.hs-esslingen.de (mirror.hs-esslingen.de)|129.143.116.10|:21... verbunden.
Anmelden als anonymous ... Angemeldet!
==> SYST ... fertig.    ==> PWD ... fertig.
==> TYPE I ... fertig.  ==> CWD (1) /pub/OpenBSD/7.4/amd64 ... fertig.
==> SIZE miniroot74.img ... 5832704
==> PASV ... fertig.    ==> RETR miniroot74.img ... fertig.
Länge: 5832704 (5,6M) (unmaßgeblich)

100%[================================================================================>] 5.832.704   2,25MB/s   in 2,5s   

2024-01-18 15:24:44 (2,25 MB/s) - »miniroot74.img« gespeichert [5832704]
 
Aber dafür ist es geeignet:
Das ist ein völlig anderer Fall. Erstens geht es hier darum, das Du Dich mit einem Client verbindest. Zweitens benötigst Du keine Verschlüsselung, weil die angeforderte Datei liegt eh für jeden offen sichtbar herum. Du hast auch kein Problem mit etwaigen Zugangsdaten, da der Zugriff "anonym" ist.
 
OpenBSD bietet auch http(s) und rsync. Verstehe also deinen Punkt nicht so ganz. FTP ist in diesem Anwendungsfall (öffentliche Bereitstellung von Datein) halt nicht so scheiße das mans sofort vergraben muss - Zum Vergleich: Es wäre ein HTTP Get - Request nötig um die Datei über http zu bekommen, wärend ftp zuerst eine Verbindung auf einem Steuerport aufbaut, sich als anonymous anmeldet, ein Dirlisting holt und dann über einen zweiten Datenport die Datei lädt.
 
Das ist ein völlig anderer Fall.
Ja das ist ein anderer Fall und beim TE ist es auch ein völlig anderer Fall.
Er hat in seinem 1. Beitrag schon mitgeteilt, dass er EFTPS und nicht FTP benutzen will und dennoch hat man ihn darauf hingewiesen, dass FTP ein historisches Protokoll ist (... was ja auch stimmt und wie man sehen kann, auch ca. 40 Jahre nach seiner Spezifizierung trotzdem benutzt wird bzw. nützlich ist).
 
Neben der Frage wie man das Problem des OP löst, kann man auch einfach mal feststellen das FTP nicht nur ein "altes" Protokoll ist - das ist okay, das ist z.B. TCP/IP auch, sondern das es ein altes Protokoll ist das von Anfang ziemlich beschissen war und durch zusätzliches drangefrickel einer Verschlüsselung auch kein besseres Protokoll wird.

Dem muss man nun wirklich keine Träne mehr nachweinen, auch wenn man sicher immer irgend eine edge-anwendung findet (IP-Kameras im lokalen Netzwerk fand ich als beispiel nicht völlig aus der Luft) wo es evtl. nicht so dramatisch ist es einzusetzen, oder weil man feststellt das OpenBSD einen FTP-Server z.B. für legacy-setups anbietet.

(Und seit dem es https://cdn.openbsd.org/pub/OpenBSD gibt muss man auch nicht mehr zwangsweise versuchen herauszufinden welcher Mirror aus der nähe denn stabil, schnell, aktuell ist etc)
 
Wird aber offenbar seit 2009 nicht mehr weiterentwickelt, ob ich das ding verbindungen zu mir fremden ftp-servern aufbauen lassen würde, wenns sich denn immer noch gegen aktuelle openssl-versionen bauen lässt ...
 
Zurück
Oben