www.ProFTPD.de
13. März 2007, 18:19:40 *
Willkommen Gast. Bitte einloggen oder registrieren.
Haben Sie Ihre Aktivierungs E-Mail übersehen?

Einloggen mit Benutzername, Passwort und Sitzungslänge
News: SMF - Neu installiert!
 
  Übersicht Hilfe Suche Login Registrieren  
  Zeige Beiträge
Seiten: [1]
1  ProFTPD / ProFTPD - Deutsch / Secure Site to Site Transfer am: 27. Februar 2006, 13:50:20
Hallo *,

kann man zwischen zwei ProFTPd verschlüsselt Daten übertragen lassen?
Wenn ich mit FlashFXP von einem ProFTPd zum anderen über einen verschlüsselten Datenkanal schicken möchte, bekomme ich folgende Meldung:
Code:
[R] CPSV
[R] 500 CPSV not understood
Secure site to site transfers not supported by this ftp server

Bei anderen FTP Deamonen tritt diese Meldung nicht auf (aber ich sage auch das ProFTPd nicht im passiven Modus angesprochen werden soll). Diese nutzen dann anscheinden den SSCN Befehl für die Verschlüsselung. Ist das mit ProFTPd nicht auch irgendwie möglich?
2  ProFTPD / ProFTPD - Deutsch / TLS: login/verbindung bricht ab am: 08. Februar 2006, 12:53:36
Anmerkung, durch Connection Tracking werden für den passiven Modus die Ports für die Datenverbindung des Transfers Ports automatisch geöffnet. Dies funktioniert aber nur, wenn das Connection Tracking in die Pakete schauen kann, was bei FTP normalerweise kein Problem ist, da es ein Klartextprotokoll ist.

Werden aber nun die Befehle verschlüsselt übermittelt, so kann das Connection Tracking die Befehler nicht mehr analysieren, und deshalb müssen zumindest für den passiven Datentransfer die Ports am Router geöffnet oder weitergeleitet werden, je nachdem ob der FTP Server auf dem Router selber oder dahinter läuft. Wird aktiv auf den FTP Server zugegriffen, sollte es ohne Probleme gehen, da normalerweise ausgehender Verkehr immer erlaubt ist, und der Server dann von seinem Port 20 auf den vom Client geöffneten Datenport verbindet.
3  ProFTPD / ProFTPD - Deutsch / Verständnisfrage zu Zugriffrechten am: 08. Februar 2006, 12:40:38
Huhu *,

mir ist das Rechtesystem ein klein wenig schleierhaft Zwinkernd
Gehe ich recht in der Annahme, daß in erster Linie die UID/GID des Proftpd Benutzers, nicht die des Deamons selber, welche in der proftpd.conf durch
Code:
User                            nobody
Group                           nogroup

festgelegt wird, Schreibrechte auf ein Verzeichnis bzw. eine Datei haben muss, und ich diese Rechte dann durch die <Directory> Direktive einschränken kann?

Ich benutze folgende Direktiven
Code:
AuthOrder               mod_auth_file.c
AuthUserFile            /usr/local/etc/passwd.proftpd
AuthGroupFile           /usr/local/etc/group.proftpd

Und habe dort drei Benutzer und drei Gruppen definiert:
Code:
Zeus:<kennwort>:1000:500::/srv/ftp:/sbin/nologin
Hermes:<kennwort>:1001:501::/srv/ftp:/sbin/nologin
Herakles:<kennwort>:1002:502::/srv/ftp:/sbin/nologin

Code:
ftpgod:x:500:
ftpmessenger:x:501:
ftpuser:x:502

Dazu folgende Verzeichnisstruktur:
Code:
/srv/ftp
/srv/ftp/nachrichten
/srv/ftp/nachrichten/upload

Wenn ich nun möchte, daß Zeus überall alle Rechte hat, Herakles nur im Unterordner nachrichten und darunter dann Herakles nur im Ordner upload was verändern darf (hochladen, löschen), wie realisiere ich das in proftpd?

