1

So I have been really struggling the past few days trying to get an FTPES chrooted instance of vsftpd set up on Red Hat 7.3.

The objective is to have external users login only to their respective directory to only download files. There will be around 50 ftp users.

vsftpd version 3.0.2, Red-Hat 7.3 

To start off here is my vsftpd conf:

# The default compiled in settings are fairly paranoid. This sample file
# loosens things up a bit, to make the ftp daemon more usable.
# Please see vsftpd.conf.5 for all compiled in defaults.
#
# READ THIS: This example file is NOT an exhaustive list of vsftpd options.
# Please read the vsftpd.conf.5 manual page to get a full idea of vsftpd's
# capabilities.
#
# Allow anonymous FTP? (Beware - allowed by default if you comment this out).
anonymous_enable=NO
#
# Uncomment this to allow local users to log in.
# When SELinux is enforcing check for SE bool ftp_home_dir
local_enable=YES
#
# Uncomment this to enable any form of FTP write command.
write_enable=NO
#
# Default umask for local users is 077. You may wish to change this to 022,
# if your users expect that (022 is used by most other ftpd's)
local_umask=022
#
# Uncomment this to allow the anonymous FTP user to upload files. This only
# has an effect if the above global write enable is activated. Also, you will
# obviously need to create a directory writable by the FTP user.
# When SELinux is enforcing check for SE bool allow_ftpd_anon_write, allow_ftpd_full_access
#anon_upload_enable=YES
#
# Uncomment this if you want the anonymous FTP user to be able to create
# new directories.
#anon_mkdir_write_enable=YES
#
# Activate directory messages - messages given to remote users when they
# go into a certain directory.
dirmessage_enable=YES

# Activate logging of uploads/downloads.
xferlog_enable=YES
dual_log_enable=YES
vsftpd_log_file=/var/log/vsftpd/vsftpd.log

# Make sure PORT transfer connections originate from port 20 (ftp-data).
connect_from_port_20=YES
#
# If you want, you can arrange for uploaded anonymous files to be owned by
# a different user. Note! Using "root" for uploaded files is not
# recommended!
#chown_uploads=YES
#chown_username=whoever
#
# You may override where the log file goes if you like. The default is shown
# below.
xferlog_file=/var/log/vsftpd/xferlog.log
#
# If you want, you can have your log file in standard ftpd xferlog format.
# Note that the default log file location is /var/log/xferlog in this case.
xferlog_std_format=YES
#
# You may change the default value for timing out an idle session.
#idle_session_timeout=600
#
# You may change the default value for timing out a data connection.
#data_connection_timeout=120
#
# It is recommended that you define on your system a unique user which the
# ftp server can use as a totally isolated and unprivileged user.
#nopriv_user=ftpsecure
#
# Enable this and the server will recognise asynchronous ABOR requests. Not
# recommended for security (the code is non-trivial). Not enabling it,
# however, may confuse older FTP clients.
#async_abor_enable=YES
#
# By default the server will pretend to allow ASCII mode but in fact ignore
# the request. Turn on the below options to have the server actually do ASCII
# mangling on files when in ASCII mode.
# Beware that on some FTP servers, ASCII support allows a denial of service
# attack (DoS) via the command "SIZE /big/file" in ASCII mode. vsftpd
# predicted this attack and has always been safe, reporting the size of the
# raw file.
# ASCII mangling is a horrible feature of the protocol.
#ascii_upload_enable=YES
#ascii_download_enable=YES
#
# You may fully customise the login banner string:
ftpd_banner=TEST
#
# You may specify a file of disallowed anonymous e-mail addresses. Apparently
# useful for combatting certain DoS attacks.
#deny_email_enable=YES
# (default follows)
#banned_email_file=/etc/vsftpd/banned_emails
#
# You may specify an explicit list of local users to chroot() to their home
# directory. If chroot_local_user is YES, then this list becomes a list of
# users to NOT chroot().
# (Warning! chroot'ing can be very dangerous. If using chroot, make sure that
# the user does not have write access to the top level directory within the
# chroot)
chroot_local_user=YES
passwd_chroot_enable=YES
local_root=/data/ftp/pub/somedir
hide_ids=YES
# (default follows)
#chroot_list_file=/etc/vsftpd/chroot_list
#
# You may activate the "-R" option to the builtin ls. This is disabled by
# default to avoid remote users being able to cause excessive I/O on large
# sites. However, some broken FTP clients such as "ncftp" and "mirror" assume
# the presence of the "-R" option, so there is a strong case for enabling it.
#ls_recurse_enable=YES
#
# When "listen" directive is enabled, vsftpd runs in standalone mode and
# listens on IPv4 sockets. This directive cannot be used in conjunction
# with the listen_ipv6 directive.
listen=YES
#
# This directive enables listening on IPv6 sockets. By default, listening
# on the IPv6 "any" address (::) will accept connections from both IPv6
# and IPv4 clients. It is not necessary to listen on *both* IPv4 and IPv6
# sockets. If you want that (perhaps because you want to listen on specific
# addresses) then you must run two copies of vsftpd with two configuration
# files.
# Make sure, that one of the listen options is commented !!
#listen_ipv6=NO

