Se usó la API de Cloud Translation para traducir esta página.

Forwarder de Google Security Operations para Windows en Docker

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

Requisitos del sistema

Las siguientes son recomendaciones generales. Si deseas obtener recomendaciones específicas para tu sistema, comunícate con el equipo de asistencia de Google Security Operations.

Versión de Windows Server: El servidor de reenvío de Google Security Operations es compatible con Microsoft Windows Server 2022.
RAM: 1.5 GB para cada tipo de registro recopilado Por ejemplo, detección y respuesta de extremos (EDR), DNS y DHCP son tipos de registro diferentes. Necesitarías 4.5 GB de RAM para recopilar los datos de los tres. Para obtener una lista de los tipos de registros y los analizadores predeterminados admitidos, consulta Analizadores predeterminados admitidos.
CPU: 2 CPU son suficientes para manejar menos de 10,000 eventos por segundo (EPS) en total en todos los tipos de datos. Si deseas enviar más de 10,000 EPS, se necesitan de 4 a 6 CPU.
Disco: 100 MB de espacio en disco es suficiente, sin importar cuántos datos controle el servidor de reenvío de Google Security Operations. Puedes almacenar el disco en el búfer si agregas los parámetros write_to_disk_buffer_enabled y write_to_disk_dir_path en el archivo de configuración.

Por ejemplo:
```
- <collector>:
     common:
         ...
         write_to_disk_buffer_enabled: true
         write_to_disk_dir_path: directory_path 
         ...
```

Rangos de direcciones IP de Google

Es posible que necesites que el rango de direcciones IP se abra cuando establezcas una configuración del servidor de reenvío de Google Security Operations, por ejemplo, cuando establezcas la configuración de tu firewall. Google no puede proporcionar una lista específica de direcciones IP. Sin embargo, puedes obtener rangos de direcciones IP de Google.

Verifica la configuración del firewall

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

Tipo de conexión	Destino	Puerto
TCP	malachiteingestion-pa.googleapis.com	443
TCP	asia-northeast1-malachiteingestion-pa.googleapis.com	443
TCP	asia-south1-malachiteingestion-pa.googleapis.com	443
TCP	asia-southeast1-malachiteingestion-pa.googleapis.com	443
TCP	australia-southeast1-malachiteingestion-pa.googleapis.com	443
TCP	europe-malachiteingestion-pa.googleapis.com	443
TCP	europe-west2-malachiteingestion-pa.googleapis.com	443
TCP	europe-west3-malachiteingestion-pa.googleapis.com	443
TCP	europe-west6-malachiteingestion-pa.googleapis.com	443
TCP	europe-west12-malachiteingestion-pa.googleapis.com	443
TCP	me-central1-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

Puedes verificar la conectividad de red a Google Cloud con los siguientes pasos:

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

Ejecuta el siguiente comando.

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

El comando muestra que TcpTestSucceeded es true.

Por ejemplo:

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

Instalar Docker en Microsoft Windows

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

Ventajas del servidor de reenvío de Google Security Operations con un contenedor:

Mejor seguridad por aislamiento:
- El entorno y los requisitos del cliente no afectan al agente de reenvío de Google Security Operations.
- El entorno y los requisitos del servidor de reenvío de Google Security Operations no afectan al cliente.
- El mecanismo de distribución de contenedores ya existe y puede ser independiente y privado para Google Cloud y los clientes. Para obtener más información, consulta Artifact Registry.

Completa los siguientes pasos en Microsoft Windows Server Core 2022.

Habilita la función de contenedor de Microsoft Windows.
```
Install-WindowsFeature containers -Restart
```

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

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

.\install-docker-ce.ps1

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

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

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

Configura el servidor de reenvío de Google Security Operations

Si deseas configurar el servidor de reenvío de Google Security Operations para Windows en Docker, consulta Cómo administrar la configuración de los servidores de reenvío mediante la IU de Google Security Operations.

