VSFTP Erweiterung: ftps (ftp mit SSL)

[Darkyputz]

ich kann "von draussen" drauf zugreifen...
habe parallel auch fernwartung an; kann daher nicht sagen ob 443 nötig iss, aber 21 reicht zumindest von den ftp ports...
schalte den 443 gerade ab...
gebe dann näher bescheid, ob der 443 dazu nötig iss...

 

[Darkyputz]

wie ich grade sehen muss, ist Port 443 wichtig für ssl mit vsftp zu sein...bedeutet man sollte den haken "ssl aktiv" mit nem portfowarding eintrag verknüpfen.
sonst könnte es zu missverständnissen kommen...

 

[henfri]

Hallo,
wir (darky und ich) haben gerade mal versucht die Verbindung von ausserhalb aufzubauen.
Ich habe versucht auf Darkys Server (der ja intern funktioniert) zuzugreifen.

Einloggen klappt.
Aber dann: Port kommando fehlgeschlagen. Siehe

Im Passiven Modus das gleiche.

Gruß,
Hendrik

 

[matze1985]

Ob das an der SSL-Verbindung liegt würde ich bezeifeln, werde es aber später auch mal testen.

Zu der Sache mit den Ports.
1) Ja man muss natürlich den Port 21 für FTP nach außen öffnen. Dies muss man aber selber machen und es ist leider auch nicht möglich dies in der Vsftpd-Gui zu machen, da die Portveraltung sehr schwer ist, dazu gibt es aber das AVM-Firewall-Gui-Paket.
2)Der Port 443 ist Standrt für https, dass hat nix mit ftps zu tun. Dazu wird nur der Port 21 weiterhin verwendet.

Hier und Hier kann man sich über FTP und FTP über SSL informairen.

Wenn man aber nur Port 21 öfnet ist nur die Nutzung des passiven FTO-Modus möglich, da die Firewall im Weg ist.

 

[henfri]

Hallo,

wie kann ich denn dafür sorgen, dass der aktive FTP Modus funktioniert? Welche Ports muss ich freischalten/wie muss ich VSFTP konfigurieren?

Gruß,
Hendrik

 

[matze1985]

@Darky:
Hat es ohne SSL funktioniert?
Wie hast du deine Portweiterleitung gemacht?

 

[matze1985]

so jetzt habe ich etwas mehr Zeit deswegen jetzt mehr Hintergründe.

FTP besteht aus 2 Verbindungen 1 Controll und 1 Daten.
Der Aufbau der passiven FTP-Verb. geschiet auf folgende Weise:
Der Client baut eine Verbindung zu Server auf Port 21 auf.
Der Server antwortet und sendet das Port komando mit einem Port und einer IP.
Auf diese IP und Port versucht der Client die Datenverb. aufzubauen.

Das ist sehr kurz und knapp beschreiben, aber dafür habe ich ja vorhin weiterführende Links gepostet.

Hier sieht man schon die 2 großen Probleme eines FTP-Servers hinter einer NAT.
1) Der Server nimmt in der Standartconfig als IP, die IP auf der die Verb. eingegangen ist. Also beim Forwarding 192.168.178.1 (oder eine VirtuelleIP), diese ist für den Client aber nicht erreichbar.
2)Der Port, mit dem der Server antwortet ist nicht in der Firewall geöffnet.

Aktuelle Firewalls können diese Probleme beheben, indem sie der FTP-Verbindung "folgen" und den Port automatisch öffnen, sowie die IP ausbessern.

Verwendet man aber SSL, geht das natürlich nciht, weil sie es nicht lesen können.
Deswegen muss man das mit der Hand machen.

zu 1) Es ist wichtig den Port nicht zu forwarden, sondern zu "öffnen", als in der ar7.cfg einen 0.0.0.0:21 0.0.0.0:21 Eintrag vorzunehmen, damit die Verbidnung auf der Öffentlichen IP eingeht. Man kann die IP beim vsftpd auch mittels "pasv_address=84.170.YYY.XXX" überscheibe, dann müsste man das aber bei jedem IP-Cange ändern.

zu 2)Man legt am besten im Webif einen Range für die Passiven Port fest (z.b. Min 22333, max 22388) und macht ein forwarding für all diese Ports, damit der Server dort erreicht werden kann.

So habe ich jetzt meinen ftps-Server nach außen erreichbar bekommen.

@ Darky schicke mir doch nochmal deine aktuelle Config, vielleicht auch ne ICQ oder, dann schauen wir mal was bei dir fehlt. Dass bekommen wir schon hin.



zum aktiven FTP nur soviel:
Hier baut der Server die Datenverb. zum Client auf, deswegen muss die NAT-Firewall des Cleint eingestellt werden, dies ist aber in der Regel noch viel kompilizerter, da man ja verschiedene Clients zu lassen wil.

 

[Darkyputz]

