Cómo rastrear actividades de superusuario

Me gustaría saber cuáles son los mejores enfoques para rastrear las actividades de superusuario en un entorno Linux.

Específicamente, estoy buscando estas características:

• A) Registro de pulsaciones de teclas en un servidor syslog seguro
• B) Capacidad para reproducir sesiones de shell (algo así como scriptreplay)
• C) Idealmente, esto debería ser algo imposible (o bastante difícil) de sortear sin tener acceso físico al servidor.

Piense en esto desde una perspectiva de seguridad / auditoría, en un entorno donde diferentes administradores de sistemas (o incluso terceros) deben poder realizar operaciones privilegiadas en un servidor.

Cada administrador tendría su propia cuenta nominal, y cada sesión interactiva debería estar completamente registrada, con la posibilidad de volver a reproducirla si fuera necesario (por ejemplo, si alguien usara mc para eliminar o alterar archivos críticos, no sería suficiente para sepa que esa persona emitió el comando mc; debe haber una manera de ver exactamente lo que se hizo después de iniciar mc).

Notas adicionales :

1. Como ha señalado womble, la mejor opción podría ser no hacer que las personas inicien sesión con privilegios de root para realizar cambios en los servidores, sino que lo hagan a través de un sistema de administración de configuración. Así que vamos a asumir una situación en la que no tenemos un sistema de este tipo y hay que conceder acceso de root a diferentes personas en el mismo servidor .
2. No me interesa en absoluto hacer esto subrepticiamente: cada persona que inicie sesión en un servidor con privilegios de root debería ser plenamente consciente de que la sesión se grabará (de la misma manera que, por ejemplo, los operadores de centros de llamadas saben que sus conversaciones son siendo grabado)
3. Nadie usaría una cuenta genérica de superusuario ("root")
4. Soy consciente de ttyrpld y parece hacer lo que estoy buscando. Pero antes de seguir así, me gustaría saber si esto se puede resolver utilizando un núcleo no modificado. Quiero saber si hay alguna herramienta para Debian en particular (o Linux en general) que permita la auditoría completa de las cuentas de superusuario sin parchear el shell o el kernel.

Para entornos con múltiples administradores, simplemente no use root, siempre que sea posible.

Use sudo para todo: sudo es extremadamente configurable y fácil de guardar.

Registre cualquiera / todos los inicios de sesión o su para rootear e investigarlos ya que alguien está siguiendo sus reglas establecidas.

Por un lado, ¿qué tipo de acceso de usuario root está buscando monitorear? ¿Estúpidos errores de administración o información maliciosa? El primero: querrá una buena solución de administración de configuración, como ya se ha sugerido. El último: si saben lo que están haciendo, solo puede esperar atrapar lo suficiente para indicar que sucedió algo que vale la pena investigar. Solo quiere saber que comenzó alguna forma de actividad no autorizada, y ser alertado de ese hecho. Si son inteligentes, deshabilitarán la mayor parte del registro que construyes (cambiando el estado del servidor o trayendo sus propias herramientas), pero con suerte podrás ver el comienzo del incidente.

Dicho esto, sugiero un par de herramientas que puedes usar. Primero, comience con una buena política de sudo (que ya se ha sugerido). En segundo lugar, revise sudoshell si necesita dar acceso a esos administradores root shell. En tercer lugar, probablemente su mejor opción (aunque la más intensiva), considere la auditoría del kernel de Linux.

Lo que podría hacer es usar esta biblioteca para sudo, dar a todos su propia cuenta de uso y poner sudo -i en el perfil de todos. De esa forma tienen acceso raíz instantáneo y se registran todos los comandos que utilizan.

Tienen raíz. Lo mejor que puede esperar es al menos ver cuándo decidieron salir de su pequeña utopía de monitoreo, pero más allá de eso, lo que hicieron es una incógnita.

La "mejor" opción en la que puedo pensar es ordenar el uso de la automatización y administración de la configuración generalizada, y administrar sus manifiestos utilizando un sistema de control de revisiones e implementar actualizaciones a través de eso. Luego, evite los inicios de sesión raíz reales en los servidores. (El acceso de emergencia "oh, no, rompí algo" puede proporcionarse mediante una contraseña no distribuida y cambiada después de cada uso o una clave SSH, y todos pueden ver al administrador de sistemas que se equivocó para asegurarse de que no Cambia cualquier cosa).

Sí, esto será inconveniente y molesto, pero si eres lo suficientemente paranoico como para querer monitorear las acciones de todos en este grado, supongo que estás en un entorno que es inconveniente y lo suficientemente molesto de otras maneras que esto ganó No parece un gran problema.