Cuando configures el servidor de reenvío de Google Security Operations, asegúrate de que todas las rutas de acceso del servidor de reenvío comiencen con el prefijo “c:”.

El servidor de reenvío de Google Security Operations aplicará automáticamente cualquier cambio realizado en el archivo de configuración en un plazo de 5 minutos.

Si quieres recopilar datos de paquetes con el servidor de reenvío de Google Security Operations para Windows en Docker, consulta Cómo recopilar datos de paquetes.

Ejecuta el servidor de reenvío de Google Security Operations dentro del contenedor de Docker

Si quieres actualizar el servidor de reenvío de Google Security Operations, comienza por limpiar las ejecuciones de Docker anteriores. En el siguiente ejemplo, el nombre del contenedor de Docker es cfps.
```
docker stop cfps

docker rm cfps
```
Obtén la imagen de Docker más reciente de Google Cloud con este comando de extracción de Docker.
```
docker pull gcr.io/chronicle-container/cf_production_stable_windows
```
Inicia el servidor de reenvío de Google Security Operations desde el contenedor de Docker.
```
docker run `
--detach `
--name cfps `
--restart=always `
--log-opt max-size=100m `
--log-opt max-file=10 `
-p 10514:10514 `
-v C:\config\:C:/opt/chronicle/external `
gcr.io/chronicle-container/cf_production_stable_windows
```
Puedes agregar varios puertos mediante múltiples opciones o varios rangos. Por ejemplo, -p 3001:3000 -p 2023:2022 o -p 7000-8000:7000-8000.

Nota: Los números de puerto proporcionados en el código de muestra son ejemplos. Debes reemplazar los números de puerto según tus requisitos.

Ver registros de reenviadores

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

  sudo docker logs cfps

Para ver la ruta del archivo en el que se almacenan los registros, ejecuta el siguiente comando:

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

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

  sudo docker logs cfps -f

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

  sudo docker logs cfps &> logs.txt

Desinstala el servidor de reenvío de Google Security Operations

Los siguientes comandos de Docker te permiten detener, desinstalar o quitar el servidor de reenvío de Google Security Operations.

Este comando detiene el contenedor de reenvío de Google Security Operations:

  docker stop cfps

Este comando quita el contenedor de reenvío de Google Security Operations:

  docker rm cfps

Actualiza el servidor de reenvío de Google Security Operations

El servidor de reenvío de Google Security Operations para Windows en Docker se actualiza constantemente con una secuencia de comandos de shell en la imagen de Docker, por lo que no es necesario proporcionar ningún ejecutable.

Recopilar datos

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

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

Recopila datos de Splunk

Puedes configurar el servidor de reenvío de Google Security Operations para que reenvíe tus datos de Splunk a Google Security Operations. Google Cloud configura el servidor de reenvío de Google Security Operations 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).
Realizar consultas de Splunk a fin de generar datos para cada uno de los tipos de datos requeridos (por ejemplo, index=dns)

FORWARDER_NAME.conf
output:
collectors:
  - splunk:
      common:
        enabled: true
        data_type: WINDOWS_DNS
        data_hint: "#fields ts      uid     id.orig_h       id.orig_p       id.resp_h         id.resp_p       proto   trans_id        query   qclass  qclass_name"
        batch_n_seconds: 10
        batch_n_bytes: 819200
      url: https://127.0.0.1:8089
      is_ignore_cert: true
      minimum_window_size: 10s
      maximum_window_size: 30s
      query_string: search index=* sourcetype=dns
      query_mode: realtime

Haz que las credenciales de tu cuenta de Splunk estén disponibles para el servidor de reenvío de Google Security Operations. Para ello, crea un archivo creds.txt.

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

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

