Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Instala y configura el servidor de reenvío en Linux

En este documento, se describe cómo instalar y configurar el servidor de reenvío en Linux. Para instalar el servidor de reenvío en Windows, consulta Reenvío de Windows.

El objeto Forwarder se usa para enviar registros del entorno del cliente a la instancia de Chronicle. Esto se usa cuando los clientes quieren enviar los registros directamente a Chronicle y no desean usar los depósitos de la nube para transferir datos, o el tipo de registro no tiene transferencia nativa a través de la API de terceros. El objeto Forwarder se puede usar como una solución lista para implementar en lugar de incorporar de forma manual la API de transferencia.

Puedes instalar el servidor de reenvío en una variedad de distribuciones de Linux, incluidas Debian, Ubuntu, Red Hat y Suse. Google Cloud proporciona el software mediante un contenedor de Docker. Puedes ejecutar y administrar el contenedor de Docker en una máquina física o virtual que ejecute Linux.

Requisitos del sistema

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

  • RAM: 1 GB para cada tipo de datos recopilados. Por ejemplo, la detección y respuesta de extremos (EDR), el DNS y el DHCP son tipos de datos separados. Necesitas 3 GB de RAM para recopilar datos para los tres archivos.

  • CPU: 2 CPU son suficientes para manejar menos de 10,000 eventos por segundo (EPS) (total para todos los tipos de datos). Si esperas reenviar más de 10,000 EPS, aprovisiona de 4 a 6 CPU.

  • Disco: 100 MB de espacio en disco son suficientes, independientemente de la cantidad de datos que controle el servidor de reenvío de Chronicle. Si necesitas almacenar en búfer los mensajes atrasados al disco en lugar de la memoria, consulta Almacenamiento en búfer en disco. El servidor de reenvío de Chronicle almacena en búfer en la memoria de forma predeterminada.

Verifica la configuración del firewall

Cualquier firewall o proxy autenticado entre el contenedor de reenvío de Chronicle y la Internet requieren reglas para abrir el acceso a los siguientes hosts:

Tipo de conexión Destino Puerto
TCP malachiteingestion-pa.googleapis.com 443
TCP malachiteingestion-europe-backstory.googleapis.com 443
TCP malachiteingestion-asia-southeast1-backstory.googleapis.com 443
TCP accounts.google.com 443
TCP gcr.io 443
TCP storage.googleapis.com 443

Cómo personalizar los archivos de configuración

Comunícate con tu representante de Chronicle para obtener las plantillas del archivo de configuración.

Google Cloud adapta los archivos de configuración a la instancia de reenvío con metadatos específicos, como se muestra en la sección de resultados. Puedes modificar los archivos de configuración, según tus requisitos, y, también, incluir información sobre los tipos de registro que se transferirán en la sección de colectores. Si necesitas más información sobre la configuración, comunícate con el equipo de asistencia de Chronicle.

Para configurar el servidor de reenvío de Linux, haz lo siguiente:

  1. Haz una copia de la plantilla del archivo de configuración que se proporciona con el software.

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

    FORWARDER_NAME.conf: Usa este archivo para definir los ajustes de configuración relacionados con la transferencia 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 la instancia de reenvío. Usa las muestras proporcionadas en este documento como referencia.

  4. Asegúrate de que exista una entrada para cada entrada en el archivo FORWARDER_NAME_auth.conf incluso si la entrada no tiene los detalles de autenticación correspondientes. Esta acción es necesaria para asignar los datos correctamente.

Configuración de ejemplo

En la siguiente muestra de código, se muestra el formato de los archivos de configuración para un servidor de reenvío. Para obtener detalles sobre la configuración de cada tipo de mecanismo de transferencia, como Splunk o Syslog, consulta Recopilación de datos.

El archivo FORWARDER_NAME.conf

output:
  url: malachiteingestion-pa.googleapis.com:443
  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
enable_auto_update: false

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"

Este sistema de dos archivos te permite almacenar las credenciales de autenticación en un archivo separado para mayor seguridad. Puedes almacenar el archivo FORWARDER_NAME.conf en un repositorio de control de versión o en cualquier sistema de administració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 servidor de reenvío.

Configuración de muestra (un solo archivo)

output:
  url: malachiteingestion-pa.googleapis.com:443
  identity:
    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
enable_auto_update: false

