PDA

View Full Version : Need help with Anonymous FTP upload



starbits
11-08-2006, 12:23 PM
Hi all,

I have a customer whose clients need to upload files via Anonymous FTP. They have been doing this on another server and I would like to provide them the same service here. However, the way the Control Panel allows me to setup Anonymous FTP is too permissive. I do not want or need the /pub/anonymous folder to be world-readable, just world-writable. Customers should not be able to see that other customers have uploaded files or that there even are other files in this folder. Previously I did this by setting the folder permissions to 733, but that des not work here. Ideas?

Thanks,
Steve

rolling
11-08-2006, 05:44 PM
The answer might lie in the last line of /etc/ftpaccess

upload /ftp/pub/anonymous * no mylogin vuser 0400 dirs 0700


upload [absolute|relative] [class=<classname>]... [-]
<root-dir> <dirglob> <yes|no> <owner> <group> <mode>
["dirs"|"nodirs"] [<d_mode>]

Define a directory with <dirglob> that permits or
denies uploads.

If it does permit uploads, all newly created files
will be owned by <owner> and <group> and will have
their permissions set according to <mode>, existing
files which are overwritten will keep their original
ownership and permissions.

starbits
11-08-2006, 07:50 PM
Thanks Richard,
Good clues. Not being a unix guru it will take me a while to play with it, but I will see what I can do and post the results.
Thanks again,
Steve

rolling
11-09-2006, 07:55 AM
You'll find detailed instructions on how to achieve what you want here (http://www.wu-ftpd.org/HOWTO/upload.configuration.HOWTO). You'll have to modify these instructions slightly to work with Westhost. For example I expect that you will have to change ftpadmin to youruser in group vuser.


Upload restrictions for anonymous FTP users
-------------------------------------------
For this example, we'll assume your system /etc/passwd file contains an
entry for the anonymous FTP user as follows:

ftp:*:95:95::/home/ftp:

If your /etc/passwd file does not contain an entry for the user 'ftp' your
site will not allow anonymous FTP. In addition, if the usernames 'ftp' or
'anonymous' appear in the /etc/ftpusers file, anonymous FTP will not be
allowed.

In /etc/ftpaccess, we need a class which allows anonymous access. The
following allows anonymous FTP from anywhere:

class anonftp anonymous *

To prevent anonymous FTP users attempting a Denial of Service (DoS) attack
against your system, you should create a special filesystem to receive
their uploads. This separate filesystem protects your server by limiting
the total size of all uploaded files while preventing those files from
consuming all available space on the server. For this example, mount the
filesystem on /home/ftp/incoming

By default, the server will not allow uploads from anonymous FTP users.
Just to be safe, and so we don't forget, let's add a clause saying that:

upload /home/ftp * no

What this says is, "For any user whose home directory is the anonymous FTP
area, /home/ftp, do not allow any uploads." As I said, this is the
default, but put it in anyway so you don't forget.

Now, we want to allow uploads into the incoming filesystem. We MUST add a
clause granting that privilege to anonymous users. Right now we don't want
to let anonymous users create directories. (I recommend NEVER allowing them
to do it, but I'll show you how in a bit.) We want to ensure, however,
the server is safe and cannot be used as a way-point for software pirates
(warez traders). So we'll set the directory permissions for the incoming
area to prevent anyone seeing what's there and make the area write-only for
anonymous users.

First, we need an FTP site administrator, someone who owns the files, but
isn't the root user or the anonymous user. Something like the following
/etc/passwd entry will do:

ftpadmin:*:96:96::/home/ftp:

Set the incoming area permissions and ownership to safe values. I
recommend the following:

chown ftpadmin /home/ftp/incoming
chgrp ftpadmin /home/ftp/incoming
chmod 3773 /home/ftp/incoming

Actually, ftpadmin should own more of the site, but I'm only talking about
uploads right now.

Finally, before we get into allowing uploads, one last thing. Whether you
allow on-the-fly tar'ing of directories or not, you should make sure an
end-run cannot be made and the incoming area downloaded using tar. To do
so, create the special file '.notar' in both the FTP directory and the
incoming area:

touch /home/ftp/.notar
chmod 0 /home/ftp/.notar
touch /home/ftp/incoming/.notar
chmod 0 /home/ftp/incoming/.notar

The zero-length .notar file can confuse some web clients and FTP proxies,
so let's mark it unretrievable.

noretrieve .notar

Time to allow uploads, put the following in /etc/ftpaccess:

upload /home/ftp /incoming yes ftpadmin ftpadmin 0440 nodirs

Notice the target directory for the uploads is relative to the view the
user will have during the FTP session.

What this says is, "For any user whose home directory is the anonymous FTP
area, /home/ftp, allow uploads into the directory /incoming but do not
allow the creation of new directories. Make all files uploaded owned by
the FTP administrator, mark them read-only so we don't allow them to be
downloaded." If uploaded files are to be made available for downloading,
the safest thing to do is to tell the FTP administrator to move them into a
public area and modify the permissions after validating and approving them.
I know this seems draconian but, in the long run, it's best.

wildjokerdesign
11-10-2006, 09:04 AM
Richard,
I have a question about this:

For example I expect that you will have to change ftpadmin to youruser in group vuser.


Could youruser be any user that is created via the Site Manager or does it need to be the default created when the account is created by West Host? If it can be any user would it be safer to be something other then the default?

I assume that the area of the tutorial you posted this relates to is this bit:

chown ftpadmin /home/ftp/incoming
chgrp ftpadmin /home/ftp/incoming
chmod 3773 /home/ftp/incoming


If so would the actual commands sent in SSH be this?

chown youruser /home/ftp/incoming
chgrp vuser /home/ftp/incoming
chmod 3773 /home/ftp/incoming

rolling
11-11-2006, 10:21 PM
My apologies. I didn't have time to read the instructions carefully before I posted them, but I've now had a look at this in more detail and we cannot do it. Sorry.

The users you add through the site manager are just mailbox and ftp users; they are not unique Unix accounts and therefore cannot own files. If you look at your files (using either ls -l or stat, you will find that they are typically owned by root/root or youruser/vuser; any file created by you (or any of your users) will be owned by youruser/vuser. If you look at etc/passwd you will see that users you create (as well as ftp) all have the same User ID and Group ID as your login (on the first line). The only difference is that their line ends with /ftponly which appears to be a Westhost special and the ftp guestgroup.

We cannot create a new Unix account as our installations are missing the Unix command useradd (among others) and we are not super users. This is understandable; if 300 people all decided to create user fred in group vuser, there would be bedlam and lots of complaints.

I have asked, and we cannot have an additional user. This is apparently a limitation of the VPS software.

The way that this should work is that we use one user ID for the anonymous ftp login and another to upload the file. The only important thing is that our login has read access to the file once it has been uploaded.

The user and group ID for anonymous ftp is defined in /etc/passwd
The user and group ID for uploaded files is defined in /etc/ftpaccess

Currently, Anonymous ftp logs in as user ftp with User ID of yourlogin and Group ID of vuser.

In my earlier instructions, the access rights to incoming were set to 3773. This means
user (7) - read, write, execute
group (7) - read, write, execute
other (3) - write, execute
The initial 3 means "sticky" and "set Group ID". When the sticky bit is set on a directory, files in that directory may be unlinked or renamed only by root or their owner. Without the sticky bit, anyone able to write to the directory can delete or rename files.

However, the directory's access rights were also changed using chown and chmod so that incoming was owned by ftpadmin of group ftpadmin. This is why user ftp could not read the directory.

The ideal solution would be for the anonymous ftp user to log in with a different user id and group (say anonftp) and we could then upload using our regular credentials. We would probably have to change the ownership and access rights of /ftp/pub/anonymous

allyn
11-12-2006, 12:33 PM
could you set the directory to be 333 most of the time, and then set it to 733 momentarily while the files are moved out and then set it back to 333 again? there would be a window of vulnerability but it would be pretty short.

if you know the file names (by some other channel, like turn on the upload logs) you could leave the directory at 333 all the time. you don't need read permission if you know the file names.

rolling
11-13-2006, 02:35 AM
I tried various solutions without success. FTP requires read access to /ftp/pub/anonymous in order to be able to login, so you have to have 733 or 773 for that directory. If you set incoming to 3333 or 333, then you cannot place a file using PUT


Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

E:\Documents and Settings\login>ftp mydomain.com
Connected to mydomain.com.
220 mydomain.com FTP server (Version wu-2.6.2(1) Mon Aug 16 17:10:57 IDT 2004) ready.
User (mydomain.com:(none)): anonymous
331 Guest login ok, send your complete e-mail address as password.
Password:
230 Guest login ok, access restrictions apply.
ftp> ls -l
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/lsplain.
total 2208
-rw-r--r-- 1 2292 101 2249464 Nov 9 09:14 gmp-4.2.1.tar.gz
d-wx-ws-wt 2 2292 101 4096 Nov 10 19:05 incoming
226 Transfer complete.
ftp: 152 bytes received in 0.03Seconds 5.07Kbytes/sec.
ftp> put test.file
200 PORT command successful.
553 test.file: Permission denied on server. (Upload)
ftp> put test.file incoming/test.file
200 PORT command successful.
553 incoming/test.file: Permission denied on server. (Upload)
ftp>
I have had no reply from Westhost, but there is no trace of the ticket either so I will resubmit it.

rolling
12-06-2006, 07:33 PM
If the user id were to be changed for any of your users, that user would no longer be able to access your hosting account via FTP. Unfortunately, there isn't a way around this limitation.


So we are unable to have hidden uploads. The only way to work around this would be to have a script running in the background which monitored /var/log/xferlog for incoming and completed and moved the incoming file straight away.