Nota: Asegúrate de que las credenciales estén almacenadas de forma segura. No reenvíes tus credenciales de Splunk a Google Cloud.
Coloca tu nombre de usuario en la primera línea y la contraseña en la segunda línea:
```
cat creds.txt

myusername
mypassword
```
Si deseas usar el servidor de reenvío de Google Security Operations para acceder a una instancia de Splunk, copia el archivo creds.txt en el directorio de configuración (el mismo en el que se encuentran los archivos de configuración). Por ejemplo:
```
cp creds.txt c:/opt/chronicle/config/creds.txt
```
Verifica que el archivo creds.txt esté en la ubicación correcta:
```
ls c:/opt/chronicle/config
```

Recopilar datos de syslog

El servidor de reenvío de Google Security Operations 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 Google Security Operations. Puedes controlar los datos exactos que el dispositivo o el servidor envían al servidor de reenvío de Google Security Operations. El servidor de reenvío de Google Security puede reenviar los datos a esta plataforma.

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

Cómo configurar rsyslog

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

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

Habilitar TLS para configuraciones de syslog

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

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

En función del ejemplo que se muestra, modifica el archivo de configuración del servidor de reenvío de Google Security Operations (FORWARDER_NAME.conf) de la siguiente manera:

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

Algunos puntos importantes para tener en cuenta:

Puedes configurar el tamaño del búfer TCP. El tamaño predeterminado del búfer TCP es de 64 KB.
El valor predeterminado y recomendado para connection_timeout es 60 segundos. Si la conexión está inactiva durante un tiempo específico, se finaliza la conexión TCP.
La versión de TLS mínima se compara con la versión TLS de la solicitud de entrada. La versión 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 certificados en el directorio de configuración y almacenar los archivos de certificados allí.

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.

Usa esta opción si quieres subir los 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 Google Security Operations desde el contenedor de Docker:

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

Puedes agregar varios puertos mediante múltiples opciones o varios rangos. Por ejemplo, -p 3001:3000 -p 2023:2022 o -p 7000-8000:7000-8000.

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

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

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

Parámetros de configuración 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. Configurar esto como true hace que todas las líneas de registro anteriores se vuelvan a enviar durante los reinicios de reenvío. Esto genera una duplicación de registros. Establecer esta marca en true es útil en ciertas situaciones (por ejemplo, durante interrupciones), porque reiniciar el servidor de reenvío vuelve a enviar las líneas de registro faltantes.

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

Recopilar datos de paquetes

En sistemas Windows, el servidor de reenvío de Google Security Operations puede capturar paquetes directamente desde una interfaz de red.

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

Comunícate con el equipo de asistencia de Google Security Operations para actualizar el archivo de configuración del servidor de reenvío de Google Security Operations para admitir la captura de paquetes.

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

Instala Npcap en el host de Microsoft Windows.
Otorga privilegios de administrador o raíz para el reenviador de Google Security Operations para supervisar la interfaz de red.
No se necesitan opciones de línea de comandos.
En la instalación de Npcap, habilita el modo de compatibilidad de WinPcap.

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

De manera alternativa, puedes modificar el archivo de configuración. Localiza la sección PCAP y reemplaza el valor GUID que se muestra junto a la interfaz por el GUID que se muestra al ejecutar getmac.exe.

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

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

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

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

Por último, esta es la sección revisada de PCAP con el nuevo GUID:

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

Recopila datos del tema de Kafka

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

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

Configuración de ejemplo: entrada de Kafka

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

Archivo FORWARDER_NAME.conf

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

Archivo FORWARDER_NAME_auth.conf

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

Recopilar datos de WebProxy

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

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

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

Instala Npcap en el host de Microsoft Windows. Habilita el modo de compatibilidad WinPcap durante la instalación.
Otorga privilegios de administrador o raíz al servidor de reenvío de Google Security Operations para supervisar la interfaz de red.
Para configurar un servidor de reenvío de WebProxy, Google Cloud necesita el GUID de la interfaz que se usa para capturar los paquetes de WebProxy.