Si usas el archivo de configuración único y deseas pasar al sistema de archivos dos, haz lo siguiente:

  1. Crea una copia de tu configuración existente.
  2. Guarda un archivo como archivo FORWARDER_NAME.conf y borra las credenciales de autorización del archivo.
  3. Guarda el otro archivo como FORWARDER_NAME_auth.conf y borra todos los datos que no sean de autorización de él. Usa los archivos de configuración de muestra proporcionados en esta guía como referencia.
  4. Asegúrate de seguir la convención de nombres y otros lineamientos mencionados en la sección Cómo personalizar los archivos de configuración.

Instala Docker

La instalación de Docker depende del entorno del host. Puedes instalar Docker en diferentes sistemas operativos del host. Google Cloud proporciona documentación limitada para ayudarte a instalar Docker en varias de las distribuciones más populares de Linux. Sin embargo, Docker es de código abierto y toda la documentación necesaria ya está disponible. Para obtener instrucciones sobre la instalación de Docker, consulte la documentación de Docker.

Una vez que Docker está instalado en tu sistema, el proceso de instalación de reenvío de Chronicle es similar a cualquier tipo de distribución de Linux.

Para verificar si Docker está instalado correctamente en su sistema, ejecute el siguiente comando (privilegios elevados):

   docker ps
  

La siguiente respuesta indica que Docker se instaló correctamente:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

Puedes recopilar información adicional sobre la instalación de Docker con el siguiente comando:

    docker info
  

Si tienes algún problema con Docker, el equipo de asistencia de Chronicle puede solicitar que el resultado de este comando te ayude a depurar el problema.

Instala el servidor de reenvío en Linux

En esta sección, se describe cómo instalar el servidor de reenvío de Chronicle mediante un contenedor de Docker en un sistema Linux.

Paso 1: Descarga, transfiere y, luego, instala los archivos de configuración de reenvío

Google Cloud proporciona archivos de configuración de reenvío específicos para su sistema operativo (Linux o Windows). Descarga los archivos desde el vínculo que te proporcionó tu representante de Chronicle en un directorio local de tu laptop (por ejemplo, en un directorio llamado chronicle). Después de completar los siguientes pasos, transfiere los archivos de configuración de la laptop al directorio /opt/chronicle/config de reenvío dentro del directorio principal del usuario.

  1. Conéctate al host del servidor de reenvío de Linux mediante una terminal.

  2. Crea un usuario nuevo en el host del servidor de reenvío de Linux.

      adduser USERNAME
      passwd USERNAME
      usermod -aG wheel USERNAME
    

  3. Cambia el directorio al directorio principal del usuario nuevo que ejecuta el contenedor de Docker.

  4. Crea un directorio para almacenar los archivos de configuración de reenvío de Chronicle:

      mkdir /opt/chronicle/config
    

  5. Cambiar directorio.

      cd /opt/chronicle/config
    

  6. Una vez que se hayan transferido los archivos de configuración, asegúrate de que se encuentren en el directorio /opt/chronicle/config:

      ls -l
    

Paso 2: Ejecuta el servidor de reenvío dentro del contenedor de Docker

Puedes usar los siguientes procedimientos para iniciar el servidor de reenvío de Chronicle por primera vez y realizar la actualización a la última versión del contenedor de Chronicle:

Las opciones de --log-opt están disponibles desde Docker 1.13. Estas opciones limitan el tamaño de los archivos de registro del contenedor y deben usarse siempre que tu versión de Docker las admita.

  1. Si quieres actualizar, primero limpia todas las ejecuciones anteriores de Docker. En el siguiente ejemplo, el nombre del contenedor de Docker es cfps. Obtén la última imagen de Docker de Google Cloud con el comando docker pull como se muestra a continuación.

    docker stop cfps
    
    docker rm cfps
    
  2. Obtén la imagen de Docker más reciente de Google Cloud:

    docker pull gcr.io/chronicle-container/cf_production_stable
    
  3. Inicia el 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 \
    --net=host \
    -v /opt/chronicle/config:/opt/chronicle/external \
    gcr.io/chronicle-container/cf_production_stable
    

Desinstala la herramienta de reenvío

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

Para detener o desinstalar el contenedor de reenvío, haz lo siguiente:

    docker stop cfps
  

Para quitar el contenedor de reenvío, haz lo siguiente:

    docker rm cfps
  

Actualiza el objeto Forwarder

El servidor de reenvío de Chronicle tiene dos partes y se actualiza de la siguiente manera:

  • Paquete de reenvío: Se actualiza automáticamente y no es necesario reiniciar.

  • Imagen de Docker de reenvío: se actualiza de forma manual después de detener el servidor de reenvío existente y de iniciar una instancia nueva, como se indica en el paso 2.

Recopilar datos

