xinetd 2.3.14 "could not bind listening IPv4 socket" to vsftpd 2.2.0 on Deb5.0.3

traylorre · 09-28-2009, 02:33 PM

Hi, I could really use some help here. Banging my head is now starting to hurt

. When I insert xinetd as a superserver, then I can no longer connect to my ftp daemon (vsftpd).

What works:
client --port21--> vsftpd
Both FTP and FTPS(TLS/SSL)

What does not work:
client --port21--> xinted --> vsftpd
Both FTP and FTPS(TLS/SSL)

(Yes, I switched vsftpd off of standalone (listen=no) for the xinetd case.)

Client and server are on the same domain. The server is a DNS-323 NAS running Debian Lenny 5.0.3. There is nothing in hosts.deny, hosts.allow. Everything is updated.

The client error:

Quote:

FileZilla
Status: Connecting to 192.168.0.150:21...
Status: Connection established, waiting for welcome message...
Response: 500 OOPS: could not bind listening IPv4 socket

Code:

CoreFTP
Connect socket #12100 to 192.168.0.150, port 21...
500 OOPS: could not bind listening IPv4 socket  
Can't establish connection --> 192.168.0.150:21 @ Mon Sep 28 11:53:23 2009   (0-2)

I also tried CuteFTP and SmartFTP.

Now you would say that something is tying up that port and that is why it cannot bind? I would agree.

Code:

Network_Drive:/var/ftp# netstat -tunapl
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:515             0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:3689            0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      2368/xinetd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      3075/sshd
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      -
tcp        0      0 192.168.0.150:139       192.168.0.195:1789      ESTABLISHED -
tcp        0      0 192.168.0.150:22        192.168.0.195:3798      ESTABLISHED 14647/sshd: root@tt
tcp        0      0 192.168.0.150:22        192.168.0.195:3318      ESTABLISHED 19734/sshd: root@tt
tcp        0      0 192.168.0.150:22        192.168.0.195:3320      ESTABLISHED 17142/sshd: root@tt
tcp        0      0 192.168.0.150:22        192.168.0.195:1571      ESTABLISHED 28767/sshd: root@tt
udp        0      0 192.168.0.150:137       0.0.0.0:*                           -
udp        0      0 0.0.0.0:137             0.0.0.0:*                           -
udp        0      0 192.168.0.150:138       0.0.0.0:*                           -
udp        0      0 0.0.0.0:138             0.0.0.0:*                           -
udp        0      0 224.0.0.1:13579         0.0.0.0:*                           -
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           -

But isn't that correct? I started an FTP daemon (xinetd superserver listening on port 21) so of course it would bind to it. I reran the above when the client was trying to connect, and there was no difference.

I also tried nmap, but uncovered nothing.

Looking at the xinetd log, I see that the ftp client is spawned but then immediately exits.

Code:

xinetd.log
05/1/1@01:04:40: DEBUG: 2368 {main_loop} select returned 1
05/1/1@01:04:40: DEBUG: 2368 {server_start} Starting service ftp
05/1/1@01:04:40: DEBUG: 2368 {main_loop} active_services = 1
05/1/1@01:04:40: DEBUG: 2614 {exec_server} duping 7
05/1/1@01:04:40: DEBUG: 2368 {main_loop} active_services = 1
05/1/1@01:04:40: DEBUG: 2368 {main_loop} select returned 1
05/1/1@01:04:40: DEBUG: 2368 {check_pipe} Got signal 17 (Child exited)
05/1/1@01:04:40: DEBUG: 2368 {child_exit} waitpid returned = 2614
05/1/1@01:04:40: DEBUG: 2368 {server_end} ftp server 2614 exited
05/1/1@01:04:40: INFO: 2368 {conn_free} freeing connection
05/1/1@01:04:40: DEBUG: 2368 {child_exit} waitpid returned = -1
05/1/1@01:04:40: DEBUG: 2368 {main_loop} active_services = 1

Meanwhile, vsftpd was not very helpful...

Code:

vsftpd.log
  ...  *chirp* *chirp* ... nothing here

Q1. xinetd does spawn vsftpd. But why does vsftpd immediately die??

Q2a. When in standalone mode, vsftpd is listening to 192.168.0.150:21, and works. I now use xinetd, and tell it that it has a service on port 21. I see in netstat that xinetd now binds to 192.168.0.150:21. Will not this cause contention for the same port?

