Respuestas:
Todos mis servidores tienen la cuenta raíz deshabilitada ( sp_pwdpestablecida en *). Esto es necesario sudopara todos los accesos a la raíz. [1] El propósito de esto es auditar todas las actividades del superusuario, para que las personas puedan ver lo que se ha hecho al sistema.
Para una opción más hardcore, puede sudoescribir en un archivo de registro (en lugar de syslog) y hacer que el archivo solo se agregue (usando chattren Linux o chflagsen BSD). De esta manera, nadie puede editar la auditoría después.
[1] También tengo la política de no ejecutar un shell raíz o hacer escapes de shell desde un proceso raíz. (Sin sudo sh -c '...'embargo, está bien usarlo para hacer tuberías o redirecciones).
Recomiendo enfáticamente no deshabilitar al usuario root. Las conexiones de root Deshabilitar o restringir (vía securetty y vía sshd_config y vía PAM y a través de lo que sea) Si el sistema lo permite, los privilegios de superusuario límite o divide el papel de la raíz (similar a la forma en RSBAC lo hace.) Pero, por favor, por favor , haga no deshabilite la cuenta raíz eliminando la contraseña, de lo contrario será imposible iniciar sesión en el sistema a través de sulogin. sulogines utilizado por todos los initscripts que conozco en caso de errores graves informados por fsck, y eso significa que se bloqueará el sistema si el sistema de archivos raíz se corrompe.
Para aclarar: "deshabilitando la cuenta raíz eliminando la contraseña" me refiero a los diversos mecanismos que terminan en a! o un * en el campo de contraseña de / etc / shadow, o similar. No quiero decir "cambiar el mecanismo de inicio de sesión raíz para que no se le solicite una contraseña".
suo sudoen su sistema disponible para los usuarios significa más riesgos de seguridad que puede evitar si solo tiene usuarios root dedicados. Esa es una posición defendida por los autores de la distribución segura de Owl (y el diseñador Solar entre ellos): unix.stackexchange.com/questions/8581/… intenta presentar su posición con referencias.
fastbootopción, desbloquear la cuenta raíz y reiniciar para finalmente ejecutarlo fsckmanualmente.
Tengo la cuenta raíz habilitada en todos mis servidores. Todos los administradores tienen su propio usuario y tienen que iniciar sesión a través de eso. Desde allí cambian a root. (root ssh está deshabilitado)
Mantenga el recuento de administrador bajo. Solo las personas que realmente necesitan acceso root en ese servidor tienen la contraseña.
No soy fanático del sudo. Es demasiado fácil simplemente hacer 'sudo bash' para un shell raíz. Sé que esto se puede desactivar, pero ¿por qué molestarse? Simplemente limite los usuarios que pueden realizar tareas de administrador y hablar entre ellos. Tenemos una política para no permitir que los terminales raíz se abran sin supervisión. Entonces es iniciar sesión, su, hacer el trabajo, cerrar sesión.
Nota: Trabajo en una empresa bastante pequeña (50 empleados) y nos movemos con solo 2 administradores a tiempo parcial (1 windows / 1 linux). Es posible que esta forma de hacer las cosas no sea la mejor cuando tiene órdenes de magnitud de más usuarios. Yo personalmente todavía no usaría sudo. Hay otras formas de registrar la actividad raíz.
Desactivar la contraseña de root es, en mi opinión, una falsa "buena idea". El día que lo necesite, realmente lo necesitará. (de acuerdo con su configuración, es posible que lo necesite para iniciar sesión en modo de usuario único, por ejemplo)
La desactivación del inicio de sesión remoto root puede ser relevante, pero solo si puede iniciar sesión localmente.
Y sí, sudo debería instalarse en cada uno de sus servidores. Es útil y fácil de configurar. ¿Por qué te gustaría no usarlo?
Disabling root remote login might be relevant but only if you are able to log on locally.Esto es descaradamente falso. Puede iniciar sesión de forma remota con cualquier cuenta; deshabilitar el inicio de sesión remoto de root no lo limita al acceso local.
Simplemente desactivo el acceso SSH para root y solicito a los usuarios (a menudo solo desarrolladores) que usen claves ssh. Hay demasiados ataques de diccionario y cambiar el puerto SSH no es una opción para nosotros.
De esa manera, no tiene que confiar en la capacidad de nadie para escribir una buena contraseña. Una vez dentro, solo los administradores tienen permisos para sudo.
Sé que este hilo es muy antiguo, pero hay algunos defectos importantes en la lógica de los artículos vinculados y me siento "rant'ie": sudo permite tanto las listas blancas como las listas negras. No solo en negro como se especifica en el artículo vinculado: esto omite la idea de AAA (Autenticación, Autorización y Auditoría): su & sudo permite la autenticación y la responsabilidad graduadas.
Escenario 1 Un administrador introduce accidentalmente un código falso en un sistema, inicia sesión como root, el código tiene acceso completo y es posible que el administrador nunca sepa qué sucedió. Al menos con los inicios de sesión graduados (por ejemplo, su / sudo), se le solicitará al administrador que se autentique si el código falso intenta usar derechos elevados ... Si no se eleva, se limita a los derechos de los usuarios, lo que debería causar un daño mínimo.
Escenario 2 Un administrador deshonesto quiere obtener información / hacer un cambio. Se conectan a la consola (acceso físico a la consola, HP iLo / similar o acceso a la consola vGuest), inician sesión como root y hacen lo que quieran. A menos que se use una cuenta / tarjeta de acceso con nombre para obtener acceso a la consola, probablemente no haya mucha pista de auditoría.
Debe exigir a todos que usen sudo para cada comando raíz como política. Nunca hay una razón para ejecutar "sudo bash" o similar, es solo por conveniencia, debido a la ignorancia, o para cubrir las huellas.
Si deshabilita los inicios de sesión en la cuenta raíz directamente, limita su capacidad de arreglar el sistema cuando hay problemas graves.
Si no puede convencer a sus administradores de que inicien sesión como ellos mismos y ejecuten sudo para cada comando que se ejecute como root, y que no se divida en un shell, tiene serios problemas para los que no hay una solución técnica.
Los autores de Owl Secure Distribuion (y Solar Designer) tienen un punto de vista opuesto cuidadosamente justificado; vea, por ejemplo, la respuesta /unix/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login/8660#8660 para Una presentación de sus reclamos. El problema de auditar las acciones del superusuario (qué persona hizo qué) también se aborda en su punto de vista (básicamente, la solución es tener varios usuarios root con diferentes nombres).