Las siguientes secciones te ayudan a configurar el servidor de reenvío de Chronicle para transferir diferentes tipos de datos, que se reenvían a la instancia de Chronicle.

Recopila datos de Splunk

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

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

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

Debes hacer que las credenciales de tu cuenta de Splunk estén disponibles para el servidor de reenvío de Chronicle. Para ello, crea un archivo creds.txt o agrega los campos user y password en la sección de configuración splunk del archivo FORWARDER_NAME_auth.conf. En los dos procedimientos siguientes, se describe cada método. Usa solo un método. El método recomendado es usar el archivo FORWARDER_NAME_auth.conf.

Para usar el archivo FORWARDER_NAME_auth.conf, agrega los campos user y password a la sección splunk del archivo FORWARDER_NAME_auth.conf, como se muestra a continuación.

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:
  - 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: 10
      maximum_window_size: 30
      user: myusername
      password: mypassword
      query_string: search index=* sourcetype=dns
      query_mode: realtime

minimum_window_size: es el intervalo de tiempo mínimo que se pasa a la consulta de Splunk. El valor predeterminado es 10 segundos. Este parámetro se usa para realizar ajustes si el requisito es cambiar la frecuencia con la que se consulta el servidor de Splunk cuando el reenvío está en estado estable. Además, cuando hay un retraso, la llamada a la API de Splunk se puede realizar varias veces.

maximum_window_size: es el intervalo de tiempo máximo que se pasa a la consulta de Splunk. El valor predeterminado es 30 segundos. Este parámetro se usa para ajustar en casos en los que hay un retraso o si se requieren más datos por consulta.

Cambia este parámetro (igual o mayor que) cuando cambias el parámetro mínimo. Los casos de retraso pueden ocurrir si una llamada de consulta de Splunk tarda más que el tamaño máximo de la ventana máxima.

query_mode: Solo hay un valor válido: realtime. Para obtener más información sobre las búsquedas en tiempo real en Splunk, consulta la documentación de Splunk.

Para usar un archivo creds.txt:

  1. Crea un archivo local para las 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 línea:

    cat creds.txt
    
    myusername
    mypassword
    
  3. Para los clientes que usan el servidor de reenvío de Chronicle a fin de acceder a una instancia de Splunk, copia el archivo creds.txt en el directorio de configuración (el mismo directorio en el que residen los archivos de configuración). Por ejemplo:

    cp creds.txt /opt/chronicle/config/creds.txt
    
  4. Verifica que el archivo creds.txt esté en la ubicación correcta:

    ls /opt/chronicle/config
    

Recopile 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 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, puerto 10514). De forma predeterminada, el agente 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 del sistema para obtener la sintaxis correcta. En los siguientes ejemplos, se ilustra la configuración de destino de rsyslog:

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

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

Habilitar TLS para las configuraciones 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 de tu propio certificado y clave de certificado generados, como se muestra en el siguiente ejemplo:

certificado “/opt/chronicle/external/certs/client_generated_cert.pem”
clave_certificado “/opt/chronicle/external/certs/client_generated_cert.key”

En función del ejemplo que se muestra, modifica el archivo de configuración 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: "/opt/chronicle/external/certs/client_generated_cert.pem"
  certificate_key: "/opt/chronicle/external/certs/client_generated_cert.key"
  minimum_tls_version: "TLSv1_3"

Algunos puntos importantes a tener en cuenta:

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

  • El valor predeterminado y recomendado para connection_timeout es de 60 segundos. La conexión TCP se finaliza si la conexión permanece inactiva durante un tiempo específico.

  • La versión mínima de TLS se verifica 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, TLSv1_3.

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

Cómo recopilar datos de archivos

Úsalo si deseas subir manualmente registros de 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 \
    --net=host \
    -v /opt/chronicle/config:/opt/chronicle/external \
    -v /var/log/crowdstrike/falconhoseclient:/opt/chronicle/edr \
     gcr.io/chronicle-container/cf_production_stable

Este comando de 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:

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

Recopilar datos de paquetes

El servidor de reenvío de Chronicle puede capturar paquetes directamente desde una interfaz de red mediante libcap en Linux. Para obtener más información sobre libcap, consulta libcap: página de manual de Linux.

Los paquetes se capturan y se envían a Chronicle en lugar de a las entradas de registro. La captura de paquetes se maneja solo desde una interfaz local. Si deseas habilitar la captura de paquetes para tu sistema, comunícate con la asistencia de Chronicle.