Ejecuta getmac.exe en la máquina en la que deseas instalar el reenvío de Google Security Operations y envía el resultado a Google Security Operations. Como alternativa, puedes modificar el archivo de configuración. Busca la sección WebProxy y reemplaza el GUID que se muestra junto a la interfaz por el que se muestra después de ejecutar getmac.exe.

Modifica el archivo de configuración del servidor de reenvío de Google Security Operations (FORWARDER_NAME.conf) de la siguiente manera:
```
  - webproxy:
    common:
        enabled : true
        data_type: <Your LogType>
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      interface: \Device\NPF_{2E0E9440-ABFF-4E5B-B43C-E188FCAD9734}
      bpf: tcp and dst port 80
```

Personaliza los parámetros de configuración

En la siguiente tabla, se enumeran los parámetros importantes que se usan en el archivo de configuración del servidor de reenvío.

Parámetro	Descripción
data_type	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 búfer de disco o archivo. 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 búfer de archivo o 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 el colector puede acumular y, luego, los datos se agrupan en lotes. El valor predeterminado es `1048576`, que es 1 MB.
batch_n_seconds	La cantidad de segundos después de los cuales los datos que recopila el recopilador se agrupan en lotes. El valor predeterminado es 11 segundos.
data_hint	Formato de datos que puede recibir el recopilador (por lo general, el encabezado del archivo de registro que describe el formato).

Para obtener una lista extensa de los parámetros usados en el archivo de configuración, consulta Campos de configuración de Forwarder y Campos de configuración de 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 Google Security Operations. Sin embargo, la compresión puede causar un aumento en el uso de la CPU. La compensación entre el uso de la 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 los ciclos de la CPU en el host que ejecuta el servidor de reenvío de Google Security Operations y la necesidad de reducir el consumo del ancho de banda de la red.

Por ejemplo, los registros basados en texto se comprimen bien y pueden proporcionar un ahorro de ancho de banda significativo 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. 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. Ten en cuenta las compensaciones.

Para habilitar la compresión de registros, configura el campo compression como true en el archivo de configuración del servidor de configuración de reenvío de Google Security Operations, como se muestra en el siguiente ejemplo:

Archivo FORWARDER_NAME.conf

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

El archivo FORWARDER_NAME_auth.conf

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

Configura el almacenamiento en búfer del disco

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

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

Puedes configurar el almacenamiento en búfer automático del disco para usar un búfer compartido de forma dinámica entre 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 de reenvío:

auto_buffer:
  enabled: true
  target_memory_utilization: 80

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

Si ejecutas el servidor de reenvío de Google Security Operations mediante Docker, Google recomienda activar un volumen separado del volumen de configuración con 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 del disco

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

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

Configura filtros de expresiones regulares

Los filtros de expresiones regulares te permiten filtrar los registros en función de las coincidencias de expresiones regulares con los registros sin procesar.

Los filtros emplean la syntax RE2.

Los filtros deben incluir una expresión regular y, de forma opcional, definir un comportamiento cuando haya una coincidencia. El comportamiento predeterminado de 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 servidor de reenvío de Google Security Operations bloquea los registros que no coinciden 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 filtros, se les debe asignar un nombre. Los nombres de los filtros activos se informarán a Google Security Operations 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 del colector. Los filtros a nivel de colector tienen prioridad en los casos de nombres contradictorios. Si no se definen filtros a nivel de la raíz o del colector, el comportamiento es permitirlos todos.

Configuración de ejemplo: filtros de expresiones regulares

En la siguiente configuración del servidor de reenvío de Google Security Operations, los registros WINEVTLOG que no coinciden con el filtro raíz (allow_filter) están bloqueados. 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 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

Configurar etiquetas arbitrarias

Las etiquetas se usan para adjuntar metadatos arbitrarios a los registros mediante pares clave-valor. Las etiquetas se pueden configurar para todo un servidor de reenvío de Google Security Operations o dentro de un recopilador específico de servidores de reenvío de Google Security Operations. Si se proporcionan ambas, las etiquetas se combinan con las claves del recopilador y tienen prioridad sobre las claves de reenvío de Google Security Operations si las claves se superponen.

