rsync over ssh - possible attack vectors

Leen Besselink leen at
Sun Apr 18 04:54:08 MDT 2010

On 04/16/2010 04:10 PM, g. sullivan wrote:
> Am 4/16/2010 10:37 AM, schrieb Leen Besselink:
>> On 04/16/2010 02:16 AM, George Sullivan wrote:
>>> Hello everybody!
>>> <snip>
>> Hello George,
>> I'm no regular rsync-developer, but I like you paranoia so I'll 
>> answer with what I know.
>> I'll start with 2 general tips:
>> 1. if you want to know if a system is compromised, use something 
>> like: tiger. It can help.
>> 2. use something like cron-apt to keep your system up to date, maybe 
>> you don't want it to automatically install, but atleast e-mail you 
>> with information about available updates
>> 3. normally with rsync -e ssh it will use ssh to connect to the 
>> remote-system and run the local rsync-command there in --daemon-mode
> If I understand it correctly this answers my primary question: rsync 
> works only one way in the sense it gives the local system access to a 
> remote system, but not the other way round.
>> 4. if you want a backup of the whole system, with that method you 
>> probably want root-rights, maybe it's better to not use rsync -e ssh 
>> and ssh into the system as the root-user. But use a regular user (and 
>> use sshs-option: Allowgroups or Allowusers to restrict who can 
>> connect), but port-forward to a rsync-daemon running (and binded) to 
>> localhost on the remote system (I didn't see a script to automate it 
>> yet though)
> I've already set PermitRootLogin to no and only backup data 
> files.Worst case is an attacker gains access as the user I'm running 
> the command. That's still bad enough as it has access to all data and 
> there's always the possibility of a privilege escalation.
>> 5. I'm pretty sure you can use something like monit to keep an eye on 
>> the running rsync-daemon, if the pid doesn't change, the binary in 
>> memory isn't changed either (atleast I wouldn't expect them to go to 
>> such lenghts normally) as Linux uses copy-on-write of the 
>> in-memory-binary/running program when doing a fork, so it should be 
>> pretty save ? I'm no expert though.
>> 6. don't forget to setup rsync with password-protected-module
> Isn't the ssh authentication enough?
>> 7. when using SSH disable all options like tunneling
> I didn't know about that. What's the risk here?
>> Some observations:
>> Although, I guess it's more likely they will change the sshd-binary 
>> instead of the rsync binary to capture passwords ? But you are not 
>> using a password, right ? you are gonna be using keys I guess.
> Now we are talking about attacking remote from local. In that case one 
> could either capture the password or gain access to the key. No way to 
> protect against that, or am I missing something?
>> I guess added an other attack-surface by running an extra process on 
>> the system with root-rights isn't a great idea either...
>> Even more likely they will just get in the kernel and change some 
>> system calls to hide their presence and most programs won't be able 
>> to see the difference.
>> So if you still want to ssh with root set it up with:
>> PermitRootLogin no
>> Match Host
>>     PermitRootLogin yes
>> Is something like that, helpfull to you ?
> Many thanks already, and sorry for all the questions.
>> You will have to make your own choices.
>>> Please also tell me if I missed anything else.
>>> Thank you!
>>> George

Sorry, for the confusion, it was a quick email because I needed to do 
other things.

If you are only doing a backup of the data, you don't need root-access 
that's even better.

Only tips 1 and 2 apply.

You should ignore most of the points I made.

Have a nice day,

More information about the rsync mailing list