Google Cloud configura el servidor de reenvío de Chronicle con la expresión del filtro de paquetes (BPF) de Berkeley que se usa cuando se capturan paquetes (por ejemplo, puerto 53 y no localhost). Para obtener más información, consulta los filtros de paquetes de Berkeley.

Recopile datos de temas de Kafka

Puede transferir datos desde los temas de Kafka de la misma forma que lo hace desde syslog. Los grupos de consumidores se aprovechan para permitirte implementar hasta 3 servidores de reenvío 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 lo siguiente: https://docs.confluent.io/platform/current/clients/consumer.html

Configuración de ejemplo: entrada de Kafka

En la siguiente configuración de reenvío, se muestra cómo configurar el reenvío para transferir datos de los temas de Kafka.

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:

Personalizar configuraciones opcionales

Activar o desactivar la compresión de datos

La compresión de registros reduce el consumo de ancho de banda de la red cuando se transfieren registros aChronicle. 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 compresión de esos datos, la disponibilidad de ciclos de CPU en el host que ejecuta el servidor de reenvío y la necesidad de reducir el consumo del ancho de banda de red.

Por ejemplo, los registros basados en texto se comprimen de manera correcta y pueden ahorrar una gran cantidad de ancho de banda con un uso bajo de CPU. Sin embargo, las cargas útiles encriptadas de paquetes sin procesar no se comprimen de forma correcta y generan un mayor uso de CPU.

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 CPU. Ten en cuenta la compensación.

Para habilitar la compresión de registros, configura el campo compresión como true en el archivo de configuración de reenvío de Chronicle 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",
...
    }

Configurar el almacenamiento en búfer en disco

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

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

Si ejecutas el servidor de reenvío con Docker, Google recomienda activar 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.

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

La siguiente configuración incluye la sintaxis para habilitar el almacenamiento en búfer en 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

Establecer filtros de expresiones regulares

Los filtros de expresión regular te permiten filtrar los registros según las coincidencias de expresiones regulares en comparación con los registros sin procesar.

Los filtros usan la sintaxis RE2 que se describe aquí: https://github.com/google/re2/wiki/Syntax.

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

Como alternativa, puedes especificar filtros con el comportamiento allow. Si especificas algún filtro allow, el servidor de reenvío bloqueará los registros que no coincidan con al menos un filtro allow.

Es posible definir una cantidad arbitraria de filtros. Los filtros de bloque tienen prioridad sobre los filtros allow.

Cuando se definen 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 en el nivel de colector. Los filtros de nivel de colector tienen prioridad en los casos de nombres en conflicto. Si no se definen filtros a nivel de raíz o de colector, el comportamiento es permitir todo.

Configuración de ejemplo: filtros de expresión regular

En la siguiente configuración de Forwarder, 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, los registros NIX_SYSTEM que contienen “foo” o “bar” están bloqueados, 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 mediante pares clave-valor. Las etiquetas se pueden configurar para un servidor de reenvío completo o dentro de un colector específico de un servidor de reenvío. Si se proporcionan ambos, las etiquetas se combinan con las claves del colector que tienen prioridad sobre las claves de reenvío si las claves se superponen.

Configuración de ejemplo: etiquetas arbitrarias

En la siguiente configuración de reenvío, las claves y los pares de valor “foo=bar” y “meow=mix” están adjuntos a los registros WINEVTLOG, y los pares de clave y 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 la red y quitar el conflicto de direcciones IP superpuestas. Puedes configurar una etiqueta de espacio de nombres para un servidor de reenvío completo o dentro de un colector específico del servidor de reenvío. Si ambos están incluidos, el espacio de nombres del colector específico tiene prioridad.

Cualquier espacio de nombres configurado para el servidor de reenvío aparece con los elementos asociados en la interfaz de usuario de Chronicle. También puedes buscar espacios de nombres con la función de búsqueda de Chronicle.

Para obtener información sobre cómo ver los espacios de nombres en la interfaz de usuario de Chronicle, consulta aquí.

Ejemplo de configuración: espacios de nombres

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

Configura el balanceo de cargas y las opciones de alta disponibilidad

El servidor de reenvío de Chronicle para Linux se puede implementar en un entorno en el que se instala un balanceador de cargas de capa 4 entre las instancias de origen y de reenvío. Esto permite que un cliente distribuya la recopilación de registros entre varios servidores de reenvío o envíe registros a un servidor de reenvío diferente si uno falla. Esta función solo es compatible con el tipo de colección syslog.

El servidor de reenvío de Linux 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 los registros no se pierdan durante el inicio o el cierre de un servidor de reenvío.

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

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

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

