Reenviador de Chronicle para Windows en Docker

En este documento, se describe cómo instalar y configurar el servidor de reenvío de Chronicle para Windows en Docker.

Requisitos del sistema

Las siguientes son recomendaciones generales. Para obtener recomendaciones específicas para tu sistema, comunícate con el equipo de asistencia de Chronicle.

  • Versión de Windows Server: El servidor de reenvío de Chronicle es compatible con Microsoft Windows Server 2022.
  • RAM: 1.5 GB para cada tipo de registro recopilado. Por ejemplo, la detección y respuesta de extremos (EDR), DNS y DHCP son tipos de registro independientes. Se necesitarían 4.5 GB de RAM para recopilar datos de los tres. Para obtener una lista de los analizadores predeterminados y tipos de registros admitidos, consulta Analizadores predeterminados compatibles.
  • CPU: 2 CPU son suficientes para controlar menos de 10,000 eventos por segundo (EPS) en total en todos los tipos de datos. Si esperas enviar más de 10,000 EPS, se necesitan de 4 a 6 CPU.

  • Disco: 100 MB de espacio en disco son suficientes, sin importar la cantidad de datos que controle el servidor de reenvío de Chronicle. Puedes almacenar en búfer el disco si agregas los parámetros write_to_disk_buffer_enabled y write_to_disk_dir_path en el archivo de configuración.

    Por ejemplo:

    - <collector>:
     common:
         ...
         write_to_disk_buffer_enabled: true
         write_to_disk_dir_path: directory_path
         ...

Rangos de direcciones IP de Google

Es posible que necesites abrir el rango de direcciones IP cuando estableces una configuración del servidor de reenvío de Chronicle, como cuando estableces la configuración de tu firewall. Google no puede proporcionar una lista específica de direcciones IP. Sin embargo, puedes obtener rangos de direcciones IP de Google.

Verifica la configuración del firewall

Si tienes firewalls o proxies autenticados entre Internet y el contenedor de reenvío de Chronicle, estas requieren reglas para permitir el acceso a los siguientes hosts de Google Cloud:

Tipo de conexión Destino Puerto
TCP malachiteingestion-pa.googleapis.com 443
TCP asia-northeast1-malachiteingestion-pa.googleapis.com 443
TCP asia-south1-malachiteingestion-pa.googleapis.com 443
TCP asia-southeast1-malachiteingestion-pa.googleapis.com 443
TCP australia-southeast1-malachiteingestion-pa.googleapis.com 443
TCP europe-malachiteingestion-pa.googleapis.com 443
TCP europe-west2-malachiteingestion-pa.googleapis.com 443
TCP europe-west3-malachiteingestion-pa.googleapis.com 443
TCP europe-west6-malachiteingestion-pa.googleapis.com 443
TCP me-central2-malachiteingestion-pa.googleapis.com 443
TCP me-west1-malachiteingestion-pa.googleapis.com 443
TCP northamerica-northeast2-malachiteingestion-pa.googleapis.com 443
TCP accounts.google.com 443
TCP gcr.io 443
TCP oauth2.googleapis.com 443
TCP storage.googleapis.com 443

Para verificar la conectividad de red a Google Cloud, sigue estos pasos:

  1. Inicia Windows PowerShell con privilegios de administrador (haz clic en Iniciar, escribe PowerShell, haz clic con el botón derecho en Windows PowerShell y, luego, haz clic en Ejecutar como administrador).

  2. Ejecuta el siguiente comando.

    C:\> test-netconnection <host> -port <port>

    El comando muestra que TcpTestSucceeded es true.

    Por ejemplo:

    C:\> test-netconnection malachiteingestion-pa.googleapis.com -port 443
ComputerName     :  malachiteingestion-pa.googleapis.com
RemoteAddress    : 198.51.100.1
RemotePort       : 443
InterfaceAlias   : Ethernet
SourceAddress    : 203.0.113.1
TcpTestSucceeded : True

Instala Docker en Microsoft Windows

En esta sección, se describe cómo instalar Docker en Microsoft Windows mediante la interfaz de línea de comandos y PowerShell.

Ventajas del servidor de reenvío de Chronicle con un contenedor:

  • Mejor seguridad mediante el aislamiento:
    • El entorno y los requisitos del cliente no afectan al reenvío de Chronicle.
    • El entorno y los requisitos del reenviador de Chronicle no afectan al cliente.
    • El mecanismo de distribución de contenedores ya existe y puede ser privado y estar separado para Google Cloud y los clientes. Para obtener más información, consulta Artifact Registry.

