Aspectos esenciales de la recolección centralizada de log con WEF WEC

La semana pasada cubrimos lo esencial del registro de eventos: asegurando que todos tus sistemas escriban registros sobre los eventos o actividades importantes que ocurren en ellos. Esta semana cubriremos lo esencial para recopilar de forma centralizada estos registros de eventos en un servidor colector de eventos de Windows (WEC), que luego reenvía todos los logs a Elastic Security.

WEF y WEC

Las versiones modernas de Windows incluyen los servicios de administración remota de Windows (WinRM), que implementan el protocolo WS-Management (WSman). Para complicar aún más la terminología, todo esto forma parte de la instrumentación de administración de Windows (WMI). Un componente de WinRM es el servicio de reenvío de eventos de Windows (WEF), por lo que es necesario habilitar WinRM y compañía. WEF puede reenviar los registros de eventos de Windows a un servidor Windows que ejecute el servicio recopilador de eventos de Windows (WEC).

Existen dos modos de reenvío:

1. Iniciado desde el origen: El servicio WEF se conecta al servidor WEC.
2. Iniciado por el recolector: El servicio WEC se conecta al servicio WEF.

Ambos emplean WSman para reenviar los registros y requieren que WinRM esté en ejecución.

Hay varios obstáculos y dificultades al establecer el WEF y el WEC. Siguiendo nuestro libro de recetas de WEC, puedes evitar estos. Sin embargo, para una visión de mayor nivel y un contexto más rico, los discutiremos aquí, así como la solución tomada en el libro de recetas.

Archivo de registro de eventos “Reenviados”

En el sistema de registro de eventos de Windows hay canales. En última instancia, estos canales están respaldados por un archivo de registro de eventos que almacena todos los registros de eventos escritos en ese canal. Un sistema Windows viene con un conjunto de canales predefinidos y las aplicaciones pueden agregar sus propios canales registrando nuevos “Proveedores”.

Esto significa que, de manera inmediata, un servidor WEC solo tiene los canales que un servidor Windows normal tiene de todos modos para sus propios logs. Entonces, ¿dónde debería uno almacenar todos los logs que se están retransmitiendo al servidor WEC? Hay tres opciones; vamos a verlas:

1. Almacenar en el canal local que coincida con el canal remoto (es decir, los eventos del canal de “Security” remoto se almacenan en el canal local de “Security” del WEC)

.

Errores:

• Todos tus logs remotos se mezclan con tus logs locales 
• El servidor WEC puede hacer un bucle de sus propios logs de eventos a este log de canal 
• y el control de acceso se hacen muy difíciles

2. Almacena todos los logs remotos en el canal local “Eventos reenviados”.

Escollos:

• Rendimiento de escritura deficiente, ya que todas las escrituras se realizan en un solo archivo.
• Rendimiento deficiente en búsquedas y lecturas, ya que los eventos no se dividen en archivos separados.
• Gestión deficiente del ciclo de vida de los datos, ya que esto es por archivo de log, por lo tanto todos los eventos reenviados se tratan por igual.
• Escaso aprovechamiento de los recursos del servidor WEC, ya que todo el trabajo se concentra en un único archivo.
• Una mala gestión de accesos, la separación de archivos permitiría controles de acceso diferenciados.
• Cobertura/visibilidad deficiente: debido a los problemas anteriores, muchos restringen en gran medida los registros de eventos que se reenvían, lo que deja lagunas en su visibilidad.

3. Crea nuevos canales para el servidor WEC. 

Esto no es tan obvio como podría parecer, y se podría perdonar a la mayoría por desconocer que era una opción. 

Muchos servidores WEC se configuraron con las opciones 1 o 2 (arriba), hasta que el propio equipo interno de Security de Microsoft escribió una publicación de blog (hace unos 15 años) explicando cómo emplearon el SDK de Windows para implementar la opción 3. Aquí hay una revisión similar publicada en 2016.

Nuevos canales de eventos WEC

