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

>>>>> "Rob" == Rob Coops <[email protected]> writes:

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

Thanks for your input, but I'm really looking for concrete <Directory>
<Limit> ... </Limit> </Directory> examples to accomplish what I need.
Just to restate:

 - customers locked into their own directory:  /ftp/cust/

 - Two directories inside called to_cust/ and from_cust/  which only
 allows internal corp users into to_cust/ and from_cust/ is only
 writeable by the customer.  It's this lock down which is giving me
 fits.

 - Internal users are locked down into /ftp/ and can only see the
 directories of the customer(s) they are group members of.  This works
 great and will help alot down the line.


Now onto my comments Rob...


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

So this brings up a good question, since the Proftpd.org site talks
about it not being a problem to run as root at all.  And it's not
clear if running vroot really makes for a better situation here.

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

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

Already doing this for now, since it's easy to switch back and forth
between root and non-root user.  I'll definitely go back to non-root
user if at all possible.

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

This is an interesting idea.  I'll have to look into it, but since
they're using the same base directory and user/group entries, I'm not
sure the seperation provides any benefit. 

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

Rob> /ftp/<customer directories>

Very much like what I use already on my legacy environment.  Which is
part of my problem, in that the end user's are comfortable with the
current sub-optimal environment and don't want *anything* to change,
which is ... annoying.  *grin*   But I'll beat them up and get them to
come into the 21st century.  

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

Already got this part working actually, and with the setup I have (as
shown below) it's working fine.  But it's the to_cust and from_cust
setup and lockdown which is causing me problems.  

Rob> Also please be smart and do not use the /etc/groups and
Rob> /etc/passwd for adding users, it is a really bad practice from a
Rob> security perspective to have users that have no reason to exist
Rob> in the /etc/passwd file existing in that file, even when using
Rob> other files please make sure that the shell is set to /bin/false
Rob> to prevent users from getting a shell easily.

I'm of two minds here.  One is that I think I really want to give each
user and group their own system specific UID/GID entries, and using
the OS provided tools makes this trivial to accomplish.  The proftpd
utility to add/update the files is a pain to use.  

Rob> A simple will allow you to create separate files for the FTP users and groups.
Rob>   AuthUserFile                  /etc/proftpd/passwd
Rob>   AuthGroupFile                 /etc/proftpd/group

Thanks, already started down that path, but changed to /etc/passwd and
/etc/group, but might go back if I get the rest of the setup working. 

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

Absolutely!  If I could, I'd push them to drop ftp support completely!
But that would involved change... not something these users like.  Oh well...


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

Yes, all this is done already, except for the SELinux part.  

Thanks for all your comments.  


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

Rob> 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.
   
Rob>     I'm not using mod_vroot at all, but I am running as a nonroot user.  I
Rob>     suspect that's the first thing I need to change.  My proftpd.conf
Rob>     looks like this:
   
Rob>          DefaultServer                   off
Rob>          Port                            0
Rob>          UseIPv6                         off
Rob>          User                            dmzftp
Rob>          Group                           dmzftp
   
Rob>          <Global>
Rob>            RequireValidShell off
Rob>            Umask                         007     007
Rob>            AllowOverwrite                yes
Rob>            UseFtpUsers off
Rob>            FactsAdvertise off
Rob>            DefaultRoot ~
Rob>          </Global>
   
Rob>          <IfModule mod_sftp.c>
Rob>            <VirtualHost 192.168.123.202>
Rob>              SFTPEngine ON
Rob>              SFTPPAMEngine off
Rob>              Port             22
   
Rob>              SFTPHostKey      /ftp/ssh/ssh_host_rsa_key
Rob>              SFTPLog          /var/log/proftpd/sftp.log
Rob>              SFTPCompression delayed
   
Rob>              # Where all the customer & TAEC user definitions are
Rob>              Include /ftp/etc/ftpd.users
Rob>            </VirtualHost>
Rob>          </IfModule>
   
Rob>          <VirtualHost 192.168.123.202>
Rob>              Port            21
Rob>              Include /ftp/etc/ftpd.users
Rob>          </VirtualHost>
   
Rob>     And the /ftp/setc/ftpd.users looks like what I posted before, but I
Rob>     have the following at the top of the file:
   
Rob>          <Directory /path/to>
Rob>            <Limit ALL>
Rob>              AllowGroup dmzftp
Rob>              DenyAll
Rob>            </Limit>
Rob>            HideNoAccess on
Rob>          </Directory>
   
Rob>     All my internal users have a default group of 'dmzftp' and my
Rob>     customers all default to a group named after their username.  So the
Rob>     system /etc/group looks like this:
   
Rob>          dmzftp:x:4999:
Rob>          cust1:x:5000:user1,user2
Rob>          cust2:x:5001:user2,user3
Rob>          cust3:x:5002:user2
Rob>          cust4:x:5003:user4
   
Rob>     This way internal users can only access/see the directories of the
Rob>     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.
   
Rob>     I have it setup and working for the simple case where a user of
Rob>     chroot'd into their own directory, and they can upload/download
Rob>     files.  This is with the following entry:
   
Rob>         <Directory /path/to/cust2>
Rob>           <Limit ALL>
Rob>              AllowGroup cust2
Rob>              DenyAll
Rob>           </Limit>
Rob>           HideNoAccess on
Rob>           HideFiles "!(.*)$" group cust2
Rob>         </Directory>

Rob>     This works great.  But since I want to be more restrictive at lower
Rob>     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?
   
Rob>     The error message I get, using openssh sftp client is as follows:
   
Rob>         sftp> put dead.letter
Rob>         Uploading dead.letter to /dead.letter
Rob>         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.
   
Rob>     Yup, I figured as much.  In my further testing here, it seems like I
Rob>     really need to re-think the 'dmzftp' as the owner of the directories,
Rob>     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?
   
Rob>     All the internal users have a home directory of /path/to, so they get
Rob>     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>

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

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


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