Ich bin gerade in der Situation, für Entwicklungszwecke parallel zwei Web-Testserver aufsetzen zu müssen – einen unter Opensuse 12.2 und einen unter Opensuse 12.3. Entwickler sollen per FTP Files in Verzeichnisse unterhalb von
/srv/www/htdocs/webs
auf die Apache Testservern hochladen. Die dortigen Verzeichnisse sind “named virtual domains” des Webservers zugeordnet. Neu entwickelte PHP-Programme sollen unter diesen Domainen für unsere Kunden getestet werden.
Der jeweils dedizierte und einzige FTP-User auf diesen Systemen hatte natürlicherweise ein zunächst leeres Home-Verzeichnis
“/srv/www/htdocs/webs”
erhalten. Bzgl. der ihm zugeordneten Shell habe ich “/bin/false” definiert. Die Entwickler sollen sich über den FTP-Account auf dem Server-System nicht in eine Shell einloggen können.
Als FTP-Serverdienst wollte ich zur Abwechslung mal “vsftp” mit SSL/TLS [ftps] statt “sftp” aus der openssh-Suite aufsetzen. Dabei erlebte ich so einige Überraschungen, die vielleicht auch für andere interessant sind, die sich an vsftp heranwagen oder von früheren Opensuse-Versionen auf OS 12.3 upgraden wollen.
Sicherheit spielt in meinem Fall für die Testserver, die nur aus einem lokalen Netz zugänglich sind, zwar nicht eine essentielle Rolle, aber wenn man einen solchen Service aufsetzt, dann natürlich zur Übung gleich auf TLS-Basis.
Die wichtigsten Statements der “/etc/vsftp.conf” sehen daher wie folgt aus:
write_enable=YES
dirmessage_enable=YES
nopriv_user=ftpsecure
local_enable=YES
anonymous_enable=NO
anon_world_readable_only=YES
syslog_enable=NO
connect_from_port_20=NO
ascii_upload_enable=YES
pam_service_name=vsftpd
listen=YES
pasv_min_port=30000
pasv_max_port=30100
anon_mkdir_write_enable=NO
anon_upload_enable=NO
ssl_enable=YES
rsa_cert_file=/etc/ssl/servercerts/servercert.pem
rsa_private_key_file=/etc/ssl/servercerts/serverkey.pem
ssl_sslv2=NO
ssl_sslv3=NO
ssl_tlsv1=YES
#require_ssl_reuse=NO
chroot_local_user=YES
local_root=/srv/www/htdocs/webs
hide_ids=YES
ftpd_banner= mysysb vsFTP Server
idle_session_timeout=900
hide_ids=YES
log_ftp_protocol=NO
max_clients=20
max_per_ip=5
pasv_enable=YES
anon_root=/srv/ftp
anon_umask=022
local_umask=006
und abhängig von der Opensuse-Version:
seccomp_sandbox=NO [für Opensuse 12.3]
Wichtiger Hinweis:
Nach meiner Erfahrung ist es leider so, dass der letzte Parameter bei Opensuse 12.3 auf NO gesetzt werden muss. Das gilt nicht für Opensuse 12.2 und Opensuse 13.1. Dort sollte man den Standard nehmen bzw. das Statement ganz weglassen. Die aktuellen man-pages führen diesen Parameter gar nicht mehr auf !
Natürlich kann man sich über das “chroot_local_user=YES” und die Tatsache, dass nicht mehrere virtuelle User angelegt wurden, vielleicht streiten. Aber wir wollen ja keine userspezifischen Daten-Container aufbauen, sondern gemeinsam genutzte Web-Test-Domainen versorgen.
Nicht ganz unwichtig ist hier das Statement
local_root=/srv/www/htdocs/webs
das auch künftige andere User auf ein ganz bestimmtes Verzeichnis – hier ist das identisch mit dem Home-Verzeichnis des FTP-Users – einschränken würde.
Übrigens: Da der FTP-User sich ja sowieso nicht einloggen darf, kann
man den Owner und die Gruppe des Verzeichnisses in unserem Fall auch auf “root:root”, z.B. mit Mode 751, ändern.
# chown root.root /srv/www/htdocs/webs
# chmod 751 /srv/www/htdocs/webs
Man muss das aber nicht. Wichtig ist hingegen der Entzug der Schreibrechte für unseren FTP-User – auch wenn das zunächst paradox wirken mag. Letzteres ist aus Sicherheitsgründen wichtig. Sie die Anmerkungen weiter unten.
Ein weiterer Hinweis:
Konfiguriert man vsftp mittels YaST2, so wird für TLS unbedingt ein File zu einem DSA-Key gefordert. Die YaST-CA-Verwaltung legt aber Serverzertifikate RSA-basiert an. Ich helfe mir über diese Klippe dadurch weg, dass ich das pem-File des RSA-Keys angebe, danach dann die Datei “vsftp.conf” editiere und die Statements zum Zertifikats- und Key-File wie oben gezeigt auf “RSA” abändere:
rsa_cert_file=/etc/ssl/servercerts/servercert.pem
rsa_private_key_file=/etc/ssl/servercerts/serverkey.pem
Die Kombination “local_enable=YES” und “ssl_enable=YES” lässt keine unverschlüsselten Sitzungen mehr zu
Hat man SSL aktiviert, werden unverschlüsselte Sitzungen nicht mehr zugelassen, wenn man sich über einen lokalen, nicht-anonymen User authentifizieren will. Das erscheint völlig logisch. Und so wunderte ich mich nicht, dass beim Versuch einer unverschlüsselten Verbindung folgende Meldung in FTP-Clients, wie Filezilla, hochkommt:
Response: 530 Non-anonymous sessions must use encryption.
Error: Could not connect to server
Eine klare und verständliche Meldung. Also “Explizites TLS” für die gewünschte FTP-Verbindung anfordern ! In Filezilla kann man das sehr einfach bei der Definition seiner FTP-Server hinterlegen.
Der FTP-User darf keine Schreibrechte auf sein chroot-Verzeichnis haben
Eine erste, wenn auch nicht wirklich überraschende Erkenntnis unter OS 12.2 und 12.3 war, dass man im Falle von
chroot_local_user=YES
aus Sicherheitsgründen gehindert wird, auf ein chroot-Verzeichnis eingeschränkt zu werden, auf dem der FTP-User Schreibrechte hat.
Aber Achtung: Das ist in unserem Beispiel das Verzeichnis aus dem Statement
local_root=/srv/www/htdocs/webs
Das wäre auch so, wenn der FTP-Account ein tieferliegendes Heimatverzeichnis hätte !
Merke:
Das Verzeichnis aus dem “local-root”-Statement kann durchaus ein anderes als das Heimatverzeichnis des FTP-Users sein! Passt man hier nicht auf, kann es bzgl. erforderlicher Rechtesetzungen schon mal zu Missverständnissen und Fehlern kommen. Der zu authentifizierende FTP-User darf bei Benutzung von “local_root” keine Scheibrechte auf demjenigen Verzeichnis haben, das in diesem Statement angesprochen wird. Die Rechte bzgl. eines ggf. abweichenden Heimatverzeichnis ist bei gesetztem “local_root” zweitrangig !
Die Einschränkung bzgl. der Schreibrechte versteht man! Das ist übrigens schon seit der vsftp-Version 2.5.x so und ist u.a. auch bei der Einrichtung aktueller sftp-Varianten mit chroot-Definitionen zu beachten.
Man kann das Verweigern einer Verbindung zu einem beschreibbaren chroot-Verzeichnis unter aktuellen vsftp-Versionen auch nicht mehr wie früher durch irgendwelche zusätzlichen Parameter wie “allow_writeable_chroot=YES” umgehen. Was dann natürlich Konsequenzen für das Setup der Verzeichnisstruktur hat, die von außen per FTP zugänglich sein soll.
Das eigentliche Problem ist aber, dass man als vsftp-Unbedarfter ggf. nicht entfernte Schreibrechte auf dem chroot-Verzeichnis nicht unbedingt als die eigentliche Ursache von Fehlermeldungen erkennt ! Solche Rechte können z.B. auch über eine unglücklich gesetzte Gruppenzugehörigkeit
ins Spiel kommen. Genau das war bei mir der Fall.
Hat man nun unglücklicherweise bei der Einrichtung des FTP-Users
- entweder Standardrechte auf seinem Heimatverzeichnis gesetzt und belassen,
- oder bei der Zuordnung zu einer Gruppe Schreibrechte auf dem chroot-Verzeichnis übersehen,
- oder nicht erkannt, dass es in der obigen Konfiguration um die Schreibrechte auf dem Verzeichnis aus dem “local_root”-Statement und nicht wirklich um das Heimatverzeichnis des FTP-Users geht,
so kann das unter bestimmten Umständen in Filezilla und unter OS 12.2 zu TLS-bezogenen Fehlermeldungen führen, was dann doch sehr missverständlich ist. Ich jedenfalls bekam beim Experimentieren mit sftp haufenweise TLS-Fehlermeldungen, die meist mit dem eigentlichen Problem – wie hier einer risikoreichen Zugangsberechtigung – im Kern gar nichts zu tun hatten und in die Irre führten. [Die Funktionstüchtigkeit seiner TLS-Einrichtung und seiner Zertifikate sollte man natürlich auch mal unabhängig von vsftp testen!]
Auf dem OS 12.3 erhielt ich dann aber nach einigen Experimenten in einer aktuellen Filezilla-Version die Meldung:
500 OOPS: vsftpd: refusing to run with writable root inside chroot ()
Die half dann wirklich weiter. Weiteren Aufschluss brachten folgender Artikel und die dortige Diskussion
https://www.benscobie.com/fixing-500-oops-vsftpd-refusing-to-run-with-writable-root-inside-chroot/
sowie ein genereller Artikel zu Sicherheit im Zshg. mit chroot()
http://www.onlamp.com/excerpt/PUIS3_chap16/index3.html
Hilfreich war zudem ein Blick in die Original-FAQ-Hinweise zum akt. vsftp-Packet in der Version 3.0.2 unter
vsftpd.beasts.org/users/cevans/untar/vsftpd-3.0.2/FAQ
aus der ich nachfolgend zitiere:
Q) Help! I’m getting the error message “refusing to run with writable root”.
A) vsftpd is protecting against dangerous configurations. The cause of this message is usually dodgy ownership of the ftp home directory. The home directory should NOT be owned by the ftp user itself. Neither should it be writable by the ftp user. A way to fix this is:
chown root ~ftp; chmod -w ~ftp
Another cause might be an attempt to use chroot_local_user without setting up the directory ownership properly.
Ok, das ist klar. Natürlich sollte ein FTP-User nicht an seinem Root-Verzeichnis herumpfuschen können. Das gilt, wie gesagt, auch für sftp-Installationen aus der openssh-Suite (s. etwa: http://www.techrepublic.com/blog/opensource/chroot-users-with-openssh-an-easier-way-to-confine-users-to-their-home-directories/229)
Also verändert man in Fällen, die meiner Konstellation vergleichbar sind, am besten die Owner und die Rechte auf dem local_root-Verzeichnis, wie oben beschrieben.
Ein weiteres interessantes Thema:
Q) Help! What are the security implications referred to in the “chroot_local_user” option?
A) Firstly note that other ftp daemons have the same implications. It is a
generic problem.
The problem isn’t too severe, but it is this: Some people have FTP user accounts which are not trusted to have full shell access. If these accounts can also upload files, there is a small risk. A bad user now has control of the filesystem root, which is their home directory. The ftp daemon might cause some config file to
be read – e.g. /etc/some_file. With chroot(), this file is now under the control of the user. vsftpd is careful in this area. But, the system’s libc might want to open locale config files or other settings…
OK, hieraus verstehe ich, dass User mit “Shell” = “/bin/false” unter gewissen Umständen zu einem Problem werden können. (Auf anderen als Opensuse Systemen muss man ggf. /bin/fale auch in die Datei /etc/shells aufnehmen).
Tatsächlich ist es mir in einigen ersten schnell hintereinander durchgeführten experimentellen Anläufen mit Filezilla unter OS 12.2 gelungen, Dateistrukturen oberhalb des chroot-Verzeichnisses zu sehen, die ich eigentlich nicht mehr hätte sehen dürfen. Ich hatte dabei zunächst TLS abgeschaltet und den FTP-User auf “/bin/false” gesetzt und keine chroot-Einschränkung vorgenommen. Danach bei laufender Filezilla-Sitzung “chroot_local_user=YES” auf dem Server gesetzt und den FTP-Service per “systemctl restart vsftp.service” neu gestartet. Die Filzilla-Sitzung wird dabei unterbrochen – man kann sie aber sofort restarten. Und dann geschehen manchmal die seltsamsten Dinge bzgl. der Anzeige des Dateibaums. Und man sieht, wie gesagt, ggf. Dinge, die man nun nicht mehr sehen sollte. Irgendwie waren dabei wohl Filezilla- und Server-Caches im Spiel. Ein Refresh in Filezilla führte nämlich jedesmal zur Reduktion der Filesystem-Darstellung.
Was immer man daraus schließen mag … ich sehe es als jedenfalls wichtig an, dass an an chroot-Konfigurationen nicht im lauenden Betrieb rumgebastelt wird, wenn nicht sichergestellt ist, dass dann alle potentiellen Zwischenspeicher geleert sind. Man muss halt den svftp-Service sauber aufsetzen und nicht im produktiven Betrieb an Berechtigungen rumbasteln. Zudem ist der oben diskutierte grundsätzliche Entzug der Ownerschip und der Schreibrechte am chroot-Verzeichnis auch hier von Bedeutung: Waren die Rechte von vornherein richtig, d.h. restriktiv gesetzt, traten die beobachteten Probleme mit der Sicht auf unerlaubte Verzeichnisbereiche erst gar nicht auf.
Konsequenz: Entzug der Schreibrechte
Man nimmt dem FTP-User und auch der Gruppe, der er zugeordnet ist, die Schreibrechte am Heimatverzeichnis. Hier “/srv/www/htdocs/webs” und legt darunter ein oder mehrere schreibbare Verzeichnisse an. In meinem Fall kein Problem. (Was aber machen Leute, die nach einem Upgrade vorhandene Verzeichnisstrukturen nicht umorganisieren können oder wollen ?)
Unter OS 12.2 lief das Ganze dann in meinem Beispiel auch ohne Problem mit der dortigen PAM, der vsftp-Version 3.0.2-3.4.1 und dem Kernel 3.4.6.
Identische vsftp-version Konfiguration wie unter OS 12.2 läuft nicht unter OS 12.3 und Kernel 3.7.10
Nachdem der vsftp-Server unter OS 12.2 dann endlich so lief, wie ich mir das wünschte, und die Rechte auf hochgeladene Verzeichnisse und Dateien per vsftp-umask, SGID-Bit und setfacl so erzeugt wurden, wie ich das für sinnvoll und notwendig befand, wollte ich die gleiche Konfiguration auch unter Opensuse 12.3 zum Laufen bringen.
Erstmal ging zu meinem Schrecken aber gar nichts. Hier ein Auszug aus der Filezilla-Kommunikation mit dem Server:
Status: TLS/SSL-Verbindung hergestellt.
Antwort: 331 Please specify the password.
Befehl: PASS *******
Antwort: 230 Login successful.
Befehl: SYST
Antwort: 215 UNIX Type: L8
Befehl: FEAT
Antwort: 211-Features:
Antwort: AUTH TLS
Antwort: EPRT
Antwort: EPSV
Antwort: MDTM
Antwort: PASV
Antwort: PBSZ
Antwort: PROT
Antwort: REST STREAM
Antwort: SIZE
Antwort: TVFS
Antwort: UTF8
Antwort: 211 End
Befehl: OPTS
UTF8 ON
Antwort: 200 Always in UTF8 mode.
Befehl: PBSZ 0
Antwort: 200 PBSZ set to 0.
Befehl: PROT P
Antwort: 200 PROT now Private.
Status: Verbunden
Status: Empfange Verzeichnisinhalt…
Befehl: CWD /
Antwort: 250 Directory successfully changed.
Befehl: PWD
Antwort: 257 “/”
Befehl: TYPE I
Antwort: 200 Switching to Binary mode.
Befehl: PASV
Fehler: GnuTLS error -15: Ein unerwartetes TLS-Paket wurde empfangen.
Fehler: Verbindung zum Server getrennt: ECONNABORTED – Connection aborted
Fehler: Verzeichnisinhalt konnte nicht empfangen werden
Nach etlichen Recherchen fand ich dann, dass ab Kernel 3.5.X wohl der Parameter zur seccomp sandbox
seccomp_sandbox=NO
auf NO gesetzt werden muss, was ich allerdings für produktive Server etwas beunruhigend finde. Siehe auch:
https://bugzilla.redhat.com/show_bug.cgi?id=845980
und
https://bugzilla.novell.com/show_bug.cgi?id=806758
und
https://bugzilla.novell.com/show_bug.cgi?id=786024.
Jedenfalls können wir mit der genannten Einstellung dann auch unter OS 12.3 auf den vsftp-Server zugreifen.
Problem mit syslog_enable=YES
Als ich dann jedoch
syslog_enable=YES
setzen wollte, kam die nächste Überraschung. In Filezilla taucht danach nämlich folgende Meldung auf :
Status: Connecting to 192.168.0.37:21…
Status: Connection established, waiting for welcome message…
Response: 500 OOPS: priv_sock_get_cmd
Error: Critical error
Error: Could not connect to server
Tja, und dafür habe ich keine Lösung gefunden als eben
syslog_enable=NO
Logging muss man dann eben anders machen. Kann ich aber mit leben ….
Ältere Filezilla-Versionen vertragen die neue Standardoption “require_ssl_reuse=NO” nicht
Bei Filezilla-Versionen 3.5.X kommt es zu Problemen mit der FTP-Verbindung, wenn
require_ssl_reuse=YES
gesetzt ist. Das ist aber in den aktuellen vsftp-Versionen als “Default” der Fall. Hier hilft dann im Falle einer Fehlermeldung ein explizites :
require_ssl_reuse=NO
oder man muss sich unter OS 12.3 die aktuellere Filezilla Version 3.7.0.1 von folgendem Repository
http://download.opensuse.org/repositories/network/openSUSE_12.3/
installieren. Mit dieser neueren Filezilla-Version geht dann auch “require_ssl_reuse=YES”.
(Ergänzung 08.06.2013: Es geht zumindest besser. Gestern bekam ich aber auch mit der neuen Filezilla-Version bei einem längeren Transfer ein Problem.)
Fazit
Ich verstehe das Bestreben der vsftp-Entwickler nach maximaler Sicherheit gut. Aber das sollte nicht zu so vielen Problemen mit aktuellen Distributionen führen. Die Doku dieser Distributionen muss diesbzgl. auch besser werden und die erforderlichen Einstellungen und potentiellen Probleme in den Release-Notes beschreiben.
Wenn ich mal meine Erfahrungen auf produktive Systeme übertrage, stelle ich mir allerdings die Situation als schlimm vor, die entsteht, wenn solche Systeme auf OS 12.3 mit 3.5-Kernels upgegraded werden. Das dann entstehende Desaster hat evtl. schon einige Admins in den Wahnsinn
getrieben. Es war auf Basis der Fehlermeldungen nämlich nicht immer so leicht, sich die richtigen Einstellungen zusammenzureimen. Nicht gerade Werbung für Opensource !
Abschließender Hinweis zu vsftp-Tests mit Änderungen der Credentials des FTP-Users auf LDAP-Servern
Ein abschließender Hinweis noch zu Experimenten mit Änderungen an den Shell-Zuordnungen oder an den Credentials des FTP-Users:
Ich hatte meinen FTP-User über einen separaten LDAP-Server konfiguriert. Unter Opensuse 12.3 kommt SSSD zum Einsatz. In der Standardkonfiguration hatte SSSD bei mir auf dem Server mit vsftp die Credentials gecacht. Dann kann es bei geänderten Passwörtern zu Problemen kommen, wenn der Remote-FTP-Client das neue und auf dem LDAP-Server auch geänderte Passwort benutzt, aber der vsftp-Server wegen des sssd-Chachings von dem neuen Passwort ggf. noch nichts mitbekommen hat!
In einer solchen Situation muss man die SSSD-Cache-Information, z.B. zu einem User, gezielt mittels des Kommandos
sss_cache -u USER
löschen. Unter USER ist die User-Id anzugeben.
(Das Thema der Verwendung gechachter Information durch SSSD hat mich beim Testen von Zugriffsberechtigungen für bestimmte vsftp-User mal kurzzeitig außer Fassung gebracht und mir gezeigt, das sssd-Caching auch mal ein substanzielles Problem darstellen kann !)
Zu anderen Varianten des sss_cache Kommados für das Purgen von Cache-Daten in bestimmten SSSD-Domainen sehe man in die man-Seiten und
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-cache.html
Unter Opensuse muss man übrigens das Paket “sssd-tools” installieren, um “sss_cache” nutzen zu können.
Ergänzung 04.09.2013 zu Firewall-Einstellungen:
Wegen eines aktuellen Erlebnisses: Natürlich muss man auch die Firewalls sowohl auf dem Server als auch auf dem Client angemessen einstellen. So ist auf dem Server der Port 21 für die Clients zu öffnen – wie auch der Range der Ports > 1024, die für den passiven FTP-Austausch benutzt werden. Die entsprechenden Port-Festlegungen hat man in der “/etc/vsftp.conf” vorgenommen. Standardmäßig ist dort der Range
pasv_min_port=30000
pasv_max_port=30100
eingestellt. Aber natürlich kann ma auch einen anderen Range wählen. Man darf dann nur nicht vergessen, die Firewall(s) anzupasssen !
Ergänzung 07.11.2014 zum Parameter connect_from_port_20
Ein Leser hat mich darauf aufmerksam gemacht, dass die Einstellung
connect_from_port_20=NO
ein kleinen Sicherheitsvorteil bringen mag. Das wird ein wenig kontrovers diskutiert. Siehe z.B.:
http://forums.opensuse.org/showthread.php/466059-VSFTP-Not-Allowing-External-Connections
In vielen vsftpd Installationsanweisungen im Internet findet man aber die Einstellung “NO”. Da ich in der NO-Einstellung auch keinen gravierenden Nachteil erkennen kann, habe ich die oben angegebenen Einstellungen entsprechend abgeändert.
