Problems With VS-FTPD Under FC4

[miCRoSCoPiC^eaRthLinG 0]

Hey guys,
[tab][/tab]I just reinstalled my server with FC4. VSFTPD is enabled on it. When I try to connect to it from my windows system using FileZilla - it connects fine, i.e. VSFTPD accepts the login/pass and shows the welcome message too. Then comes the problem - when it issues a LIST command and tries to show me the default directory it gets stuck for a good while and then times out. This is happening for ANY and EVERY directory. At first I thought it must be something to do with the chmodding - so I tried all the modes +777, +755 etc.. but no avail. Same result in all cases. Can someone point out where I'm going wrong ?

Here's my vsftpd.conf:

# Example config file /etc/vsftpd/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=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.#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## If you want, you can have your log file in standard ftpd xferlog formatxferlog_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 turning on ascii_download_enable enables malicious remote parties# to consume your I/O resources, by issuing the command "SIZE /big/file" in# ASCII mode.# These ASCII options are split into upload and download because you may wish# to enable ASCII uploads (to prevent uploaded scripts etc. from breaking),# without the DoS risk of SIZE and ASCII downloads. ASCII mangling should be# on the client anyway..#ascii_upload_enable=YES#ascii_download_enable=YES## You may fully customise the login banner string:ftpd_banner=Welcome to ABCD Co. FTP Services.# 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().#chroot_list_enable=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=YESpam_service_name=vsftpduserlist_enable=YES#enable for standalone modelisten=YEStcp_wrappers=YES

Here's a typical FileZilla session:

Status: Connecting to 10.19.168.5 ...Status: Connected with x.x.x.x. Waiting for welcome message...
Response: 220 Welcome to ABCD Co. FTP Services.
Command: USER abcd
Response: 331 Please specify the password.
Command: PASS *********
Response: 230 Login successful.
Command: FEAT
Response: 211-Features:
Response: EPRT
Response: EPSV
Response: MDTM
Response: PASV
Response: REST STREAM
Response: SIZE
Response: TVFS
Response: 211 End
Command: SYST
Response: 215 UNIX Type: L8
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/home/abcd"
Command: TYPE A
Response: 200 Switching to ASCII mode.
Command: PASV
Response: 227 Entering Passive Mode (10,19,168,5,207,58)
Command: LIST
Error: Timeout detected!
Error: Could not retrieve directory listing

This is getting too irritating I swear. I tried quite a few different ftp clients too. I even used the dos-based ftp client - same problem, except that it can list the files - but cannot upload/write any.

The folder /home/abcd is owned by the user/group abcd. So I don't see why there should be any problem listing/writing to it.

[yordan 10]

Just for clearness and completeness.Please try to connect using FileZilla in "Passive" mode.This mode is set up inside FileZilla, go the Sites Menu, click your site, then choose "advanced" choose "passive" mode instead of "active" or "automatic" mode.Please tell me first if this works.Then we will have to fix why vsftpd needs passive mode to be manually set.On some sites I really have to set this mode to passive, on other site I have seen "automatic" to automatically switch to passive when asked by the remote host.RegardsYordan

[miCRoSCoPiC^eaRthLinG 0]

This is really funny - FileZilla was in Passive mode all this while. I went to the Advanced as you said and found it to be in passive itself. Just for the heck of it, I set it to Active and have it a shot. And IT LISTED THE DIRECTORY !!!! I tried all three options there - i.e., Active, Passive and Default. Out of these only Active is working.

 

Well - that's one problem done.

 

Now to the second one - even though I can see the directory listing now - I still cannot write anything to it. Files pre-existing in the dir can be downloaded - but nothing uploaded to it !! When I attempt to upload - the file gets stuck in the queue with a message saying - Critical Transfer Error - and that's about it. Any bright ideas ?

 

For your reference, here's the new FileZilla log, after I switched it to Active

Status: Connecting to 10.19.168.5 ...

Status: Connected with 10.19.168.5. Waiting for welcome message...

Response: 220 Welcome to ABCD Services.

Command: USER abcd

Response: 331 Please specify the password.

Command: PASS *********

Response: 230 Login successful.

Command: FEAT

Response: 211-Features:

Response: EPRT

Response: EPSV

