Solución:
Una ventaja de seguridad de deshabilitar root y crear un usuario no root que pueda usar sudo está protegiendo su servidor contra ataques de fuerza bruta que intentan adivinar su contraseña “root”.
Como dijo Rinzwind, ¿cuál crees que es más seguro?
- Cuenta raíz + Contraseña difícil de adivinar
- Un nombre de usuario personalizado + contraseña difícil de adivinar
La otra ventaja más importante es que cuando solo tiene un usuario root, todo lo que está ejecutando se está ejecutando con el poder de “root”, que tiene acceso para hacer todo, por lo que ejecutar un comando incorrecto o cometer un simple error tiene el potencial de destruyendo su servidor.
Simplemente creando un usuario no root:
- ¡No está dando su contraseña de root!
- ¡Puedes definir quién puede hacer qué!
- ¡Puede auditar quién hizo qué!
- Está minimizando la posibilidad de ejecutar un comando incorrecto o peligroso con acceso de root.
Y también recuerde que si alguien tiene acceso físico al servidor, él o ella puede hacer casi lo que quiera en el servidor a menos que todo esté encriptado en ese servidor.
Además de las preocupaciones válidas mencionadas en la respuesta de @ Ravexina, creo que es importante tener en cuenta:
SSH en su servidor no es la única forma en que un actor malintencionado podría realizar acciones
De hecho, un ataque de fuerza bruta exitoso en SSH es probablemente el menos probable forma en que un pirata informático entraría en su servidor. SSH duerme durante 3 segundos cuando se ingresa una contraseña no válida, por lo que forzar una contraseña SSH remota segura es prácticamente imposible. *
Lo más probable es que puedan encontrar una vulnerabilidad de ejecución remota de código y “entrar” de esa manera. Si cuando lo hacen, usted quiere que tengan el menor permiso posible. usted De Verdad no quiero que sean root.
Vea, cuando ejecuta un programa, como Apache, PHP o un script PHP / Python / NodeJS, o incluso su navegador web: ese “proceso” también debe ejecutarse como un usuario. Por ejemplo: si ejecuta un script PHP como root, entonces ese proceso PHP puede hacer cualquier cosa root puede hacer.
Digamos, por ejemplo, que un actor malintencionado puede llevar a cabo un ataque de “ejecución remota de código”: puede ejecutar código en su servidor. Si PHP ejecuta ese código malicioso y PHP se ejecuta como root, eso significa que el código del hacker también se ejecuta como root. Pero si PHP se ejecuta como un usuario con menos privilegios (es decir: webapp), mitiga significativamente la cantidad de daño que puede causar. Esto también se aplica cuando ejecuta scripts de consola, y no solo a PHP: todos los idiomas pueden tener este problema.
Lo complicado aquí es: es posible que la vulnerabilidad RCE ni siquiera sea un código usted escribió: podría estar enterrado profundamente en alguna biblioteca / módulo de terceros al que su código llama: calcular fechas, interactuar con una base de datos, renderizar HTML, etc. En otras palabras: es posible que ni siquiera sepa que está allí. Y podría agregarse silenciosamente a su base de código cuando actualice sus dependencias / bibliotecas. Como vimos en el truco de EventStream, puede ser trivialmente fácil obtener el control de un repositorio de biblioteca ascendente y usarlo para enviar código malicioso a aplicaciones desprevenidas aguas abajo. Si ese código malicioso se ejecuta como root, puede tomar el control de todo su servidor e incluso cubrir sus pistas hasta donde nunca se sabe que sucedió.
Por lo tanto, aunque tener usuarios separados para todo puede no evitar un ataque por completo, será mitigar significativamente daño que podría provenir de un ataque de ejecución de código remoto si ocurre.
* Obviamente si tu contraseña es abc123 esto no se aplica, porque probablemente sea uno de los primeros que intentarán los piratas informáticos cuando utilicen la fuerza bruta.