pam_service_name=vsftpd
userlist_enable=YES
tcp_wrappers=YES

# Enable Passive Mode for ftp server.
pasv_enable=YES
pasv_min_port=10090
pasv_max_port=10100

# Enable TLS / SSL Connections
ssl_enable=YES

# To Allow anonymous users to use SSL
allow_anon_ssl=NO

# To force local users to use SSL
force_local_data_ssl=YES
force_local_logins_ssl=YES

# The following option depend on the authentication method you require.
ssl_ciphers=HIGH
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO

# These values must adjust according to your environemnt.
rsa_cert_file=/etc/pki/tls/certs/<removed_full_name>.pem
rsa_private_key_file=/etc/pki/tls/private/<removed_full_name>.key

require_ssl_reuse=NO

Currently I set users directories up like this:

/data/ftp/pub/somedir/./ftpuser1
/data/ftp/pub/somedir/./ftpuser2
This works and chroots me into /ftpuser1 however I am unable to view any files or other directories & I am able to traverse down one directory into the /data/ftp/pub/SOMEDIR which I do not want, because users will be able to see how many other ftpuserxx there are.

I have also tried:

/data/ftp/pub/somedir/ftpuser3/./ 
<this fails with error code: Error: GnuTLS error -15: An unexpected TLS packet was received. Error:Could not connect to server>

Permissions on the ftp directories are as follows: inside /data/ftp/pub:

drwxr-xr-x. 5 root root 48 Jan 12 09:03 somedir

inside /data/ftp:

drwxr-xr-x. 3 root root 21 Jan 10 16:42 pub

inside /data:

drwxr-xr-x. 3 root root 17 Jan 10 16:42 ftp

inside somedir folder:

drwx------. 3 ftpuser1 ftpuser 108 Jan 11 16:23 ftpuser1
drwx------. 2 ftpuser2 ftpuser  78 Jan 12 09:04 ftpuser2
drwx------. 3 ftpuser3 ftpuser  92 Jan 12 09:03 ftpuser3

inside ftpuser1 folder:

drwx------. 2 ftpuser1 ftpuser 23 Jan 11 16:23 test_instructions
-rwx------. 1 ftpuser1 ftpuser  0 Jan 11 16:23 test.txt
Mr.J
  • 123
  • 1
  • 1
  • 10
  • 1
    Logs from `/var/log/vsftpd.log` and `/var/log/auth.log` can probably explain what's happening under the hood. I have a `vsftpd` service on my Debian, the configs look similar to yours, yet I remember wading through a lot of issues before it eventually worked the way I wanted, and looking into the logs helped greatly. – Vlad Nikiforov Jan 12 '17 at 15:07
  • Thank you for the comments. I've checked `/var/log/vsftpd/vsftpd.log` and there isn't any relevant information. It basically just has generic connected strings. Is there a way to place this into debug mode? I do see some `denied {read} for pid=13793 comm="vsftpd"`. I'll look into this, which may be the reason why I can not see any files. This still doesnt fix my chroot issue however. – Mr.J Jan 12 '17 at 15:47
  • 1
    I was able to allow files to be shown by adding setting the `ftpd_full_access boolean on`. Unfortunately the `ftp_home_dir` was removed in `7.3` noted in a question I posted a few days ago. I'm still having issues with users Chrooting into their `jailed /ftpuser1 directory`, however then having the ability to move to the `jailed / directory` which lists all `ftpuserxxx` directories. – Mr.J Jan 12 '17 at 16:45
  • 1
    Sorry, I'm out of ideas. Moreover, I just realized that our configurations are very different in that aspect, that I use a separate user database in MySQL, while you seem to use native Linux users to authenticate. So we have completely different permission schemes, and my experience is unlikely to be helpful in your case :( – Vlad Nikiforov Jan 12 '17 at 20:58
  • 1
    Your advice was helpful! No worries, checking my audit.log helped me fix one issue. I just am still having issues with users being able to access the jailed `/root` dir. – Mr.J Jan 13 '17 at 18:59

0 Answers0