• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Problem mit vsftpd in Verbindung mit SSL

Mr.Check

New Member
Moin moin,

ich habe einen Server mit CentOS 6.5 auf dem jetzt für eine spezielle Anwendung neben SFTP auch FTP(S) zum Einsatz kommen. Dafür wurde vsftpd installiert, welcher grundsätzlich auch funktioniert. Sobald allerdings SSL bzw. TLS genutzt werden soll, kommt keine Verbindung zustande.

Hier der Logauszug aus FileZilla:

Code:
Status:	Verbindung hergestellt, warte auf Willkommensnachricht...
Antwort:	220 (vsFTPd 2.2.2)
Befehl:	AUTH TLS
Antwort:	234 Proceed with negotiation.
Status:	Initialisiere TLS...
Fehler:	Zeitüberschreitung der Verbindung
Fehler:	Herstellen der Verbindung zum Server fehlgeschlagen

Und das dazu passende Gegenstück aus dem Serverlog:

Code:
Thu Oct  2 09:10:02 2014 [pid 29771] CONNECT: Client "xxx.xxx.xxx.xxx"
Thu Oct  2 09:10:23 2014 [pid 29771] DEBUG: Client "xxx.xxx.xxx.xxx", "SSL_accept failed: error:00000000:lib(0):func(0):reason(0)"

Die SSL-Konfig sieht so aus:

Code:
ssl_enable=YES
ssl_tlsv1=YES
ssl_sslv2=YES
ssl_sslv3=YES
debug_ssl=YES
force_local_data_ssl=yes
force_local_logins_ssl=yes
rsa_cert_file=/etc/ssl/private/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.pem
require_ssl_reuse=NO
ssl_ciphers=HIGH

Der Server wird hinter einem NAT-Gateway betrieben, sämtliche Ports werden 1:1 weitergeleitet.

Jemand eine Idee, was dieses Verhalten hervorrufen könnte?
 
Hab den Servernamen eingetragen, Port 21, Protokoll FTP, Verschlüsselung "Explizites SSL über TLS anfordern", Verbindungart "normal".

Bevor ich die beiden Konfig-Optionen

Code:
force_local_data_ssl=yes
force_local_logins_ssl=yes

eingetragen habe funktionierte ohne Verschlüsselung auch alles. Nur das aushandeln der Verschlüsselung läuft in einen Timeout.
 
Du könntest mal testweise auch die schwächeren Cipher-Algoritmen zulassen, indem du bei ssl_ciphers nicht HIGH sondern MEDIUM, DEFAULT oder ALL verwendest (absteigende Anforderungen, es gibt aber noch mehr Möglichkeiten). Die Strings sind in der ciphers Man-Page beschrieben, die OpenSSL mitbringt.
 
Horche mal auf einer der beiden Seiten - am Besten auf beiden - in den Netzwerkverkehr rein (Wireshark, tcpdump...). Das Problem liegt vermutlich eher am Client und dem NAT ;)

Bei unverschlüsseltem FTP kann das NAT-Gateway auf dem Control-Channel mitlesen welche Ports in welche Richtung geöffnet werden müssen und die Datenverbindungen direkt durchlassen (ALG nennt sich das Zauberwort).
Sobald FTPS zum Einsatz kommt geht das nicht mehr und du rennst vor die Firewalls resp. vor das NAT.

Allerdings ist es zumindest hochgradig ungewöhnlich dass das bereits beim Login zusammenfällt - eigentlich dürfte dieses Problem erst Auswirkungen auf die Übertragung von Dateien haben.
 
Du könntest mal testweise auch die schwächeren Cipher-Algoritmen zulassen, indem du bei ssl_ciphers nicht HIGH sondern MEDIUM, DEFAULT oder ALL verwendest (absteigende Anforderungen, es gibt aber noch mehr Möglichkeiten). Die Strings sind in der ciphers Man-Page beschrieben, die OpenSSL mitbringt.

Habe die Ciphers mal auf ALL gesetzt, hat leider nichts gebracht.

Horche mal auf einer der beiden Seiten - am Besten auf beiden - in den Netzwerkverkehr rein (Wireshark, tcpdump...). Das Problem liegt vermutlich eher am Client und dem NAT ;)

Ja das NAT habe ich ehrlich gesagt auch im Verdacht, kann mir aber noch nicht so richtig erklären an welcher Stelle. Dass der Client hinter einem NAT-Router ist, ist ja nichts ungewöhnliches und das Gateway, hinter dem der Server steht macht 1:1 NAT, die öffentliche IP wird also komplett auf die interne gemapped.

Habe das jetzt mal auf beiden Seiten mit tcpdump bzw. Wireshark analysiert und bin zu folgendem Ergebnis gekommen:

Der Anhang zeigt die Wireshark-Ausgabe auf der Client-Seite. Das Paket mit der lfd. Nr. 16, mit dem der Client versucht die Aushandlung der Verschlüsselung zu beginnen, kommt nicht beim Server an und daher läuft die Aushandlung in einen Timeout. Woran kann das liegen?

Ach ja, habe gerade mal testweise eine verschlüsselte FTP-Verbindung zu einem cPanel Server mit Pure-FTPD aufgebaut, der auch hinter einem NAT Gateway steht. Hier funktioniert alles einwandfrei.

Die große Frage bleibt für mich also gerade, warum der FTP Request nicht ankommt, obwohl er an die richtige (öffentliche) IP und Port 21 adressiert ist.
 

Attachments

  • wireshark.PNG
    wireshark.PNG
    38.7 KB · Views: 227
seccomp_sandbox=NO
in die Konfiguration und es könnte laufen.

Code:
vsftpd für vsftpd starten:500 OOPS: unrecognised variable in config file: seccomp_sandbox

Wenn ich das richtig sehe, gibt es dieses Feature und die dazugehörige Möglichkeit es zu deaktivieren erst ab vsftpd Version 3, über das CentOS 6 Repository wird "nur" Version 2.2.2 bereitgestellt.
 
Ich habe gerade in meiner funktionierenden vsftpd-Config (2.0.5, CentOS 5) nachgesehen - bei mir funktioniert TLS, allerdings ist der Server auch nicht hinter einem NAT:

Code:
tcp_wrappers=YES

ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=NO
force_local_logins_ssl=NO
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
rsa_cert_file=...........

pasv_min_port=40000
pasv_max_port=41000

Ich meine mich zu erinnern, dass es eine echte Hilfe war, SSLv3 und v2 abzuschalten und in jedem Fall die PASV-Ports zu definieren. Letztere sollten aber nur für Dateiübertragungen Auswirkungen haben.
 
Passives FTP ist sinnvoll und die Freigabe bestimmter Portranges in der Firewall.
Und meiner Erfahrung nach versagt Statefulinspection bei FTPS.
 
Passives FTP ist sinnvoll und die Freigabe bestimmter Portranges in der Firewall.
Und meiner Erfahrung nach versagt Statefulinspection bei FTPS.

Moin moin,

wie gesagt, auf Serverseite ist im NAT Gateway jeder Port freigeschaltet, da es sich um ein 1:1 NAT handelt, es wird also die komplette öffentliche IP auf die interne umgeschrieben.


@Lord Gurke

So hatte ich die Konfig aus Sicherheitsgründen auch am Anfang, habe dann nur nach und nach immer mehr erlaubt um Fehlerquellen auszuschließen.


Für mich bleibt es ein Rätsel, warum der FTP-Request des Clients sein Ziel nicht erreicht..
 
Kannst du einmal auf dem Server und dem NAT-Gateway desselben reinhören, ob da das Paket aufschlägt? Evtl. verschluckt das ja schon irgendein toller Heimrouter oder eine noch viel tollere Internet-Security Software.
 
Kannst du einmal auf dem Server und dem NAT-Gateway desselben reinhören, ob da das Paket aufschlägt? Evtl. verschluckt das ja schon irgendein toller Heimrouter oder eine noch viel tollere Internet-Security Software.

Also auf dem Server kommt das Paket definitiv nicht an. In das NAT Gateway vor dem Server kann ich leider nicht "reinschauen", da es sich um ein VMware vAPP-Netzwerk Gateway handelt.

Zum Verständnis: An einer lokalen Sicherheitssoftware auf dem Client kann es doch eigentlich nicht liegen, wenn das Paket im Wireshark auftaucht, richtig?
 
An einer lokalen Sicherheitssoftware auf dem Client kann es doch eigentlich nicht liegen, wenn das Paket im Wireshark auftaucht, richtig?
Lässt du SSL-Verbindungen scannen? Kann je nach Virenscanner/Desktop-Firewall mal Ärger machen, mal nicht. :confused:
 
Lässt du SSL-Verbindungen scannen? Kann je nach Virenscanner/Desktop-Firewall mal Ärger machen, mal nicht. :confused:

Ne SSL wird nicht gescannt, hab das auch gerade nochmal mit dem EICAR-Testfile getestet. Habe es auch mittlerweile von verschiedenen Geräten / Internetzugängen aus probiert, immer mit dem selben Resultat.

Hier habe ich ein ähnliches Problem gefunden:

http://serverfault.com/questions/162797/cant-connect-to-vsftpd-from-windows-xp-ftps

Allerdings konnte ich mich auch von einem OS X Client aus nicht verbinden..
 
Back
Top