soo...
habe einige teste gemacht...
ohne ssl und port 21 offen ->alles klar
mit ssl und port 21 offen ->fehler siehe oben von henfri
mit ssl und port 21 und 443 offen ->alles klar
mit port 20 habe ich nicht getestet...

 

[matze1985]

mit ssl und port 21 und 443 offen ->alles klar

ernsthalft?
kannst du mir nochmal deine config schicken?
Ich melde mich später über icq nochmal.

 

[cuma]

Schau doch einfach an welchen Ports der Prozess "listen" ist

 

[matze1985]

Hey,
leider habe ich es mit doch leichter vorgestellt, als ich dachte.
Bis jetzt hatte ich es selber immer nur aus dem lokalen Netz oder halt gestern auf meiner 2.Box probiert und dort mit pasv_address die IP überschreiben.
Heute habe ich dann auch mal auf der Hauptbox, die neue Firmware geflashed.
Dort habe ich das Portforwarding

0.0.0.0:21 0.0.0.0:21

angelgt, wie ich groß getön habe, aber leider hat sich meine Vermutung nicht bestätigt, und auch dass ist nur ein Forwarding

netstat -n
..
tcp        0      0 169.254.2.1:21          XXX.XXX.XX.X:54849     ESTABLISHED
...

aber auf das Fallback Interface.
Also habe ich meine GUI jetzt erweitert.
Im Anhang ist ein Patch, der folgendes erlaubt.
Zum einen kann man aktivieren, dass die aktuelle öffentliche IP automatisch beim generieren der config als pasv_address eingetragen wird. Und damit das auch nach einen DSL-Reconnet noch hält kann man aktivieren, dass ein Script restart_vsftpd unter /etc/onlinechanged angelegt wird, welches bei einem Reconnect dann automatisch den VSFTPD neu startet, damit die config neu generiert wird.

Dazu gibt es 2 Sachen, die Vorrausgesetzt sein müssen:
1.) Eine Labor-Firmware von AVM, denn diese führt alle unter /etc/onlinechanged/ liegenden Scripte aus.
2.)Mini-fo, denn da hier noch keine Einigung ist, wie man damit verfährt, kann man das script nur im read-only Bereich /etc/onlinechanged/ ablegen, welcher aber mit mini-fo beschreibbar ist. (sobald es dort einen besseren ort gibt, wird das dann von mir geändert)


##########################################################

Bei klappt damit dauerhaft der Zugang per SSL von außen.
Meine Config ist habe ich mit den Forwarding-Rules mal als Bsp in den Anhang gepackt.

 

[cuma]

Die IP fest in die Config zu generieren ist nicht so prickelnd, die ändert sich von zeit zu Zeit.

Hab eben auch mal versucht vsftpd mit ssl zu nutzen, was aber nciht so ganz funktioniert. Hier mal ein kleiner Bugreport:
-unter "Einstellungen" heisst der Menüpunkt "VSFTPD: Zertifikat&Schlüssel". Die Bezeichnung ist ersten mal zu lang und zweitens sind diese HTML-Sonderzeichen drin
-die Menüpunkt "VSFTPD: Zertifikat&Schlüssel" erscheint auch wenn SSL deaktivert ist.
-von "Pakete" - "Vsftpd" ist keine Link auf "VSFTPD: Zertifikat&Schlüssel" gesetzt
- Was bedeuted bei
"lokale Benutzer zwingen eine SSL-Verbindung für den Datenverkehr zu nutzen"
und
"lokale Benutzer zwingen eine SSL-Verbindung für den Login zu nutzen "
das "lokale", was nutzen die anderen Benutzer?
-Bei der "Chroot_List" ist auch noch ein Schreibfehler: "Fü alle Nutzer in die Liste ein"
-Die "Zusätzliche Konfigurationsoptionen" und "Chroot_List" könnte man auf eigene Seiten auslagern, die Hauptseite von Vsftpd ist mittlerweile ziehmlich voll geworden. Bei anderen Paketen wird das auch so gehandhabt
-Und was evtl noch fehlt (hatte ich schonmal angeregt): Hinweis "welches" Zertifikat, man braucht und "wie" man es erstellt (ich mache das nicht täglich)
Am fehlerhaften Zertifikat hat mein Test dann auch geendet

 

[matze1985]

welche Revision hast du ausgecheckt?
- Der zu lange Menüpunkt, da hast du Recht.
- Link von "Pakete" - "Vsftpd" zu "VSFTPD: Zertifikat&Schlüssel" sollte mit r2780 eingecheckt sein.
- das zwingen bedeutet, dass lokale Benutzer (alle auf der passwd) ssl verwenden müssen, es gibt Möglichkeiten nur den Login zu verschlüsseln, oder auch die Daten, die andern Benutzer sind anonymus.
-den Schreibfehler hatte ich mal korrigiert, aber Oliver hat da wohl den falschen patch erwischt.
-Den Hinweis zum erstellen kann ich nochmal hinzufügen.

