Good morning,

I was hoping to get assistance from the team here, I am missing something blatantly obvious and have been unable to correct the issue. I believe this is a pretty common misconfiguration.

This is my vsftpd.conf
listen=YES
listen_ipv6=NO
connect_from_port_20=YES

anonymous_enable=NO
local_enable=YES
write_enable=YES
chroot_local_user=YES
allow_writeable_chroot=YES
secure_chroot_dir=/var/run/vsftpd/empty

chown_uploads=YES
chown_upload_mode=0644
chown_username=nobody
pam_service_name=vsftpd

pasv_enable=YES
pasv_min_port=40000
pasv_max_port=45000

userlist_enable=YES
userlist_file=/etc/vsftpd.userlist
userlist_deny=NO

rsa_cert_file=/etc/ssl/private/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.pem

ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES

ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO

require_ssl_reuse=NO
ssl_ciphers=HIGH

guest_enable=NO

vsftp.userlist
*** Contains unix login id's of people who should be able to use VSFTPD

/etc/passwd

ftpuser:x:1001:1001::/var/www/vhosts/fakewebsite.com/:/bin/bash

ftpuser is a member of NOGROUP which owns all of the files under the website.


So, what I am trying to do is login with the ftpuser, and be able to write to the website and have vsftp change the owner and group to nobody / nogroup. But I am getting a 553 unable to write.

I believe i'm close, but i'm missing something in front of my face, I would appreciate any insight that can be provided.

Thanks,
Nick

What user owns the directory (where you are trying to write)?
And, for troubleshooting purpose, remove "vsftp" out of equation... meaning, try to write as the same user locally, does that work?
As far as setting permissions on newly created file(s) you can use something like "setfacl"...

Obvious thing would be to look at the permissions on the directory itself, and be aware of what a website is and how it works. Chances are the files/directories are owned by the webserver user (wwwrun, apache, etc.), and if you have things that need to function, they may need that same ownership. That would be the first place to start.

Past that, this exercise is a HORRIBLE idea, both in terms of security and your website. Make a typo in what you uploaded? Your website is now offline until you find/fix it. You've just overwritten the file that was there. And FTP (even VSFTP) isn't the right transfer tool. SFTP/SCP are much better options.

Hey, thank you both for the feedback! Yes, I am aware this is a questionable decision for security purposes, but this is the directive I was given. To clarify we are using filezilla with SFTP, so the connection is encrypted, and the ftp password is obnoxiously long and complicated I can't possibly remember it. Back to the web folder. The web folder is owned by nobody / nogroup. While I realize I could change the whole folder to be owned by the FTP user and I could accomplish the task, I am very hesitant to make this change on a live production server for the reasons you outlined.

I must not understand the following configuration line. I mistakenly believed this would upload files as the nobody user which is the owner of the directory and files.

chown_username=nobody

While I do come from the Windows world, my understanding is I need to create a new group and add the nobody user and the ftp user to and apply that group as owner to the entire folder structure which is really more change than I wanted to have occur. I appreciate the constructive criticism, and I accept the feedback. This is how the owner wants to run his business, and I am trying to get it to function the way he wants it without using root as the ftpuser. This is a small ecommerce store, and I am doing my best to keep the server patched, and mysql running with as little interruption as possible.

Thank you again,
Nick

Right... so I would still recommend you to login to the machine where the client will connect to.. then as the user that you will be connecting as, try to create a file. Does it work.

My 2-cents here...
Since as you said, you come from Windows world
And
This is a production system

my recommendation is if you have resources available, build another machine (a VM perhaps) with same software setup and test it there before changing anything on production system.

DC.901, yes as you suggested earlier. I logged on the server, and did a su ftpuser, and tried to touch a file under the webfolder and was unable to create a file. Here is the results as expected for the ftpuser from the shell.

touch: cannot touch 'test2.php': Permission denied

So since the ftpuser is a member of nogroup I was able to chmod g+rwx on a file and then modify it from the shell prompt.

As you mentioned a VM would be great to test this in, unfortunately we are using licensed plugins and specifically litespeed webserver which makes it a very expensive test if we wanted to duplicate the environment in a testing setting. Correct me if I am wrong in my logic, but I am thinking I can create another vhosts on this server with some very basic php, and then test this at least on a different instance other than production.

I believe I have the concepts down, just not the absolute certainty I would have on a Windows file server to test and apply these changes live in production.

On another topic, I am actually working on implementing kexec on a similar setup in a VM so we can apply kernel updates and restart the website quickly other than going through the long ass startup on the supermicro server we are leasing. Right now, I have Canonicals live patching service running, but with all of the ransomware attacks I am pretty vigilant about keeping the server patched.

It does not sound like you are using SFTP. It sounds more like you are using FTPS and not SFTP. FTPS is FTP + TLS and is what you can hammer out with a whole lot of difficulty using VSFTPd. SFTP is dead simple and works out of the box on the server side if you have OpenSSH server running. SFTP is also supported by FileZilla and pretty much any other similar tool these days.

If you already have SFTP available, I would ditch FTPS post haste, especially if the user accounts are all system accounts. If you were using virtual accounts for FTP(S) then that would be a different matter but it appears that you aren't.

Either way, make a new group for the project and put the relevant accounts into it and then set the group membership and the SetGID bit for the shared directory.

If you're using SFTP, you are *NOT* using VSFTPD...SFTP is part of the SSH suite, and VSFTPD isn't SFTP. The two are not the same.
Yep...and I'll say that you need to get something, in writing, from whomever gave you this moronic 'directive', and be sure to outline all the bad reasons for this, and that you're bringing it to their attention. When things go very bad (and they will), you will get thrown under the bus. Seen things like this many times over the years.
Has zero to do with this; FTP is absurdly insecure, period. The password may be long, but it can be sniffed/replayed VERY easily, even using vsftpd. Not only are you opening an additional port in your firewall (making your exposure larger), you're giving someone free-rein to upload whatever they want to a LIVE ECOMMERCE WEBSITE. If I was going to do anything, I'd simply download the files from your site, find the one that does credit-card processing and change it to be my bank details, and re-upload it. Let all your orders go out, and have the money sent straight to me....by the time you catch it, it's a month (or more) down the road.

Web pages need to be owned by the web server user, as stated. That's the ownership you need. You'd be FAR better served by using a version control system like SVN or git on your system, so pages can be checked in. Further, you could put up a test instance to use the files uploaded when changes are made, to test things out. THEN the administrator can go in, and move the files to production. Problem with the site? No worries...you have all the previous versions there and ready to roll back in minutes.

1 members found this post helpful.

Great idea using SVN or git. Thank you for your assistance.

Nick