Como otros han dicho, prácticamente no hay forma de registrar a los usuarios con acceso completo a la raíz de una manera que no puedan desactivar, pero si está ejecutando debian / ubuntu, eche un vistazo a snoopy , que se acerca bastante a lo que desea

snoopy es simplemente una biblioteca compartida que se utiliza como envoltorio para la función execve () proporcionada por libc para registrar cada llamada a syslog (authpriv). Los administradores del sistema pueden encontrar útil a Snoopy en tareas tales como la supervisión de sistemas ligeros / pesados, el seguimiento de las acciones de otros administradores, así como para tener una buena idea de lo que está sucediendo en el sistema (por ejemplo, apache ejecutando scripts cgi).

Estoy de acuerdo con los comentarios de disableddleopard sobre el uso de sudo para todo. Ciertamente hace que las cosas sean un poco más fáciles de registrar.

También agregaría una copia de seguridad del archivo de historial de bash periódicamente. Aparentemente a menudo se pasa por alto, pero a veces puede ser una gran fuente de información ... solo pregunte a Goldman Sachs. ;-)

http://www.guardian.co.uk/business/2009/jul/12/goldman-sachs-sergey-aleynikov

Eso sería difícil ...

root puede ejecutar scripts cuidadosamente probados que pueden violar todas las medidas de seguridad (eliminar procesos de monitoreo), destruir archivos de registro / recortarlos, etc. Pero aún así ...

Asumiendo que múltiples administradores con privilegios de root estén trabajando en equipo. Y root también puede matar cualquier proceso de monitoreo. Y desafortunadamente, ese nombre de usuario / contraseña se hace público. O consiguen compañía no deseada.

La creación de varias cuentas raíz con UID 0, aunque no se recomienda, podría ser aplicable aquí.

En / etc / ssh / sshd_config Cambiando la línea a: PermitRootLogin no

es recomendado. Para que, aquí, un usuario inicie sesión con su cuenta normal (la marca de fecha y hora se registra junto con (tal vez una dirección IP falsificada)) y luego cambia a root. usando su comando

Y el inicio de sesión directo como root se evita de esta manera.

Tenemos que pensar, qué raíz no puede hacer aquí.

Sudo debería ser bueno. Hacer una copia de seguridad de los archivos de configuración del directorio / etc debería ser bueno. / var / directorio Los archivos de registro deben enviarse por correo electrónico periódicamente o almacenarse en un NFS separado.

¿Qué hay de escribir scripts que integren API de compañías de Mobile Gateway que agrupan SMS a todos los móviles de los usuarios root, que uno de ellos está fuera de casa para trabajar? Sé que eso sería irritante, pero aún así.

Romper SSH está fuera de discusión.

Tenemos la siguiente configuración en el sitio de un cliente:

• Del mismo modo, abierto para autenticar con kerberos en AD (cuentas personales)
• Autorización solo para ciertos grupos de AD de administradores de Unix
• sudoers group == AD group
• Agentes OSSEC HIDS en cada servidor y un administrador en un servidor reforzado
• Interfaz web de OSSEC
• Splunk 3 con Splunk-for-OSSEC

Registrará cada uso de sudo en los servidores y también realizará un seguimiento de cualquier cambio en los archivos, instalación de paquetes, procesos sospechosos, etc.

Tenemos varios servidores de terminal para acceder a todos nuestros equipos, lo que significa que uno puede iniciar sesión desde cualquier servidor de terminal o si tiene acceso físico.

Sshd en servidores de terminal está parcheado con http://www.kdvelectronics.eu/ssh-logging/ssh-logging.html , funciona bien, pero no se actualizó durante mucho tiempo. Lo modifiqué un poco para que funcione en openssh 4.7, pero no pude hacerlo con 5.1. Segfaults de sshd parcheado, y mientras no tenga suficiente tiempo para arreglar eso, casi me he cambiado a ttyrpld.

Hasta ahora, esto es lo que tengo:

• sudosh : parece admitir A y B (aunque no estoy completamente seguro de A)
• Sudoscript : parece admitir B (Sudoscript tiene un componente llamado sudoshell, y si eso es lo que sugirió romandas, gracias por el consejo)
• Snoopy Logger o sudo_exetrace : no es exactamente lo que estoy buscando, pero podría ser un buen complemento (gracias a theotherrecibir y blauwblaatje por esos enlaces)

¿Conoces otras herramientas similares que no impliquen parchear el núcleo u otros componentes del sistema?