rsync over ssh - possible attack vectors
Leen Besselink
leen at consolejunky.net
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 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
>>
>
>
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,
Leen.
More information about the rsync
mailing list