rsync over ssh - possible attack vectors

[g. sullivan]

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 xx.xxx.xx.xx
>     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
>