Q2b. If Q2a is indeed the source of bind error, then how else am I supposed to configure xinetd and vsftpd? For example, if I tell xinetd to listen on a different port, how do I redirect that flow to port 21 which is what vsftpd expects? I do not see such a configuration in man xinetd.conf.

I am new to xinetd/inetd, so of course I suspect my configuration file xinetd.conf could have problems. Nothing fancy:

Code:

xinetd.conf
service ftp
{
        socket_type             = stream
        port                    = 21
        protocol                = tcp
        wait                    = no
        user                    = root
        group                   = group
        server                  = /usr/local/sbin/vsftpd
        server_args             = /etc/vsftpd_scott.conf
        nice                    = 10
        disable                 = no
        instances               = 10
        nice                    = 10
        per_source              = 6
        cps                     = 10 3
}

Any help is much appreciated.

Thanks alot for your time!

bathory · 09-28-2009, 05:31 PM

Why don't you use /etc/xinetd.d/vstpd and leave the default xinetd.conf alone, to see if it helps.

Regards

traylorre · 09-28-2009, 10:22 PM

[Ooops incomplete post, please see message #5 by me]

Smartpatrol · 09-28-2009, 10:37 PM

traylorre · 09-28-2009, 10:39 PM

Hi bathory,

At first I felt that I had already done what you suggested but then I thought -- where would I ever get if I didn't take troubleshooting advise?

Well I tried it as you suggested, and I still can't connect with vsftpd when xinetd is in the equation. Only this time, I do not get could not bind listening IPv4 socket error, instead I just get Connection Timed Out.

Here is the xinetd server debug output:

Code:

Network_Drive:/etc# xinetd -d
Service defaults
        Instances = 25
        Bind = All addresses.
        Only from: All sites
        No access: No blocked sites
        Logging to file: /var/log/servicelog (no limits)
        Log_on_success flags = HOST PID
        Log_on_failure flags = HOST

Service configuration: ftp
        id = ftp
        flags = IPv4
        socket_type = stream
        Protocol (name,number) = (tcp,6)
        port = 21
        Instances = 4
        wait = no
        user = 0
        Groups = no
        Nice = 10
        PER_SOURCE = -1
        Bind = All addresses.
        Server = /usr/local/sbin/vsftpd
        Server argv = vsftpd
        Only from: All sites
        No access: No blocked sites
        Logging to common log file
        Log_on_success flags = HOST DURATION PID USERID
        Log_on_failure flags = HOST USERID

05/1/1@02:23:38: DEBUG: 15769 {cnf_start_services} Started service: ftp
05/1/1@02:23:38: DEBUG: 15769 {cnf_start_services} mask_max = 6, services_started = 1
05/1/1@02:23:38: NOTICE: 15769 {main} xinetd Version 2.3.14 started with libwrap loadavg options compiled in.
05/1/1@02:23:38: NOTICE: 15769 {main} Started working: 1 available service
05/1/1@02:23:38: DEBUG: 15769 {main_loop} active_services = 1
-- OK try to connect with GNU ftp from SAME IP 192.168.0.150 --
05/1/1@02:23:57: DEBUG: 15769 {main_loop} select returned 1
05/1/1@02:23:57: DEBUG: 15769 {server_start} Starting service ftp
05/1/1@02:23:57: DEBUG: 15769 {main_loop} active_services = 1
05/1/1@02:23:57: DEBUG: 15775 {exec_server} duping 8
-- I AM IN ... and viewing files and changing directories --
-- Now I log off of GNU FTP session --
05/1/1@02:24:37: DEBUG: 15769 {main_loop} active_services = 1
05/1/1@02:24:37: DEBUG: 15769 {main_loop} select returned 1
05/1/1@02:24:37: DEBUG: 15769 {check_pipe} Got signal 17 (Child exited)
05/1/1@02:24:37: DEBUG: 15769 {child_exit} waitpid returned = 15775
05/1/1@02:24:37: DEBUG: 15769 {server_end} ftp server 15775 exited
05/1/1@02:24:37: DEBUG: 15769 {svc_postmortem} Checking log size of ftp service
05/1/1@02:24:37: INFO: 15769 {conn_free} freeing connection
05/1/1@02:24:37: DEBUG: 15769 {child_exit} waitpid returned = -1
05/1/1@02:24:37: DEBUG: 15769 {main_loop} active_services = 1
-- Now I try to connect with FileZilla, this time from a different host 192.168.0.195 --
05/1/1@02:25:03: DEBUG: 15769 {main_loop} select returned 1
05/1/1@02:25:03: DEBUG: 15769 {server_start} Starting service ftp
05/1/1@02:25:03: DEBUG: 15769 {main_loop} active_services = 1
05/1/1@02:25:29: DEBUG: 15769 {main_loop} select returned 1
05/1/1@02:25:29: DEBUG: 15769 {server_start} Starting service ftp
05/1/1@02:25:29: DEBUG: 15769 {main_loop} active_services = 1
05/1/1@02:25:33: DEBUG: 15805 {exec_server} duping 8
05/1/1@02:25:33: DEBUG: 15769 {main_loop} active_services = 1
05/1/1@02:25:33: DEBUG: 15769 {main_loop} select returned 1
05/1/1@02:25:33: DEBUG: 15769 {check_pipe} Got signal 17 (Child exited)
05/1/1@02:25:33: DEBUG: 15769 {child_exit} waitpid returned = 15805
05/1/1@02:25:33: DEBUG: 15769 {server_end} ftp server 15805 died
05/1/1@02:25:33: DEBUG: 15769 {svc_postmortem} Checking log size of ftp service
05/1/1@02:25:33: INFO: 15769 {conn_free} freeing connection
05/1/1@02:25:33: DEBUG: 15769 {child_exit} waitpid returned = 0
05/1/1@02:25:33: DEBUG: 15769 {main_loop} active_services = 1
05/1/1@02:25:59: DEBUG: 15814 {exec_server} duping 8
05/1/1@02:25:59: DEBUG: 15769 {main_loop} active_services = 1
05/1/1@02:25:59: DEBUG: 15769 {main_loop} select returned 1
05/1/1@02:25:59: DEBUG: 15769 {check_pipe} Got signal 17 (Child exited)
05/1/1@02:25:59: DEBUG: 15769 {child_exit} waitpid returned = 15814
05/1/1@02:25:59: DEBUG: 15769 {server_end} ftp server 15814 died
05/1/1@02:25:59: DEBUG: 15769 {svc_postmortem} Checking log size of ftp service
05/1/1@02:25:59: INFO: 15769 {conn_free} freeing connection
05/1/1@02:25:59: DEBUG: 15769 {child_exit} waitpid returned = -1
05/1/1@02:25:59: DEBUG: 15769 {main_loop} active_services = 1
-- FileZilla cannot connect, and has given up trying to connect --

Again, no log shows in vsftpd. ... *chirp* *chirp* ...

Code:

Network_Drive:/etc# sed -e '/^#.*/d' xinetd.conf
anonymous_enable=YES
local_enable=YES
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
xferlog_file=/var/log/vsftpd.log
listen=NO
Network_Drive:/etc# sed -e '/^#.*/d' xinetd.conf

defaults
{
        instances               = 25
        log_type                = FILE /var/log/servicelog
        log_on_success  = HOST PID
        log_on_failure = HOST
        disabled                = tftp
}

service ftp
{
        socket_type             = stream
        wait                    = no
        user                    = root
        server                  = /usr/local/sbin/vsftpd
        instances               = 4
        log_on_success  += DURATION USERID
        log_on_failure += USERID
        nice                    = 10
}

Code:

Network_Drive:/etc# sed -e '/^#.*/d' vsftpd.conf
anonymous_enable=YES
local_enable=YES
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
xferlog_file=/var/log/vsftpd.log
listen=NO

Please, any other ideas?

traylorre · 09-28-2009, 11:01 PM

Quote:

Originally Posted by Smartpatrol

Few things can you even run vsftpd d for daemon out of inetd? I don't think so since I am pretty sure it wants to run as a daemon. what was the motivation for running it from xinetd?

I built and manage my companies FTP server using vsftpd running as a daemon without issue.

Hi Smartpatrol,

I have read that to run vsftpd in standalone, we set LISTEN=YES in vsftpd.conf. If LISTEN=NO, then vsftpd is awakened by a super-server like inetd or xinetd. From what I gathered, it is common to match vsftpd with xinetd.

My motivation is to use xinetd to enforce protection policy for vsftpd. I like the multitude of the features of xinetd, like IP/domain banning. If the hacker got root access on my box (and managed to get out of chroot), then all of my family's information would be exposed. I bet this is a slim chance, but the risk is unfathomably bad (now I sound like I harbor lots of dark secrets!

)

