Cómo rastrear actividades de superusuario

21

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.
mfriedman
fuente
2
(agarra la silla y palomitas de maíz) esto debería ser bueno ...
Avery Payne
+1 ... estaba pensando exactamente lo mismo. LOL
KPWINC
También tenga en cuenta esta pregunta relacionada: serverfault.com/questions/46614/…
sleske
Sigo pensando que debería usar un sistema de gestión de configuración. (marioneta / cfengine / chef / systemimager / chef / etc ...)
KevinRae
Kevin, estoy de acuerdo contigo. Vea por ejemplo mi comentario a la respuesta de womble : serverfault.com/questions/50710/… . Desafortunadamente, esa no es una opción en este entorno, y es por eso que solicité asumir un escenario en el que un sistema de administración de configuración no está disponible. De todos modos, me gustaría agradecerles por sus comentarios sobre este tema.
mfriedman

Respuestas:

8

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.

DisabledLeopard
fuente
3
Sí, sudo tiene un excelente registro: todas esas entradas de "womble run / bin / sh as root" son realmente útiles. Sin la administración de la configuración, las personas siempre se convertirán en root para realizar tareas administrativas, y alguien que quisiera hacer algo nefasto podría hacer lo suyo en la misma sesión raíz que realizar una tarea válida. La portada perfecta.
womble
La política tiene que desalentar el simple hecho de descartar como raíz para que esto sea bueno, por supuesto, y no podrá saber lo que hicieron una vez que salieron de la reserva, pero reduce la lista de sospechosos ...
dmckee
2
Política: "sudo / bin / sh" = despedido / investigado. Solución bastante clara y bastante fácil.
Karl Katzke el
55
hay tantas maneras de obtener un shell de los programas que la gente tendrá que ejecutar legítimamente (por ejemplo, desde sudo vi) que no tiene mucho sentido simplemente bloquear 'sudo /bin/sh'... a menos que pueda estar seguro de que ha bloqueado todos los métodos posibles, solo estaría presentando un desafío para encontrar formas más oscuras. en cualquier caso: a) a veces es necesario sudo / bin / sh, yb) es un problema de gestión, no de tecnología.
cas
Chris hace un gran punto: problema de gestión, no problema técnico.
Karl Katzke el
2

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.

romandas
fuente
+1 Gracias por sugerir sudoshell, y especialmente por mencionar el sistema de auditoría del kernel de Linux, eso podría ser un excelente complemento para lo que estoy tratando de lograr.
mfriedman
2

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.

blauwblaatje
fuente
+1 No sabía sobre esa biblioteca. ¡Gracias por compartir!
mfriedman
1

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.

womble
fuente
Estoy de acuerdo con usted. La mejor opción sería 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. Sus comentarios son útiles para refinar y aclarar mi pregunta.
mfriedman
1

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).

el otro recibir
fuente
Gracias por tu respuesta. ¿Admite el registro de pulsaciones de teclas o solo el registro de comandos?
mfriedman
0

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

KPWINC
fuente
2
Tengo un script .bash_logout que hace una copia con fecha y hora del historial en /var/lib/history/$user.$tty-or-IP.$yymmddhhss si me importara más, configuraría la contabilidad de procesos o la correcta herramientas de auditoría ... pero no es realmente por seguridad, es para poder averiguar quién hizo algo tonto y decirles a) que no lo vuelvan a hacer, yb) cómo hacerlo correctamente. aumentar el nivel de pista de los juniors es mucho más un problema aquí que la confianza.
cas
1
Me recuerda la historia en la que un chico de ventas junior arruina el trato del millón de dólares. Él espera que el jefe lo despida y el jefe dice: "¡Diablos, no! ¡Solo me costó un millón de dólares ENTRENARTE!" Puedo sentir el "nivel de pista" de los juniors aumentando mientras hablamos. ;-)
KPWINC
0

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.

Siddharth Bhattacharya
fuente
0

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.

chmeee
fuente
0

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.

Dima Medvedev
fuente
0

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?

mfriedman
fuente