Si un servidor está comprometido, un atacante podría agregar su propia clave pública a authorized_keys. ¿Cómo se previene esto? ¿Quién debería tener acceso al archivo?
Si un servidor está comprometido, un atacante podría agregar su propia clave pública a authorized_keys. ¿Cómo se previene esto?
La modificación del archivo authorized_keys de un usuario por parte de un atacante evita que el sistema se vea comprometido hasta el punto de que el atacante pueda modificar archivos críticos arbitrarios en primer lugar, y para en menor medida, asegurando que este archivo crítico tenga permisos que no permitan que usuarios arbitrarios cambien su contenido.
¿Quién debería tener acceso al archivo?
Solo el usuario que posee el archivo debe tener acceso de escritura (incluso a sus directorios principales), pero el acceso de lectura es en principio seguro, ya que el archivo solo contiene datos de clave pública. (La clave privada correspondiente se almacena en el sistema desde el cual se conecta el usuario). En la práctica, no hay razón para configurar nada más permisivo que 0600, y el servidor SSH debería rechazar el archivo si tiene permisos que le permiten ser modificado o reemplazado por alguien que no sea el propietario.
Considere el escenario que está describiendo. El atacante, en ese caso, ya tiene acceso de root, o efectivamente, ya que puede modificar el archivo authorized_keys de un usuario. En ese momento, no hay razón para hacer algo tan mundano como instalar una clave SSH adicional que permita iniciar sesión como ese usuario; como ya se ha señalado, es mucho mejor instalar un servidor SSH personalizado (que tiene todo el inicio de sesión arrancado, por ejemplo, y probablemente intenta enmascararse u ocultarse contra el administrador, por dos).
El único escenario en el que me parece tener sentido incluso considerar la modificación del archivo authorized_keys de un usuario es si el atacante solo logró obtener acceso a la cuenta de ese usuario y desea hacerlo. lo que puedan para mantener acceso al menos a esa cuenta. Pero si el usuario mira ese archivo, a menos que tenga algo como docenas de claves legítimamente autorizadas, es probable que la línea adicional se destaque como un pulgar dolorido.
E incluso en este escenario, en la gran mayoría de los casos es probable que existan formas mucho mejores de garantizar el acceso continuo al sistema comprometido.
Si el atacante puede obtener acceso equivalente a la raíz, hay muchas, muchas formas de garantizar un acceso continuo que son mucho más difíciles de detectar, y mucho menos de limpiar, incluso por un usuario atento o administrador del sistema.
Eche un vistazo a esta respuesta existente.
Considere el caso de uso del servidor en su escenario, particularmente la frecuencia y la diversidad de las sesiones de SSH, y ejerza el principio de privilegio mínimo en consecuencia.
La mayoría de los escenarios de compromiso que vienen a la mente provienen de un endurecimiento inadecuado (es decir, con respecto a las cuentas de usuario) y / u otras fallas de configuración.
Si un servidor está comprometido, básicamente se termina el juego. Puede restaurar desde copias de seguridad buenas o reinstalar, y puede hacer algunos análisis post mortem para averiguar cómo obtuvieron la entrada, pero ese sistema está instalado y no debe repararse sino reinstalarse.
Por lo tanto, nada impide que un atacante que haya obtenido privilegios de superusuario modifique authorized_keys . Normalmente, solo el usuario al que pertenece este archivo (y raíz, por supuesto) debe poder acceder a él.
Lea otras preguntas en las etiquetas authorization ssh system-compromise access-control