Configuración de ejemplo: etiquetas arbitrarias

En la siguiente configuración del servidor de reenvío de Google Security Operations, los pares clave y valor foo=bar y meow=mix se vinculan a registros WINEVTLOG, mientras que los pares clave y valor foo=baz y meow=mix se vinculan 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 segmentos de red distintos y resolver conflictos con las direcciones IP superpuestas. Puedes configurar una etiqueta de espacio de nombres para todo un servidor de reenvío de Google Security Operations o un recopilador específico de este servidor. Si ambos están incluidos, tiene prioridad el espacio de nombres del colector específico.

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

Si quieres obtener información para ver los espacios de nombres en la interfaz de usuario de Google Security Operations, consulta aquí.

Configuración de ejemplo: espacios de nombres

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

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

Configura las opciones de balanceo de cargas y alta disponibilidad

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

El servidor de reenvío de Google Security Operations para Windows en Docker incluye un servidor HTTP integrado que responde a las verificaciones de estado de 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 de Google Security Operations.

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

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

http://<host:port>/meta/available: Son verificaciones de actividad para los organizadores y programadores de contenedores, como Kubernetes.
http://<host:port>/meta/ready: Verificaciones de preparación y verificaciones de estado de balanceadores de cargas tradicionales.

La siguiente configuración del servidor de reenvío de Google Security Operations 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 : graciaful_timeout	La cantidad de tiempo que el servidor de reenvío de Google Security Operations devuelve una verificación de preparación o estado incorrecta y aún acepta conexiones nuevas. Este también es el tiempo de espera entre la recepción de una señal para detenerse y el comienzo real del cierre del servidor. Esto le da tiempo al balanceador de cargas para quitar el servidor de reenvío de Google Security Operations del grupo.
servidor : desvío_timeout	Es la cantidad de tiempo que el servidor de reenvío de Google Security Operations espera a que las conexiones activas se cierren de forma correcta por su cuenta antes de que el servidor las cierre.
servidor : HTTP : puerto	El número de puerto que escucha el servidor HTTP para las verificaciones de estado del balanceador de cargas. Debe estar comprendido 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 del sistema local (0.0.0.0).
servidor : http : read_timeout	Se usa para ajustar el servidor HTTP. Por lo general, no es necesario cambiar de la configuración predeterminada. La cantidad máxima de tiempo permitida para leer toda la solicitud, 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 de la configuración predeterminada. La cantidad máxima de tiempo permitida para leer encabezados de solicitud. La conexión lee, y el plazo 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 de la configuración predeterminada. La cantidad máxima de tiempo permitida para enviar una respuesta. Se restablece cuando se lee un nuevo encabezado de la solicitud.
servidor : http : inactivos_timeout	Se usa para ajustar el servidor HTTP. Por lo general, no es necesario cambiar de la configuración predeterminada. La cantidad máxima de tiempo que se debe esperar a la siguiente solicitud cuando las conexiones inactivas están habilitadas. Si inactivos_timeout es cero, se usa el valor de read_timeout. Si ambos son cero, se usa read_header_timeout.
rutas : meta : ready_status	El código de estado que muestra el servidor de reenvío de Google Security Operations cuando está listo para aceptar el tráfico en cualquiera de las siguientes situaciones: La verificación de preparación se recibe de un organizador o 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 muestra el servidor de reenvío de Google Security Operations cuando no está listo para aceptar tráfico.
rutas : meta : available_status	El código de estado que muestra el servidor de reenvío de Google Security Operations cuando se recibe una verificación de funcionamiento y el servidor de reenvío de Google Security Operations está disponible. Los organizadores y programadores de contenedores como Kubernetes suelen enviar verificaciones de actividad.