Gestionar manualmente el archivo de configuración del reenviador

Disponible en:

En esta página se describe cómo crear y modificar manualmente un archivo de configuración de reenviador de Google Security Operations. Para configurar el reenviador a través de la interfaz de usuario (opción recomendada), consulta Gestionar configuraciones de reenviador a través de la interfaz de usuario de Google SecOps.

Cada reenviador de Google SecOps implementado requiere un archivo de configuración del reenviador. Un archivo de configuración de reenvío especifica los ajustes para transferir los datos a tu instancia de Google SecOps.

Para obtener información sobre cómo instalar y configurar el reenviador de Google SecOps, los requisitos del sistema y los detalles sobre los ajustes de configuración, consulta Instalar y configurar el reenviador.

Antes de empezar

Antes de crear el archivo de configuración, planifica la implementación. Para ello, debes conocer los tipos de datos que se pueden ingerir y los atributos clave que debes definir en el archivo de configuración.

Crea el archivo de configuración

Para crear el archivo de configuración manualmente, sigue estos pasos:

  1. Descarga los archivos de configuración a través de la interfaz de usuario.

  2. Guarda los dos archivos en el mismo directorio con la siguiente convención de nomenclatura:

    FORWARDER_NAME.conf: usa este archivo para definir los ajustes de configuración relacionados con la ingesta de registros.

    FORWARDER_NAME_auth.conf: usa este archivo para definir las credenciales de autorización.

  3. Modifica los archivos para incluir la configuración de tu instancia de reenviador.

    Para obtener información sobre los ajustes de cada tipo de mecanismo de ingesta, como Splunk o Syslog, consulta Definir tipos de datos en el archivo de configuración. Para obtener información sobre cómo personalizar cada atributo, como la compresión de datos o el almacenamiento en búfer en disco, consulta Configurar atributos clave en el archivo de configuración.

  4. Asegúrate de que haya una entrada para cada entrada en el archivo FORWARDER_NAME_auth.conf, aunque la entrada no tenga los detalles de autenticación correspondientes. Es necesario para asignar los datos correctamente.

El forwarder aplicará automáticamente los cambios que se hagan en el archivo de configuración en un plazo de cinco minutos.

Configuraciones de ejemplo

Puede usar los siguientes archivos de configuración como plantillas para crear los suyos.

Configuración de ejemplo de dos archivos

Este sistema de dos archivos almacena las credenciales de autenticación en un archivo independiente para mejorar la seguridad. Puedes almacenar el archivo FORWARDER_NAME.conf en un repositorio de control de versiones o en cualquier sistema de gestión de configuración abierto. Puedes almacenar el archivo FORWARDER_NAME_auth.conf directamente en la máquina física o virtual que ejecuta el reenviador.

En el siguiente código de ejemplo se muestra el formato de los archivos de configuración de un reenviador.

El archivo FORWARDER_NAME.conf

output:
  url: {region}-chronicle.googleapis.com (for example: us-chronicle.googleapis.com)
  use_dataplane : true
  project_id: PROJECT_ID
  region: {region} (for example: {us})
  identity:
    identity:
    collector_id: COLLECTOR_ID \
    customer_id: CUSTOMER_ID \

collectors:
  - syslog:
      common:
        enabled: true
        data_type: "WINDOWS_DHCP"
        data_hint:
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      tcp_address: 0.0.0.0:10514
      udp_address: 0.0.0.0:10514
      connection_timeout_sec: 60
      tcp_buffer_size: 524288
  - 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
      connection_timeout_sec: 60
      tcp_buffer_size: 524288

El archivo FORWARDER_NAME_auth.conf

output:
  identity:
    secret_key: |
      {
        "type": "service_account",
        "project_id": "PROJECT_ID" \,
        "private_key_id": "PRIVATE_KEY_ID" \,
        "private_key": "-----BEGIN PRIVATE KEY-----\\"PRIVATE_KEY" \n-----END PRIVATE KEY-----\n",
        "client_email": "CLIENT_EMAIL" \,
        "client_id": "CLIENT_ID" \,
        "auth_uri": "https://accounts.google.com/o/oauth2/auth",
        "token_uri": "https://oauth2.googleapis.com/token",
        "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
        "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/example-account-1%40example-account.iam.gserviceaccount.com"
      }

