¿Mejores prácticas para reforzar el sudo?

Su pregunta es bastante amplia, y trata varios temas diferentes. Puede ser mejor tomar algunos de los detalles y colocarlos en una pregunta por separado.

  

¿Es suficiente prohibir su y permitir sudo para mantener la trazabilidad de las acciones del administrador?

     

... ¿el comando sudo puede tener utilidad sin una configuración de sudoer fuerte? cuáles?

sudo sin restricciones tiene un par de beneficios sobre su .

• Cada sudoer puede usar su contraseña personal. De esta manera, no tiene que volver a distribuir la contraseña de root si se modifica.

• sudo puede configurarse para registrar la actividad. Si su configuración syslog escribe en una ubicación remota, entonces será difícil para alguien cubrir sus huellas.

Sin embargo, el acceso no restringido root sigue siendo 'no restringido'.

• Si no usa un servidor syslog remoto, las pistas se pueden cubrir fácilmente.

• Por conveniencia, la gente a menudo usará sudo -s para obtener una shell interactiva. Esto le permite obtener bash autocompletar en directorios restringidos. Desafortunadamente, los beneficios de syslog son nulos si una persona puede ejecutar sudo -s . También hay muchas alternativas a sudo -s que pueden permitir que los comandos se ejecuten sin un registro específico.

  

(Puedo imaginar un escenario en el que un usuario realiza muchas acciones de sudo antes de eliminar su bash_history)

bash_history no debe usarse como herramienta de rastreo de historial. Es solo para conveniencia del usuario.

  

¿Hay otra fuente además de .bash_history útil para mantener la trazabilidad? ¿Puede un administrador de este tipo actualizar un archivo (con sudo)?

Cualquier persona en el servidor puede actualizar los archivos con acceso ilimitado root . (ya sea a través de sudo o su )

Cómo rastrear la actividad de un usuario root puede ser el tema de una pregunta diferente. Creo que las configuraciones avanzadas de SELinux pueden hacer esto, pero probablemente no sea práctico. No conozco ninguna otra forma de rastrear la actividad de un usuario root .

Como he dicho, si tiene algún registro que deba escribirse en un servidor de registro remoto para evitar que el atacante los borre.

  

¿Es posible restringir sudo -i y sudo -s en la configuración?

Para responderte textualmente, esto puede ser posible, pero está fuera del alcance de esta publicación. Considera crear una nueva pregunta.

Sin embargo, esto no resolverá su problema. Por ejemplo, uno podría usar sudo su en lugar de sudo -s . Se podría usar sudo sudoers , o actualizar el crontab , etc.

La única forma de resolver esto es "restringir" las habilidades sudo usando una lista blanca. Como ha dicho, esto no es tan común, pero ciertamente es la única forma de lograr el objetivo de una trazabilidad confiable con cualquier nivel de detalle.

Espero que esto ayude. No dude en pedir una aclaración sobre mi respuesta o publicar una pregunta más específica si tiene preguntas nuevas basadas en lo que aprendió hasta ahora.

Dirigiéndome a tu última oración, en realidad hago algo con ese espíritu en mi servidor SSH. Tengo dos usuarios allí: ssh_user y sudo_user . Solo se permite el inicio de sesión a ssh_user , pero no está en sudoers y tiene que emitir un comando su sudo_user para hacer las cosas. Esto proporciona una línea de defensa adicional: incluso si el atacante obtiene las credenciales de ssh_user (por ejemplo, al robar los archivos de configuración de mi masilla), no tendrá acceso inmediato a sudo o /etc/shadow en el servidor y tendrá que forzar la contraseña de sudo_user o ejecutar un exploit en el sistema para obtener acceso de root.

Por supuesto, una vez que el atacante tenga acceso a la cuenta ssh_user , el servidor se verá comprometido, pero espero que este truco me dé un poco más de tiempo para reaccionar antes de que se produzca el daño real.

En cuanto a esto:

  

Iniciar sesión con el usuario root y normal con la misma contraseña parece ser una mala práctica.

sudo puede configurarse para solicitar la contraseña del usuario "objetivo", o una contraseña de root, en lugar de la contraseña del usuario en ejecución. Por lo tanto, para un solo usuario puede tener distintas contraseñas de administrador y no privilegiadas. Para los administradores múltiples, quienes deberían tener contraseñas distintas para los privilegios y el acceso de administradores, es más difícil y es probablemente más fácil al crear usuarios adicionales con uid 0.

De sudoers (5) :

  

[sudo] valida las credenciales del usuario que invoca, no las credenciales del usuario objetivo (o de la raíz). Esto se puede cambiar a través de las banderas rootpw , targetpw y runaspw , que se describen más adelante.