Tengo curiosidad por saber qué tan seguro es el registro de eventos de Windows y exactamente qué medidas de seguridad utiliza.
¿Incluye alguna defensa contra la manipulación indebida? Por ejemplo, ¿utiliza firmas digitales o cadenas de hash?
Si bien las ACL son la principal forma de asegurar el registro de eventos, implementa algunas otras características de seguridad.
Cuando el registro de eventos se borra del visor de eventos, se agrega un nuevo evento que contiene el nombre de usuario del usuario que lo borró.
Windowstambiénmantieneabiertoslosarchivosderegistrodeeventosmientraselsistemaoperativoseestáejecutando,bloqueandolosarchivosdetalmaneraquesolosepuedenescribirenelprocesoderegistrodeeventos
Es sensato enviar sus registros a un servidor remoto y reforzado. Una serie de herramientas gratuitas, como Snare , admiten el reenvío de registros de Windows a un servidor de syslog. La mayoría de las herramientas SIM / SIEM también lo admiten, ya sea mediante el uso de agentes instalados localmente para enviar los registros al servidor remoto, o mediante el servidor remoto que extrae los registros de los sistemas de origen a través de WMI (de manera menos escalable). También puede usar el Recopilador de eventos de Windows .
El registro de eventos de Windows es tan seguro como el sistema en el que se está ejecutando. Porque las cuentas en el sistema leen, escriben y modifican los eventos , cualquier persona que comprometa la máquina, o cualquier persona con privilegios de administrador, puede modificar los eventos. Técnicamente, solo se supone que LSASS puede escribir, pero la historia puede decirle cómo Sasser y otros gusanos hicieron que esto fuera inútil.
Personalmente, la única defensa posible que puedo pensar contra la manipulación sería utilizar el registro remoto, por ejemplo. eventlog-to-syslog . Esto permite que CUALQUIER y TODAS las entradas se almacenen de forma remota. El único método que alguien puede usar para evitar cualquier cosa sería DESPUÉS del hecho. Lo que significa que SIEMPRE sería la instancia inicial de un registro que nunca se puede cambiar. Si un administrador DID de un atacante comienza a manipular los registros, deberá realizar una programación de alto rendimiento para interceptar las llamadas del sistema antes de que se escriba (a través de LSASS) para ocultar sus pistas.
Aun así (logrando manipular los registros), el único mecanismo que tendrían (el (los) atacante (s)) podría hacer, regresar y ocultar / modificar sus entradas, sería comprometer también el servidor syslog.
EDITADO a las 3:42 PM EST para mayor claridad en mi respuesta inicial ...
Desde el inicio, debe observar cómo Windows está almacenando cualquier cosa con respecto a EventLog. Se realiza en las capas de aplicación, sesión, presentación, transporte. Todo esto se hace en la propia máquina. Cada instancia individual se escribe localmente. Este es el período problemático. Para CUALQUIERA que tenga acceso a la lectura, escritura, apertura, tendría la capacidad (no la habilidad a menos que sea un administrador) para leer y escribir archivos.
Piensa en eso por un momento. Si estoy en una máquina con estos privilegios, hay poco que me impida modificar. Incluso si intentaste registrar lo que estoy haciendo, puedo modificar estos registros. De hecho, timestomp (programa de lucha contra la ofensiva) hace precisamente eso para los tiempos de MACE. El ÚNICO mecanismo para prohibir esto, sería enviar los registros fuera de la máquina. No conozco ningún mecanismo que impida que alguien local en la máquina obtenga la HABILIDAD para modificar los datos del registro de eventos. Esto se debe a que las lecturas y las escrituras se realizan en la propia máquina. Existe la posibilidad de que a) una actualización puede romper cosas b) un usuario con privilegios escalados puede eliminar y / o modificar los datos.
El registro remoto tiene más sentido porque los registros (eventos) no se almacenan, se escriben, se modifican localmente. Alguien tendría que entrar en la máquina de registro para manipular (modificar, borrar) las entradas. El único otro mecanismo (suma de comprobación local, etc.) se ALWAYS será superado porque siempre debe haber un superusuario (administrador, raíz, etc.). Los autores de malware, los creadores de virus y los atacantes maliciosos tienden a modificar las entradas de eventos la mayoría de las veces. Esto debería ser evidente que no se puede hacer mucho a nivel local.
En cuanto a "prueba de manipulación indebida", Gestionar reclamaciones del motor puede hacer esto Sin embargo, lo están haciendo de forma remota.