La siguiente configuración de reenvío es un ejemplo para el 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 muestra una verificación de estado o de preparación deficiente y, aun así, acepta conexiones nuevas. Este también es el tiempo de espera entre la recepción de una señal y la inicio del cierre del servidor. Esto le da tiempo al balanceador de cargas para quitar el objeto Forwarder del grupo.
servidor : desvío_timeout La cantidad de tiempo que el servidor de reenvío espera a que las conexiones activas se cierren correctamente por su cuenta antes de que el servidor las cierre.
servidor : http : puerto El número de puerto que el servidor HTTP escucha en las verificaciones de estado del balanceador de cargas. Debe ser un valor entre 1024 y 65535.
servidor : http : host La dirección IP, o 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 cambiar la configuración predeterminada. El tiempo máximo permitido para leer la solicitud completa, tanto el encabezado como el cuerpo. Puedes configurar read_timeout y read_header_timeout.
servidor : http : read_header_timeout Se usa para ajustar el servidor HTTP. Por lo general, no es necesario cambiar la configuración predeterminada. La cantidad máxima de tiempo permitida para leer encabezados de solicitud. La fecha límite para leer 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 cambiar la configuración predeterminada. El tiempo máximo permitido para enviar una respuesta. Se restablece cuando se lee un nuevo encabezado de solicitud.
servidor : http : tiempo_inactividad Se usa para ajustar el servidor HTTP. Por lo general, no es necesario cambiar la configuración predeterminada. Tiempo máximo para esperar la siguiente solicitud cuando las conexiones inactivas están habilitadas. Si inactivo_timeout es cero, se usa el valor de read_timeout. Si ambos son cero, se usa el read_header_timeout.
rutas : meta : estado_listo El código de estado que muestra el servidor de reenvío cuando está listo para aceptar el tráfico en cualquiera de las siguientes situaciones:
  • La verificación de disponibilidad se recibe desde un programador o un programador de contenedores, como Kubernetes.
  • La verificación de estado se recibe de un balanceador de cargas tradicional.
rutas : meta : unready_status El código de estado que se muestra en el reenvío cuando no está listo para aceptar tráfico
rutas : meta : disponible_estado El código de estado que muestra el servidor de reenvío cuando se recibe una verificación de actividad y el servidor de reenvío está disponible Los organizadores o programadores de contenedores, como Kubernetes, suelen enviar verificaciones de funcionamiento.

Preguntas frecuentes

¿Cómo actualizo el servidor de reenvío?

El servidor de reenvío de Windows no se actualiza constantemente, ya que pocos clientes lo utilizan. El servidor de reenvío de Linux se actualiza constantemente a través de una secuencia de comandos de shell en la imagen de Docker, por lo que no es necesario proporcionar ningún ejecutable para esto. Sin embargo, si un cliente abre un caso de ayuda a fin de obtener el último archivo ejecutable de Windows para el servidor de reenvío, el equipo de asistencia le proporciona un archivo EXE al cliente a través del portal de asistencia.

¿Qué es un contenedor de Docker?

  • Los contenedores de Docker son como máquinas virtuales que proporcionan seguridad adicional, aislamiento y administración de recursos.

  • Las máquinas virtuales tienen un espacio con privilegios (kernel de Linux) y un espacio de usuario (todo con lo que interactúas: libc, python, ls, tcpdump, etcétera).

  • Los contenedores solo tienen un espacio de usuario (todo lo que interactúas: libc, Python, ls, tcpdump, etc.) y dependen del espacio privilegiado del host.

¿Por qué distribuir el servidor de reenvío de Chronicle mediante un contenedor?

  • Mayor seguridad mediante el aislamiento:
    • El entorno y los requisitos del cliente no afectan el servidor de reenvío de Chronicle.
    • Los requisitos y el entorno del servidor de reenvío de Chronicle no afectan al cliente.
    • El mecanismo de distribución de contenedores ya existe y puede ser privado y separar para Google Cloud y los clientes. https://cloud.google.com/container-registry/

¿Por qué solo Linux para contenedores? ¿Qué sucede con Windows?

  • Los contenedores se desarrollaron primero para Linux y están listos para la producción.

  • La compatibilidad de Windows con contenedores está en curso. Los contenedores están disponibles para Windows Server 2016 y Windows 10.

¿Necesitas aprender comandos avanzados de Docker?

  • Chronicle Forwarder usa un solo contenedor, por lo que no es necesario aprender sobre los enjambres, la organización, Kubernetes ni otros conceptos o comandos avanzados de Docker.