proftpd mit mod_tls

crotchmaster

crotchmaster

happy BSD user
Hi,

ich habe jetzt auf einem FreeBSD-Server den proftpd mit TLS-Unterstützung aus den Ports installiert. Als Firewall verwende ich pf.

Ein Auszug aus der proftpd.conf
Code: 
ServerName                      "FTP Server"
ServerType                      standalone
DefaultServer                   on
ScoreboardFile                  /var/run/proftpd.scoreboard
UseReverseDNS                   off
IdentLookups                    off
Port                            21
PassivePorts                    55001 56999
Umask                           002 002
TimeoutLogin         60
TimeoutNoTransfer    900
TimeoutStalled      3600
LogFormat               default "%h %l %u %t \"%r\" %s %b"
LogFormat               auth    "%v [%P] %h %t \"%r\" %s"
LogFormat               write   "%h %l %u %t \"%r\" %s %b"
MaxInstances                    10
User                            www
Group                           www
LoginPasswordPrompt             on
RootLogin                       off
UseFtpUsers                     on
ShowSymLinks                    on
DenyFilter                      \*.*/
DefaultRoot /opt/wwwhome
<IfModule mod_tls.c>
        TLSEngine on
        TLSLog                          /var/log/proftpd/tls.log
        TLSProtocol                     SSLv23
        TLSRSACertificateFile           /usr/local/etc/proftpd/beastie.domain.tld.crt
        TLSRSACertificateKeyFile        /usr/local/etc/proftpd/beastie.domain.tld.key
        TLSCACertificateFile            /usr/local/etc/proftpd/CA.crt
        TLSOptions                      NoCertRequest
        TLSVerifyClient                 off