Also, I may want to start up some other daemons like mail and would like to have one portal to configure for protection of all my daemons.

traylorre · 09-28-2009, 11:44 PM

Great... some useful information! Like bathory said, try the vanilla setup. So far, I got FTP without encryption to work for all these clients EXCEPT FileZilla (that's a shame; FileZilla is my favorite)

I managed to get this to work:
client FTP ---->xinted --> vsftpd
Again, this is regular FTP.

I updated all the logs in message #5 above.

I ran this while BSD FTP was connected from the same host as xinetd (192.168.0.150):

Code:

Network_Drive:/etc# netstat -tunapl
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      15998/xinetd
tcp        0      0 192.168.0.150:21        192.168.0.150:2864      ESTABLISHED 16000/vsftpd
tcp        0      0 192.168.0.150:2864      192.168.0.150:21        ESTABLISHED 15999/ftp

15998/xinetd is the superserver listening daemon.
16000/vsftpd is the vsftpd daemon
15999/ftp is my local BSD FTP client

Note the 21 above: this answers my question about whether there is a port conflict on port 21, and how the system looks when it is working.

Summary (for the same vanilla unecrypted xinetd + vsftpd setup):
-- I can connect via local machine using standard linux FTP (connects INSTANTLY
-- I can connect via network machine using Windows SmartFTP (1 minute wait)
-- I can connect via network machine using Windows CuteFTP (1 minute wait)
-- I can connect via network machine using Windows FireFTP Firefox plugin (1 minute wait)
-- I can connect via network machine using Windows CoreFTP (1 minute wait)

-- I cannot connect via network machine using Windows FileZilla

If someone should in future encounter my problem, then please cut and paste my vsftpd.conf file and xinetd.conf files in previous post and see if that works. Now I will try to get SSL/TLS to work.

Will update here ASAP.

traylorre · 09-29-2009, 02:44 AM

Whew. Solved.

In a nutshell, I isolated these directives in vsftpd.conf to be the culprit:

If ANY of these banner directives are enabled, then the connection fails (and without mention of the banner being a culprit)!

Code:

#banner                  = /etc/xinetd.banner
#banner_success          = /etc/xinetd_success.banner
#banner_fail             = /etc/xinetd_fail.banner

Keep them commented, I say.

I also tried creating brand new files in Windows notepad because there is mention of \CR\LF line endings that might be needed by clients. Still did not work.

I will list here which FTP clients I tried and the results for posterity, along with xinetd.conf and vsftpd.conf:

Setup:
client (LAN) -> (WAN) DNS to lookup mydomain.net (WAN) -> (LAN) xinetd -> vsftpd
FTP using TLS encryption

CuteFTP 8.0.2: SUCCESS
connection takes 30-60 seconds

CoreFTP LE 2.1: SUCCESS
connection takes 30-60 seconds
Changing directories is very slow (~10 seconds) :/

FireFTP Firefox plugin : FAIL

Code:

Unable to make a connection. Please try again.
Unable to make a connection. Please try again.

SmartFTP v4.0.1: FAIL
Note, if I connect directly to my linux box, then it works ok. But when I go through WAN, then I get this error. Yet CoreFTP and CuteFTP works through WAN just fine.

Code:

...
[00:24:35] PROT P
[00:24:35] 200 PROT now Private.
[00:24:35] PASV
[00:24:35] 227 Entering Passive Mode (192,168,0,150,196,95).
[00:24:35] Passive ip address returned from server different from server ip.
[00:24:35] Opening data connection to 192.168.0.150 Port: 50271
[00:24:35] LIST -aL
[00:24:35] Connected. Exchanging encryption keys...
[00:24:35] 0 bytes transferred. (0 bytes/s) (93 ms)
[00:24:35] 425 Security: Bad IP connecting.
[00:24:35] SSL/TLS internal error (Error = 0xa387465c).
[00:24:35] The token supplied to the function is invalid
[00:24:35] The token supplied to the function is invalid
[00:24:35] Client closed the connection.

Code:

Network_Drive:/etc# cat xinetd.conf
#
# Configuration file for xinetd
#

defaults
{
        instances               = 25
        log_type                = FILE /var/log/servicelog
        log_on_success  = HOST PID
        log_on_failure = HOST
}

service ftp
{
#--------------------------------------------------------------------------------
# determines the uid for the server process.
# Ineffective if the effective user ID of xinetd is not super-user
        user                    = root
# determines the gid for the server process.
# If not specified, then group of user will be used (from /etc/passwd).
# Ineffective if the effective user ID of xinetd is not super-user and if the groups attribute is not set to 'yes'
#       group                   = root
# Yes=executed with access to the groups that the server's effective UID has access to.
# No=server runs with no supplementaty groups.  Needed for many BSD systems.
#       groups                  = yes
#--------------------------------------------------------------------------------
        socket_type             = stream
        protocol                = tcp
        port                    = 21
# no=multithreaded; yes=singlethreaded
        wait                    = no
        server                  = /usr/local/sbin/vsftpd
        server_args             = /etc/vsftpd.conf
#--------------------------------------------------------------------------------
# Banner
#       banner                  = /etc/xinetd.banner
#       banner_success          = /etc/xinetd_success.banner
#       banner_fail             = /etc/xinetd_fail.banner
# Log everything
        log_type                = file /var/log/xinetd_vsftpd.log 5K 20K
        log_on_success          += DURATION HOST USERID EXIT
        log_on_failure          += HOST USERID ATTEMPT
#--------------------------------------------------------------------------------
# Limits the total number of connections from ALL IP sources
        instances               = 20
# Determines server priority.  check nice(3) for more info.  Can be negative
        nice                    = 10
# Limits the total number of connections from one IP source
        per_source              = 10
# Linits the rate of incoming connections.  Connections per second; number of seconds to wait.
        cps                     = 10 3

Code:

Network_Drive:/etc# cat vsftpd.conf
# Example config file /etc/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.
local_enable=YES
#
# Uncomment this to enable any form of FTP write command.
write_enable=YES
#
# 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=011
#
# 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.
#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
#
# 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.log
debug_ssl=YES
#
# 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
idle_session_timeout=6000
#
# 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=Welcome to my FTP server.
# Override ftpd_banner with a file
banner_file=/etc/vsftpd.banner
#
# 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 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=NO
#
# This directive enables listening on IPv6 sockets. To listen on IPv4 and IPv6
# sockets, you must run two copies of vsftpd whith two configuration files.
# Make sure, that one of the listen options is commented !!
#listen_ipv6=YES

#rsa_cert_file=/usr/share/ssl/certs/vsftpd_cert.pem
#rsa_private_key_file=/usr/share/ssl/certs/vsftpd_private_key.pem
#rsa_cert_file=/usr/share/ssl/certs/vsftpd_both.pem

rsa_cert_file=/usr/share/ssl/certs/server.crt
rsa_private_key_file=/usr/share/ssl/certs/server.key

log_ftp_protocol=YES

require_cert=NO
ssl_request_cert=NO
# I think this following breaks CoreFTP
require_ssl_reuse=NO
implicit_ssl=NO

ssl_enable=YES
force_local_data_ssl=YES
force_local_logins_ssl=YES

ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=YES

#background=YES
use_localtime=YES

# enable the userlist file
userlist_enable=YES
# NO = users on list are ALLOWED access (otherwise not); YES = users on list are DENIED access (otherwise not)
userlist_deny=NO
userlist_file=/etc/vsftpd.user_list

# If chroot_list_enable is YES, then this list becomes a list of
# users to NOT chroot().
# users to chroot (see chroot_list_enable after)
chroot_local_user=YES
# YES = user on list ARE NOT chrooted (enabled full dir access); NO = users on list ARE chrooted (not enabled full dir access)
chroot_list_enable=YES
chroot_list_file=/etc/vsftpd.chroot_list

#delay_successful_login=1
#ftp_data_port=20

listen_port=21
max_clients=20
max_login_fails=10
max_per_ip=10
pasv_min_port=50000
pasv_max_port=51000

Thanks bathory, and SmartPatrol!

traylorre · 09-29-2009, 04:26 AM

SmartPatrol,

Do you use anything in conjunction with your vsftpd setup for security?

Thanks.

Smartpatrol · 09-29-2009, 10:47 PM