Response: MDTM

Response: PASV

Response: REST STREAM

Response: SIZE

Response: TVFS

Response: 211 End

Command: SYST

Response: 215 UNIX Type: L8

Status: Connected

Status: Retrieving directory listing...

Command: PWD

Response: 257 "/home/abcd"

Command: TYPE A

Response: 200 Switching to ASCII mode.

Command: PORT 10,19,168,50,15,76

Response: 200 PORT command successful. Consider using PASV.

Command: LIST

Response: 150 Here comes the directory listing.

Response: 226 Directory send OK.

Status: Directory listing successful

 

Log of when I try to upload

Status: Starting upload of C:\Temp\test.txt

Command: TYPE A

Response: 200 Switching to ASCII mode.

Command: PORT 10,19,168,50,15,110

Response: 200 PORT command successful. Consider using PASV.

Command: STOR test.txt

Response: 553 Could not create file.

Error: Upload failed

Status: Retrieving directory listing...

Command: TYPE A

Response: 200 Switching to ASCII mode.

Command: PORT 10,19,168,50,15,111

Response: 200 PORT command successful. Consider using PASV.

Command: LIST

Response: 150 Here comes the directory listing.

Response: 226 Directory send OK.

Status: Directory listing successful

 

[yordan 10]

What are your directory settings ?

From the logs it seems that the guy doing the ftp (the one who give his username and password) is not the owner of the filesystem, while the filesystem's umask is 022.