collectors:
  - syslog:
  - syslog:
      certificate: "../forwarder/inputs/testdata/localhost.pem"
      certificate_key: "../forwarder/inputs/testdata/localhost.key"

Configuración de ejemplo de un solo archivo

output:
  url: us-chronicle.googleapis.com
  use_dataplane: true
  project_id: PROJECT_ID
  region: us
    identity:
    collector_id: COLLECTOR_ID \
    customer_id: CUSTOMER_ID \
    secret_key: |
      {
        "type": "service_account",
        "project_id": "PROJECT_ID" \,
        "private_key_id": "PRIVATE_KEY_ID" \,
        "private_key": "-----BEGIN PRIVATE KEY-----\ "PRIVATE_KEY" \n-----END PRIVATE KEY-----\n",
        "client_email": "CLIENT_EMAIL" \,
        "client_id": "CLIENT_ID" \,
        "auth_uri": "https://accounts.google.com/o/oauth2/auth",
        "token_uri": "https://oauth2.googleapis.com/token",
        "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
        "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/malachite-test-1%40malachite-test.iam.gserviceaccount.com"
      }

collectors:
  - syslog:
      common:
        enabled: true
        data_type: "WINDOWS_DHCP"
        data_hint:
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      tcp_address: 0.0.0.0:10514
      udp_address: 0.0.0.0:10514
      connection_timeout_sec: 60
      tcp_buffer_size: 524288
  - 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
      connection_timeout_sec: 60
      certificate: "../forwarder/inputs/testdata/localhost.pem"
      certificate_key: "../forwarder/inputs/testdata/localhost.key"
      tcp_buffer_size: 524288

Convertir de un sistema de un solo archivo a un sistema de dos archivos

Si estás usando un solo archivo de configuración y quieres cambiar al sistema de dos archivos, haz lo siguiente:

  1. Crea una copia del archivo de configuración.

  2. Guarda un archivo como FORWARDER_NAME.conf y elimina las credenciales de autorización del archivo.

  3. Guarda el otro archivo como FORWARDER_NAME_auth.conf y elimina todos los datos que no sean de autorización del archivo. Puedes usar la configuración de ejemplo como referencia. Asegúrate de seguir las convenciones de nomenclatura y otras directrices mencionadas en la sección Personalizar las configuraciones.

Definir tipos de datos en el archivo de configuración

En las siguientes secciones se explica cómo configurar el reenviador de Google SecOps para que ingiera diferentes tipos de datos, que se reenvían a la instancia de Google SecOps.

Datos de Splunk

