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

Hi Rob and others,

Due to $WORK issues, I've had to put this on the back burner for ages,
but now that I'm stuck WFH more, other stuff has slowed down and I've
been able to come back to this.  Let's hope that we all pull through
this with our health and sanity intact.  

Thank you all very much for your feedback here, I've been going round
and round with how to make this all work better, since I know my old
server is really long in the tooth.

So I'm sure I'll be bugging you for some futher thoughts, but I really
wanted to just thank you and all the rest for these excellent
suggestions and pointers.  Once I get this setup, I hope I can find
the time to get this documented so that other's can work off a good
base.

Also, do people have a web interface they like for managing this?
I've got an old perl script I use for doing my current setup, but it's
not ideal and would need a ton of hacking to make it work again.
Something where I can push this off on other internal users would be
awesome.

Thanks,
John


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

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

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.

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

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

Rob> When setting up two separate groups like this (customers and internal users) be wise and use two
Rob> virtual hosts (one for the customers) and one for the internal users. This way you can for
Rob> instance write more detailed logs or make the site only available to certain IP ranges (your
Rob> offices) while the customers have a 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.

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

Rob> /ftp/<customer directories>

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

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

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

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

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