¿Cuál es el valor real de deshabilitar el inicio de sesión remoto mediante ssh?

4

He leído las respuestas sobre por qué debes desactivar el inicio de sesión remoto, pero hay algo que me molesta. Supongamos esto:

  • Escenario 1:
    • Servidor remoto A.
    • Inicio de sesión de root remoto deshabilitado.
    • La autenticación de contraseña está deshabilitada.
    • El usuario A está usando la autenticación rsa para iniciar sesión.
    • El usuario A ejecuta /bin/su - para convertirse en root e ingresa la contraseña de root.
  • Escenario 2:
    • Servidor remoto B
    • Inicio de sesión remoto habilitado.
    • La autenticación de contraseña está deshabilitada.
    • El usuario B está utilizando la autenticación rsa para iniciar sesión como root.

Ya sé lo que se dice sobre varias líneas de defensa, y sí, sé que es más probable que los bots en Internet intenten usar la raíz en comparación con la mayoría de los otros inicios de sesión, pero el escenario 1 ofrece algunas ventajas significativas sobre el escenario 2 si asume que un atacante encuentra una forma de evitar la autenticación rsa (ya sea mediante el secuestro, las vulnerabilidades o simplemente copiando el archivo de claves) utilizado en ambos escenarios?

Digamos que un atacante obtiene acceso al servidor A y puede iniciar sesión como usuario A. ¿No es correcto que a partir de ese momento, el usuario A no pueda iniciar sesión y su a la raíz sin potencialmente compartir el ¿Contraseña de root con el atacante? ¿Es difícil simplemente agregar un comando hecho en casa al final del script de shell de inicio de sesión de los usuarios que interceptará y transmitirá (o almacenará) la contraseña de la raíz?

Mi punto no es que sea seguro permitir que los usuarios inicien sesión como root de forma remota, sino que obligar a los usuarios a iniciar sesión con otra cuenta es casi tan inseguro: varios bots de módulo que siempre están atacando las cuentas de root en todas partes.

¿Me estoy perdiendo algo?

    
pregunta Michael Zedeler 27.04.2013 - 00:28
fuente

1 respuesta

6

Justo en la parte superior de mi cabeza:

  • Si las credenciales del usuario están comprometidas, el bloqueo de esa cuenta en el directorio de usuarios es mucho más rápido y confiable que la edición de /root/.ssh/authorized_keys en todos los sistemas para eliminar la clave de ese usuario.
  • Los demonios de auditoría de Linux distinguen entre "uid" y "uid efectivo". El demonio de auditoría considerará a los usuarios como ssh como ellos mismos y luego sudo para obtener privilegios como "bob de usuario actuando como root" en lugar de "root" si son ssh directamente como root. Es importante contar con un registro de auditoría que se remita al usuario que realiza las acciones.
  • Puede requerir un token de autenticación de 2 factores para sudo. Si bien esto también se puede hacer en el nivel sshd, esto requiere un parche de terceros y tiene un impacto significativo en la facilidad de uso, ya que no se puede habilitar simplemente para un grupo de usuarios.
respondido por el mricon 27.04.2013 - 00:59
fuente

Lea otras preguntas en las etiquetas