¿Cuáles son las implicaciones de seguridad al reescribir SSH_ORIGINAL_COMMAND para permitir que rsync se ejecute desde el trabajo cron rsnapshot?

3

Tenemos el siguiente archivo authorized_key que sincronizamos en todos nuestros hosts para usar con nuestro trabajo cron rsnapshot:

from="192.168.1.337",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,\
command="rsync --server --sender -logDtprRe.iLsfxC --numeric-ids -- . \"${SSH_ORIGINAL_COMMAND#* . }\"" \
ssh-rsa AAAAB3NzaC1yc2EA...ER9+vQ== [email protected]

El último argumento puede diferir de un host a otro (lo que significa que podría obtener acceso a cualquier archivo que desee).

  • ¿Hay alguna forma más segura de usar rsnapshot en un trabajo de computadora?
  • ¿Está utilizando comillas dobles guardar razonablemente contra argumentos inyectables?
  • ¿Existe la posibilidad de leer datos relevantes a través de / proc o / sys?
  • ¿Puede el servidor rsync modificar cualquier archivo en el host?
  • está obteniendo la contraseña & las claves privadas desde el interior de los archivos (archivos de configuración, / etc / contraseña) que se están sincronizando son el único ataque razonable (supongo que necesitaríamos un montaje de encfs inverso en el host para mitigar este riesgo)?

Nota: los argumentos (incluido --server --sender) se copian de lo que rsync dentro de rsnapshot llama a través de SSH, también es por eso que no estoy seguro de si alguien, por ejemplo. podría por ejemplo eliminar / sobrescribir archivos arbitrarios a través del protocolo rsync (por ejemplo, / root / ssh / authorized_keys) haciendo que todo el esfuerzo sea inútil.

    
pregunta till 16.01.2018 - 23:13
fuente

0 respuestas

Lea otras preguntas en las etiquetas