Armados con la capacidad de crear canales de eventos arbitrarios, ¿qué debemos crear? ¿Cómo deberíamos organizar y diseñar nuestro servidor WEC? Hay muchas escuelas de pensamiento: el libro de cocina WEC agrupa los activos de la empresa para que pueda administrar el control de acceso y el ciclo de vida de los datos de su log

en consecuencia.

Antes de profundizar, veamos otro enfoque. Algunos de ustedes quizás vieron la arquitectura y las directrices de WEC de Palantir. En ellas, crearon un canal por cada tipo de registro de eventos: PowerShell, WMI, DNS, Firewall, etc. Estos canales contienen registros de todos los tipos de activos (controladores de dominio, servidor de dominio, estación de trabajo de dominio) y departamentos/unidades de negocio/OU. Tampoco están organizados en una jerarquía, por lo que serían solo una larga lista en el Visor de eventos. Por lo tanto, los canales también tienen sus suscripciones de WEC. Palantir también tiene una política de auditoría recomendada. 

Me gusta señalar otros enfoques, como este de Palantir, ya que no hay una solución única para todos y su enfoque podría adaptar mejor a tu organización que el que expone nuestro Cookbook.

Si consultaste la lista de canales de Palantir, notaste su formato “WEC#-Algo”, donde el número '#' aumenta cada siete canales. Esto se debe a que, en el sistema de registro de eventos de Windows log, los canales se definen mediante lo que se conoce como un “proveedor” y solo pueden definir hasta ocho canales.

Sin embargo, un error puntual en la herramienta "ecmangen", que todos los que trabajábamos en seguridad sin ser desarrolladores del SDK de Windows, empleábamos, hacía frustrante tener más de siete canales por proveedor.

En lugar de corregir los muchos bugs, parece que Microsoft eliminó ecmangen del SDK de Windows. Es decir, o bien usas un SDK antiguo o creas tú mismo el archivo XML de manifiestos — quizá con tu editor XML favorito.

Como todo el mundo, usé ecmangen (originalmente) y me quedé con siete canales para facilitarme la vida. El Cookbook actual se basa en scripts de PowerShell que generan el XML. Ecmangen ya no es necesario, así que puedes tener ocho canales si quieres, aunque el Cookbook sigue usando solo siete canales recomendados.

Nota: piensa en un proveedor como una caja de ocho canales, donde cada canal es, en última instancia, un archivo de registro separado.

Organiza por activo

Aprovechando el hecho de que puedes tener tantos Proveedores como quieras, podemos usar esto para organizar por activo. En tu entorno AD, probablemente ya hayas agrupado a los miembros del dominio por tipo de activo (por ejemplo, servidores de dominio, controladores de dominio, estaciones de trabajo, etc.) y/o por el departamento (me atrevo a decir unidad organizativa) en el que se encuentran esos activos

.

Así que en el Cookbook puedes crear fácilmente proveedores que se ajusten a la organización de tu AD, en términos de proveedores por departamento (unidad de negocio o OU) y/o por tipo de activo y/o por criticidad de activo (laboratorio/prueba/producción).

Cuando se separa por tipo de activo, obtienes el beneficio adicional de poder administrar mejor el control de acceso y el ciclo de vida del log. Si necesitas mirar los logs de un tipo de activo específico, sabes dónde están.

Para simplificar las cosas, todos los proveedores obtienen el mismo conjunto de (hasta ocho canales). Luego, los sistemas se asignan a un proveedor (a través de OU) y los registros de eventos en ese sistema se asignan a canales en ese proveedor

.

De forma predeterminada, el script “wec_config.ps1”, que se emplea para configurar el servidor WEC de modo que coincida con la arquitectura de su Active Directory, tiene definidos algunos proveedores y asignaciones de activos:

• Controladores de dominio: creo que la asignación de miembros está clara aquí.
• Servidores de dominio: Los servidores de su dominio.
• Clientes de dominio: Estaciones de trabajo de usuario (computadoras de escritorio/portátiles)
• Sistemas con privilegios de dominio: Sistemas con mayores privilegios (por ejemplo, servidores Jumphost o WEC).
• Miembros del dominio: Engloba a todos los miembros normales del dominio; no pertenecen a los demás grupos.
• Dominio Varios: Varios, para aquellos hosts que no encajan

Te recomendamos que refines y edites la lista para adaptarla a tu entorno de Active Directory.

Entonces, la lista de canales lista para usar es:

• Aplicación: "Aplicación" y registros similares
• Seguridad: "Seguridad" y registros similares
• Sysmon: "Microsoft-Windows-Sysmon/Operational"
• Sistema: "System", "HardwareEvents", DNS-Client, DHCP-Client, "Setup" y registros similares
• Script: "Windows PowerShell" y registros similares
• Servicio: DNS-Server, DHCP-Server y otros registros de servicio
• Misceláneos: Otros registros misceláneos

De nuevo, eres libre de cambiar esto según tus necesidades.

Suscripciones WEC

Una suscripción a WEC define lo siguiente:

• Un filtro de registro de eventos (XPath) que selecciona qué eventos deben reenviar.
• Un canal de destino que indica dónde almacenar los eventos recibidos en el servidor WEC.
• Tipo:
  • Iniciado por el recolector, el WEC se conecta al servicio WEF.
    • Computadoras de destino, una lista de computadoras a las que conectarse
  • Iniciado por el origen, el WEF se conecta al servidor WEC.
    • Grupos informáticos, los grupos de AD cuyos miembros (informáticos) pueden acceder a esta suscripción.
• Opciones de entrega de eventos para controlar el ancho de banda/latencia y/o HTTP/HTTPS.
• Tipo de formato: RenderedText o simplemente el XML del evento.

Los scripts del libro de recetas (en individua setup_subscriptions.ps1) configuran el formato XML de eventos. Estos son mucho más pequeños, lo que se traduce en mayor rendimiento, más logs almacenados, menor carga y menor consumo de ancho de banda. Sin embargo, la desventaja es que si el proveedor de origen (en el sistema remoto) no está registrado localmente en el sistema de log de eventos del servidor WEC, el visor de eventos no podrá mostrar una descripción textual del mensaje en su idioma. No obstante, el envío de eventos de texto renderizado consume tantos recursos que resulta difícil justificarlo.

Al principio mencioné que WEF es una función de WinRM. Este componente de WinRM se ejecuta como el usuario "Servicio de red" del sistema local. Esto significa que WEF no puede leer la mayoría de los logs del sistema, y el servidor WEC recibirá un mensaje genérico con el ID de evento 111, sin ningún otro log. Por este motivo, la guía le explica cómo crear una GPO para agregar "Servicio de red" al grupo local "Lectores de logs de eventos".

¿Cómo consigue WinRM la configuración para WEF? En la misma GPO mencionada anteriormente, también publicamos una URL de WSman que lista todas las suscripciones WEC en ese servidor. De hecho, podemos listar múltiples URLs de suscripciones WSman de varios servidores WEC, y el servicio WEF intentará obtenerlas y ejecutarlas todas, permitiendo así servidores WEC redundantes.

¿Todas las suscripciones? ¡No quiero que mi estación de trabajo envíe los registros de eventos a mis archivos de registro del Controlador de Dominio! Las entradas de WSman que representan una suscripción tienen permisos de grupo AD aplicados, tal y como se configura en la configuración de suscripción. Esto significa que si la computadora en la que se ejecuta WEF no es miembro de un grupo AD que tenga permiso para leer la suscripción, no puede obtener ni ejecutar la suscripción. También significa que si no tienes cuidado y una computadora es miembro de más de un grupo de suscripción de WEC, recibirás múltiples registros de eventos iguales de ese anfitrión WEF en tu WEC.