Completa los siguientes pasos en Microsoft Windows Server Core 2022.

  1. Habilita la función de contenedor de Microsoft Windows.

    Install-WindowsFeature containers -Restart

  2. Ejecuta el siguiente comando en el modo de administrador de PowerShell para instalar Docker CE:

    Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/Windows-Containers/Main/helpful_tools/Install-DockerCE/install-docker-ce.ps1" -o install-docker-ce.ps1

.\install-docker-ce.ps1

  3. Prueba la interfaz de línea de comandos de Docker ejecutando el comando docker ps, que muestra una lista de los contenedores en ejecución. Si el comando no muestra ningún contenedor en ejecución, la instalación se realiza de forma correcta. Si Docker no está instalado correctamente, se muestra un error.

    Para obtener más información, consulta Primeros pasos: Prepara ventanas para contenedores.

    Para implementaciones empresariales, instala Mirantis Container Runtime, también conocido como Docker EE.

Configura el servidor de reenvío de Chronicle

Si deseas configurar el servidor de reenvío de Chronicle para Windows en Docker, consulta Administra la configuración del servidor de reenvío mediante la IU de Chronicle.

Cuando configures el servidor de reenvío de Chronicle, asegúrate de que todas las rutas de este comiencen con el prefijo “c:”.

El servidor de reenvío de Chronicle aplicará automáticamente los cambios que se realicen en el archivo de configuración en un plazo de 5 minutos.

Si deseas recopilar datos de paquetes mediante el servidor de reenvío de Chronicle para Windows en Docker, consulta la sección sobre cómo recopilar datos de paquetes.

Ejecuta el servidor de reenvío de Chronicle en el contenedor de Docker

  1. Si actualizas el servidor de reenvío de Chronicle, primero limpia las ejecuciones de Docker anteriores. En el siguiente ejemplo, el nombre del contenedor de Docker es cfps.

    docker stop cfps

docker rm cfps

  2. Obtén la imagen de Docker más reciente de Google Cloud con este comando de extracción de Docker.

    docker pull gcr.io/chronicle-container/cf_production_stable_windows

  3. Inicia el servidor de reenvío de Chronicle desde el contenedor de Docker.

    docker run `
--detach `
--name cfps `
--restart=always `
--log-opt max-size=100m `
--log-opt max-file=10 `
-p 10514:10514 `
-v C:\config\:C:/opt/chronicle/external `
gcr.io/chronicle-container/cf_production_stable_windows

    Puedes agregar varios puertos con varias opciones o varios rangos. Por ejemplo, -p 3001:3000 -p 2023:2022 o -p 7000-8000:7000-8000.

Ver registros de reenviadores

Para ver los registros del servidor de reenvío de Chronicle, ejecuta el siguiente comando:

  sudo docker logs cfps

Ejecuta el siguiente comando para ver la ruta de acceso del archivo en el que se almacenan los registros:

docker inspect --format='{{.LogPath}}' CONTAINER_NAME

Para ver los registros en ejecución, ejecuta el siguiente comando:

  sudo docker logs cfps -f

Para almacenar los registros en un archivo, ejecuta el siguiente comando:

  sudo docker logs cfps &> logs.txt

Desinstala el servidor de reenvío de Chronicle

Los siguientes comandos de Docker te permiten detener y desinstalar o quitar el servidor de reenvío de Chronicle.

Este comando detiene el contenedor de reenvío de Chronicle:

  docker stop cfps

Con este comando, se quita el contenedor de reenvío de Chronicle:

  docker rm cfps

Actualiza el agente de reenvío de Chronicle

El servidor de reenvío de Chronicle para Windows en Docker se actualiza de manera constante mediante una secuencia de comandos de shell en la imagen de Docker, por lo que no es necesario proporcionar ningún archivo ejecutable.

Recopilar información

En las siguientes secciones, podrás configurar el servidor de reenvío de Chronicle para transferir diferentes tipos de datos, que se reenvían a la instancia de Chronicle.

No configures un valor superior a 1 MB para batch_n_bytes. Si configuras un valor superior a 1 MB, se restablecerá automáticamente el valor a 1 MB.

Recopila datos de Splunk

