Reenviador de Chronicle para Linux

En este documento, se describe cómo instalar y configurar el servidor de reenvío en Linux. Consulta la herramienta de reenvío de Windows para instalar la herramienta de reenvío en Windows.

El reenvío se usa para enviar registros del entorno del cliente a la instancia de Chronicle. Se usa cuando los clientes quieren enviar los registros directamente a Chronicle y no desean usar los buckets de la nube para transferir datos, o cuando el logtype no tiene transferencia nativa a través de una API de terceros. El reenviador se puede usar como una solución lista para implementar, en lugar de incorporar manualmente la API de transferencia.

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

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.

• RAM: 1 GB para cada tipo de datos recopilados (colector) que Chronicle acepta para la transferencia Por ejemplo, si especificaste 4 colectores diferentes, necesitas 4 GB de RAM para recopilar datos de los cuatro colectores.

• CPU: 2 CPU son suficientes para controlar menos de 10,000 eventos por segundo (EPS) (en 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, sin importar la cantidad de datos que controle el servidor de reenvío de Chronicle. Si necesitas almacenar en búfer los mensajes pendientes en el disco en lugar de la memoria, consulta Almacenamiento en búfer en disco. El reenvío de Chronicle almacena en búfer la memoria de forma predeterminada.

Rangos de direcciones IP de Google

Es posible que necesites abrir el rango de direcciones IP cuando estableces una configuración de reenvío, por ejemplo, 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

Cualquier firewall o proxy autenticado que se encuentre entre Internet y el contenedor del servidor de reenvío de Chronicle requieren reglas que abran el acceso a los siguientes hosts:

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

Personaliza los archivos 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 descargar el archivo de configuración según tus requisitos e incluir información sobre los tipos de registros que se transferirán en la sección de colectores. Si deseas obtener más información sobre los parámetros de configuración, consulta Referencia de los parámetros de configuración.

Configura el servidor de reenvío de Linux

Para configurar el servidor de reenvío de Linux a través de la IU, consulta Administra la configuración de los servidores de reenvío con la IU de Chronicle.

Para configurar el reenviador de Linux de forma manual, sigue estos pasos:

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

2. Descarga el archivo de configuración a través de la IU.

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

   FORWARDER_NAME.conf: Usa este archivo para definir los parámetros de configuración relacionados con la transferencia de registros.

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

4. Modifica los archivos para incluir la configuración de la instancia de reenvío. Usa las muestras que se proporcionan en este documento como referencia.

5. 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. Esto es necesario para asignar los datos correctamente.

El servidor de reenvío aplicará automáticamente cualquier cambio que se realice en el archivo de configuración en un plazo de 5 minutos.

Configuración de ejemplo

En la siguiente muestra de código, se observa 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 Recopilar 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

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"

Estos dos sistemas de archivos te permiten almacenar credenciales de autenticación en un archivo separado para mejorar la seguridad. Puedes almacenar el archivo FORWARDER_NAME.conf en un repositorio de control de versión o en cualquier sistema de administración de configuraciones abierto. Puedes almacenar el archivo FORWARDER_NAME_auth.conf directamente en la máquina física o virtual que ejecuta el reenviador.

Nota: Si ya ejecutas una instancia de Chronicle Forwarder con un solo archivo de configuración, puedes seguir usando ese archivo único para configurar el servidor de reenvío para la recopilación de datos.

Configuración de muestra (archivo único)

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

Si usas un solo archivo de configuración y quieres pasar a ambos sistemas de archivos, haz lo siguiente:

1. Crea una copia de tu configuración existente.
2. Guarda un archivo como 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 sin autorización del archivo. Utiliza 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 que se mencionan en la sección Personaliza los archivos de configuración.

Precaución: No compartas los archivos de configuración fuera de tu organización.

Instala Docker

La instalación de Docker depende del entorno del host. Puedes instalar Docker en diferentes sistemas operativos de host. Google Cloud ofrece documentación limitada para ayudarte a instalar Docker en varias de las distribuciones de Linux más populares. 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, consulta la documentación de Docker.

Una vez que se instala Docker en tu sistema, el proceso de instalación del servidor de reenvío de Chronicle es similar al de cualquier tipo de distribución de Linux.

Para comprobar si Docker está instalado correctamente en tu sistema, ejecuta el siguiente comando (privilegios elevados):

   docker ps
  

La siguiente respuesta indica que Docker se instaló correctamente:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

Comandos útiles de Docker

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

  docker info
  

• El servicio de Docker podría estar inhabilitado de forma predeterminada. Para verificar si está inhabilitada, ejecuta el siguiente comando:

  systemctl is-enabled docker
  

• Para habilitar el servicio de Docker y para iniciarlo de inmediato, ejecuta uno de los siguientes comandos:

  sudo systemctl enable --now docker
  

  sudo systemctl enable /usr/lib/systemd/system/docker.service
  

  Resultado:

  Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /lib/systemd/system/docker.service
  

• Cuando inicies un servidor de reenvío, ejecuta el siguiente comando para configurarlo de modo que se reinicie automáticamente:

  sudo docker run --restart=always `IMAGE_NAME`
  

  IMAGE_NAME es el nombre de la imagen de reenvío.

• Para verificar el estado y los detalles del servicio de Docker, ejecuta el siguiente comando:

  sudo systemctl status docker
  

  Resultado:

  ● docker.service - Docker Application Container Engine
      Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
      Active: active (running) since Sat 2020-07-18 11:14:05 UTC; 15s ago
  TriggeredBy: ● docker.socket
        Docs: https://docs.docker.com
    Main PID: 263 (dockerd)
        Tasks: 20
      Memory: 100.4M
      CGroup: /system.slice/docker.service
              └─263 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
  Jul 18 11:14:05 swarm-kraken dockerd[263]: time="2020-07-18T11:14:05.713787002Z" level=info msg="API listen on /run/docker.sock"
  Jul 18 11:14:05 swarm-kraken systemd[1]: Started Docker Application Container Engine
  

  Si tienes algún problema con Docker, el equipo de asistencia al cliente de Chronicle puede solicitar el resultado de este comando para ayudar y depurar el problema.

Instala el reenviador en Linux

En esta sección, se describe cómo instalar Chronicle Forwarder con un contenedor de Docker en un sistema Linux.

Paso 1: Descarga, transfiere y, luego, instala los archivos de configuración de reenviadores

Chronicle proporciona archivos de configuración de reenviadores específicos para tu sistema operativo (Linux o Windows). Puedes descargar el archivo de configuración según tus requisitos. Después de completar los siguientes pasos, transfiere los archivos de configuración de tu laptop al directorio de reenvío /opt/chronicle/config, que se encuentra en el directorio principal del usuario.

Nota: Puedes especificar el nombre que desees para el directorio. El nombre /config es solo un ejemplo de nombre de directorio. Sin embargo, asegúrate de usar el mismo nombre de directorio en todo momento.

1. Conéctate al host del servidor de reenvío de Linux mediante la 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 del servidor de reenvío de Chronicle:

     mkdir /opt/chronicle/config
   

   Nota: El nombre del directorio, config, es un ejemplo. Puedes especificar cualquier nombre para este directorio. Sin embargo, asegúrate de usar el mismo nombre de directorio cuando ejecutes el comando Docker run.

5. Cambia de directorio.

     cd /opt/chronicle/config
   

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

     ls -l
   

Paso 2: Ejecuta el reenviador dentro del contenedor de Docker

Puedes usar los siguientes procedimientos para iniciar el servidor de reenvío de Chronicle por primera vez y actualizar a la versión más reciente 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 mientras tu versión de Docker las admita.

1. Si actualizas, primero limpia las ejecuciones de Docker anteriores. En el siguiente ejemplo, el nombre del contenedor de Docker es cfps. Obtén la imagen de Docker más reciente 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 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 \
   --net=host \
   -v /opt/chronicle/config:/opt/chronicle/external \
   gcr.io/chronicle-container/cf_production_stable
   

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

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 servidor de reenvío

La herramienta de reenvío de Chronicle consta de 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 del reenvío: se actualiza de forma manual después de detener el servidor de reenvío existente y, luego, iniciar una instancia nueva, como se indica en el Paso 2.

Importante: Si no actualizaste la imagen de Docker de Forwarder desde el 1 de abril de 2023, debes hacerlo antes del 31 de octubre de 2023. Esto garantiza que el paquete de reenvíos siga recibiendo actualizaciones.

Instala el reenviador detrás de un proxy

En esta sección, se describe cómo instalar el servidor de reenvío de Chronicle detrás de un proxy.

1. Configura tu máquina para usar el proxy.

   1. Agrega las siguientes líneas a tu archivo /etc/resolv.conf:

      nameserver = 10.0.0.1
      nameserver = 10.0.0.2
      

   2. Configura las siguientes variables del entorno:

      $HTTP_PROXY = http://proxy.example.com:80
      $HTTPS_PROXY = https://proxy.example.com:80
      

2. Configurar Docker para usar el proxy

   1. Crea un directorio directo systemd para el servicio de Docker.

      mkdir /etc/systemd/system/docker.service.d
      

   2. Crea un archivo /etc/systemd/system/docker.service.d/http-proxy.conf que agregue las variables de entorno HTTP_PROXY y HTTPS_PROXY.

      [Service]
      Environment="HTTP_PROXY=http://proxy.example.com:80/"
      Environment="HTTPS_PROXY=https://proxy.example.com:80/"
      

   3. Limpia los cambios.

      $ sudo systemctl daemon-reload
      

   4. Verifica que se haya cargado la configuración.

      $ sudo systemctl show --property Environment docker
      Environment=HTTP_PROXY=http://proxy.example.com:80/
      Environment=HTTPS_PROXY=https://proxy.example.com:80/
      

   5. Reinicia Docker.

      $ sudo systemctl restart docker
      

3. Obtén la imagen de Docker del servidor de reenvío de Chronicle más reciente de Google Cloud.

   docker pull gcr.io/chronicle-container/cf_production_stable
   

4. Agrega variables de entorno de proxy para ejecutar el contenedor de reenvío de Chronicle.

   docker run \
   --env HTTP_PROXY="http://proxy.example.com:80/" \
   --env HTTPS_PROXY="https://proxy.example.com:80/" \
   --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
   

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.

Nota: No configures un valor superior a 4 MB para batch_n_bytes.

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:

• 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 necesarios (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.

   Nota: Asegúrate de que las credenciales se almacenen de forma segura. No reenvíes tus credenciales de Splunk a Google Cloud.

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 /opt/chronicle/config/creds.txt
   

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

   ls /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 generado y la clave de certificado propios, como se muestra en el siguiente ejemplo:

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

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

Ten en cuenta los siguientes aspectos:

• 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 de 60 segundos. La conexión TCP se finaliza si la conexión está inactiva durante un tiempo específico.

• 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í.

Nota: Quita el campo udp_address del archivo de configuración FORWARDER_NAME.conf de Chronicle. TLS debe usar TCP para el transporte, por lo que no se puede configurar UDP.

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 \
    --net=host \
    -v /opt/chronicle/config:/opt/chronicle/external \
    -v /var/log/crowdstrike/falconhostclient:/opt/chronicle/edr \
     gcr.io/chronicle-container/cf_production_stable

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

Nota: Crea la configuración para establecer la entrada del archivo como se muestra.

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 libcap en Linux. Para obtener más información sobre libcap, consulta la página del manual de Linux de libcap.

Los paquetes se capturan y se envían a Chronicle en lugar de entradas de registro. La captura de paquetes se controla solo desde una interfaz local. Para habilitar la captura de paquetes en tu sistema, comunícate con el equipo de asistencia de Chronicle.

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

Recopilar datos del tema de Kafka

Puede transferir datos de los temas de Kafka al igual que desde syslog. Los grupos de consumidores se aprovechan para permitirte implementar hasta 3 reenviadores 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

La siguiente configuración de la herramienta de reenvío muestra cómo configurar la herramienta de 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:

Recopila datos de WebProxy

El servidor de reenvío de Chronicle puede capturar datos de WebProxy directamente desde una interfaz de red mediante libcap en Linux. Para obtener más información sobre libcap, consulta la página del manual de Linux sobre libcap. Para habilitar la captura de datos de WebProxy en tu sistema, comunícate con el equipo de asistencia de Chronicle.

Modifica la configuración del servidor de reenvío de Chronicle (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

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 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 en true en el archivo de configuración del servidor 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",
...
    }

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 reenviador o el host subyacente. Ten en cuenta que habilitar el almacenamiento en búfer en el disco puede afectar el rendimiento.

Nota: Si recibes el mensaje de error “Se alcanzó el límite del lote (xxx) y se libera un lote del trabajo pendiente”, aumenta max_file_buffer_bytes a 1 GB o más.

Si el almacenamiento en búfer en el disco está inhabilitado, el servidor de reenvío 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.

Puedes configurar el almacenamiento en búfer de memoria 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 la herramienta de reenvío con Docker, Google recomienda activar un volumen independiente de tu 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
      # /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

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 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 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 algún filtro allow, el reenviador bloqueará los registros que no coincidan con al menos un filtro 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 a través de 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 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 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 un servidor de reenvío completo o dentro de un recopilador específico de un servidor de reenvío. Si se proporcionan ambas, las etiquetas se combinan con las claves del recopilador que tienen prioridad sobre las del servidor de reenvío si las claves se superponen.

Configuración de ejemplo: etiquetas arbitrarias

En la siguiente configuración de reenvío, 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 un servidor de reenvío completo o dentro de un recopilador específico del servidor de reenvío. Si se incluyen ambos, tiene prioridad el espacio de nombres del recopilador específico.

Cualquier espacio de nombres configurado para el servidor de reenvío aparecerá con los recursos 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 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 instale un balanceador de cargas de capa 4 entre la fuente de datos y las instancias del servidor de reenvío. Esto permite que un cliente distribuya la recopilación de registros entre varios servidores de reenvío o que envíe registros a otro servidor de reenvío si alguno falla. Esta función solo es compatible con el tipo de colección syslog.

La herramienta de reenvío de Linux incluye un servidor HTTP integrado que responde a las verificaciones de estado HTTP desde el 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 server 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 el programador de contenedores y las implementaciones basadas en organización, además de los balanceadores de cargas tradicionales.

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.

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

La siguiente configuración de reenvío es un ejemplo de balanceo de cargas 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	La cantidad de tiempo que el servidor de reenvío 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 del grupo.
servidor : Flood_timeout	La cantidad de tiempo que el servidor de reenvío espera a que las conexiones activas se cierren de forma correcta por sí solas 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 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. 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 reenviador cuando no está listo para aceptar tráfico.
rutas : meta : available_status	El código de estado que muestra el servidor de reenvío cuando se recibe una verificación de funcionamiento y el servidor de reenvío está disponible. Los organizadores o programadores de contenedores a menudo envían verificaciones de funcionamiento.

Preguntas frecuentes

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

La herramienta de reenvío de Linux se actualiza de manera constante mediante una secuencia de comandos de shell en la imagen de Docker. Para actualizar la imagen de Docker, ejecuta el servidor de reenvío.

¿Qué es un contenedor de Docker?

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

• Máquinas virtuales: Tienen un espacio con privilegios (kernel de Linux) y un espacio de usuario (todo con el que interactúas: libc, python, ls, tcpdump, etc.).

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

¿Por qué distribuir el 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 ser independiente de Google Cloud y de los clientes. https://cloud.google.com/container-registry/

¿Por qué usar Linux solo para contenedores? ¿Qué ocurre 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?

• El servidor de reenvío de Chronicle usa un solo contenedor, por lo que no es necesario aprender sobre Swarm, la organización ni otros conceptos o comandos avanzados de Docker.