#        TLSRequired                     on
</IfModule>
<Directory /opt/wwwhome/*>
        AllowOverwrite          on
</Directory>
<Global>
</Global>
RequireValidShell               no
ExtendedLog                     /var/log/proftpd/access.log WRITE,READ write
ExtendedLog                     /var/log/proftpd/auth.log AUTH auth

Hier meine pf.conf
Code: 
ip_if="bge0"
log_if="bge0"
ip_addr="1.2.3.4"
table <allowed> { 2.3.4.5, 6.7.8.9 }
set timeout { interval 10, frag 30 }
set timeout { tcp.first 120, tcp.opening 30, tcp.established 86400 }
set timeout { tcp.closing 900, tcp.finwait 45, tcp.closed 90 }
set timeout { udp.first 60, udp.single 30, udp.multiple 60 }
set timeout { icmp.first 20, icmp.error 10 }
set timeout { other.first 60, other.single 30, other.multiple 60 }
set timeout { adaptive.start 0, adaptive.end 0 }
set limit { states 10000, frags 5000 }
set loginterface $log_if
set optimization normal
set block-policy drop
set require-order yes
scrub in all
block in log all
pass in quick on $ip_if inet proto tcp from any to $ip_addr port 80 keep state
pass in quick on $ip_if inet proto tcp from any to $ip_addr port 443 keep state
pass in quick on $ip_if inet proto tcp from <allowed> to $ip_addr port 21 keep state
pass in quick on $ip_if inet proto tcp from <allowed> to $ip_addr port 55000><57000 keep state
pass in quick on $ip_if inet proto tcp from <allowed> to $ip_addr port 22 keep state
pass out on $ip_if proto { tcp, udp } all keep state

Mein Problem ist nun, dass das Ganze ohne TLS wunderbar funktioniert, aber sobald ich den Kommentar vor TLSRequired entferne, kann ich mich mit dem Server verbinden und einloggen, das anschliessende Directorylisting wird dann irgendwann mit einem timeout abgebrochen.
Irgendwie sieht es so aus, als ob die Datenverbindung nicht zustande kommt, ähnlich einem blockierten Port für die Datenverbindung. Das sollte aber eigentlich durch die PassivePorts-Direktive und der Freischaltung der Ports durch pf erledigt sein.

Ich habe gegoogelt und auch die proftpd-Seite durchgearbeitet, aber keine Lösung gefunden.
Kann mir jemand ein Tipp geben?

Gruß c.

PS: Ich habe jetzt das ganze nochmal ohne pf ausprobiert, das gleiche Problem. Am Zusammenspiel von pf u. proftpd kann es nicht liegen.
 
Zuletzt bearbeitet:
starte doch einfach mal den proftpd im Debug Modus und schau was genau abgeht wenn Du mit dem Client über tls drauf bist.

Gruß Bummibaer
 
Mit der passiven Geschichte kann es ein Problem geben, wenn du dich aus einem anderen Netz auf deinen Server verbindest und dieser hinter einem Router steht. Sollte dem so sein, dann sag bescheid.

I.MC
 
Hi,

danke für eure Tipps,

Ich habe heute morgen auf meinem FreeBSD-Desktopsystem die Konstellation nachgebaut.
Hier funktioniert es super. Es liegt wahrscheinlich an unserer Firewall, über die unser internes Netz angebunden ist. Prinzipiell funtioniert es aber mit der angebenen Konfiguration des ProFTPD.

@pertze
Als clients habe ich kasablanca und unter Windoof CoreFTP Lite genutzt.

Bei kasablanca geht es ohne die Option 'TLSRequired on'. Ich dachte erst, das k. die Datenverbindung nicht verschlüsseln kann. Ich habe aber mal mit ethereal die Verbindung belauscht. Wenn ich in kasablanca die Verschlüsselung aktiviere, wird ab dem FTP-Befehl 'AUTH TLS' alles verschlüsselt, während ich bei Deaktivierung der Verschlüsselung alles mitlesen kann.
Sobald ich aber die Option 'TLSRequired on' aktiviere, kann ich mich mit proftpd verbinden, bekomme aber bei dem Versuch Dateien zu übertragen den Fehler '534 Unwilling to accept security parameters'. Das scheint wohl eine Unverträglichkeit zw. kasablanca und proftpd zu sein.

CoreFTP ist es egal, wie die Option TLSRequired gesetzt ist. Da funktioniert es immer.

Gruß c.
 
Wenn der Server hinter einer Firewall bzw. Router hängt liegt das Problem nahe. Bei passiven Verbindungen gibt der FTP Server als Zielip die SEINES Systems an die Clients zurück. Das siehst du schön am FTP Verbindungsdialog. Natürlich muss der Server aber die IP des Routers zurückliefern, hinter welchem er hängt. Ist die IPs des davorhängenden Routers 10.0.0.1 dann musst du also in der Conf "masqueradeaddress 10.0.0.1" eintragen. Dann liefert der FTP diese IP an die Clients zurück und dann tut auch das Portforfwarding. Man kann auch DNS dort eintragen, ändert sich die IP unter dem DNS aber immer, weil es z.B. eine dynamische Einwahlverbindung ist, dann muss man den proftpd per inedt / xinetd starten, denn die Direktiven werden nur einmalig beim Start ausgelesen.

Gruss, I.MC
 
ändert sich die IP unter dem DNS aber immer, weil es z.B. eine dynamische Einwahlverbindung ist, dann muss man den proftpd per inedt / xinetd starten, denn die Direktiven werden nur einmalig beim Start ausgelesen.
Zum Vergrößern anklicken....
Hier hilft einem das Modul "mod_dynmasq".

BTW:
Ist es nicht gescheiter hier einen NAT-Router zu benutzen, der soviel von FTP versteht das er die gemeldete pasv-IP anpassen kann?
 
@Wiedemann

Oh das Modul gab es damals noch gar nicht. Begeisterung...
Klar, ein Paketfilter der das versteht wäre supi. Aber geht das überhaupt mit verschlüsselten Paketen :-)?

I.MC
 
Aber geht das überhaupt mit verschlüsselten Paketen :-)?
Zum Vergrößern anklicken....
Ups *indieeckestell*

Oh das Modul gab es damals noch gar nicht. Begeisterung...
Zum Vergrößern anklicken....
Ist kein Modul das direkt bei den Sourcen dabei ist. Vielleicht ist es dir deshalb nicht aufgefallen?
Muss auch sagen, dass ich das selber noch nie benutzt habe. Ich kompiliere das bei mir im Packet halt immer mit, da ich mir denke das mancher dafür Verwendung haben könnte.
 
I.MC schrieb:
Wenn der Server hinter einer Firewall bzw. Router hängt liegt das Problem nahe. Bei passiven Verbindungen gibt der FTP Server als Zielip die SEINES Systems an die Clients zurück. Das siehst du schön am FTP Verbindungsdialog. Natürlich muss der Server aber die IP des Routers zurückliefern, hinter welchem er hängt. Ist die IPs des davorhängenden Routers 10.0.0.1 dann musst du also in der Conf "masqueradeaddress 10.0.0.1" eintragen. Dann liefert der FTP diese IP an die Clients zurück und dann tut auch das Portforfwarding. Man kann auch DNS dort eintragen, ändert sich die IP unter dem DNS aber immer, weil es z.B. eine dynamische Einwahlverbindung ist, dann muss man den proftpd per inedt / xinetd starten, denn die Direktiven werden nur einmalig beim Start ausgelesen.

Gruss, I.MC
Zum Vergrößern anklicken....
Hi, der 'richtige' Server, bei dem es noch nicht klappt, hat eine feste öffentliche IP-Adresse. Das NATing erfolgt nur auf der Firewall, die unser LAN absichert.

Gruß c.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben