Instala y configura el reenvío en Linux

En este documento, se describe cómo instalar y configurar el reenvío en Linux. Puedes instalar el servidor de reenvío en una variedad de distribuciones de Linux (Debian, Ubuntu, Red Hat, Suse, etc.). 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.

Cómo personalizar los archivos de configuración

Según la información que enviaste antes de la implementación, Google Cloud te proporciona el software de reenvío y los archivos de configuración. Google Cloud adapta los archivos de configuración a la instancia de reenvío de tu red. Si necesitas alterar la configuración, comunícate con el equipo de asistencia de Chronicle.

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 Chronicle.

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

  • CPU: 2 CPU son suficientes para controlar 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, sin importar la cantidad de datos que procese el reenvío de Chronicle. Consulta también el almacenamiento en búfer si necesitas almacenar en búfer los mensajes pendientes en el disco en lugar de la memoria. El reenvío de Chronicle se almacena en búfer de forma predeterminada.

Verifique la configuración del firewall

Si tienes firewalls o proxies autenticados entre el contenedor de reenvío de Chronicle y la Internet, estos requieren reglas para abrir el acceso a los siguientes hosts:

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

Recopila datos de Splunk.

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

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

  • Consultas de Splunk para 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 reenvío de Chronicle.

Crea un archivo local para las credenciales de Splunk y asígnale el nombre creds.txt. Coloca tu nombre de usuario en la primera línea y la contraseña en la segunda línea:

  cat creds-file

  myusername
  mypassword

Para los clientes que usan el 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 que los archivos de configuración). Por ejemplo:

cp creds-file ~/config/creds.txt

Verifique que el archivo creds.txt em&gt esté en la ubicación correcta:

ls ~/config

- 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: admin
      password: letmeinaA1!
      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 utiliza para el ajuste si el requisito es cambiar la frecuencia con la que se consulta el servidor de Splunk cuando el objeto Forwarder se encuentra estable. Además, cuando hay 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 utiliza para ajustar los casos en los que hay un retraso y se necesitan más datos por consulta.

Cambia este parámetro (igual o mayor que) cuando cambies el parámetro mín. Los casos de retraso pueden ocurrir si una llamada de consulta de Splunk tarda más que el valor max_window_size.

Instala Docker

Puedes instalar Docker en una variedad de sistemas operativos host. La instalación real de Docker depende del entorno 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 la documentación pertinente ya está disponible.

Una vez que hayas instalado Docker en tu sistema, el resto del proceso de instalación del servidor de reenvío de Chronicle es idéntico, sin importar la distribución de Linux que uses.

Ejecute el siguiente comando (privilegios elevados) para verificar que Docker esté instalado en su sistema:

# 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 problemas con Docker, la Asistencia de Chronicle podría solicitar el resultado de este comando para ayudarte con la depuración.

Instala la herramienta de reenvío

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

Paso 1: Descarga, transfiere e 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 del vínculo que te proporcionó tu representante de Chronicle a un directorio local de tu laptop (por ejemplo, chronicle). Después de completar los siguientes pasos, transfiere los archivos de configuración de tu laptop al directorio de reenvío ~/config dentro del directorio de inicio del usuario.

  1. Conéctate a tu servidor de reenvío de Linux mediante una terminal.

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

    # adduser <username>

    # passwd <username>

    # usermod -aG wheel <username>

  3. Cambie el directorio al directorio principal del usuario nuevo que ejecutará el contenedor de Docker.

  4. Crea un directorio para almacenar los archivos de configuración de reenvío de Chronicle: # mkdir ~/config

  5. Cambia de directorio

  6. Una vez que se hayan transferido los archivos, confirme que los archivos de configuración se encuentren en el directorio ~/config:

    # ls -l

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

Puedes usar los siguientes procedimientos para iniciar el 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 se deben usar siempre que sean compatibles con tu versión de Docker.

  1. Si vas a realizar la actualización, comienza por limpiar todas las ejecuciones anteriores de Docker. En el siguiente ejemplo, el nombre del contenedor de Docker es cfps y, luego, obtén la imagen de Docker más reciente de Google Cloud con el comando de Docker # que se muestra a continuación.

    # docker stop cfps
    # docker rm cfps
    
  2. Obtenga la última imagen de Docker 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 ~/config:/opt/chronicle/external \
    
      gcr.io/chronicle-container/cf_production_stable
    

Estos comandos también se proporcionan como una secuencia de comandos de shell denominada run_docker_production_stable.sh.

El contenedor de Docker (y el reenvío de Chronicle) persisten después de que se reinicia el sistema.

Paso 3: Supervisa y administra el reenvío

Los siguientes comandos de Docker te ayudan a supervisar y administrar el reenvío de Chronicle:

  • Revise si el contenedor de Docker está en ejecución:

    docker ps

  • Muestra los registros del contenedor. Ten en cuenta que esto puede generar un volumen de salida significativo, pero es útil para la depuración:

    docker logs cfps

  • Para ver lo que se ejecuta en el contenedor, haga lo siguiente:

    docker top cfps

  • Para detener el contenedor, haz lo siguiente:

    docker stop cfps

Recopilar datos de syslog

El reenvío de Chronicle puede funcionar como un servidor Syslog, lo que significa que puedes configurar cualquier dispositivo o servidor que admita el envío de datos de syslog mediante una conexión TCP o UDP para reenviar sus datos al reenvío de Chronicle. Puedes controlar exactamente los datos que el dispositivo o servidor envía al reenvío de Chronicle. El reenvío de Chronicle puede reenviar los datos a Chronicle.

El archivo de configuración (proporcionado por Google Cloud) especifica qué puertos supervisar para cada tipo de datos reenviados (por ejemplo, puerto 10514). De forma predeterminada, el 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 verificar la sintaxis correcta. En los siguientes ejemplos, se ilustra una configuración de destino rsyslog:

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

  • Tráfico de registro de 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 Chronicle. En el archivo de configuración de reenvío de Chronicle, especifica la ubicación de tu propio certificado generado y tu clave de certificado como se muestra en el siguiente ejemplo:

certificado "/opt/chronicle/external/certs/client_generate_cert.pem"
certificado_clave "/opt/chronicle/external/certs/client_generate_cert.key"

Según el ejemplo que se muestra, la configuración del reenvío de Chronicle se modificaría 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"

El valor de batch_n_bytes no debe exceder los 5 MB.

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

Recopilar datos de archivos

Inicia el 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 ~/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 mapear el volumen de carga al contenedor.

A partir de este ejemplo, podrías modificar la configuración de reenvío de Chronicle 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
       filter:

Recopilar datos de paquetes

El reenvío de Chronicle puede capturar paquetes directamente desde una interfaz de red mediante libpcap en Linux. 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. Si deseas habilitar la captura de paquetes para tu sistema, comunícate con el equipo de asistencia de Chronicle.

Google Cloud configura el reenviador de Chronicle con la expresión de filtro de paquetes de Berkeley (BPF) que se usa cuando se capturan paquetes (por ejemplo, puerto 53 y no localhost).

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 podría causar un aumento en el uso de CPU. La compensación entre el uso de CPU y el ancho de banda depende de muchos factores, como el tipo de datos de registro, la compresión de esos datos, la disponibilidad de ciclos de CPU en el host que ejecuta el 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 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 de forma correcta y generan un uso mayor de la CPU.

La compresión de registros está inhabilitada de forma predeterminada. Habilitar la compresión de registros puede reducir el consumo del ancho de banda. Sin embargo, habilitar la compresión de registro también puede aumentar el uso de CPU. Ten en cuenta la compensación.

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

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
      secret_key: |
        {
          "type": "service_account",
...

Almacenamiento en búfer

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

Si ejecutas el objeto Forwarder con Docker, Google recomienda activar un volumen independiente del volumen de configuración para fines de aislamiento. Además, se debe aislar cada entrada 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

Filtros de expresión regular

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

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

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 un bloque (también puedes configurarlo de forma explícita como bloqueo).

Como alternativa, puedes especificar filtros con el comportamiento allow. Si especificas algún filtro de permiso, el objeto de reenvío bloqueará cualquier registro que no coincida con al menos uno de los filtros permitidos.

Es posible definir una cantidad arbitraria de filtros. Los filtros de bloqueo tienen prioridad sobre los filtros de permiso.

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

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 bloquean los registros NIX_System que contienen foo y bar, o están bloqueados, a pesar de allow_filter. Esto se debe a que los filtros usan un operador lógico OR. Todos los registros se procesan hasta que se activa un filtro.

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

Etiquetas arbitrarias

Las etiquetas se usan para adjuntar metadatos arbitrarios a los registros mediante pares clave-valor. Las etiquetas se pueden configurar para un objeto Forwarder completo o dentro de un recopilador específico de un objeto Forwarder. Si se proporcionan ambas, las etiquetas se combinan con las claves de colector que tienen prioridad sobre las claves de reenvío si estas se superponen.

Configuración de ejemplo: etiquetas arbitrarias

En la siguiente configuración de Forwarder, los pares de clave &'foo=bar 'meow=mix' están adjuntos a los registros de WINEVTLOG, y los pares 'foo=baz' y'meow=mix' y los de NIX_System.

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

Espacios de nombres

Usa etiquetas de espacio de nombres para identificar los registros de distintos segmentos de red y quita la superposición de direcciones IP. Puedes configurar una etiqueta de espacio de nombres para un objeto Forwarder completo o dentro de un colector específico del objeto Forwarder. Si se incluyen ambos, el espacio de nombres específico del colector tiene prioridad.

Cualquier espacio de nombres configurado para la clase Forwarder 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 más información sobre cómo ver los espacios de nombres en la interfaz de usuario de Chronicle, consulta aquí.

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

Entrada de Kafka

Puede transferir datos desde temas de Kafka del mismo modo que lo hace para 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 sobre los grupos de consumidores de Kafka, consulte la siguiente documentación: 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 temas de Kafka:

collectors:
- kafka:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      username: user
      password: password
      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

Balanceo de cargas y alta disponibilidad

El 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 la fuente de datos y las instancias de reenvío. Esto le permite a un cliente distribuir la recopilación de registros entre varios servidores de reenvío o enviar 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 apagado 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 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 en las implementaciones basadas en organización, así como de balanceadores de cargas tradicionales.

Use las siguientes rutas de URL para las verificaciones de estado, de preparación y de funcionamiento. Los valores de <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 preparación y de estado del balanceador de cargas tradicional.

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 objeto reenviador 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 la recepción de una señal de detención y el inicio real del cierre del servidor. Esto permite que el balanceador de cargas tenga tiempo para quitar el reenviador 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 Número de puerto que el servidor HTTP escucha para las verificaciones de estado del balanceador de cargas. El valor debe estar comprendido entre 1024 y 65535.
servidor : http : host 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 de la configuración predeterminada. 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 de la configuración predeterminada. Tiempo máximo permitido para leer encabezados de solicitud. El plazo de lectura de la conexión se restablece luego de que se lee 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. Indica la cantidad máxima de tiempo permitida para enviar una respuesta. y se restablece cuando se lee un nuevo encabezado de solicitud.
servidor : http : inactividad_timeout Se usa para ajustar el servidor HTTP. Por lo general, no es necesario cambiar de la configuración predeterminada. Tiempo máximo de espera para la siguiente solicitud cuando las conexiones inactivas están habilitadas. Si inactividad_timout es cero, se usa el valor de read_timout. Si ambos son cero, se usa Read_header_timeout.
rutas : meta : Ready_status El código de estado que muestra el objeto reenviador cuando está listo para aceptar tráfico en cualquiera de las siguientes situaciones:
  • La verificación de preparación se recibe de 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 muestra el objeto reenviador cuando no está listo para aceptar tráfico.
rutas : meta : available_status El código de estado que muestra el objeto reenviador cuando se recibe una verificación de funcionamiento y está disponible. A menudo, las verificaciones de actividad se envían mediante organizadores o programadores de contenedores, como Kubernetes.

Preguntas frecuentes

¿Qué es un contenedor de Docker?

  • Los contenedores de Docker, como las máquinas virtuales, 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.).

  • Contenedores: solo tienen un espacio de usuario (todo lo que interactúas con libc, Python, ls, tcpdump, etc.) y se basa en el espacio de privilegios del host.

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

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

¿Por qué elegir solo Linux para los contenedores? ¿Qué ocurre con Windows?

  • Primero, los contenedores se desarrollaron para Linux y están listos para la producción.

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

¿Necesitas aprender comandos avanzados de Docker?

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