¿Grupos de computadoras? ¡Pero quiero mapear las computadoras basándome en la OU en la que están colocadas! Desafortunadamente, así no funcionan WEF/WEC/WinRM/WSman. Sin embargo, el Cookbook proporciona un mecanismo para mantener la membresía de un grupo dado sincronizada con las ubicaciones específicas de la OU. ¡Así puedes fingir que todo se hace a través de OU!

Reuniéndolo todo

Hay mucha complejidad y elementos en movimiento que acertar al configurar WEF y WEC para buena observabilidad o casos de uso de seguridad.

Sin embargo, no temas, porque nuestro Cookbook está aquí, acompañado de un conjunto de scripts de Powershell para automatizar la mayoría de los pasos. Esto significa que hay menos margen para errores, las acciones son reproducibles, y por tanto los errores son más fáciles de corregir.

Todo comienza con el script wec_config.ps1, que puedes editar a tu gusto. Todos los scripts siguientes se basarán en él. Por lo tanto, puedes, por ejemplo, cambiar fácilmente el filtro del registro de eventos que se usa para seleccionar qué registros de eventos se reenvían en wec_config.ps1 y luego volver a ejecutar setup_subscriptions.ps1 para aplicar el cambio.

Veamos qué hacen los guiones (el Cookbook entra en mucho más detalle sobre cómo usarlos):

• wec_config.ps1 - La configuración de tu servidor WEC, basada en los otros scripts
• gen_manifest.ps1 - Esto creará el XML del manifiesto que describe todos tus proveedores y sus canales para el SDK de Windows (¡ya no es necesario usar ecmangen!).
• build_man2dll.ps1 - Al tomar tu manifiesto, esto construirá la DLL del Módulo de Subsistema de Eventos de Windows que implementa todos tus nuevos proveedores y canales en cualquier sistema que instales (normalmente el servidor WEC)
• install_channels.ps1 - Toma la DLL y el manifiesto e instala en el sistema local
• configure_channels.ps1 - Aplicará la configuración de Ruta de Log y Tamaño de Log (de wec_config.ps1) a todos tus canales recién instalados
• setup_subscriptions.ps1 - Configurará (creará o reconfigurará) todas las suscripciones para tu proveedor/canales en el servidor WEC
• map_ou2group.ps1 - Probablemente quieras usar las OUs de tu AD, pero las suscripciones WEC seleccionan computadoras a través de AD Groups. Este script sincronizará la pertenencia de grupos dados con las computadoras bajo OUs especificadas, usando nuevamente la configuración en wec_config.ps1
• gen_winlogbeat_config.ps1 - La configuración que se envía con Winlogbeat no conocerá todos tus canales extra de suscripción WEC, así que esto actualizará esa configuración por ti
• beat_cmd.ps1 - Un script de ayuda para interactuar con comandos Beat en PowerShell

Desafortunadamente, toda la configuración en el lado de AD, como las Políticas de Grupo, aún tiene que hacer manualmente — pero el Cookbook incluye guías paso a paso con capturas de pantalla. Puede que algún día escriba guiones para eso también, estén atentos.

Finalmente, Winlogbeat debe configurar para enviar todos los logs WEC a Elastic Security. El libro de cocina también te guiará en esto.

Conclusión

Espero que, tras leer esta publicación de blog, y posiblemente el propio Cookbook, tengas una buena idea de las decisiones que necesitas tomar antes de empezar, además de contar con toda la orientación y las herramientas necesarias para crear ese servidor WEC perfecto para tu compañía.

Ahora que tienes las políticas de auditoría adecuadas, configurado el WEF y un servidor WEC configurado para reenviar los registros de eventos de tu dominio AD a Elastic Security, en nuestra próxima publicación de blog veremos qué puedes hacer con estos datos de log extremadamente importantes y útiles en Elastic Security.

Si eres nuevo en Elastic Security, puedes probar nuestra última versión de Elasticsearch Service en Elastic Cloud. Además, cerciórate de aprovechar nuestro entrenamiento Quick Start para prepararte para el éxito.

Consulta otras guías de libros de cocina que escribí: https://ela.st/tjs-cookbook-lib