Hello All,

I have recently set up an old pc with Centos and want to use vsftpd. I've read quite a few tutorials and some mention setting up user accounts and groups for the ftp users. To do this I would have to enable chroot_local_user=YES. So here are some questions before I ask what are some fundamental Do's and Don'ts. If I go the chroot_local_user=YES route and all they see is their home, will that mean no one will see a list of all files and just what they have uploaded? Nex question - security wise, could this be a vulnerability giving them a home? Lastly, should (or can) I create a partition just for the ftp and keep it seperate? So any assistance and added do's and don't are most appreciated.

My question would be, have you looked into using sftp or scp instead of
straight ftp?
Using the built in ssh setup would probably prove a lot more secure, and
doesn't require any special setup beyond what is already in place.
Best of all, it means not opening up the unstable FTP port.
It uses the OS users and permission system on top of that.
SCP can be used by practically any OS, even Windows having the ability
if you get something like winSCP, or some of the newer FTP clients.
If you need command line support, it should be easier to do that with
ssh/scp than with ftp.

Failing that:

If you use the local user's privs, it shouldn't let them see anything
besides what the OS lets them see.
That might include groups.
It never hurts to add more security by separating out the FTP functions
to another partition.
That makes it easier to lock it down.
I might also suggest changing the FTP port to something non-standard if
possible.
It doesn't make the port any more secure, but it makes it a little less
obvious what is there.
If the daemon has the option to allow only sftp, I would recommend doing
that.
It's not as nice as straight scp, but better than plain text ftp.

> My question would be, have you looked into using sftp or scp instead of
> straight ftp?

Your suggestion may be good security wise if you are providing
security to a power user type, or if they are accessing stuff that
they are storing locally. However, if your intention is to make files
accessable to people who have browsers (as in a click to look at from
a blog, for example) you have to use regular FTP as that is the least
common denominator that all browsers can do. So you have to make a
risk-function determination.

> Using the built in ssh setup would probably prove a lot more secure, and
> doesn't require any special setup beyond what is already in place.

On the server side. Every client has to install software and use an
unfamiliar interface.

> Best of all, it means not opening up the unstable FTP port.
> It uses the OS users and permission system on top of that.

Which is perhaps not an advantage as compared to chroot. Unix has
traditionally had a weak permission system - ACLs are better but
almost impossible to set up and everyone ends opening up way too much
just for functionality.

> SCP can be used by practically any OS, even Windows having the ability
> if you get something like winSCP, or some of the newer FTP clients.
> If you need command line support, it should be easier to do that with
> ssh/scp than with ftp.
>
> Failing that:
>
> If you use the local user's privs, it shouldn't let them see anything
> besides what the OS lets them see.

It is common for people to set up FTP users that have /bin/false as a
shell - they can't log in and see anything. All they can see is what
they can see from FTP. Chroot locks them in a box beyond permissions,
within the FTP client. If they can't otherwise log in, this is a good
thing.

> That might include groups.
> It never hurts to add more security by separating out the FTP functions
> to another partition.

I agree with this - because of inherent issues with chroot. Unix file
systems are essentially dual. There is the named file system and the
inode file system. The named file system is a quick index into the
inode file system. chroot(2) uses the named file system to provide
security to the inode file system. Now, how can a user manipulate the
named file system into pointing into the inode file system? Symlinks
don't work - they are limited to the part of the file system that is
under chroot. But hard links do - as do file over file mounts and
directory over directory mounts - they can be seen by the chrooted ftp
server.

The issue is a dual service attack. Suppose the user can cause pop3 to
cause a hard link, and change permissions but nothing else.

So the user makes a hard link from their partition to /bin/sh,
perhaps, and makes a hard link from /bin/ls into their partition - and
suddenly root is executing a program they prepared, which makes a
bunch of security changes to let the user in, then puts /bin/ls back,
and btw, execs the original /bin/ls with the original arguments so
that aparrently nothing has malfunctioned. Then they access the
system with ftp, and ftp lets them out of their chroot box and makes
them uid 0. This sort of thing is not likely today, but

The security tradeoffs with chroot are "interesting". Consider what
ftp does and compare it to what getty/login do. Getty conditions the
port to a known state, possibly puts up the initial prompt, and calls
login with what it reads off the initial prompt (maybe, it has been a
while since I read this). Login verifies credentials as root, and
then adopts the user's identity and hands control to their shell.

