Yes, vsftpd 3.0.0 just came out and I really, badly wanted to compile it under a Centos 6.2 machine that I have, which is getting brute-forced from an address in China (surprise! surprise!).
Compiling under Centos 6.2 is not a big deal, just as long you make sure you have the following dependencies installed on your server:
Here is the list of packages you should install on a Centos machine:
[root@galactus ~]# rpm -qa | grep -i tcp_wrap tcp_wrappers-7.6-57.el6.x86_64 tcp_wrappers-devel-7.6-57.el6.x86_64 tcp_wrappers-libs-7.6-57.el6.x86_64 [root@galactus ~]# rpm -qa | grep -i libcap libcap-devel-2.16-5.5.el6.x86_64 libcap-ng-0.6.4-3.el6_0.1.x86_64 libcap-ng-devel-0.6.4-3.el6_0.1.x86_64 libcap-2.16-5.5.el6.x86_64
As usual, if these packages are not installed on your machine, a simple yum install should be more than enough.
To do this, edit the file named builddefs.h, which should contain the following:
[root@galactus vsftpd-3.0.0]# less builddefs.h #ifndef VSF_BUILDDEFS_H #define VSF_BUILDDEFS_H #undef VSF_BUILD_TCPWRAPPERS #define VSF_BUILD_PAM #undef VSF_BUILD_SSL #endif /* VSF_BUILDDEFS_H */ builddefs.h (END)
Modify this as follows to activate the tcp wrappers function:
#ifndef VSF_BUILDDEFS_H #define VSF_BUILDDEFS_H #define VSF_BUILD_TCPWRAPPERS <-- #define VSF_BUILD_PAM #undef VSF_BUILD_SSL #endif /* VSF_BUILDDEFS_H */ builddefs.h (END)
Save the file and compile away, with make!
On my Centos machine, make install failed, because some man directories were not created. Correcting this was simple:
[root@galactus vsftpd-3.0.0]# mkdir -v /usr/local/man/man5
mkdir: created directory `/usr/local/man/man5'
[root@galactus vsftpd-3.0.0]# mkdir -v /usr/local/man/man8
mkdir: created directory `/usr/local/man/man8'
[root@galactus vsftpd-3.0.0]# make install
if [ -x /usr/local/sbin ]; then \
install -m 755 vsftpd /usr/local/sbin/vsftpd; \
else \
install -m 755 vsftpd /usr/sbin/vsftpd; fi
if [ -x /usr/local/man ]; then \
install -m 644 vsftpd.8 /usr/local/man/man8/vsftpd.8; \
install -m 644 vsftpd.conf.5 /usr/local/man/man5/vsftpd.conf.5; \
elif [ -x /usr/share/man ]; then \
install -m 644 vsftpd.8 /usr/share/man/man8/vsftpd.8; \
install -m 644 vsftpd.conf.5 /usr/share/man/man5/vsftpd.conf.5; \
else \
install -m 644 vsftpd.8 /usr/man/man8/vsftpd.8; \
install -m 644 vsftpd.conf.5 /usr/man/man5/vsftpd.conf.5; fi
if [ -x /etc/xinetd.d ]; then \
install -m 644 xinetd.d/vsftpd /etc/xinetd.d/vsftpd; fi
And I found myself with two versions of vsftpd installed:
[root@galactus vsftpd-3.0.0]# /usr/sbin/vsftpd -v vsftpd: version 2.2.2 [root@galactus vsftpd-3.0.0]# /usr/local/sbin/vsftpd -v vsftpd: version 3.0.0
/etc/init.d/vsftpd script (optional)For some reason -- that I have neither the time nor the interest to investigate -- the original /etc/init.d/vsftpd script failed to start vsftpd properly.
I simply replaced it with my own script, which has proved very reliable and starts vsftpd without a hitch:
#!/bin/sh
# Start/stop/restart VSFTPD
# Start vsftpd:
vsftpd_start() {
echo -n "Starting vsftpd... "
/usr/local/sbin/vsftpd /etc/vsftpd/vsftpd.conf &
test=$(echo $?)
case ${test} in
"0")
echo "[OK]"
exit 0
;;
*)
echo "[FAILED]"
exit 1
;;
esac
echo
}
# Stop vsftpd:
vsftpd_stop() {
echo -n "Stopping vsftpd... "
ftp_pid=`ps faxu | grep -i [v]sftpd.*vsftpd.conf | awk '{print $2}'`
kill -9 ${ftp_pid}
test=$(echo $?)
case ${test} in
"0")
echo "[OK]"
;;
*)
echo "[FAILED]"
exit 1
;;
esac
}
# Restart vsftpd:
vsftpd_restart() {
vsftpd_stop
sleep 1
vsftpd_start
}
# Check if vsftpd is running
vsftpd_status() {
echo "vsftpd status:"
vsftpd_pid=`ps faxu | grep -i [v]sftpd.*vsftpd.conf | awk '{print $2}'`
case ${vsftpd_pid} in
"")
echo "vsftpd is NOT running on server"
exit 1
;;
*)
echo "vsftpd is running, with PID=${vsftpd_pid}"
exit 0
;;
esac
}
case "$1" in
'start')
vsftpd_start
;;
'stop')
vsftpd_stop
;;
'restart')
vsftpd_restart
;;
'status')
vsftpd_status
;;
*)
echo "usage $0 start|stop|restart|status"
esac
exit 0
# end of script.The moment of trutch has arrived... Will vsftpd 3 and tcp wrappers work as advertised? To the logs!!
[root@galactus vsftpd-3.0.0]# tailf /var/log/vsftpd.log Fri Jun 15 07:00:46 2012 [pid 19948] CONNECT: Client "61.147.110.19", "Connection refused: tcp_wrappers denial." Fri Jun 15 07:00:46 2012 [pid 19948] FTP response: Client "61.147.110.19", "421 Service not available." Fri Jun 15 07:00:47 2012 [pid 19951] CONNECT: Client "61.147.110.19", "Connection refused: tcp_wrappers denial." Fri Jun 15 07:00:47 2012 [pid 19951] FTP response: Client "61.147.110.19", "421 Service not available." Fri Jun 15 07:00:47 2012 [pid 19953] CONNECT: Client "61.147.110.19", "Connection refused: tcp_wrappers denial." Fri Jun 15 07:00:47 2012 [pid 19953] FTP response: Client "61.147.110.19", "421 Service not available." Fri Jun 15 07:00:48 2012 [pid 19957] CONNECT: Client "61.147.110.19", "Connection refused: tcp_wrappers denial." Fri Jun 15 07:00:48 2012 [pid 19957] FTP response: Client "61.147.110.19", "421 Service not available." Fri Jun 15 07:00:49 2012 [pid 19960] CONNECT: Client "61.147.110.19", "Connection refused: tcp_wrappers denial." Fri Jun 15 07:00:49 2012 [pid 19960] FTP response: Client "61.147.110.19", "421 Service not available."
YES! (The client was, of course, integrated into /etc/hosts.deny before.
If you experience issues with users that are chrooted into a directory, this may be because (a) your users have a shell set to /bin/false and/or (b) because the chroot itself is not writable. The solution is then to add the following line into your /etc/vsftpd/vsftpd.conf file:
# the virtual user is restricted to the virtual FTP area # --- STANDARD CHROOT COMMAND --- chroot_local_user=YES # --- ADD THIS LINE TO MAKE THE CHROOT WRITABLE --- allow_writeable_chroot=YES
The problem can be seen in the following message:
gil@GALINUX:~> ftp your_ftp_server Connected to vv.ww.xx.yy. 220 (vsFTPd 3.0.0) Name (your_ftp_server:gil): johnuser 331 Please specify the password. Password: 530 Login incorrect. <--- 530 = problem. ftp: Login failed.
Apply the changes shown above and your user should now be able to login.