Re: [Proftpd-user] Setting up restricted ftp/sftp site

A few things I seen here (some already addressed in the mail chain.

NEVER EVER run as root if this is anything else than a test, if the test
has the potential of connecting to the outside world (in other words the
machine could even just in theory be connected to the outside world do not
run as root. There is way to much risk associated with doing so, just
create a user (with no shell access, an its own group used by nothing else)
and run as that user instead it makes it just that little bit harder if
someone manages to get your FTP server software to execute a bit of code
for them. I'd certainly advise to use vroot there is little to no overhead
for your server to deal with it and it helps ensure that users stay put in
their home directory.

To run as a different user add something like this to your proftd.conf:

# Set the user and group that the server runs as
User                            nobody
Group                           nobody

The nobody user and group ensures that the server process has minimal
rights (no shell, nothing on the machine can be executed by nobody etc)

When setting up two separate groups like this (customers and internal
users) be wise and use two virtual hosts (one for the customers) and one
for the internal users. This way you can for instance write more detailed
logs or make the site only available to certain IP ranges (your offices)
while the customers have a different policy. This will come in handy in a
future where a security audit has a look at how you set this stuff up.

What I would do when setting this up would be the following directory
structure:

/ftp/<customer directories>

The internal users are locked into the /ftp/ where customers home
directories are where they are locked. In the customer directory you create
the to_corp directory and allow that one to be written to by the customer,
the customer home directory should not be writable by the customer.. Each
customer is setup with its own user and its own group, it is the group that
gives them access to their home directory, internal users are added to the
customer groups that they need to access, even though they will see th
eother customers directories they will not be able to access them...

Also please be smart and do not use the /etc/groups and /etc/passwd for
adding users, it is a really bad practice from a security perspective to
have users that have no reason to exist in the /etc/passwd file existing in
that file, even when using other files please make sure that the shell is
set to /bin/false to prevent users from getting a shell easily.
A simple will allow you to create separate files for the FTP users and
groups.
  AuthUserFile                  /etc/proftpd/passwd
  AuthGroupFile                 /etc/proftpd/group

Then there is one last thing and that is kind of important... there is a
reason why everyone and their mother is switching over from http to https
(encrypted connections). This is that sending data over the internet in
clear text is not really smart if the data that you are sending is not
meant for outsiders. Since you are going out of your way to segregate your
customers, and restrict access for internal users to need to know only I
would suggest that having you customers sending data in plain text over the
interwebs is not really what you are after. (Even their username and
password will be sent in plain text, so the site is basically completely
insecure regardless of the efforts you put in up to this point.
Using SFTP makes sure you use encrypted connections, also it allows for the
use of SSH keys instead of passwords. With SSH keys being far more complex
than what your normal user would use as a password it enhances the security
a little further still.

Also when you are clearly concerned about what your users can and cannot do
and who can and cannot see certain data etc, plese make sure the machine
that is running the sftp server is a dedicated machine, shutdown all
services and close all ports that are not needed for the sftp server to
run, enable SELinux (not promiscuous mode of course) it is a royal pain to
setup if you have not used it before, but persist and get it working
because it will provide a little extra hurdle to malicious users.

In short FTP is not secure, running a root is asking for trouble, do not
allow users to have shell access, split the user groups to allow for
different policies for internal and external users and protect the machine
to the best of your ability. You current setup is something I would very
strongly advise not using for actual customers or their data.

On Fri, Nov 15, 2019 at 10:18 PM John Stoffel <[email protected]> wrote:

> >>>>> "Matus" == Matus UHLAR <- fantomas <[email protected]>> writes:
>
> Matus> On 15.11.19 11:50, John Stoffel wrote:
> >> Been plugging away at setting up a new ftp/sftp site and I have some
> >> specific requirements which I need to meet.  I've been reading and
> >> re-reading the site trying to get a working configuration for what I
> >> need, but I'm missing some something subtle here.  Looking at the FAQ
> >> and sample configurations doesn't help since I just want one site, but
> >> with very locked down users, both internal and external.
> >>
> >> So my requirements are:
> >>
> >> - customers are restricted to their own home directories.  This is
> >> solved using the mod_vroot stuff.  And DefaultRoot ~ as default.
>
> Matus> you can do this without mod_vroot, if proftpd runs under root user.
>
> I'm not using mod_vroot at all, but I am running as a nonroot user.  I
> suspect that's the first thing I need to change.  My proftpd.conf
> looks like this:
>
>      DefaultServer                   off
>      Port                            0
>      UseIPv6                         off
>      User                            dmzftp
>      Group                           dmzftp
>
>      <Global>
>        RequireValidShell off
>        Umask                         007     007
>        AllowOverwrite                yes
>        UseFtpUsers off
>        FactsAdvertise off
>        DefaultRoot ~
>      </Global>
>
>      <IfModule mod_sftp.c>
>        <VirtualHost 192.168.123.202>
>          SFTPEngine ON
>          SFTPPAMEngine off
>          Port             22
>
>          SFTPHostKey      /ftp/ssh/ssh_host_rsa_key
>          SFTPLog          /var/log/proftpd/sftp.log
>          SFTPCompression delayed
>
>          # Where all the customer & TAEC user definitions are
>          Include /ftp/etc/ftpd.users
>        </VirtualHost>
>      </IfModule>
>
>      <VirtualHost 192.168.123.202>
>          Port            21
>          Include /ftp/etc/ftpd.users
>      </VirtualHost>
>
> And the /ftp/setc/ftpd.users looks like what I posted before, but I
> have the following at the top of the file:
>
>      <Directory /path/to>
>        <Limit ALL>
>          AllowGroup dmzftp
>          DenyAll
>        </Limit>
>        HideNoAccess on
>      </Directory>
>
> All my internal users have a default group of 'dmzftp' and my
> customers all default to a group named after their username.  So the
> system /etc/group looks like this:
>
>      dmzftp:x:4999:
>      cust1:x:5000:user1,user2
>      cust2:x:5001:user2,user3
>      cust3:x:5002:user2
>      cust4:x:5003:user4
>
> This way internal users can only access/see the directories of the
> customers they need to interact with.
>
> >> - internal users can only see and access the directories of customers
> >> if they are in that customer's group.  This is working.
>
> I have it setup and working for the simple case where a user of
> chroot'd into their own directory, and they can upload/download
> files.  This is with the following entry:
>
>     <Directory /path/to/cust2>
>       <Limit ALL>
>          AllowGroup cust2
>          DenyAll
>       </Limit>
>       HideNoAccess on
>       HideFiles "!(.*)$" group cust2
>     </Directory>
>
>
> This works great.  But since I want to be more restrictive at lower
> levels... that's why I'm asking for help.
>
>
> >> - Customers can only put files into the 'to_corp' directory, and only
> >> read files in the 'from_corp' directory, but I can't seem to make
> >> this work.
>
> Matus> which one?
> Matus> what is the error message?
>
> The error message I get, using openssh sftp client is as follows:
>
>     sftp> put dead.letter
>     Uploading dead.letter to /dead.letter
>     Couldn't get handle: Permission denied
>
>
> Matus> note that when reading or writing, proftpd permissions are not
> enough.
> Matus> Logged users must have filesystem permissions to be allowed to
> access/write
> Matus> files.
>
> Yup, I figured as much.  In my further testing here, it seems like I
> really need to re-think the 'dmzftp' as the owner of the directories,
> and as whether to run proftpd as the root user.
>
>
> >> All customers belong to a group called 'cust'.  Internal users are
> >> members of the 'dmzftp' group, and then are added to /etc/groups as
> >> members of those customer groups the need access to.  The idea is
> >> that intneral users only see those customers they have access to,
> >> nothing else.
>
> >> <Directory /path/to/cust1>
>
> Matus> what are those users home directories?
>
> All the internal users have a home directory of /path/to, so they get
> chroot'd as well.
>
> >> HideNoAccess on
> >>
> >> <Limit CWD PWD LIST MLST STAT READ>
> >> AllowUser cust1
> >> AllowGroup cust1
> >> </Limit>
> >> <Limit ALL>
> >> DenyAll
> >> </Limit>
> >> </Directory>
> >>
> >> <Directory /path/to_cust1/to_corp>
> >> <Limit ALL>
> >> DenyAll
> >> </Limit>
> >> <Limit CDUP CWD PWD XCWD XCUP DIRS>
> >> AllowGroup cust1
> >> </Limit>
> >> <Limit STOR STOU>
> >> AllowUser cust1
> >> </Limit>
> >> </Directory>
> >> <Directory /path/to/cust1/from_corp>
> >> <Limit CWD PWD DIRS READ>
> >> AllowUser cust1
> >> </Limit>
> >> <Limit ALL>
> >> DenyUser cust1
> >> AllowGroup dmzftp
> >> </Limit>
> >> </Directory>
>
>
> _______________________________________________
> ProFTPD Users List   <[email protected]>
> Unsubscribe problems?
> http://www.proftpd.org/list-unsub.html
>

_______________________________________________
ProFTPD Users List   <[email protected]>
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html