Security issues with rsync from server to DS110j

[KuJoe]

Hello, I recently setup my offsite server to automatically rsync a few backup directories to me new DS110j using an RSA key (no password) but I have the RSA key restricted to that server's IP so only my server can access my NAS with that key. My problem is that I created a new user specifically for this task but unfortunately it still has full access to all of my other directories on the NAS even the ones I set to NA via the web interface.

I am looking for a way to implement a jailed shell for that user so it can only access one directory as a security measure in case my offsite server gets compromised the attacker cannot get my personal data on my NAS and will be restricted to only my server backups since they will be able to SSH into my NAS without a password.

I've searched all over the forums and the great Google but to no avail.

[LleMikeByw]

Hi!

This sounds familiar - and you have probably resolved the issue now - but if not....

Check my post below>>>> (Requires some work on Linux command line and via SSH to DiskStation but that's not really that scary, is it?)

http://forum.synology.com/enu/viewtopic.php?f=15&t=31332#p134474

My posting here might capture others who ace a similar issue and map to your post.

Mike

[viknet]

I have the same issue here,
rsync work through ssh and a private key.
to secure the stuff and avoid arbitrary command beeing executed I even setup an rsync filter used as a shell reference in /etc/password and .ssh/authorized key
I take care of this because I want to setup this for rsyncing my mother's pc (accross the internet I not living with my mother)
but after beeing there I spoted that all /volumesX shares have 777 permission, even If I setup special permission using the web interface.

Unfortunately this mean that anybody with the right key (including my mother assuming she is an evil dirty hacker) can erase all files in /volumes, the good news is that he cannot erase or change /etc/password but, in fact I don't care

so the option are:
- I could manually remove my rsyncing user from the users group but the webinterface does not allow me to do that (and there is probably a reason for that)
- change the permission of all shares to be more secure (but it does not seems to be synology phylosophy)
- enhance the shell filter so it rekect all rsync command with a path not beeing the right one (probably not very secure and I am even not sure it's enough)

Could anybody point me at the right solution ?? or shall I avoid using rsync (over ssh) with the synology at all.


best regards

Vincent

[LleMikeByw]

SEE MY POST BELOW TOO: It may be more relevant to your precise circumstances... Mike

It seems to me you are accessing the DiskStation through the web interface.

Via that method - you have to be very, very clear on how User and Group privileges interact.

You must remember that NA in either Group Privileges or User Privileges MEANS NA in both. NA always conquers RW which always conqeurs RO.

I have successfully used the web interface to avoid users having access to folders they should not have access, but you cannot rely on manipulating just the default user group - which you cannot get rid off (from the web interface). You MUST enable user HOMEs and you MUST create another user group and make relevant users members of that group - which you then lock down completely.

Personally - I haven't stuck to the web interface because it is fairly cumbersome and so have used SSH to access the DiskStation as root.

When you are this user you are all powerful and you can issue the following commands to restrict access to folders:

Code: Select all

chown -R user.group /volume1/homes/user-folder

where user, group and user-folder obviously need to be amended to what you want.

Then you can issue a:

Code: Select all

chmod -R 700 /volume1/homes/user-folder

restricting the access to the folder to just the user specified above.

The link above will take you to a detailed description of the various things I have been tackling and resolving on the DiskStation and you might find it useful.

Mike

[LleMikeByw]

Re-reading your post I noted that you are using RSYNC - but to be able to "see" what you are seeing - you must be using root to RSYNC.

It is possible to setup users in an user environment for SSH and hence RSYNC over SSH via the details I have posted here:

http://forum.synology.com/enu/viewtopic.php?f=15&t=31332#p134474

If you used the chmod commands indicated above then the user is denied access to the home directories of other users (and root etc.) for whatever purpose.

Hope that is of help.

Mike

[viknet]

hello mike and thanks for your answer and thanks for the inormations:

so yes I did already setup rsync for other users as per your post but at the step :

-------------------------------------------------------------------
3) Change the following in the relevant user's line:

Code: Tout sélectionner
/sbin/nologin


becomes

Code: Tout sélectionner
/bin/ash
---------------------------------------------------------------------

I did not choose /bin/ash as a shell but use "/volume1/homes/validate-rsync" instead to avoid the user beeing able to ssh into my DS see http://troy.jdmz.net/rsync/index.html for more details.

Concerning the permission change, I might end up doing the chown myself ,but I was reluctant that I might break other things into the DS, I might try the creation of a new group as per your recomandation.

If we could have an "offcial" synology answer concerning the permissions and why they are setup 777 for all file that might help us doing a mistake while tinkering with our DS.


Best regards to all of you


Viknet

[viknet]

OK I am fed up

after tinkering permissions back and forth within linux (chmod) and with the web interface may conclusion is:
it is not feasable: new file are created with default synology access right so tinkering permissions within linux is useless

The conclusion seems to be sad, but secure rsync is not feasable on a synology.......


Sorry to say that, but anybody looking for an over the internet rsync or scp solution should stay away from synology, and the sad part is that everything else is great on the synology....


I will only find another way to backup my mother's computer

apart from that, a big thanks to synology for creating such a great product, keep going.....

[LleMikeByw]

Hi VikNet,

I've had a quick look at the page to which you referred me.

Basically, you are running your rsync over ssh - just restricting accepted commands to rsync commands rather than anything else passed via ssh.

Consequently your issue with permissions is entirely down to user ownership and group ownership of directories (user.group and permissions 777 or 700 or 770 or 774 etc. etc.) and how this is managed in the web interface.

As I recall - from some time back now - the original installation of the DiskStation allowed any user of the DiskStation logging in via the web interface to see "homes" - that "view" included other users' directories.

This was caused by the initial setup of the group "users" in the DiskStation (and how new folders were created).

I believe I did resolve this matter previously by adjustment in the web interface at first - by adding another group of users in addition to the default group (StandardUser say) and making all users members of that new group - then adjusting down permissions of that group.

In the end however, I have abandoned bothering with the web interface and am managing the folders through the command line including SSH access for specific users.

I just make sure that the web interface correlates with my settings in the basic Linux filesystem. The settings there generally over-ride the web interface settings - although they do have an influence on each other.

In your position - I'd set up another web interface group and make the relevant users members of that group in the web interface. Then gradually tone down group permissions.

Mike

P.S. Unrelated observation: I don't really understand why you are so concerned about giving users access via SSH - since users are denied the opportunity to access any system files, cannot see SHADOW, cannot access security logs and can only write to their own folder (and TMP) so damage is severely limited to amending/deleting their own files/running unprivileged applications (which cannot gain privilege rights).

[viknet]

right my permission ownership is entirly down to user ownership and group ownership of directories.

So I started to change group and ownership of all shares, but if a user create/add a new file using samba/ftp/filestation the rights/ownership is not preserved and is 777 (meaning anybody can write/delete) so I think this solution is not a good one.

concerning your P.S. question, I fully understand that the user won't be able to change system file, but what I care and what has value for me are the other data in the other shares, and these are not secured, with the right command the remote user can wipe/get out all of my data and I care about this because my key will be on another computer on the internet that I don't trust.....

best regards and thank for your support.

[LleMikeByw]

VikNet,

I don't want to labour the point - because I think you are on the right track with creating new groups/users in the web interface and regressing rights there - but I just wanted to clarify that the key you talk about for SSH access is the key for THAT user (possibly root) of the SSHD daemon on the DiskStation.

The rights bestowed on that user can be equivalent to the rights of an ordinary user of a Linux operating system if you make the changes I suggest in my other posting (see link above) - who can be denied the rights to run specific programs, access specific folders etc.

Consequently, I was indicating that SSH access was 'safe' - provided it is restricted to user SSH access not root SSH access.

Different RSA keys for the users are stored in:

/root/.ssh (Specifically for root ssh access)

OR

/volume1/homes/USER/.ssh (for that USER).

Then when the USER logs in SSHD checks the user's key against the /volume1/homes/USER/.ssh/id_pub.rsa key and - if accepted - the user logs in at that level with that USER's rights...

Yes - they can cd to other folders but those folders are restricted by the OS and rights to commands like IFCONFIG (say) are restricted. I always CHMOD /root and other users' folders (to stop the access).

Hope that makes it a little clearer why I feel SSH access isn't THAT dangerous... unless you genuinely fear that somebody is going to hack the SSH Daemon (but they could do that even with your current setup <g>).

Hope I have been able to help a little

Mike