How I solved the (secure) remote file access dilemma

[Vocatus]

Hi all,

 

I've been trying to determine a way to provide remote access to my files and the files of my users, and I think I have a good solution. The downside is that it requires an additional 'kicker' machine. The upside is that it's more secure.

 

I threw out the usual methods for these reasons:

- FTP:   plain-text passwords are not acceptable

- FTPS: tremendous headache getting it to work w/ my pfSense firewall (for both implicit and explicit SSL) without putting the server in a DMZ. Plus FileZilla server is crap with firewalls

- VPN:   too much work to setup (for me), and way too much work for my 8 or so users on varying platforms (Ubuntu, Mac OSX, Win7)

 

Additionally, because unRAID:

 a. Does not natively support some remote-access method

 b. Is not security-oriented,

 

I decided against having the remote access mechanism on unRAID itself. Getting SSH and/or FTP to work with the Samba shares without a crazy amount of work wasn't feasible.

 

Final decision was to use a 'kicker' machine running an SFTP server that connects to unRAID on the backend via SMB/Samba, and presents those shares to SFTP users.

 

Final setup looks like this:

 

unRAID <---> 'Kicker' machine running an SFTP server (Windows XP SP3) <---> Router <---> Internet <---> users

 

The actual user that unRAID sees connecting is 'ftp', because the connection is coming from the xLight SFTP program. Technically, the 'ftp' user can access ANYTHING on unRAID, but is prevented from doing so by access control in xLight itself (shares are presented as as read-only). This is how it looks (excuse the ghetto text diagram :-P )

 

User ---> xLight server (running in restricted Windows account) ---> Samba connection as user 'ftp' ---> unRAID box

 

Steps:

1. User connects to xLight, and is authenticated against xLights internal user database

2. In the background, xLight connects to unRAID as the Samba user 'ftp'

3. xLight presents shares to the user (typically Media, Programs, Personal Backup, and Public)

4. User downloads/uploads their files, which are essentially relayed through the kicker machine.

 

 

This is specifically how I did it:

1. On unRAID:  Created a user 'ftp' on the unRAID box. Gave 'ftp' a strong password.

2. On unRAID:  Added user 'ftp' to each share as user with full read/write access

3. On Kicker:   xLight SFTP server (excellent program, similar to FileZilla server) connects to unRAID as Samba/SMB user 'ftp' using the password I set for it.

4. On Kicker:   xLight a "Server User" user group provides (by default) read-only access to Media and Programs shares, and read/write access to the Public folder and the users private backup folder

5. When users connect, this is what they see:

                - Media               (read-only)

                - Programs           (read-only)

                - Personal Backup (read/write)

                - Public               (read/write)

 

So that's about it. These are the pros/cons of this method:

 

Pros:

1. Logical separation of access point from data server

2. More secure than a direct-access method

3. Exploiting xLight not likely, as it is running in a restricted Windows account

4. Failure of the kicker machine does not affect unRAID itself. The only thing lost is remote file access. Local file access is still up.

5. xLight is easy to use and manage, and gives tons of detail about who is connected, for how long, what they are downloading, etc.

6. Keeps unRAID box free of additional programs

7. It pleases the nerd in me

 

Cons:

1. Have to create users twice (on unRAID, and then again in xLight)

2. Have to create special 'ftp' user to avoid really complicated mappings and permissions

3. More complicated than a direct-access method

4. Potential security issue with the 'ftp' user. Since 'ftp' has read/write access to all shares on unRAID, if a user were somehow able to exploit xLight and gain direct access to the underlying SMB mapping, they could access all files on unRAID. However I think running the SFTP server with restricted rights negates this for the most part.

5. xLight is not open source, and although the Personal version is free, the Professional version with SFTP module costs nearly $100 (ouch!)

 

One final note: I tried for the longest time to get FileZilla server working, but for whatever reason it is complete crap with NAT firewalls. I tore my hair out for three days messing with it. I finally broke down and went with a commercial SFTP server, and it has worked flawlessly. On my old setup I was using OpenSSH, but that was a Windows file server, so it worked directly with Windows user accounts. However, it is very difficult if not impossible to share network paths via OpenSSH when doing SFTP.

 

I appreciate any thoughts or comments on the setup.

 

[S80_UK]

Edit: 41 views and no comments??? Let me know what you think!

 

I came; I saw; I read; I understood; I decided I wanted remote access without another machine running... 

 

Still looking for the best way to do this.  And I'm not enough of a Linux guru to do it all myself at this point.

[gfjardim]

I agree running another machine as SFTP server is overkill. Maybe a router with a custom firmware like dd-wrt or a spare Atom machine running pfSense and OpenVPN server would be better.

 

I'm running an Atom machine with pfSense as my firewall, and I have IPSec, OpenVPN and PPTP services running, allowing me to access my home network from all sort of devices - e.g. iPhone, iPad and Windows7 laptop. The setup is very easy and now I have a true firewall protecting my network.

[Vocatus]

I agree running another machine as SFTP server is overkill. Maybe a router with a custom firmware like dd-wrt or a spare Atom machine running pfSense and OpenVPN server would be better.

 

I'm running an Atom machine with pfSense as my firewall, and I have IPSec, OpenVPN and PPTP services running, allowing me to access my home network from all sort of devices - e.g. iPhone, iPad and Windows7 laptop. The setup is very easy and now I have a true firewall protecting my network.

 

Thanks for the feedback gfjardim. Yeah, the extra machine really is overkill, but i have it doing other duties as well (torrenting, Tor relay, various other stuff) so it's not just a whole box solely for remote access. The best way would be to run the SFTP server directly on the router, or perhaps in a low-power embedded device.

[speeding_ant]

Wouldn't a good way be something like Ajaxsplorer running on PHP hosted by unRAID? Setup via HTTPS with self generated cert. Ajaxplorer will connect and auth to an SMB share. You can then access your data via HTTPS, with user protection. You can change the auth module to ldap, local users, etc, to control the usernames and passwords.

 

Any reason why this wouldn't work? Ajaxsplorer will work on a pretty minimalistic setup.

[Vocatus]

Wouldn't a good way be something like Ajaxsplorer running on PHP hosted by unRAID? Setup via HTTPS with self generated cert. Ajaxplorer will connect and auth to an SMB share. You can then access your data via HTTPS, with user protection. You can change the auth module to ldap, local users, etc, to control the usernames and passwords.

 

Any reason why this wouldn't work? Ajaxsplorer will work on a pretty minimalistic setup.

 

 I'm sure that would work speeding_ant, but a big part of my criteria was that it be easy to set up and use gui management, so I wouldn't have to spend a lot of time learning by reading man pages and forums. If you wrote up a guide for it though, I think I'd give it a shot.

 

It would be nice to get rid of the extra machine. Maybe in 5.0 final [/wishful thinking]

[defected07]

That looks very cool, speeding_ant.  I'll look into that when I'm all up and running.

[speeding_ant]

I think I know what my next project will be 

[Vocatus]

I think I know what my next project will be  

 

if you manage to make it work, I'm very interested in attempting to duplicate your setup...

[S80_UK]

Me too.

 

I would be interested enough to put together a second box with a basic unRAID just to try this stuff out.  (I don't want to touch my regular server - it's not experimental.)

[speeding_ant]

Essentially it shouldn't be that hard. I've got a similar setup already at work, so I'll replicate it and add the repositories I need. Then create a simple php file with some variables to change settings, install unMenu to get PHP on whatever webserver is packaged for slackware, and hopefully it'll work out of the box.

 

Easier said than done though

[Vocatus]

Essentially it shouldn't be that hard. I've got a similar setup already at work, so I'll replicate it and add the repositories I need. Then create a simple php file with some variables to change settings, install unMenu to get PHP on whatever webserver is packaged for slackware, and hopefully it'll work out of the box.

 

Easier said than done though

 

our lives are in your hands ant! go forth and godspeed