Puede configurar el reenviador de Google SecOps para que reenvíe sus datos de Splunk a Google SecOps. Google Cloud configura el reenviador de Google SecOps con la siguiente información para reenviar sus datos de Splunk:

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

  • Consultas de Splunk para generar datos de cada uno de los tipos de datos obligatorios (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
  • Facilita las credenciales de tu cuenta de Splunk al reenviador de Google SecOps. Para ello, crea un archivo creds.txt.

Para usar un archivo creds.txt, sigue estos pasos:

  1. Crea un archivo local para tus credenciales de Splunk y llámalo creds.txt.

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

    cat creds.txt

myusername
mypassword

  3. Para usar el reenviador de Google SecOps y acceder a una instancia de Splunk, copia el archivo creds.txt en el directorio de configuración (el mismo directorio en el que se encuentran los archivos de configuración).

    Linux

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

    Windows

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

  4. Comprueba que el archivo creds.txt se encuentre en el directorio correspondiente:

    Linux

      ls /opt/chronicle/config

    Windows

    ls c:/opt/chronicle/config

Datos de syslog

Un reenviador puede funcionar como servidor Syslog. Puede configurar cualquier servidor que admita el envío de datos de Syslog a través de una conexión TCP o UDP para que reenvíe sus datos al reenviador de Google SecOps. Puedes controlar los datos que el servidor envía al reenviador, y este puede reenviar los datos a Google SecOps.

El archivo de configuración FORWARDER_NAME.conf (proporcionado porGoogle Cloud) especifica qué puertos se deben monitorizar para cada tipo de datos reenviados (por ejemplo, el puerto 10514). De forma predeterminada, el reenviador de Google SecOps acepta conexiones TCP y UDP.

Puedes personalizar el tamaño del búfer TCP. El tamaño predeterminado del búfer TCP es de 64 KB. El valor predeterminado y recomendado de connection_timeout es de 60 segundos. La conexión TCP se termina si está inactiva durante más de 60 segundos.

Configurar rsyslog

Para configurar rsyslog, debe especificar un destino para cada puerto (por ejemplo, para cada tipo de datos). En los siguientes ejemplos se muestra la configuración de destino de rsyslog:

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

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

Para obtener más información, consulta la documentación de tu sistema.

Habilitar TLS para configuraciones de Syslog

Puedes habilitar TLS para la conexión Syslog al reenviador de Google SecOps. En el archivo de configuración del reenviador (FORWARDER_NAME.conf), especifica la ubicación del certificado y de la clave del certificado que hayas generado, tal como se muestra en el siguiente ejemplo. Puedes crear un directorio certs en el directorio configuration y almacenar los archivos de certificado en él.

Linux:

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

Windows:

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, modifique el archivo de configuración del reenviador (FORWARDER_NAME.conf) de la siguiente manera:

Linux:

 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: "/opt/chronicle/external/certs/client_generated_cert.pem"
   certificate_key: "/opt/chronicle/external/certs/client_generated_cert.key"
   minimum_tls_version: "TLSv1_3"

Windows:

  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"

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.

Datos de archivo

Un recolector de archivos está diseñado para obtener registros de un archivo que está vinculado al contenedor Docker. Puedes usar esta opción si quieres subir manualmente los registros de un solo archivo de registro.

Inicia el reenviador de Google SecOps desde el contenedor de Docker para asignar el volumen de carga al contenedor:

Linux

     docker run 

       --detach 

       --name cfps 

       --log-opt max-size=100m 

       --log-opt max-file=10 

       --net=host 

       -v /opt/chronicle/config:/opt/chronicle/external 

       -v /var/log/crowdstrike/falconhostclient:/opt/chronicle/edr 

       gcr.io/chronicle-container/cf_production_stable

Windows

  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/falconhostclient:c:/opt/chronicle/edr `
     gcr.io/chronicle-container/cf_production_stable_windows

Puedes añadir varios puertos usando varias opciones o varios intervalos. Por ejemplo, -p 3001:3000 -p 2023:2022 o -p 7000-8000:7000-8000. Los números de puerto proporcionados en el código de ejemplo son ejemplos. Sustituye los números de puerto según tus necesidades.

Según el ejemplo, puede modificar la configuración del reenviador de Google SecOps (archivo FORWARDER_NAME.conf) de la siguiente manera:

Linux

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

Windows

 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/sample.txt
       filter:

El archivo sample.txt debe estar en la carpeta /var/log/crowdstrike/falconhostclient.

Configuraciones de marcas

skip_seek_to_end (booleano): esta marca tiene el valor false de forma predeterminada y la entrada de archivo solo envía nuevas líneas de registro como entrada. Si se define este valor como true, se volverán a enviar todas las líneas de registro anteriores durante los reinicios del reenviador. Esto provoca que se dupliquen los registros. Definir esta marca como true es útil en determinadas situaciones (por ejemplo, durante interrupciones), ya que al reiniciar el reenviador se vuelven a enviar las líneas de registro que faltan.

poll (booleano): el recopilador de archivos usa la biblioteca Tail para comprobar si hay cambios en el sistema de archivos. Si se asigna el valor true a esta marca, la biblioteca Tail usará el método de sondeo en lugar del método de notificación predeterminado.

Datos de paquetes

El reenviador de SecOps de Google puede capturar paquetes en lugar de entradas de registro directamente desde una interfaz de red.

Sistemas Linux

El reenviador de Google SecOps puede capturar paquetes mediante libcap en Linux. Para obtener más información sobre libcap, consulta la página del manual de Linux de libcap.

En lugar de entradas de registro, se capturan paquetes de red sin procesar y se envían a Google SecOps. Esta captura se limita a una interfaz local. Para habilitar la captura de paquetes en tu sistema, ponte en contacto con el equipo de Asistencia de Google SecOps.

Google SecOps configura el reenviador de Google SecOps con la expresión del filtro de paquetes de Berkeley (BPF) que se usa al capturar paquetes (por ejemplo, el puerto 53 y no localhost). Para obtener más información, consulta Filtros de paquetes de Berkeley.

Sistemas Windows

El reenviador de Google SecOps puede capturar paquetes mediante Npcap en sistemas Windows.

En lugar de entradas de registro, se capturan paquetes de red sin procesar y se envían a Google SecOps. Esta captura se limita a una interfaz local. Para configurar tu reenviador de Google SecOps para la captura de paquetes, ponte en contacto con el equipo de Asistencia de Google SecOps.

Requisitos de un reenviador de PCAP de captura de paquetes:

  • Instala Npcap en el host de Microsoft Windows.

  • Concede privilegios de administrador o de root al reenviador de Google SecOps para monitorizar la interfaz de red.

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

Para configurar un reenviador PCAP, Google Cloud necesita el GUID de la interfaz que se usa para capturar paquetes. Ejecuta getmac.exe en el ordenador en el que quieras instalar el reenviador de Google SecOps (el servidor o el ordenador que escucha en el puerto de span) y envía el resultado a Google SecOps.

También puedes modificar el archivo de configuración. Busca la sección PCAP y sustituye el valor GUID por el GUID obtenido al ejecutar getmac.exe.

Por ejemplo, a continuación se muestra una sección 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

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}

Sección PCAP revisada 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

El getmac.exe de Nombre de transporte empieza por \Device\Tcpip, mientras que la sección pcap comparable empieza por \Device\NPF.

Datos de un tema de Kafka

El reenviador de Google SecOps admite la ingestión de datos directamente desde temas de Kafka. Puedes implementar hasta tres reenviadores y extraer datos del mismo tema de Kafka aprovechando el concepto de grupos de consumidores para conseguir un procesamiento eficiente y paralelo. Para obtener más información, consulta Kafka. Para obtener más información sobre los grupos de consumidores de Kafka, consulta Consumidor de Kafka.

En la siguiente configuración de reenviador se muestra cómo configurar el reenviador para ingerir datos de los temas de Kafka.

Linux

El 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: "/path/to/cert.pem"
           certificate_key: "/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

El archivo FORWARDER_NAME_auth.conf

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

Windows

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:

Datos de WebProxy

El reenviador de Google SecOps puede capturar datos de WebProxy directamente desde una interfaz de red.

Linux

El reenviador de Google SecOps puede capturar datos de WebProxy mediante libcap en Linux. Para obtener más información sobre libcap, consulta la página del manual de Linux de libcap. Para habilitar la captura de datos de WebProxy en tu sistema, ponte en contacto con el equipo de Asistencia de Google SecOps.

Modifica la configuración del reenviador de Google SecOps (archivo FORWARDER_NAME.conf) de la siguiente manera:

   - webproxy:
         common:
           enabled : true
           data_type: <Your LogType>
           batch_n_seconds: 10
           batch_n_bytes: 1048576
         interface: any
         bpf: tcp and dst port 80

Windows

El reenviador puede capturar datos de WebProxy mediante Npcap y enviarlos a Google Cloud.

Para habilitar la captura de datos de WebProxy en tu sistema, ponte en contacto con el equipo de Asistencia de Google SecOps.

Antes de ejecutar un reenviador WebProxy, sigue estos pasos:

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

  2. Concede privilegios de administrador o root al reenviador para monitorizar la interfaz de red.

  3. Obtén el GUID de la interfaz usada para capturar los paquetes de WebProxy.

    Ejecuta getmac.exe en el equipo en el que quieras instalar el reenviador de Google SecOps y envía el resultado a Google SecOps. También puedes modificar el archivo de configuración. Busca la sección WebProxy y sustituye el GUID que se muestra junto a la interfaz por el GUID que aparece después de ejecutar getmac.exe.

    Modifica el archivo de configuración del reenviador de Google SecOps (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

Configurar atributos de clave en el archivo de configuración

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

Parámetro Descripción
data_type El tipo de datos de registro que puede recoger y procesar el recopilador.
metadata Metadatos que anulan los metadatos globales.
max_file_buffer_bytes Número máximo de bytes que se pueden acumular en el búfer de disco o de archivo. El valor predeterminado es 1073741824, que equivale a 1 GB.
max_memory_buffer_bytes Número máximo de bytes que se pueden acumular en el búfer de memoria. El valor predeterminado es 1073741824, que equivale a 1 GB.
write_to_disk_dir_path Ruta que se va a usar para el archivo o el búfer de disco.
write_to_disk_buffer_enabled Si true, se usa el búfer de disco en lugar del búfer de memoria. El valor predeterminado es false.
batch_n_bytes Número máximo de bytes que puede acumular el recopilador antes de que los datos se agrupen en lotes. El valor predeterminado es 1048576, que es 1 MB.
batch_n_seconds Número de segundos transcurridos los cuales se agrupan los datos recogidos por el recolector. El valor predeterminado es 11 segundos.
data_hint Formato de datos que puede recibir el recolector (normalmente, el encabezado del archivo de registro que describe el formato).

Para ver una lista completa de los parámetros que se usan en el archivo de configuración, consulta los campos de configuración de reenviador y de recogedor.

Compresión de datos

De forma predeterminada, la compresión de registros está inhabilitada. Habilitar la compresión de registros puede reducir el consumo de ancho de banda. Sin embargo, habilitar la compresión de registros también puede aumentar el uso de la CPU. Evalúa la compensación en función de tu entorno y de los datos de registro.

Para habilitar la compresión de registros, asigna el valor compression al campo true en el archivo de configuración del reenviador de Google SecOps, tal como se muestra en el siguiente ejemplo:

El 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",
...
    }

Almacenamiento en búfer en el disco

El almacenamiento en búfer en el disco te permite almacenar en búfer los mensajes pendientes en el disco, en lugar de en la memoria.

Puedes configurar el almacenamiento en búfer de memoria automático para usar un búfer compartido dinámicamente entre los recolectores, lo que permite gestionar mejor los picos de tráfico. Para habilitar el búfer compartido dinámicamente, añade lo siguiente a la configuración del forwarder:

auto_buffer:
  enabled: true
  target_memory_utilization: 80

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

Si ejecutas el reenviador con Docker, te recomendamos que montes un volumen independiente del volumen de configuración por motivos de aislamiento. Además, cada entrada debe aislarse con su propio directorio o volumen para evitar conflictos.

Ejemplo de configuración

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

collectors:
- syslog:
    common:
      write_to_disk_buffer_enabled: true
      # /buffers/NIX_SYSTEM is part of the external mounted volume for the
forwarder
      write_to_disk_dir_path: /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

Filtros de expresiones regulares

Los filtros de expresiones regulares te permiten filtrar registros buscando patrones en los datos de registro sin procesar. Los filtros utilizan la sintaxis de RE2. Los filtros deben incluir una expresión regular y, opcionalmente, definir un comportamiento cuando haya una coincidencia.

El comportamiento predeterminado en una coincidencia es block. Puede especificar filtros con allow comportamiento. Si especifica un filtro allow, el reenviador bloquea los registros que no coincidan con al menos un filtro allow.

Se puede definir un número arbitrario de filtros. Los filtros Block tienen prioridad sobre los filtros allow.

Cuando se definen filtros, se les debe asignar un nombre. Los nombres de los filtros activos se comunicarán a Google SecOps a través de métricas de estado del reenviador. Los filtros definidos en la raíz de la configuración se combinan con los filtros definidos a nivel de recopilador. Los filtros a nivel de recopilador tienen prioridad en los casos en los que los nombres entran en conflicto. Si no se define ningún filtro en la raíz ni en el nivel del recopilador, se permitirán todos los registros.

Ejemplo de configuración

En la siguiente configuración de reenvío, 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 bloquean los registros de NIX_SYSTEM que contengan "foo" o "bar", a pesar de allow_filter. Esto se debe a que los filtros usan un operador lógico OR. 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

Etiquetas arbitrarias

Las etiquetas se usan para asociar metadatos personalizados a los registros mediante pares clave-valor. Puede configurar etiquetas para todo un reenviador o para un recopilador específico del reenviador. Si ambos están presentes, las etiquetas a nivel de recolector anulan las etiquetas a nivel de reenviador si las claves se solapan.

Ejemplo de configuración

En la siguiente configuración de reenvío, los pares clave-valor "foo=bar" y "meow=mix" se adjuntan a los registros de WINEVTLOG, y los pares clave-valor "foo=baz" y "meow=mix" se adjuntan a los registros de 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

Espacios de nombres

Puedes usar etiquetas de espacio de nombres para identificar registros de distintos segmentos de red y resolver conflictos de direcciones IP solapadas. Cualquier espacio de nombres configurado para el reenviador aparece con los recursos asociados en la interfaz de usuario de Google SecOps. También puedes buscar espacios de nombres con la función de búsqueda de Google SecOps.

Para obtener información sobre cómo ver los espacios de nombres en la interfaz de usuario de Google SecOps, consulta Espacios de nombres de recursos.

Ejemplo de configuración

En la siguiente configuración de reenvío, los registros de WINEVTLOG se adjuntan al espacio de nombres FORWARDER y los registros de NIX_SYSTEM se adjuntan 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

Opciones de balanceo de carga y alta disponibilidad

Puede configurar el servidor HTTP, el balanceo de carga y las opciones de alta disponibilidad en la sección del servidor del archivo de configuración del reenviador. Estas opciones permiten definir duraciones de tiempo de espera y códigos de estado que se devuelven en respuesta a comprobaciones de estado recibidas en implementaciones basadas en la orquestación y el programador de contenedores, así como en balanceadores de carga.

Usa las siguientes rutas de URL para las comprobaciones de estado, disponibilidad y vivacidad. Los valores de <host:port> se definen en la configuración del forwarder.

  • http://<host:port>/meta/available: comprobaciones de actividad para programadores u orquestadores de contenedores
  • http://<host:port>/meta/ready: comprobaciones de preparación y comprobaciones del estado del balanceador de carga

La siguiente configuración de reenviador es un ejemplo de balanceo de carga y 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 Tiempo durante el que el reenviador devuelve una comprobación de estado o de disponibilidad incorrecta y sigue aceptando conexiones nuevas. También es el tiempo que se espera entre que se recibe una señal para detenerse y que se inicia el cierre del servidor. De este modo, el balanceador de carga tiene tiempo para quitar el reenviador del grupo.
Servidor : drain_timeout El tiempo que espera el reenviador a que las conexiones activas se cierren correctamente por sí solas antes de que las cierre el servidor.
servidor : http : puerto Número de puerto en el que escucha el servidor HTTP las comprobaciones del estado del balanceador de carga. Debe estar 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).
server : http : read_timeout Se usa para ajustar el servidor HTTP. Por lo general, no es necesario cambiar el ajuste predeterminado. Tiempo máximo permitido para leer toda la solicitud, tanto el encabezado como el cuerpo. Puedes definir tanto read_timeout como read_header_timeout.
server : http : read_header_timeout Se usa para ajustar el servidor HTTP. Por lo general, no es necesario cambiar el ajuste predeterminado. Tiempo máximo permitido para leer los encabezados de las solicitudes. El tiempo de espera de lectura de la conexión se restablece después de leer el encabezado.
server : http : write_timeout Se usa para ajustar el servidor HTTP. Por lo general, no es necesario cambiar el ajuste predeterminado. Tiempo máximo permitido para enviar una respuesta. Se restablece cuando se lee un nuevo encabezado de solicitud.
server : http : idle_timeout Se usa para ajustar el servidor HTTP. Por lo general, no es necesario cambiar el ajuste predeterminado. Tiempo máximo que se espera para la siguiente solicitud cuando las conexiones inactivas están habilitadas. Si idle_timeout es cero, se usa el valor de read_timeout. Si ambos son cero, se usa read_header_timeout.
routes : meta : ready_status El código de estado que devuelve el reenviador cuando está listo para aceptar el tráfico en cualquiera de las siguientes situaciones:
  • Se recibe una comprobación de disponibilidad de un programador de contenedores o un orquestador.
  • La comprobación de estado se recibe de un balanceador de carga tradicional.
routes : meta : unready_status El código de estado que devuelve el reenviador cuando no está listo para aceptar tráfico.
routes : meta : available_status El código de estado que devuelve el reenviador cuando se recibe una comprobación de actividad y el reenviador está disponible. Los programadores u orquestadores de contenedores suelen enviar comprobaciones de actividad.

¿Necesitas más ayuda? Recibe respuestas de los miembros de la comunidad y de los profesionales de Google SecOps.