Die IP fest in die Config zu schreiben ist nicht das optimale, da hast du recht, aber ich habe auf die Schnelle keine andere Möglichkeit gefunden, deswegen gibt es ja den Punkt mir dem restart_after_IP-change_script, welches über den multid aufgerufen wird.
Der Patch ist wohl auch noch nciht das richtige fürs svn, denn wie gesagt, dazu müssen die 2 Vorraussetztungen erfüllt sein, das ist wohl erst der fall, wenn sich hier was geklärt hat.
Leider fande ich in der Config keine Möglichkeit das zu umgehen.

edit: zum erstellen des Zertifikates:

openssl req -new -x509 -nodes -out vsftpd.pem -keyout vsftpd.pem

 

[cuma]

Ich hab Revision 2775 (Signatur) da sich danach iptables nicht mehr bauen lassen. Hätte wohl mal in den Trunk schauen sollen.
Das "lokale Benutzer" meint also alle, oder können da noch andere angelegt werden?
Das Verbinden mit dem Server war bisher bei mir kein Problem, weder aktiv noch passiv. Eigentlich kann das Problem auch nur bei "aktiv" auftreten, da der Server hier IP und Port vorgibt. Ich vermute aber vielmehr dass es ein Problem vom Client ist (bei Filezilla: Bearbeiten - Einstellungen - Verbindungen - FirewallEinstellungen). Alternativ könnte man sich noch iptables mit nat für ftp anschauen, das sollte aber schon von Seiten AVM gemacht worden sein, deren ftp läuft übers Internet. Die IP vorzugeben und immer zu ändern ist mehr ein Wörkaround

 

[matze1985]

das ist richtig, dass das mehr nen Workaround ist.

Es ist nicht ganz richtig, das der Server beim aktiven IP und Port vorgibt.
Beim aktiven FTP stellt der Server die Datenverbindung zum Client her.
Beim passiven gibt er Port und IP vor, auf die sich dann der Client verbindet.

Das ganze im beim unverschlüsselten FTP auch kein Problem, denn die meisten NAT-Firewalls (auch AVM) können diesem Verkehr folgen und öffnen automatisch die richtgen Port und ersetzten die IP, dass können sie beim verschlüsselten FTP nicht mehr, deswegen gibt es hier Probleme, da die Firewall von AVM leider auf keinem realen Interface ist, sondern "eher" virtuell und dann forwardet, deswegen, aber die Pakete auf interface xyz (siehe oben) ankommen und der ftp-server meint, ok da müssen sie dann wohl hin.


Es gibt grundsätzlich die möglichkeit virtuelle User einzurichten (siehe hier) habe es aber noch nie ausprobiert.

 

[cuma]

Stimmt, bei Verschlüsselung hat der Paketfilter das Nachsehen.
Es müsste dann allerdings vsftpd restartet werden, wenn onlinechanged auftritt. Bei mir ändert sich die IP dadurch allerdings nicht. Eine bessere möglichkeit wäre dann der inetd-Modus

 

[Darkyputz]

hehe...die fehler habe ich auch gesehn geahbt aber wollte nicht meckern da ich ja froh bin das sich das ding entwickelt...ich mecker immer erst ab trunk verison ,-)
habe das verhalten mit dem ssl und nicht mehr paketfilterfunktion bisher nicht so beobachten können...
sehr merkwürdig...oder iss das das ding was henfri oben gepostet hat?

 

[matze1985]

@cuma, meinst du, dass inet da was ändert, denn auch da kommen die Pakete auf der falschen IP rein.

@Darky: bin mir bei dir nicht ganz sicher, da ich meist immer ne Verbindung gekommen habe, aber dann nicht ins Verzeichnis schauen konnte (weil das Listing über die Datenverb. läuft, die nicht auf gebaut werden konnte.)

 

[Darkyputz]

so...meine butze iss jetzt mit ssl unterwegs...
kannst gern drauf rumkruachen und testen...
wenn du willst ändere ich dann auch gern mal was immer du willst...in remote drauf und kann eisntellen was du magst...

 

[matze1985]

hey Darky,

nachdem du nun die pasv_addres eingetragen hast und die Port für den Passiven-Verkehr geforwardet hast, konnte ich auf den FTP zugreifen und hab dir eine kleine Datei dagelassen (fuerDarky.txt) als Beweis.

Den Bug mit der input-feld für minimum und maximum der passiven Port (dort springt der Cursor immer raus), habe ich auch schonmal bemerkt, habe es umgangen, indem ich die Maus auf dem Feld festgehalten habe während des schreibens. Das ist aber noch von vor meiner Zeit, werde mir das aber mal anschauen bei Gelegenheit.

Das du auch ne Labor mit Mini-fo verwendest, kannst du dir mal nen Patch von oben anschauen, damit die Passiv-IP bei jedem Start richtig eingetragen wird und bei einem IP-Change VSFTPD neugestartet wird (um die config neu zu generieren).