¿Cómo evitar que los administradores accedan a los registros de su propia actividad?

La solución aceptada para esto es no almacenar los registros localmente, sino en un servidor de registro. Una vez que los registros están allí, puede restringir o limitar el acceso como mejor le parezca.

En algunas soluciones de servidor de registro / agregador, puede impedir que un usuario vea entradas que contienen referencias a ciertos datos (como sus cuentas de usuario o direcciones IP de máquinas). Esto significa que puede habilitar a los administradores para que vean otra actividad de administrador, pero no la suya propia.

Por lo general, desea colocar alertas dentro del servidor / agregador de registros para que se activen si los registros de una máquina dejan de ingresar o se reducen por debajo de ciertos umbrales, lo que ayuda a detectar si un administrador local ha impedido que los registros se envíen Servidor de registro / agregador.

Servidores de syslog, SIEMs, agregadores de registros, pilas ELK, etc. Existen numerosas opciones para que explore.

Cualquier registro en un host comprometido es sospechoso. Necesita una plataforma de registro centralizada, ya sea un servidor de syslog central / splunk / logrhythm / lo que sea. Mantener un conjunto diferente de administradores y cuentas. Esa es toda la idea.

Una vez que tenga una plataforma en su lugar, puede delegar los derechos para ver sus acciones, ya sea su administrador propio o de otro tipo: se puede realizar. Tuvimos derechos de lectura de fuentes de registro específicas y hosts delegados.

Si un atacante adquirió altos privilegios en una máquina, toda la máquina ya no es confiable , y mucho menos registrará los controladores.

Un servidor de registro remoto es la única opción aquí, aunque los detalles pueden variar. Podrá manejar los registros y administrar los controles de acceso de una manera más segura que almacenar los registros localmente.

El primer paso es enviar los registros a un servidor diferente, de modo que después de que el primer servidor se vea comprometido (y, por lo tanto, sus registros puedan modificarse), ese servidor de registros tenga esas entradas de registro. Y este servidor puede (debería) protegerse más estrechamente.

Sin embargo, alguien debe poder administrar ese servidor, ¡solo para que el servidor pueda actualizarse!

Formas en que puede proteger adicionalmente los registros en ese servidor:

• Requieren múltiples administradores para cualquier acción (no trivial) (por ejemplo, los comandos introducidos requieren la confirmación de los administradores de N)
• Los registros se pueden almacenar vinculando a los anteriores en un árbol Merkle , por lo que la eliminación o modificación de una entrada afectará a los posteriores¹
• El hash del registro actual podría enviarse a una parte externa (obteniéndose de un servidor de sellado de tiempo, enviando una empresa asociada o simplemente enviándolo a una fuente de Twitter²).

¹ Al argumentar para usar esto, es posible que se venda mejor afirmando que usa tecnología de cadena de bloques .

² O si los registros en sí no son confidenciales, incluso podría enviar algunos eventos del servidor de registros en claro: "inicie sesión en el servidor de registros y ejecute rm -rf / "

Algunas formas posibles de proteger los registros del administrador:

• el registro remoto en una máquina que no está controlada por el administrador en cuestión
• escriba el registro en un medio de una sola escritura (por ejemplo, Bluray Recordable), tenga en cuenta que también puede necesitar una estrategia para evitar el llenado excesivo de los medios, como desconectar a todos los administradores si los registros están a punto de llenarse
• publica el hash de los registros en una cadena de bloques pública, esto detecta la manipulación, aunque no la destrucción del registro
• forzar el acceso a la máquina a través de un servidor mitm, los administradores solo pueden conectarse a la máquina administrada a través del servidor mitm, que registrará todas las entradas clave / mouse y la salida de pantalla / terminal (usando ssh mitm o vnc / rdp mitm)

Una solución es usar un diodo de datos para proteger el acceso al servidor centralizado del recolector de registros, al que solo se puede acceder físicamente, lo que es fácil de controlar. Además, se pueden crear cuentas de usuario individuales específicas para una mejor protección.

Filter auditd logs con rsyslog por uid tener un archivo por uid. Luego se puede aplicar SELinux para implementar cualquier política, especialmente para evitar que un administrador acceda a sus propios registros. La solución propuesta aquí evita requerir que un equipo independiente de administradores acceda a los registros en los servidores de registro cuando tenga una política restrictiva.

Como han dicho otros, los registros deben estar centralizados. Además, el acceso a estos servidores de registro centralizados se realizará solo con cuentas locales.