Eine Möglichkeit ist natürlich mit umask 002 den Usern der gleichen Gruppe erlauben die Dateien zu ändern, sprich ich füge Zeus allen Gruppen hinzu, und Herakles dann noch der Gruppe ftpuser. Und dann setze ich die Rechte der Ordner folgendermassen:
Code:
drwxrwxr-x  Zeus     ftpgod       /srv/ftp
drwxrwxr-x  Hermes   ftpmessenger /srv/ftp/nachrichten
drwxrwxr-x  Herakles ftpuser      /srv/ftp/nachrichten/upload


Doch würde das auch mit <Directory> und AllowGroup Direktiven gehen?

Oder wären .ftpaccess Dateien die richtige Wahl? Wie müssen dann die Rechte der Verzeichnisse aussehen?
4  Linux / Linux / tls und iptables? am: 05. Februar 2006, 18:12:08
Huhu!

Normalerweise werden für den passiven Modus die Ports dynamisch von iptables freigegeben, dafür sorgt das Connection Tracking Modul für FTP . Dieses schaut sich die Pakete genau an, merkt, wann ein PASV Befehl abgeschickt wurde und liest hier den zu öffenden Port dann aus.

Dies ist aber nur möglich, da FTP eigentlich ein Klartext-Protokoll ist. In verschlüsselte Verbindungen kann iptables nicht reinschauen und somit auch nicht die Ports dynamisch öffnen. Die Lösung für dieses Problem ist die Ports direkt zu öffnen. Z.B.:
proftpd.conf:
Code:
Port 21
PassivePorts 49152 65534

und nun je nach Fall:
proftpd läuft auf nem Rechner direkt am Internet:
Code:
iptables -A INPUT -p TCP --dport 21 -j ACCEPT
iptables -A INPUT -p TCP --dport 49152:65534 -j ACCEPT

oder proftpd läuft hinter einem Router auf der ip $IP_FTP und das Internet liegt an der Schnittstelle $DEV_INET:
Code:
iptables -t nat -A PREROUTING -p TCP -i $DEV_INET --dport 21 -j DNAT --to $IP_FTP:21
iptables -t nat -A PREROUTING -p TCP -i $DEV_INET --dport 49152:65534 -j DNAT --to $IP_FTP:49152-65534
iptables -A FORWARD -p TCP -i $DEV_INET -d $IP_FTP --dport 21 -j ACCEPT
iptables -A FORWARD -p TCP -i $DEV_INET -d $IP_FTP --dport 49152:65534 -j ACCEPT


Bei einer aktiven Verbindung sollte das Problem nicht auftreten, wenn ausgehende Verbindungen erlaubt sind. Laut RFC (?) verbindet dann der FTP von Port 20 zum Client, wobei der Client dann den Port für die Datenverbindung bestimmt und öffnet.
5  ProFTPD / ProFTPD - SFV Checker / Wo liegt mein Berechtigungsproblem? am: 05. Februar 2006, 17:33:37
Hallo *,

leider komme ich mit dem SFV-Checker nicht so zurecht, wie ich es gerne hätte.

Ich würde gerne den ftpexecd im Kontext eines anderen Users laufen lassen. Doch so bald ich
Code:
User = root
Group = root

ändere, und z.b. nobody/nogroup angebe, gehen die Probleme schon los.
Hier die wichtigen Auszüge aus meinen Konfigurationsdateien:

proftpd.conf:
Code:
ServerName                      "ProFTPD Default Installation"
ServerType                      standalone
DefaultServer                   on

# Port 21 is the standard FTP port.
Port                            21

# Umask 022 is a good standard umask to prevent new dirs and files
# from being group and world writable.
Umask                           002

# To prevent DoS attacks, set the maximum number of child processes
# to 30.  If you need to allow more than 30 concurrent connections
# at once, simply increase this value.  Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of processes per service
# (such as xinetd).
MaxInstances                    30

# Set the user and group under which the server will run.
User                            nobody
Group                           nogroup

# To cause every FTP user to be "jailed" (chrooted) into their home
# directory, uncomment this line.
#DefaultRoot ~
DefaultRoot             /srv/ftp/FTP

# Normally, we want files to be overwriteable.
# and allow resume
AllowOverwrite          on

#AllowRetrieveRestart   on
AllowStoreRestart       on

AuthOrder               mod_auth_file.c
AuthUserFile            /srv/ftp/proftpd/passwd.proftpd
AuthGroupFile           /srv/ftp/proftpd/group.proftpd

