Durante mucho tiempo he tenido la impresión de que con unix, nunca deberías iniciar sesión como root .
Ahora he empezado a usar los servidores privados virtuales en DigitalOcean , y algunos consejos es usar las claves SSH para iniciar sesión como root.
Esto tiene sentido para mí, pero me siento incómodo, como si me hubieran pillado usando tabulaciones y espacios en el mismo archivo de texto.
¿Es más seguro usar el inicio de sesión de SSH o como otro usuario con una contraseña engañosa?
mricon trajo dos puntos excelentes para no usar el inicio de sesión de root en un multi Sistema de usuario. Solo quiero agregar un punto de contraataque para usar root login. Si necesito los archivos de configuración de rsync en el servidor, puedo hacerlo en un solo paso utilizando el inicio de sesión root en lugar de subir al directorio de inicio de un usuario, luego hacer su o sudo a rsync de nuevo en el Carpeta /etc . Por supuesto, soy el único administrador en el servidor y la auditoría no es un problema aquí.
No existe una regla estricta y rápida para no permitir el inicio de sesión de root. Es parte de una medida de defensa en profundidad . Para ese propósito, puede implementar el filtrado de IP o el bloqueo de puertos en su firewall. Estos, junto con una contraseña o una autenticación de clave strong deberían ponerlo en una buena posición.
La primera regla a recordar es que no realiza tareas como root a menos que tengan que realizarse como root.
Esta parte reduce el riesgo de daño por un error tipográfico u otro error. También reduce el riesgo de daños si las herramientas que está utilizando tienen una vulnerabilidad de seguridad.
Las cuentas adicionales solo deberían tener los privilegios que necesitan y nada más que eso.
Con esas partes enunciadas, veamos los argumentos de los dos enfoques para el acceso de raíz.
Argumentos para iniciar sesión como no root y usar sudo
Obtienes un registro de auditoría en el que es más fácil averiguar quién hizo qué. No ejecuta todos los comandos como root, sino solo aquellos que prefija con sudo .
Argumentos por los que puede no brindarte tanta seguridad como dicen las personas
La pista de auditoría solo funciona mientras las personas cumplan con las reglas. Es conveniente si hay más de dos personas con acceso sudo o si simplemente no puede recordar todo lo que hizo. Luego puedes ver quién hizo algo y preguntarles por qué lo hicieron.
Pero si alguien quiere pasar por alto la pista de auditoría, puede hacerlo. Si intenta evitar que alguien pase por alto la pista de auditoría, es probable que esas restricciones eventualmente eviten que hagan su trabajo.
La gente puede poner sudo delante de cada comando por reflejo, incluso cuando no era necesario. Y en el caso de una vulnerabilidad de seguridad, ejecutar sin el comando sudo no le dará muchos beneficios ya que si un atacante pone en peligro un proceso en ejecución, no importa si se ejecutó con sudo o no, porque solo puede execve sudo para obtener los mismos privilegios.
Argumentos por los que el uso de sudo puede ser malo
La contraseña del usuario le da acceso a más privilegios. El usuario puede escribir la contraseña del usuario con frecuencia. Si un atacante obtiene esta contraseña, se puede usar para ejecutar comandos a través de sudo .
Una cuenta de usuario comprometida otorga efectivamente privilegios root . ¿Recuerda la parte sobre no ejecutarse como root a menos que tuviera que hacerlo y no darles más privilegios de los que necesitan?
Si inicia sesión como usuario no root para todas las tareas que no requieren privilegios de root, reduce la exposición. No obtienes ese beneficio si la cuenta tiene sudo de acceso. Las tareas que no se ejecutaron como root se convierten en un objetivo más valioso para un atacante, si esa misma cuenta tiene sudo access.
¿Qué más puedes hacer?
Si desea lo mejor de ambos lados, puede dar a cada administrador dos inicios de sesión en el servidor. Un inicio de sesión para las tareas del día a día, que no necesitan privilegios de root. Y un inicio de sesión secundario con sudo de acceso para cuando lo necesiten. Pero lo único que es diferente entre esa segunda cuenta y el inicio de sesión directamente como root es la pista de auditoría. Pero puede ser más fácil para las personas olvidar que no deben usar la cuenta con sudo de acceso todo el tiempo. Recordar no iniciar sesión como root todo el tiempo parece un poco más fácil de recordar para las personas.
¿Qué pasa con el forzado de contraseña?
Algunos argumentan que es más fácil forzar una contraseña para un atacante que solo necesita adivinar una contraseña y no tanto el nombre de usuario como la contraseña. En realidad, este es un argumento débil.
Puede configurar sshd para permitir solo los inicios de sesión usando una clave. No es necesario permitir el inicio de sesión con una contraseña. Si no se permiten los inicios de sesión de contraseña, entonces el forzado de la contraseña bruta ya no es un problema. Ni siquiera es necesario que exista una contraseña, que da acceso a la cuenta raíz. Y nadie va a adivinar la clave secreta para la autenticación ssh.
Cuando /root/.ssh/authorized_keys contiene una clave pública para cada administrador, esas claves públicas podrían usarse como un registro de auditoría que muestre quién hizo qué. Y es tan fácil revocar el acceso eliminando una clave de authorized_keys como por cualquier otro medio.
Esta recomendación es más relevante en sistemas donde varias personas pueden realizar operaciones de nivel raíz. El daemon de auditoría de Linux puede distinguir "UID" y "UID efectivo", por lo que el usuario "bob" que hace "sudo -i" y luego realiza una operación de nivel raíz aparecerá en los registros de auditoría como "bob de usuario actuando como usuario root" . Por lo tanto, si realiza un seguimiento de los cambios en los archivos en / etc, o las ejecuciones de archivos en / sbin, sabrá exactamente quién realizó estas acciones. Si alguien inicia sesión directamente como root, esta información no estará disponible.
También simplifica la administración de la cuenta: si un miembro de su equipo de administración se retira, solo tiene que bloquear su cuenta y no reemplazar las claves de root ssh en todos los sistemas (aunque de todas formas es una buena práctica, junto con cambiar las contraseñas de root).
Lo que normalmente hago yo mismo es configurar el inicio de sesión en la cuenta raíz, configurar el servidor con sudo (agregarme a los sudoers) y luego no permitir el inicio de sesión de raíz a través de SSH.
No veo una razón por la que no puedas trabajar así, pero si tienes un caso válido, usar una clave y una contraseña normalmente es una buena protección (es una autenticación de dos factores, ya que es algo que Sabes y algo que tienes).
Si deshabilitas el inicio de sesión de root, también disminuyes la superficie de ataque de tu máquina. Otro argumento que generalmente se da es que sudo le brinda una cantidad de responsabilidad, la cuenta raíz es generalmente una cuenta del sistema y usted no puede, si algo o alguien inicia sesión usando la raíz, saber quién está ejecutando realmente esos comandos. Cuando usa sudo, todavía tiene esa responsabilidad ya que la persona primero tiene que iniciar sesión en su propia cuenta y luego sudo para rootear. Es posible que esto no se aplique a usted si tiene pocas cuentas (y en la mayoría de los casos no es un sistema de registro remoto separado.
Siempre reviso el océano digital cuando aprovisiono un VPS, siga estos pasos.
Agregar un nuevo usuario (comando estándar)
Otorgue privilegios de root a este nuevo usuario ejecutando visudo y agregando su nombre de usuario debajo del de root en la sección titulada "# Especificación de privilegios de usuario". Dése efectivamente los mismos privilegios que root
Cambie el puerto en el que SSH escucha mediante la edición de etc / ssh / sshd_config usando el editor de su elección. Localice la línea que dice "Puerto 22" y cambie la parte numérica de esa línea a otra cosa. Naturalmente, no utilice un puerto reservado. Un vistazo rápido en línea le mostrará cuáles están disponibles. En ese mismo archivo, ubique "PermitRootLogin yes" y cambie "yes" a "no" Como último paso, pero hágalo con precaución, proporcione acceso explícito a SSH a su nueva cuenta de usuario. Esto requiere agregar una línea "AllowUsers"
Tras todo esto, reinicie el servicio SSH (service ssh restart).
NOTA: Si no tiene acceso de consola a su VM / VPS, considere cuidadosamente cuántos de estos pasos cambiará. p.ej. Simplemente cambiando el puerto predeterminado es bueno.
¡Buena suerte!
Fuente: enlace
Creo que en un servidor la recomendación de "no iniciar sesión como root" no es tan difícil. Si está en un escritorio, no usa los privilegios de root la mayoría del tiempo. Pero si está en un servidor, la mayoría del tiempo que lo usa es una tarea de mantenimiento. Si bien puede dar a las personas que solo tienen que cuidar las cuentas limitadas del servidor web, si usted es el administrador del servidor, puede iniciar sesión como root. Bruteforcing es difícil si usa una clave para el inicio de sesión de root.
Si le da a algunas personas ALL=(ALL:ALL) ALL -sudo derechos, debe hacer el registro en otro servidor, ya que algunos de sus comandos pueden alterar los registros.
Gracias a todos por las respuestas, ha sido realmente útil. FWIW Estoy publicando mi propia respuesta para completarla, que básicamente es iniciar sesión como usuario no root con la clave SSH, no permitir contraseñas.
Es un servidor VPS al que solo tengo acceso y que solo ejecuta un par de servicios confidenciales. Para ese fin, quiero que sea lo más seguro posible con la menor molestia posible:
$ adduser demo
authorized_keys en ~/.ssh/
$ visudo demo ALL=(ALL:ALL) ALL
$ vim /etc/ssh/sshd_config
%código%
PasswordAuthentication no
$ PermitRootLogin no
Espero que lo haga, asegure el inicio de sesión SSH sin poderes de root :)
Lea otras preguntas en las etiquetas authentication ssh unix