Puedes configurar el servidor de reenvío de Chronicle para que reenvíe tus datos de Splunk a Chronicle. Google Cloud configura el servidor de reenvío de Chronicle con la siguiente información para reenviar tus datos desde Splunk:

  • Es la URL de la API de REST de Splunk (por ejemplo, https://10.0.113.15:8089).

  • Consultas de Splunk para generar datos para cada uno de los tipos de datos requeridos (por ejemplo, index=dns)

FORWARDER_NAME.conf
output:
collectors:
  - splunk:
      common:
        enabled: true
        data_type: WINDOWS_DNS
        data_hint: "#fields ts      uid     id.orig_h       id.orig_p       id.resp_h         id.resp_p       proto   trans_id        query   qclass  qclass_name"
        batch_n_seconds: 10
        batch_n_bytes: 819200
      url: https://127.0.0.1:8089
      is_ignore_cert: true
      minimum_window_size: 10s
      maximum_window_size: 30s
      query_string: search index=* sourcetype=dns
      query_mode: realtime
  • Haz que las credenciales de tu cuenta de Splunk estén disponibles para el reenvío de Chronicle. Puedes hacerlo creando un archivo creds.txt.

Para usar un archivo creds.txt, haz lo siguiente:

  1. Crea un archivo local para tus credenciales de Splunk y asígnale el nombre creds.txt.

  2. Coloca tu nombre de usuario en la primera línea y la contraseña en la segunda:

    cat creds.txt

myusername
mypassword

  3. Si deseas usar el servidor de reenvío de Chronicle para acceder a una instancia de Splunk, copia el archivo creds.txt en el directorio de configuración (el mismo en el que se encuentran los archivos de configuración). Por ejemplo:

    cp creds.txt c:/opt/chronicle/config/creds.txt

  4. Verifica que el archivo creds.txt esté en la ubicación correcta: 

    ls c:/opt/chronicle/config

Recopilar datos de syslog

El servidor de reenvío de Chronicle puede funcionar como un servidor syslog. Puedes configurar cualquier dispositivo o servidor que admita el envío de datos de syslog a través de una conexión TCP o UDP para reenviar sus datos al servidor de reenvío de Chronicle. Puedes controlar los datos exactos que el dispositivo o el servidor envían al servidor de reenvío de Chronicle. El servidor de reenvío de Chronicle puede reenviar los datos a Chronicle.

El archivo de configuración FORWARDER_NAME.conf (proporcionado por Google Cloud) especifica qué puertos supervisar para cada tipo de datos reenviados (por ejemplo, el puerto 10514). De forma predeterminada, el servidor de reenvío de Chronicle acepta conexiones TCP y UDP.

Configura rsyslog

A fin de configurar rsyslog, debes especificar un destino para cada puerto (por ejemplo, cada tipo de datos). Consulta la documentación de tu sistema para conocer la sintaxis correcta. En los siguientes ejemplos, se muestra la configuración de destino rsyslog:

  • Tráfico de registro de TCP: dns.* @@192.168.0.12:10514

  • Tráfico de registro de UDP: dns.* @192.168.0.12:10514

Habilitar TLS para los parámetros de configuración de syslog

Puedes habilitar TLS para la conexión de syslog al servidor de reenvío de Chronicle. En el archivo de configuración de reenvío de Chronicle (FORWARDER_NAME.conf), especifica la ubicación del certificado y la clave del certificado generados como se muestra en el siguiente ejemplo:

certificado c:/opt/chronicle/external/certs/client_generated_cert.pem
certificate_key c:/opt/chronicle/external/certs/client_generated_cert.key

Según el ejemplo que se muestra, modifica el archivo de configuración del servidor de reenvío de Chronicle (FORWARDER_NAME.conf) de la siguiente manera:

  collectors:
- syslog:
    common:
      enabled: true
      data_type: WINDOWS_DNS
      data_hint:
      batch_n_seconds: 10
      batch_n_bytes: 1048576
    tcp_address: 0.0.0.0:10515
    tcp_buffer_size: 65536
    connection_timeout_sec: 60
    certificate: "c:/opt/chronicle/external/certs/client_generated_cert.pem"
    certificate_key: "c:/opt/chronicle/external/certs/client_generated_cert.key"
    minimum_tls_version: "TLSv1_3"

Algunos puntos importantes para tener en cuenta:

  • Puedes configurar el tamaño del búfer de TCP. El tamaño predeterminado del búfer de TCP es de 64 KB.

  • El valor predeterminado y recomendado para connection_timeout es 60 segundos. Si la conexión está inactiva durante un tiempo específico, se finaliza la conexión TCP.

  • La versión mínima de TLS se compara con la versión de TLS de la solicitud de entrada. La versión de TLS de la solicitud de entrada debe ser superior a la versión mínima de TLS. La versión mínima de TLS debe ser uno de los siguientes valores: TLSv1_0, TLSv1_1, TLSv1_2 o TLSv1_3.

Puedes crear un directorio de certs en el directorio de configuración y almacenar los archivos de certificados allí.

Cómo recopilar datos de archivos

Un recopilador de archivos está diseñado para recuperar los registros de un archivo. El archivo debe estar vinculado al contenedor de Docker.

Úsalo si quieres subir registros de forma manual desde un solo archivo de registro. Esto se puede usar para reabastecer los registros de un archivo de registro en particular.

Inicia el servidor de reenvío de Chronicle desde el contenedor de Docker:

  docker run `
    --name cfps `
    --log-opt max-size=100m `
    --log-opt max-file=10 `
    -p 10514:10514 `
    -v c:/opt/chronicle/config:c:/opt/chronicle/external `
    -v c:/var/log/crowdstrike/falconhoseclient:c:/opt/chronicle/edr `
     gcr.io/chronicle-container/cf_production_stable

Puedes agregar varios puertos con varias opciones o varios rangos. Por ejemplo, -p 3001:3000 -p 2023:2022 o -p 7000-8000:7000-8000.

Este comando docker run es fundamental para asignar el volumen de carga al contenedor.

En función de este ejemplo, debes modificar la configuración del servidor de reenvío de Chronicle (archivo FORWARDER_NAME.conf) de la siguiente manera. El archivo sample.txt debe estar presente en la carpeta /var/log/crowdstrike/falconhostclient.

 collectors:
  - file:
       common:
         enabled: true
         data_type: CS_EDR
         data_hint:
         batch_n_seconds: 10
         batch_n_bytes: 1048576
       file_path: c:/opt/chronicle/edr/output/sample.txt
       filter:

Configuraciones de marcas

skip_seek_to_end (bool): Esta marca se establece en false de forma predeterminada y la entrada del archivo solo envía líneas de registro nuevas como entrada. Configurarlo como true hace que todas las líneas de registro anteriores se vuelvan a enviar durante los reinicios del servidor de reenvío. Esto genera una duplicación de registros. Establecer esta marca en true es útil en ciertas situaciones (por ejemplo, durante interrupciones), ya que reiniciar el reenviador vuelve a enviar las líneas de registro faltantes.

poll (bool): El recopilador de archivos usa la biblioteca Tail para verificar si hay cambios en el sistema de archivos. Si configuras esta marca como true, la biblioteca de la cola usa el método de sondeo en lugar del método de notificación predeterminado.

Cómo recopilar datos de paquetes

El servidor de reenvío de Chronicle puede capturar paquetes directamente desde una interfaz de red mediante Npcap en sistemas Windows.

Los paquetes se capturan y envían a Google Cloud en lugar de entradas de registro. La captura se realiza solo desde una interfaz local.

Comunícate con el equipo de asistencia de Chronicle para actualizar tu archivo de configuración de reenvío de Chronicle para admitir la captura de paquetes.

Para ejecutar un servidor de reenvío de captura de paquetes (PCAP), necesitas lo siguiente:

  • Instala Npcap en el host de Microsoft Windows.

  • Otorga privilegios de administrador o raíz al servidor de reenvío de Chronicle para supervisar la interfaz de red.

  • No se necesitan opciones de la línea de comandos.

  • En la instalación de Npcap, habilita el modo de compatibilidad de WinPcap.

Para configurar un servidor de reenvío PCAP, Google Cloud necesita el GUID de la interfaz que se usa para capturar paquetes. Ejecuta getmac.exe en la máquina en la que planeas instalar el servidor de reenvío de Chronicle (ya sea el servidor o la máquina que escucha en el puerto de intervalo) y envía el resultado a Chronicle.

Como alternativa, podrías modificar el archivo de configuración. Localiza la sección PCAP y reemplaza el valor del GUID que se muestra junto a la interfaz por el GUID que se muestra cuando se ejecuta getmac.exe.

Por ejemplo, esta es una sección de PCAP original:

- pcap:
      common:
        enabled: true
        data_type: PCAP_DNS
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      interface: \Device\NPF_{1A7E7C8B-DD7B-4E13-9637-0437AB1A12FE}
      bpf: udp port 53

Este es el resultado de la ejecución de getmac.exe:

C:\>getmac.exe
  Physical Address    Transport Name
  ===========================================================================
  A4-73-9F-ED-E1-82   \Device\Tcpip_{2E0E9440-ABFF-4E5B-B43C-E188FCAD1234}

Por último, aquí está la sección revisada de PCAP con el nuevo GUID:

- pcap:
      common:
        enabled: true
        data_type: PCAP_DNS
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      interface: \Device\NPF_{2E0E9440-ABFF-4E5B-B43C-E188FCAD9734}
      bpf: udp port 53

Recopilar datos del tema de Kafka

Puede transferir datos de los temas de Kafka al igual que desde syslog. Los grupos de consumidores se usan para permitirte implementar hasta tres servidores de reenvío de Chronicle y extraer datos del mismo tema de Kafka. Para obtener más información, consulta Kafka.

Para obtener más información sobre los grupos de consumidores de Kafka, consulta Grupos de consumidores de Kafka.

Configuración de ejemplo: entrada de Kafka

En la siguiente configuración del servidor de reenvío de Chronicle, se muestra cómo configurar este servicio para transferir datos de los temas de Kafka.

Archivo FORWARDER_NAME.conf

collectors:
- kafka:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      topic: example-topic
      group_id: chronicle-forwarder
      timeout: 60s
      brokers: ["broker-1:9092", "broker-2:9093"]
      tls:
        insecureSkipVerify: true
        certificate: "c:/path/to/cert.pem"
        certificate_key: "c:/path/to/cert.key"
- syslog:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: WINEVTLOG
        enabled: true
      tcp_address: 0.0.0.0:30001
      connection_timeout_sec: 60

Archivo FORWARDER_NAME_auth.conf

collectors:
- kafka:
      username: user
      password: password
- syslog:

Recopila datos de WebProxy

El servidor de reenvío de Chronicle puede capturar datos de WebProxy directamente desde una interfaz de red mediante Npcap y enviarlos a Google Cloud.

Para habilitar la captura de datos de WebProxy en tu sistema, comunícate con el equipo de asistencia de Chronicle.

Antes de ejecutar un servidor de reenvío de WebProxy, haz lo siguiente:

  1. Instala Npcap en el host de Microsoft Windows. Habilita el modo de compatibilidad de WinPcap durante la instalación.

  2. Otorga privilegios de administrador o raíz al servidor de reenvío de Chronicle para supervisar la interfaz de red.

  3. A fin de configurar un servidor de reenvío de WebProxy, Google Cloud necesita el GUID de la interfaz que se usa para capturar los paquetes de WebProxy.

    Ejecuta getmac.exe en la máquina en la que deseas instalar el servidor de reenvío de Chronicle y envía el resultado a Chronicle. También puedes modificar el archivo de configuración. Ubica la sección WebProxy y reemplaza el GUID que se muestra junto a la interfaz por el GUID que se muestra después de ejecutar getmac.exe.

    Modifica el archivo de configuración de reenvío de Chronicle (FORWARDER_NAME.conf) de la siguiente manera:

      - webproxy:
    common:
        enabled : true
        data_type: <Your LogType>
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      interface: \Device\NPF_{2E0E9440-ABFF-4E5B-B43C-E188FCAD9734}
      bpf: tcp and dst port 80

Personaliza los parámetros de configuración

En la siguiente tabla, se enumeran los parámetros importantes que se usan en el archivo de configuración de reenviadores.

Parámetro Descripción
data_type Es el tipo de datos de registro que el recopilador puede recopilar y procesar.
metadatos Metadatos, que anulan los metadatos globales.
max_file_buffer_bytes Cantidad máxima de bytes que se pueden acumular en el disco o el búfer de archivos. El valor predeterminado es 1073741824, que es 1 GB.
max_memory_buffer_bytes Cantidad máxima de bytes que se pueden acumular en el búfer de memoria. El valor predeterminado es 1073741824, que es 1 GB.
write_to_disk_dir_path La ruta de acceso que se usará para el archivo o el búfer de disco.
write_to_disk_buffer_enabled Si es true, se usa el búfer de disco en lugar del búfer de memoria. El valor predeterminado es false.
batch_n_bytes Cantidad máxima de bytes que puede acumular el colector después de la cual se agrupan los datos en lotes. El valor predeterminado es 1048576, que es 1 MB.
batch_n_seconds La cantidad de segundos después de los cuales se agrupan en lotes los datos que recopila el recopilador. El valor predeterminado es 11 segundos.
data_hint Formato de datos que el recopilador puede recibir (por lo general, el encabezado del archivo de registro que describe el formato).

Para obtener una lista extensa de los parámetros que se usan en el archivo de configuración, consulta Campos de configuración del reenvío y Campos de configuración del colector.

Activar o desactivar la compresión de datos

La compresión de registros reduce el consumo de ancho de banda de red cuando se transfieren registros a Chronicle. Sin embargo, la compresión puede causar un aumento en el uso de la CPU. La compensación entre el uso de CPU y el ancho de banda depende de muchos factores, incluidos el tipo de datos de registro, la compresibilidad de esos datos, la disponibilidad de ciclos de CPU en el host que ejecuta el servidor de reenvío de Chronicle y la necesidad de reducir el consumo de ancho de banda de red.

Por ejemplo, los registros basados en texto se comprimen bien y pueden proporcionar ahorros de ancho de banda considerables con un uso bajo de CPU. Sin embargo, las cargas útiles encriptadas de paquetes sin procesar no se comprimen bien y generan un mayor uso de CPU.

De forma predeterminada, la compresión de registros está inhabilitada. Si habilitas la compresión de registros, es posible que se reduzca el consumo del ancho de banda. Sin embargo, habilitar la compresión de registros también puede aumentar el uso de CPU. Ten en cuenta el equilibrio.

Para habilitar la compresión de registros, establece el campo compression como true en el archivo de configuración de reenvío de Chronicle, como se muestra en el siguiente ejemplo:

Archivo FORWARDER_NAME.conf

output:
  compression: true
    url: malachiteingestion-pa.googleapis.com:443
    identity:
      identity:
      collector_id: 10479925-878c-11e7-9421-10604b7cb5c1
      customer_id: ebdc4bb9-878b-11e7-8455-10604b7cb5c1
...

El archivo FORWARDER_NAME_auth.conf

output:
  identity:
    secret_key: |
    {
     "type": "service_account",
...
    }

Configura el almacenamiento en búfer del disco

El almacenamiento en búfer en el disco te permite almacenar en búfer los mensajes pendientes en el disco, en lugar de hacerlo en la memoria. Los mensajes pendientes se pueden almacenar en caso de que falle el servidor de reenvío de Chronicle o el host subyacente. Ten en cuenta que habilitar el almacenamiento en búfer en el disco puede afectar el rendimiento.

Si el almacenamiento en búfer en el disco está inhabilitado, el servidor de reenvío de Chronicle usa 1 GB de memoria (RAM) para cada tipo de registro (por ejemplo, para cada conector). Especifica el parámetro de configuración max_memory_buffer_bytes. La memoria máxima permitida es de 4 GB.

Puedes configurar el almacenamiento en búfer de disco automático para usar un búfer compartido de forma dinámica entre los colectores, que se ocupa mejor de los aumentos repentinos de tráfico. Para habilitar el búfer compartido de forma dinámica, agrega lo siguiente a tu configuración del servidor de reenvío:

auto_buffer:
  enabled: true
  target_memory_utilization: 80

Si el almacenamiento en búfer de disco automático está habilitado, pero no se define target_memory_utilization, usa un valor predeterminado de 70.

Si ejecutas el servidor de reenvío de Chronicle mediante Docker, Google recomienda activar un volumen independiente del volumen de configuración para fines de aislamiento. Además, cada entrada debe aislarse con su propio directorio o volumen para evitar conflictos.

Configuración de ejemplo: almacenamiento en búfer en el disco

La siguiente configuración incluye sintaxis para habilitar el almacenamiento en búfer en el disco:

collectors:
- syslog:
    common:
      write_to_disk_buffer_enabled: true
      # c:/buffers/NIX_SYSTEM is part of the external mounted volume for the
forwarder
      write_to_disk_dir_path: c:/buffers/NIX_SYSTEM
      max_file_buffer_bytes: 1073741824
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

Configura filtros de expresiones regulares

Los filtros de expresiones regulares te permiten filtrar registros según las coincidencias de expresiones regulares con los registros sin procesar.

Los filtros emplean la syntax RE2.

Los filtros deben incluir una expresión regular y, de forma opcional, definir un comportamiento cuando haya una coincidencia. El comportamiento predeterminado en una coincidencia es el bloqueo (también puedes configurarlo de forma explícita como bloque).

Como alternativa, puedes especificar filtros con el comportamiento allow. Si especificas filtros allow, el servidor de reenvío de Chronicle bloqueará cualquier registro que no coincida con al menos un filtro de allow.

Es posible definir un número arbitrario de filtros. Los filtros de bloqueo tienen prioridad sobre los filtros allow.

Cuando se definen los filtros, se les debe asignar un nombre. Los nombres de los filtros activos se informarán a Chronicle mediante las métricas de estado de Forwarder. Los filtros definidos en la raíz de la configuración se combinan con los filtros definidos a nivel del colector. Los filtros de nivel de recopilador tienen prioridad en casos de nombres en conflicto. Si no se definen filtros a nivel de raíz o de colector, el comportamiento es permitir todos.

Configuración de ejemplo: filtros de expresiones regulares

En la siguiente configuración del servidor de reenvío de Chronicle, se bloquean los registros WINEVTLOG que no coinciden con el filtro raíz (allow_filter). Dada la expresión regular, el filtro solo permite registros con prioridades entre 0 y 99. Sin embargo, se bloquea cualquier registro de NIX_SYSTEM que contenga “foo” o “bar”, a pesar de allow_filter. Esto se debe a que los filtros usan un OR lógico. Todos los registros se procesan hasta que se activa un filtro.

regex_filters:
  allow_filter:
    regexp: ^<[1-9][0-9]?$>.*$
    behavior_on_match: allow
collectors:
- syslog:
    common:
      regex_filters:
        block_filter_1:
          regexp: ^.*foo.*$
          behavior_on_match: block
        block_filter_2:
          regexp: ^.*bar.*$
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

Configurar etiquetas arbitrarias

Las etiquetas se usan para adjuntar metadatos arbitrarios a los registros con pares clave-valor. Las etiquetas se pueden configurar para todo un servidor de reenvío de Chronicle o dentro de un recopilador específico de un servidor de reenvío de Chronicle. Si se proporcionan ambas, las etiquetas se combinarán con las claves del recopilador con prioridad sobre las claves del servidor de reenvío de Chronicle si las claves se superponen.

Configuración de ejemplo: etiquetas arbitrarias

En la siguiente configuración del servidor de reenvío de Chronicle, los pares clave-valor foo=bar y meow=mix se adjuntan a los registros WINEVTLOG, y los pares clave-valor foo=baz y meow=mix se adjuntan a los registros NIX_SYSTEM.

metadata:
  labels:
    foo: bar
    meow: mix
collectors:
syslog:
    common:
      metadata:
        labels:
          foo: baz
          meow: mix
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

Configurar espacios de nombres

Usa etiquetas de espacio de nombres para identificar los registros de distintos segmentos de red y eliminar los conflictos de las direcciones IP que se superponen. Puedes configurar una etiqueta de espacio de nombres para todo el servidor de reenvío de Chronicle o dentro de un recopilador específico del servidor de reenvío de Chronicle. Si se incluyen ambos, tiene prioridad el espacio de nombres del recopilador específico.

Cualquier espacio de nombres configurado para el reenviador de Chronicle aparecerá con los elementos asociados en la interfaz de usuario de Chronicle. También puedes buscar espacios de nombres con la función Chronicle Search.

Si necesitas información para ver los espacios de nombres en la interfaz de usuario de Chronicle, consulta este vínculo.

Configuración de ejemplo: espacios de nombres

En la siguiente configuración del servidor de reenvío de Chronicle, los registros WINEVTLOG se adjuntan al espacio de nombres FORWARDER y los registros de NIX_SYSTEM al espacio de nombres CORPORATE.

metadata:
  namespace: FORWARDER
collectors:
- syslog:
      common:
        metadata:
          namespace: CORPORATE
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      tcp_address: 0.0.0.0:30000
      connection_timeout_sec: 60
- syslog:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: WINEVTLOG
        enabled: true
      tcp_address: 0.0.0.0:30001
      connection_timeout_sec: 60

Configura el balanceo de cargas y las opciones de alta disponibilidad

El servidor de reenvío de Chronicle para Windows en Docker se puede implementar en un entorno en el que se instala un balanceador de cargas de capa 4 entre la fuente de datos y las instancias del servidor de reenvío de Chronicle. Esto te permite distribuir la colección de registros entre varios servidores de reenvío de Chronicle o enviar registros a otro servidor de reenvío de Chronicle si uno de ellos falla. Esta función solo es compatible con el tipo de colección syslog.

El servidor de reenvío de Chronicle para Windows en Docker incluye un servidor HTTP integrado que responde a las verificaciones de estado HTTP del balanceador de cargas. El servidor HTTP también ayuda a garantizar que no se pierdan los registros durante el inicio o el cierre de un servidor de reenvío de Chronicle.

Configura el servidor HTTP, el balanceo de cargas y las opciones de alta disponibilidad en la sección server del archivo de configuración del servidor de reenvío de Chronicle. Estas opciones admiten la configuración de las duraciones de los tiempos de espera y los códigos de estado que se muestran en respuesta a las verificaciones de estado recibidas en el programador de contenedores y las implementaciones basadas en organización, así como de los balanceadores de cargas convencionales.

Usa las siguientes rutas de URL para las verificaciones de estado, preparación y funcionamiento. Los valores de <host:port> se definen en la configuración del servidor de reenvío de Chronicle.

  • http://<host:port>/meta/available: Verificaciones de funcionamiento para organizadores o programadores de contenedores, como Kubernetes.
  • http://<host:port>/meta/ready: Verificaciones de preparación y verificaciones de estado tradicionales del balanceador de cargas.

La siguiente configuración del servidor de reenvío de Chronicle es un ejemplo del balanceo de cargas y la alta disponibilidad:

collectors:
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60
server:
  graceful_timeout: 15s
  drain_timeout: 10s
  http:
    port: 8080
    host: 0.0.0.0
    read_timeout: 3s
    read_header_timeout: 3s
    write_timeout: 3s
    idle_timeout: 3s
    routes:
    - meta:
        available_status: 204
        ready_status: 204
        unready_status: 503
Ruta de configuración Descripción
servidor : Graceful_timeout La cantidad de tiempo que el servidor de reenvío de Chronicle muestra una verificación de estado o preparación incorrecta y aún acepta conexiones nuevas. Este también es el tiempo de espera entre el momento en que se recibe la señal y el inicio del cierre del servidor. Esto permite que el balanceador de cargas tenga tiempo de quitar el servidor de reenvío de Chronicle del grupo.
servidor : Flood_timeout Es la cantidad de tiempo que el servidor de reenvío de Chronicle espera a que las conexiones activas se cierren de forma correcta por su cuenta antes de que el servidor las cierre.
servidor : http : puerto El número de puerto en el que el servidor HTTP escucha para las verificaciones de estado del balanceador de cargas. Debe ser un número entre 1024 y 65535.
servidor : http : host La dirección IP, o el nombre de host que se puede resolver en direcciones IP, que el servidor debe escuchar. Si está vacío, el valor predeterminado es el sistema local (0.0.0.0).
servidor : http : read_timeout Se usa para ajustar el servidor HTTP. Por lo general, no es necesario cambiarla de la configuración predeterminada. El tiempo máximo permitido para leer la solicitud completa, tanto en el encabezado como en el cuerpo. Puedes establecer read_timeout y read_header_timeout.
servidor : http : read_header_timeout Se usa para ajustar el servidor HTTP. Por lo general, no es necesario cambiarla de la configuración predeterminada. La cantidad máxima de tiempo permitida para leer los encabezados de la solicitud. La fecha límite de lectura de la conexión se restablece después de leer el encabezado.
servidor : http : write_timeout Se usa para ajustar el servidor HTTP. Por lo general, no es necesario cambiarla de la configuración predeterminada. El tiempo máximo permitido para enviar una respuesta. Se restablece cuando se lee un encabezado de la solicitud nuevo.
servidor : http : inactive_timeout Se usa para ajustar el servidor HTTP. Por lo general, no es necesario cambiarla de la configuración predeterminada. La cantidad máxima de tiempo que se debe esperar a la próxima solicitud cuando las conexiones inactivas están habilitadas. Si incremental_timeout es cero, se usa el valor de read_timeout. Si ambos son cero, se usa el read_header_timeout.
rutas : meta : ready_status El código de estado que muestra el servidor de reenvío de Chronicle cuando está listo para aceptar el tráfico en cualquiera de las siguientes situaciones:
  • La verificación de preparación se recibe desde un organizador o programador de contenedores, como Kubernetes.
  • La verificación de estado se recibe desde un balanceador de cargas tradicional.
rutas : meta : unready_status El código de estado que muestra el servidor de reenvío de Chronicle cuando no está listo para aceptar tráfico.
rutas : meta : available_status Es el código de estado que muestra el servidor de reenvío de Chronicle cuando se recibe una verificación de funcionamiento y está disponible. Los programadores y organizadores de contenedores, como Kubernetes, suelen enviar verificaciones de actividad.