Sé que una de las primeras cosas que debe hacer para proteger un servidor es no permitir el inicio de sesión raíz remoto.
Las contraseñas son bastante débiles; ¿Qué piensa la gente de solo permitir el inicio de sesión raíz a través de claves ssh u otros métodos sin contraseña?
¿Qué métodos son los mejores? ¿Es mejor no arriesgarse? ¿El ssh-ing con una cuenta secundaria y el uso su -realmente agrega seguridad?
¿Cómo las personas en serverfault.com acceden a la raíz en un servidor remoto?
Respuestas:
En su mayor parte, se gana poco al deshabilitar los inicios de sesión raíz remotos. Ayuda marginalmente a aplicar una política que los administradores inician sesión a través de sus propias cuentas y suenrutar según sea necesario (o usar sudoposiblemente con sudosh... dependiendo de sus políticas).
La creación de contraseñas raíz extremadamente largas y engorrosas (efectivas siempre y cuando todavía no esté utilizando el antiguo deshilachado de sal DES + de 12 bits para sus contraseñas) es tan eficaz para hacer cumplir dicha política.
Un sitio con el que estoy familiarizado tenía un sistema mediante el cual las contraseñas únicas se generaban aleatoriamente para cada host, se almacenaban en una base de datos y se enviaban a los sistemas. Los administradores debían usar sshcon sus cuentas normales y sudopara la mayoría de las operaciones. Sin embargo, la contraseña de root estaba disponible para ellos a través de un servicio web interno basado en SSL (que además requería su token y PIN RSA SecurID). Obtener una contraseña de root implicaba ingresar una justificación (generalmente un enlace a un número de ticket de Remedy (TM)) y accesos donde se audita periódicamente. Una de las pocas razones aceptables para usar la contraseña de root directamente fue en aquellos casos en que se detuvo un sistema fsckdurante el proceso de arranque ... ysuloginrequería una contraseña raíz real para ejecutar manualmente la verificación del sistema de archivos y los procesos de reparación. (Hubo una discusión sobre métodos alternativos para esto --- que son relativamente fáciles para Linux, pero se vuelven mucho más difíciles a medida que intenta extender sus procedimientos para tener en cuenta los muchos sistemas heredados HP-UX, AIX y SunOS y Solaris anteriores que todavía estaban en producción en ese ambiente).
Hay casos en los que es necesaria una contraseña de root, o al menos es la mejor alternativa disponible. Mantenerlo disponible mientras lo hace lo suficientemente robusto contra los tipos de amenazas que puede anticipar es generalmente su mejor estrategia.
Otro sitio que conozco tiene un enfoque bastante elegante para la administración descentralizada de cuentas. Tienen paquetes user- * y sudo- * (piense en RPM) que se instalan en los sistemas utilizando los procedimientos normales de gestión de paquetes y la infraestructura de automatización. En su caso, el paquete sudo- * depende del paquete user- * correspondiente. Esto es bueno porque le permite tener grupos de máquinas con cuentas localizadas (todas las cuentas son administradores, desarrolladores, personal de soporte o cuentas "sin cabeza") y elimina la dependencia de LDAP / NIS u otros servicios de identidad y autenticación en red. (Esto reduce el acoplamiento entre sistemas los hace significativamente más robustos).
Una cosa que me gusta de ese enfoque es que brinda flexibilidad. Cualquier persona con sudoacceso puede emitir un comando para agregar un usuario normal u otra sudocuenta de usuario. Entonces, si estoy trabajando en un ticket, cualquiera de las personas que ya tienen acceso a un sistema me puede dar acceso fácilmente. No hay demoras mientras un ticket para agregarme a alguna lista de control de acceso en alguna base de datos central se procesa a través de un proceso de aprobación centralizado y finalmente propaga un cambio de regreso al sistema en cuestión. Cualquiera de los sudousuarios autorizados en el sistema puede darme acceso y luego eliminarme. (Sí, si fuera malvado y me juegansudoPodría modificar maliciosamente cosas para retener el acceso ... de hecho, hay algunas cosas que podría hacer como usuario normal para retener el acceso después de dicha eliminación. Sin embargo, esa no es la amenaza que les preocupa. Mi acceso todavía está limitado a un número relativamente menor de sistemas en general; por lo que el impacto de una cuenta comprometida es aún más limitado que la mayoría de los esquemas similares que he visto.
Si deshabilita el acceso remoto a la raíz, evita que los atacantes remotos obtengan acceso directo a la raíz: tienen que romper otra cuenta, obtener acceso a la máquina y luego intentar obtener acceso a la raíz. Es un paso extra.
En general, la raíz está deshabilitada para el acceso remoto. SU funciona bien. Si algo realmente se rompe, siempre hay acceso directo a la caja para solucionarlo.
Si quieres ser más estricto, simplemente deshabilita la raíz por completo, para eso está sudo. Una vez más, con ese enfoque aún puede obtener acceso de root al pasar al modo de usuario único, a la Ubuntu. Aunque, creo que usaron un init parcheado para eso, según sus documentos.
Además, puede configurar inactivo para iniciar usuarios inactivos en caso de que sus terminales se dejen abiertos y las PC también estén abiertas. Puede obligar a todos los usuarios a usar claves, pero la administración de claves puede ser difícil.
Un único host de registro de paso como un sistema de tipo breakglass también forzó una capa adicional de protección y una pista de auditoría.
Le sugiero que configure el sistema para permitir el acceso de root SOLAMENTE en la consola.
De lo contrario, usando sudo con la opción de contraseña, permita que los usuarios seleccionados accedan a comandos privados. Por cierto, tenga en cuenta que sudo puede diseñarse para restringir una cuenta de usuario a ciertos comandos si lo desea. Sudo, deja una "marca" en el registro del sistema que se utilizó. sudo es mejor que su porque la contraseña de root no se revela. Por lo tanto, puede cambiar la contraseña de root y el usuario que usa sudo no sería más sabio.
El uso permitido de sudo para acceder a comandos privados debe ir acompañado de cambios de contraseña periódicos y forzados con la frecuencia dependiendo del entorno.
nunca permitir root
configurar el sistema para permitir el acceso a través de claves solo sin contraseñas
luego configure sudo para los usuarios autorizados a realizar cambios a través de la cuenta raíz