Also ich gehe mal davon aus, dass dem Kunden Zugriff auf seinen WebSpace gegeben werden soll, von daher ist das erst mal ein legitimer Vorgang.
Baut man dann auch etwas Sicherheit z.B. per Suexec+FastCGI (aufgrund des Mangels der mpm-per-user Apache Engine unter FBSD, etc. ) ein und lässt den WebServer nur unter der Userid des Kunden auf dessen WebSpace zugreifen, dann ist es auch okay, chrootet man die ftp-Session mit entsprechender Userid.
proftpd verwende ich nicht, setze aber bsdftpd-ssl erfolgreich ein mit dem das und mehr möglich ist. Hier mal die vollständige Konfiguration, wo die Authentifikation des ftp-Clients per Zertifikat und Verschlüsselung ausschließlich auf Ebene von TLS Voraussetzung ist.
In /usr/local/etc/rc.d/bsdftpd_ssl.sh
werden die Anforderung entsprechend konfiguriert:
##spaulding, som
##0) Consider
http://bsdftpd-ssl.sc.ru/documentation.html in general.
##1) Consider /usr/local/share/doc/bsdftpd-ssl/INSTALL to install a dummy cert
## with /usr/local/share/doc/bsdftpd-ssl/cert/cert-dummy.sh
## oder
http://www.werthmoeller.de/doc/microhowtos/openssl/apache/
## Dummy must be located under /etc/ssl/certs/ftpd.pem after this step.
##2) set up the trusted users under /etc/ftpusers
##3) $man ftpchroot-ssl and chroot the users
##4) configure welcome msg $ln -s /etc/motd /etc/ftpwelcome
##5) configure /etc/shells with a valid '/sbin/nologin' shell to let ftp users connect without ssh access!
##6) configure /etc/hosts.allow for particular access controlled by client domain
##adjust the args:
command_args="$command_args -h -l -l -L anon-abs -L wu-abs -z verify=2"
command_args="$command_args -z cert=/etc/ssl/certs/ftpd.pem"
command_args="$command_args -z CAfile=/usr/local/etc/x509-certs.crt -z auth=3"
command_args="$command_args -z debug -z logfile=/var/log/bsdftpdssl.log"
command_args="$command_args -S wu-ext -t 86400 -T 86400"
##auth=3 (instead off auth=2)!:
##Many clients need real unix account password confirmation too! (It's not sufficient to supply the certificate passphrase on backhand!)
#However, take the "Ipswitch WS_FTP 2007"-Client and everything is perfect!
##FireFtp extension for firefox works as client!
#TurboFtp is the second best choice, but it's a bit tricky handle the very first certificate handshake
##spaulding, eom.
Angenommen ist eine Userid unter der z.B. ein virtual Host läuft:
/etc/passwd:
spaulding:*:1035:1035:User &:/home/spaulding:/sbin/nologin
Für das ftp Login muss die "Shell" des Users zugelassen werden:
/etc/shells:
#
# List of acceptable shells for chpass(1).
# Ftpd will not allow users to connect who are not using
# one of these shells.
/bin/sh
/bin/csh
/bin/tcsh
/sbin/nologin
/usr/local/bin/bash
/usr/local/bin/rbash
Die userid darf
nicht in /etc/ftpusers eingetragen sein!
bsd-ftpd ist in dem Fall so konfiguriert, dass der Ftpd-Client mit einem Zertifikat (selbst signiert genügt) authentifizieren muss. Der öffentliche Schlüssel des Zertifikats wird als x509 Zertifikat eingetragen in
/usr/local/etc/x509-certs.crt:
#spaulding
-----BEGIN CERTIFICATE-----
SjELMAkGA1UEBhMCREUxETAPBgNVBAgMCE3DvG5jaGVuMQ8wDQYDVQQHEwZCYXll
cm4xFzAVBgNVBAMTDkp1bGlhbiBSZWlzY2hsMIIBIjANBgkqhkiG9w0BAQEFAAOC
xLkEWp2p0YU5ilun6/HeaFA+OI9ydADnsQibdRRzhrJVh9BMu24d8pAdO2KeJ8z5
vT5AqLm9oxfCwnBk58gbsLKgFJ8Ie2yVRooBYXDhb1vSN6NCqBKNSz8oXw7ujMny
MIIDETCCAfmgAwIBAAIFAIn+khYwDQYJKoZIhvcNAQEFBQAwSjELMAkGA1UEBhMC
REUxETAPBgNVBAgMCE3DvG5jaGVuMQ8wDQYDVQQHEwZCYXllcm4xFzAVBgNVBAMT
Dkp1bGlhbiBSZWlzY2hsMB4XDTA4MDYxODE3NTUzNFoXDTEyMDYxODE3NTUzNFow
EKldDsZLDzdVdDfU0+QppaVLzNvAGFRBwpt4RwIDAQABMA0GCSqGSIb3DQEBBQUA
AQ8AMIIBCgKCAQEAqqcq2vgux3+gv6yt36AtiDIQI8OL7b5J4XIE+MId9gUrGGY6
NCpa7fPrcOCks87WFHYla2wa3ntllhZ0nQj7vVyLuGJ3aXgidM3+i28lILqkGSCY
xHXW/4JiqlsuPQue0zwtUDoH4OSfH0XyHMc/7fHjB+zpte901tscAa+bvjIlXeps
A4IBAQCB2/E1W8m7Xgav/UdzDA4tJUq3S/z+108RuFIDs2T57iPqMFDypz+Z/wkH
NwPATxNxjjHGaKsHaOE/YRCiaWNCFQkI2l4vME6GIyECy6H9G0kr88mCartT2SJd
lX8JtJslwdoBgKyWNAIeGTF3DZ5IjyjyKzDP9zehxK+mfz8ZZ+SJb0xH/1Wxk+Mi
zlKUMzYtKYAWYEZs7AUKpz0lKp599jdG/X6Y4++bWLKtoP9Uu3gKX0kjq2p15UMM
j8piE9mydNvswEBg5mtaUTxkQJyNkQe7ZyBlRKnnUVcXHkHyot7IGtKqXqQjogT9
vuN1K4XP9liMsgazLqfYkYXoR0NQ
-----END CERTIFICATE-----
Authentifikation über öffentlichen Schlüssel und Mapping auf effektive Userid wird vorgenommen in
/etc/x509.auth:
ftpd:allow:spaulding:/C=DE/ST=RHP/L=Mainz/O=spaulding/OU=Spaulding/CN=Spaulding
Der Eintrag wird von der x509-Klartextdatei z.B. wie folgt erzeugt:
#openssl x509 -in x509.pem -noout -text|grep 'Subject:'|sed 's/^.*: /ftpd:allow:\/O:\//'|sed 's/, /\//g'
Das zu chrootende Verzeichnis wird definiert in
/etc/ftpchroot:
spaulding /cust/spaulding
Das von einer CA signierte Zertifikat (zur Not auch selbst signiert auch wenn bei der Authentifikation der Umstand angemeckert wird und man dann eben für die Zukunft eine Ausnahmebehandlung zulässt) eintragen in /etc/ssl/certs/ftpd.pem .
In dem Verbingunsprofil des ftp-Clients muss ja neben dem Zertifikat auch die Userid und Passwort des Accounts angegeben werden. Das Passwort also mit passwd einstellen.
Wer noch einen Tick mehr Sicherheit einbauen will und der User das auch wirklich mit sich machen lässt, der kann z.B. auch die Dialin Domain des Clients noch als Voraussetzung für den Verbindungsaufbau konfiguirieren:
/ets/hosts.allow:
ftpd:.the_clients_dialin_domain.de:ALLOW
Wenn das nicht gewünscht ist, dann generischen Zugriff einstellen
ftpd:ALL:ALLOW
Überwindet dennoch ein Hacker aller Sicherheitsvorkehrungen, dann kann man evtl. dennoch versuchen, ein schlechtes Gewissen einzureden:
/etc/ftpwelcome:
*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_W_A_R_N_I_N_G_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*
*__THIS_SYSTEM_IS_RESTRICTED_TO_AUTHORIZED_USERS_FOR_AUTHORIZED_USE_ONLY.___*
*__UNAUTHORIZED_ACCESS_IS_STRICTLY_PROHIBITED.______________________________*
*__IF_NOT_AUTHORIZED_TO_ACCESS_THIS_SYSTEM,_DISCONNECT_IMMEDIATELY!_________*
*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_W_A_R_N_I_N_G_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*
---