SystemLog               /srv/ftp/proftpd/proftpd.log
ExtendedLog             /srv/ftp/proftpd/proftpd.elog

# Enable SFV Checker:
Logformat               sfv "%m %f"
ExtendedLog             /srv/ftp/proftpd/sfv.fifo WRITE sfv

<Directory /srv/ftp/FTP>
        <Limit ALL>
                DenyAll
        </Limit ALL>

        <Limit ALL>
                AllowGroup ftpadmin
        </Limit>

        <Limit DIRS READ>
                AllowGroup ftpuser
        </Limit>
</Directory>


group.proftpd:
Code:
ftpadmin:x:500:
ftpuser:x:501:


passwd.proftpd:
Code:
Admin:<kennwort>:500:500::/srv/ftp/FTP:/bin/false
User:<kennwort>:501:501::/srv/ftp/FTP:/bin/false


Mein Wunsch ist es, die Berechtigungen nach Gruppen zu verteilen. So sollen z.b. die Gruppenmitglieder von ftpadmin alles dürfen, ftpuser jedoch erstmal nur lesen. Jedoch sollen diese noch einen eigenen Upload Ordner bekommen, in den sie etwas hochladen können. Und die gleichen Leute einer Gruppe sollen auch die Ordner anderer User dieser Gruppe "bearbeiten" können. Deshalb hab ich als umask 002 gewählt.

Nun die Frage der Berechtigungen:
Ich habe rausgefunden, daß die FIFO Datei sfv.fifo von proftpd und ftpexecd beschreibbar sein muss. Doch wie muss ich die Berechtigungen einstellen, damit der SFV-Checker in die Ordner schreiben darf? Geht das überhaupt, wenn ich virtuelle User verwende?
Loggt sich ein virtueller User ein, so läuft eine proftpd Instanz mit der UID des virtuellen Users und auch mit dieser UID/GID werden die Dateien und Ordner des Users erstellt. Testhalber habe ich die Gruppen mit den gleichen GIDs aus der group.proftpd in die System-Datei group hinzugefügt, und dort dann den User nobody (in dessen Kontext ftpexecd läuft) angefügt. Doch auch wenn die Verzeichnisse mit der umask 002 für die Gruppe schreibbar ist, wird die SFV Datei nicht überprüft, bzw. es werden keine Statusdateien/-verzeichnisse erstellt.

Lasse ich manuell den SFV-Check laufen, funktioniert es:
Code:
su nobody -c "ftpsfvcheck.pl testfile.sfv"

Aber auch nur, da nobody in der entsprechenden Gruppe ist. Benutze ich einen anderen User, klappt es aufgrund mangelnder Berechtigungen nicht.

Was hab ich nun übersehen, oder falsch eingestellt? Any help would be appreciated Zwinkernd
6  ProFTPD / ProFTPD - Deutsch / Back to topic ;) am: 04. Februar 2006, 23:23:21
Ich habe auch einmal Verschlüsselung einstellen wollen und bin über folgendes Debian Howto gestolpert: de:howtos:sarge:proftpd_tls
Dort wird beschrieben, wie man ein Zertifikat mit nur eine Befehlszeile erstellen kann:
Code:
openssl req -new -x509 -days 365 -nodes  -out /etc/ssl/certs/proftpd.cert.pem -keyout /etc/ssl/certs/proftpd.key.pem

Dazu dann noch die entsprechenden Direktiven:
Code:
<IfModule mod_tls.c>
TLSEngine                       on
TLSLog                          /var/log/tls.log
TLSProtocol                     SSLv23
TLSOptions                      NoCertRequest
TLSRSACertificateFile           /etc/ssl/certs/proftpd.cert.pem
TLSRSACertificateKeyFile        /etc/ssl/certs/proftpd.key.pem
TLSVerifyClient                 off
</IfModule>

Scheint mir etwas schneller und einfacher, als eine eigene CA aufzumachen?
Seiten: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.2 | SMF © 2006-2007, Simple Machines LLC Prüfe XHTML 1.0 Prüfe CSS
Seite erstellt in 0.143 Sekunden mit 16 Zugriffen.