Simply, if the guy who wants to perform the ftp is georges just try "chown -R georges ." (don't forget the "." !

[evought 0]

Hey guys,

[tab][/tab]I just reinstalled my server with FC4. VSFTPD is enabled on it. When I try to connect to it from my windows system using FileZilla - it connects fine, i.e. VSFTPD accepts the login/pass and shows the welcome message too. Then comes the problem - when it issues a LIST command and tries to show me the default directory it gets stuck for a good while and then times out. This is happening for ANY and EVERY directory. At first I thought it must be something to do with the chmodding - so I tried all the modes +777, +755 etc.. but no avail. Same result in all cases. Can someone point out where I'm going wrong ?

 

<snip>

 

 

Ha Ha Ha. Funny thing is, I have seen this before. It took me weeks to figure this out. Do you have any kind of firewall in between you and your server (it can even be a built in windows or linux firewall)?

 

If so, it is a problem with either your FTP passive ports setting or your firewall, or both.

 

When a client connects passively, it uses a transient port requested by the server. This line tells you what the port is:

 

Response: 227 Entering Passive Mode (10,19,168,5,207,58)

 

A firewall is blocking this connection. You need to reconfigure your server to request different ports or your firewall(s) to accept different ports, preferably both. See an earlier post of mine with more complete discussion (http://forums.xisto.com/no_longer_exists/). This was for ProFTPd, but the principle is exactly the same.

[xboxrulz1405241485 0]

really odd, try disabling FC4's firewall.It usually helps, if you want firewall, make sure to open port 20 (according to your config; default FTP service usually use port 21)xboxrulz

[iGuest 3]

Hey M^E,

 

I just did a clean install of FC5 not so long ago (was using FC4), so vsftpd setup will be one of the things on my to do list, although I prefer SSH/SCP/SFTP over this.

 

Windows usually defaults the FTP Server to Active while Linux defaults usually to Passive.

 

Firstly I would configure the firewall to allow FTP, which you've probably done. I would also disable SELinux (bad idea I know, but too much hassle in configuring, especially if you want to use an httpd directory as a directory for ftpd, disabling SELinux can sometimes make things work, it was the only possible solution to get my printer working on the network).

 

I'm going to start from the beginning, for those who may or may not have vsftpd or it even running:

 

First to check if we have vsftpd:

 

whereis vsftpd

If it returns a location like /usr/sbin/vsftpd then we can safely assume we have it, if not, we'll install it:

 

su -c "yum -y install vsftpd"

Now to check if it's running:

 

pgrep vsftpd

If nothing returns, it's not running, if a (PID) number returns then it's running.

 

or we could do:

 

netstat -a | grep ftp

And if it returns a connection that's listening (LISTEN) then it's running and waiting.

 

So if it's not running, lets set it up as a service to run everytime our computer starts, and also the one off command to start it for this session we're in:

 

su -c "/sbin/chkconfig --level 345 vsftpd on"su -c "/sbin/service vsftpd start"

Now would probably be a good time to configure the configuration file for vsftpd, vsftpd.conf: (I use vim as my editor, use whichever one you like)

 

su -c "vim /etc/vsftpd/vsftpd.conf"

The lines that I altered:

 

anonymous_enabled=NO

ftpd_banner=Whatever Welcome Message You Want To Present

chroot_local_users=YES

chroot_list_enabled=YES

chroot_list_file=/etc/vsftpd/chroot_list

 

Next I create the chroot_list_file, which contains local users that are allowed to get out of their home directory:

 

su -c "vim /etc/vsftpd/chroot_list"

Add whatever users you want to allow access outside of their home directory, or just save it and leave it blank.

 

If SELinux is enabled, there's more steps you would need to take, but I'm leaving it disabled, so won't provide configuration for it, but if you're wanting to look into this, then "chcon" is the command you'll be looking for.

 

Actually, "chcon" would only work if you actually created the policy for it, though you should be looking at using "public_content_t", so instead I'll just give an alternative that should allow uploading from the allowed users:

 

the alternative

 

su -c "/usr/sbin/setsebool -P ftpd_disable_trans 1"

What setsebool does and you could do manually is creates or appends ftpd_disable_trans 1 to /etc/selinux/targeted/booleans.local, so you could create this file manually, or append that line onto it.

 

Let's restart vsftpd:

 

su -c "/sbin/service vsftpd restart"

Next is creating our public FTP location for additional users, which they're required to login, as there's no anonymous users allowed. This will only be read-only for these users, so it's a means of controlling who goes on your FTP server, and also so you can place files here so that these users can access them.

 

First lets create the group:

 

su -c "groudadd ftp-users"

Next lets create the directory:

 

su -c "mkdir /home/public_ftp"

Now to make it accessible to the ftp-users:

 

su -c "chmod 750 /home/public_ftp"su -c "chown root:ftp-users /home/public_ftp"

Next would be adding users you want to be able to access this directory and setting their password:

 

su -c "useradd -g ftp-users -d /home/public_ftp UserNameHere"su -c "passwd UserNameHere"

Run this command as many times as you need to create additional users.

 

Now all you would need to do is place some files into it for it to be accessed by these created users. We change the permission of these files to read-only:

 

su -c "chown root:ftp-users /home/public_ftp/*"su -c "chmod 740 /home/public_ftp/*"

Restarting vsftpd would be a good idea now. I think I've covered most of the general things, I will later talk about how we can create our FTP for making modifications for our web hosted files but will leave that till another time.

 

 

Cheers,

 

 

MC

[miCRoSCoPiC^eaRthLinG 0]

Thanks for all the help guys

 

Am not done with it yet - gotta finish today's work and then sit with it.

 

yordan: The home folder /home/abcd is owned by the login (abcd) and it's own group (abcd) I'm using.. I tried doing a whole bunch of chown's on it, e.g.:

chown -R abcd:abcd /home/abcd

Then I even tried various chmod's on /home/abcd.. +777, +755, +775 - nothing seemed to be able to make it write to the dir.

 

MC: Yep - you're right, this is FC4 with selinux. I had a feeling that selinux was at the root of all this evil but couldn't get my fingers on the right spot. Will follow all these directions and try to get it working tonight.

 

One last note - there IS a firewall on my WinXP system - it's the integrated firewall that came with my AV BitDefender Pro 9. It's a relatively painless firewall, that asks you whether to ALLOW/DISALLOW incoming/outgoing connections when you launch some new network client. Once ALLOWED with the "Remember Settings" option - it never bother's you for that client again.

 

And while you can specify incoming/outgoing ports for it - you can select an option to allow a client to make connections to ANY port. So I don't think the firewall at my end is the issue.

[iGuest 3]

Hey M^E,Well since you have SELinux, I updated the above just to help you out in that situation, but SELinux is quite a lot to take in and even with everything I've read about it, sometimes it's easier just to turn the thing off, but one day I'll be comfortable with it, just have to keep learning more and more about it.As for those chmod permissions, I think it's silly to actually allow things like 777, either 775 would be sensible or 755 on directories/executables (750 on cgi-bin, 700 on your home directory) and 664 or 644 on images/text files/archives, becauser user/group are the same, but in some cases you may have a users in the same group that you don't want to allow writing to that directory.Cheers,MC

[yordan 10]

I think it's silly to actually allow things like 777

Correct. However, for debugging purposes, it could be suitable to do it temporarily. Like today, this showed that these "permission denied" problems are not due to real user rights, because chmod 777 changed nothing. This allowed to go to the right direction.

[iGuest 3]

Correct. However, for debugging purposes, it could be suitable to do it temporarily. Like today, this showed that these "permission denied" problems are not due to real user rights, because chmod 777 changed nothing. This allowed to go to the right direction.

chmod 777 still does nothing in this sense though because the problem is still related to user rights and could be SELinux which provides even more security than permission settings.

What's important to understand is who can access your home directory and what rights do you have on your own home directory (chmod 700 by default), understanding this, and not thinking linux screws up permissions (who knows maybe linux could have?). This isn't about FTP though, this is just something that's standard no matter what means you log in as and if you couldn't perform any of your users regular actions against your own home directory, then you would question it, but do not think FTP is any different to normal login, SSH, etc, it uses the same principles, if you can write to your own home directory under normal login, then FTP should be similar (depending on the configuration file).

Then thinking about how the FTP worked, you can see from the config that local users are allowed to login, in which they get transferred to their home directory (remember only an owner would get transferred to that directory, other users would get transferred to their own home directory but from there on they could browse your directory if you gave it chmod 777 and you don't chroot users). Super Users shouldn't be allowed FTP login, so it'd be safe to assume they're not on FTP.

That's why I'm saying chmod 777 is silly, I prefer teaching people to understand why there is no need for this (also understanding the difference between local user access and ftp user access), and is always an alternative to discovering what the problem could actually be. If there ever was a need for chmod 777, then it's possibly because you're trying to allow a user who is not the owner full rights, but why make all users have this, just limit it by sticking those users in the same group and having chmod 770. Although the only time that you may use 777 is when you can't put the user in the same group, e.g. it's a server that requires full rights (not likely) to that directory but I have never come across the needs for explicitly allowing 777, it's best to fine tune it to only allow what they need and probably not use your home directory for such activity and create a more general directory for this to take place like I explained with the above instructions when creating /home/public_ftp which doesn't allow writing but you could change that if you wanted to let users upload.


Cheers,


MC

[iGuest 3]

Ohhh, God!

If you pretend to be unix user, you have to know what you are doing! Does anyone here know that FTP doesn't use TCP port 20 or 21 - it uses BOTH! One for command mode, another for datamode respectively.

Look, your client opens TCP connection to port 20 of the server from a randomly chosen port, for example, 65535. Then it sends FTP command USER and PASS to authorize. You can send FEAT to see all features supported by server, and HELP for commands. Than, for example, you want to retrieve a file. You send RETR "filename". Server opens TCP connection to port 65535 from port 21. It sends data, then closes the connection.

If there is a firewall on server, it should have port 20 opened for incoming and port 21 for outgoing traffic.
If there is a firewall on client, it should have destination port 20 opened. And accept connections from port 21, of course.

In passive mode, which is entered in by using PASV command, server doesn't open data itself, it waits for an income connection. In that case, firewall on the client side may have port 21 destination blocked. But then port 21 should be opened for ingiong connections on server.

That's about ports, now about data transfer modes. There two: binary and ascii. Most modern servers and clients use binary, as it transfers all 8 bits from a byte. ASCII mode is saved for some older ones. Historically, it was used for transferring directory listings, as only 7 bits where send in this case.

vsftpd, as many other modern secure ftp servers don't allow ascii connections for transferring anything else then LIST, although it is not recommended now to use it for any perpose at all!

Guys, you really should contact documentation before asking such questions... And you definately should read this: RFC 959 and RFC 1579.

[yordan 10]

If you pretend to be unix user, you have to know what you are doing!

Nope ! I you want to be a Unix network security admin, you need to know that. If you are a unix administrator you may know this. If you are a unix user, you don't have to worry about that.