FTP traditionally listens on a port and parses input lines, so far
just like login. The problem is that the parsing is much more complex.
You can do quite a bit before you log in, and the parser loop is a lot
more complex - which means fragile. Most ftp specific attacks have
attacked the parser loop. And before login, the parser loop is
executed as root because ftp has to change permisssions to a specific
user - and possibly even chroot. Now, solid parser loops are not
impossible to write - look at postfix or qmail. Sendmail parser loops
are much more complex - but they are not required to react to stupid
telnet don't/won't stuff which adds even more complexity. But you have
to write them with your first job being to reject attack, and not with
your first thought just as to making them functional.

So breaking the parser loop at this point (worst case) causes one to
get a process with root permissions - because changing identity and
(perhaps) chrooting are traditionally root functions.

Given the pre-existing need to change process permissions, I am not
sure that adding the chroot before that is ever a bad idea if you
don't want to allow users to share files. The input to the chroot
usually comes from a control file or even /etc/passwd, and not from
the end user. In fact, if sftp or scp don't have these capabilities,
I would think that ftp would be superior in terms of security when you
consider user isolation and user-system isolation, since user
permissions are weak and frequently compromised. All that a user can
compromise is their own stuff in their chroot box, through a properly
functioning ftp client.

> That makes it easier to lock it down.
> I might also suggest changing the FTP port to something non-standard if
> possible.
> It doesn't make the port any more secure, but it makes it a little less
> obvious what is there.

Security through obscurity - I used to think it was a bad idea -
because years ago, the hack model was to do scans on a particular
target, and when you get an FTP server it is usually obvious. But
these days, attacks are more horizontal - someone will scan hundreds
of thousands of systems for a particular vulnerability on a particular
port and automatically attack those which show a problem. Since port
can be specified in the URL to a browser running FTP, this is not as
much of an issue. But if the port is published in a URL it is a short
leap to imagine that they could google for an appropriate URL and scan
it for a port number. So don't depend on it.

> If the daemon has the option to allow only sftp, I would recommend doing
> that.
> It's not as nice as straight scp, but better than plain text ftp.
>
>
>
> Frost Jack wrote:
> > Hello All,
> >
> > I have recently set up an old pc with Centos and want to use vsftpd. I've read quite a few tutorials and some mention setting up user accounts and groups for the ftp users. To do this I would have to enable chroot_local_user=YES. So here are some questions before I ask what are some fundamental Do's and Don'ts. If I go the chroot_local_user=YES route and all they see is their home, will that mean no one will see a list of all files and just what they have uploaded?

They will only see files under their personal root. If they use "cd
.." at root they do not leave their box, it just puts them back at
root, just as "cd /../../../.." does at the real root. The isolated
root might contain some helpers and so forth, or it might not,
depending on ftp implementation. Yes, since scp, et. al., use the
user's permissions, your users should not be able to see or access
files from their shells that they can't access from their shell
accounts, but it sounds like you want to give them ftp accounts
without giving them shell accounts.

That is not a bad thing.

> Nex question - security wise, could this be a vulnerability giving them a home? Lastly, should (or can) I create a partition just for the ftp and keep it seperate? So any assistance and added do's and don't are most appreciated.

Generally, I think that you have done most of the damage just giving
them a userid. Things like mail and login and other services that
might allow them on the system have to know that these are ftp only
users. But any of these solutions allow for the same sorts of issues
because they all require giving people userids.

If there is a way to give them userids outside of /etc/passwd, like in
an ftp control file, that is actually superior - this is, IMHO, the
windows security weakness - all userids are in the same security
manager, which provides them a minimum of permission to any process
that allows system/anyuser. Sometimes it is better that security
lists not be centralized.

You can slightly reduce your risk by putting all ftp users in a
separate partition. The problem is that to do the attacks I've talked
about they need to have cracked root anyway - and if they have cracked
root, the attacks I've talked about are the least of your problems.
Putting them is a separate partition eliminates the "denial of service
by full file system" attack (which might well be inadvertent).

--
A man can't live in the everglades
Where a man can hide and never be found and have no fear of the bayin' hound
But he better keep movin' and don't stand still
If the skeeters don't get him then the gators will